Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Eclipse, Junit 4, A lot of test cases & Singleton

 
Z Sugiarto
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All,

I have a problem which I found in eclipse, but not in Netbeans. I hope you can help me find a workaround for this.

I have a lot of test cases that requires a singleton the created for the duration of each test case. When I run the test case on its own, it is fine.

Problem is, in Netbeans each test case is executed as a unit. Therefore the singleton instance is not shared from one test case to another - which I reckon is the correct behavior.

However, in Eclipse the test case fails because the singleton implementation is shared between one test case and another.

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?

Thanks for any help.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34084
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Z Sugiarto
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:
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.


Hi,

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
Saloon Keeper
Pie
Posts: 18009
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34084
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18009
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic