This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Zenikko Sugiarto wrote:Is there away to tell Eclipse to run the test cases one by one?
Or, is there a way to enforce this behavior so that my test cases is not IDE-dependent?
You could write an Ant script and fork it so each test gets it's own JVM. Or you could null out the singleton between tests so there aren't side effects.
Yeah I can write ant or shell script to fork out each test case but I won't be able to see it from the nice GUI JUNIT runner within Eclipse. I want to see the green / red bar!
I ended up modifying the test case to not use the singleton method. I have the classes intended to be singleton instantiated using its constructor on the @beforeClass of each relevant test case. So essentially it becomes a static class for that particular test case.
I was hoping that there's a way to do it in Eclipse. i.e telling Eclipse to run all test classes on separate process / JVM, because really you don't want any dependency between one class to another.
Ideally singleton should exist only for the duration of one test case. I wasn't expecting Eclipse to run all test case under the same process/JVM.
Anyway, problem fixed the hard way, I've got it all under control now - thanks for the reply!
Tim Holloway wrote:Actually, it sounds like what you want is a Junit Test Suite. A Suite is a set of unit tests run in a batch, and Eclipse supports both single and suite testing.
Doesn't the test suite run in a single JVM though? That wouldn't solve the original problem with the singleton.
Hmmmm. There's something that doesn't seem to sit quite right here. The whole concept of a singleton is one object, many users, so tearing a singleton down and reconstructing it for each test sounds questionable. Of course, it could be some sort of state machine-type construct that you want to reset between suites. In that case, I'd probably provide a package-scope object reset method that would release the original singleton instance or reset its internals or whatever. Package-scope because otherwise JUnit couldn't access it, but not public scope to reduce the likelihood that some ignorant person couldn't attempt to use it for non-test purposes.