Screaming Penguin - Source Does Matter

No, not really.

I am entering this discussion admittedly late but it is still a useful dialog so I thought I would post it.

When using Junit I assumed that the test case class was loaded once and each "test" method was run. This would logically give one test method access to some member variable another test method had established. Logical but not the way Junit works. By design as it turns out Junit instantiates a new instance of the test class for each test method. (This is done for obvious reasons, so that dependencies and execution order cant clobber a test, obvious as to why, debatable as to whether or not it should be done that way. I had planned to have tests check for any required member variables established by a previous test, before executing themselves, yes this would leave it to me to implement but at least would allow the flexibility to do that.)

I did not realize this but just happened to be writing all my tests in the past using a static member block to establish member variables used by all the tests (where I needed such a class member, cases where I did not want to totally instatiate a test object used in multiple tests each time). This was used as a way to centralize test stuff needed for a particular test class across multiple test methods. (The "setUp" and "tearDown" Junit methods are also invoked per each test, so you cant do this type thing there.)

Though Martin Fowler doesnt like the "statics" approach, without really expanding upon why, " Generally it's wise to shy away from statics, but often they're fine in the context of a test run - although I still prefer to shun them".

Mr. Fowler does expand a bit upon a Junit alternative TestSetup which can be used as "A Decorator to set up and tear down additional fixture state. Subclass TestSetup and insert it into your tests when you want to set up additional state once before the tests are run".

As it turns out, and Mr. Folwer also mentions, Cedric doesnt like this Junit behavior (and has written his own testing framework that explicitly does not do this: testNG).

Many of the people that commented on Cedrics post agree with him, many do not. Several of the commenters noted the "static" stuff which is simple and can be used to get around the original Junit issue (yet again many people seem to say "arghhh" to "static", with no reason why).

Overall, after thinking about it more, I have come to the conclusion that it is a good call that Junit did this. There is an alternative in Junit. Its sort of difficult to get there from here and this multiple instances per is NON INTUITIVE (my biggest complaint with it, its the opposite of what a class normally does) but overall I think Junit has gone with the least problematic for the masses approach - and those that want to override can do so in a variety of ways.