Your class must have either a run() or a runInSameVM() method without parameters. Optionally, you can have a stop() method, also without parameters. The latter is called before the instance of the class is destroyed. To allow JLoop to instantiate your class, make sure there is either a default constructor or an explicit public constructor without parameters.
Always use JUnitLoop, except you really can't. JUnitLoop is the tool to prefer as it encourages one to write test cases which guarantee sustainable results. JLoop is only more appropriate if you're having a hard time to access the results produced by your code (e.g., if you're creating a UI, a 3D scene or some sound).
JUnitLoop creates a single test suite that runs all tests affected by your recent changes. This has two implications. First, the tests run in a different working directory. If your tests make assumptions about the current working directory (e.g., to load test data), they can fail. To resolve this issue, change the test to be independent of the working directory. Second, the classpath for the test suite is global (i.e., includes more projects compared to running a single test directly). If resources in the classpath overlap (e.g., multiple property files with the same name), the first one that is found will be used. This can also cause trouble.
You can annotate test methods with @Category(Runtime.class) to tell JUnitLoop to not run these test methods. This can, for example, be used for long running methods.