rename RunModeType.REMOTE to RunModeType.IN_CONTAINER

I think that the combination of the terms LOCAL and REMOTE in the RunModeType enum is confusing. RunModeType is attempting to describe where the test runs in relationship to the test runner. In that case, the terms are defensible.

LOCAL = test is local to the test runner (same JVM)
REMOTE = test is remote from the test runner (different JVM)

In the case of LOCAL, the test must use remote communication to invoke the code under test. This is where we overuse the term "remote". The term "remote" implies remote communication, but it's not clear what is remote from the standpoint of the test writer. We are describing internal behavior. And besides, REMOTE isn't entirely accurate since in embedded containers, no remote communication is used.

It's more natural to describe where the test is in relation to the code under test. In that case, local means that the test case stays behind. The other term would be in-container, which may or may not be remote. It's about the packaging. The test is with the test code executing in the container.

I'd like to propose these constants instead:

public enum RunModeType
{
/**

• In LOCAL mode, the @Deployment is processed and deployed to the Container,
• but the test is not executed inside the container. It's local to the test runner.
  */
  LOCAL,

/**

• In IN_CONTAINER mode, the @Deployment is processed and deployed to the container along side the test
• case and the test case is executed inside the container.<br/>
• This is the default mode when none specified.
  */
  IN_CONTAINER
  }

Perhaps I'm just thinking about it wrong, but I just can't get my mind to believe that @RunMode(REMOTE) means that the test case is running in the container. I get how it is technically correct, but human tendency leads me to believe we are going to have to constantly clarify this. @RunMode(IN_CONTAINER) makes it clear that the test is getting relocated to the container.

(I'm even open to changing LOCAL to NORMAL if you think it helps the terminology)