RE: [junit] TestCase Dependency Hierarchy
> What test runners do most ordinary folks [and not just theI cannot tell you what "most ordinary folks" use, I am
> junit experts
> who've been using it for years] use most, do those runner
> primarily use
> collectors, and do suites add value to those runners?
just one single of the ordinary folks ;-)
When I started with junit i built my suites by hand which
become more and more annoying (always check that you do not
miss to add a new test)
Currently I work with eclipse' and ant's runner which search
the filesystem for the test to run.
In my first project where I used junit (enhancement of highly
layered legacy code) I felt also the need to have some sort of
test hierarchy. (If some test for the lower layers failed the test
for higher layers failed also). But this need faded away and
did not appear again, so I forgot about it.
I only followed your discussion roughly, but I guess my need
for test hierarchies disappeared because my unit tests
are independent from each other.
This is your example from another mail from you:
> Ok, another example. I have a class that walks a classpath and generatesto
> listener events on things found, I test that. I have a class that listens
> such events to "find" things that match a certain criterion, I test that.If
> the first class fails to send events, then I ought not blame (or dig into)of
> the second for not finding anything. The tests are (I believe) unit tests
> each, without duplication.How would you blame the second for not finding anything?
Do you run this as one or two tests?
The first test could be: are the expected events thrown for
a given classpath? Do not use the second class in this test.
(I guess you have some listener interface: have the test-class
implement this listener interface: "self-shunt")
The second test could be: does the second class react correctly on a given
In this test the event(s) is/are created by the test code and not by the
first class: Do not use the first class to create events in this test.
You do not have test code duplication here but you can run theese test
>So said carlos.manzanares@... on 2003-08-06 --------------------The underlying problem is that you need to initialize the singleton (or toolbox) at some point in time during server startup or application startup. When do you do it? What if you have a messaging system, which may process a message before the first servlet loads?
>I read that article some time ago and certainly was very useful: I've been
>using the Toolbox pattern since then and it works nicely.
>The only problems I've encountered so far while using Toolbox are:
>- when I ported old RMI servers to EJBs I found that the Toolbox was not
>so easy to initialize anymore: it needs to be done in an Application
>Server specific way (e.g.: initialization classes in weblogic) or using
>the init method from a Servlet, none of this alternatives seem to be very
>elegant to me
I agree that placing this in an application server context makes it all the more difficult. One bad thing about application servers: there is no definite application object that starts before everything else.
>- the setup of the Toolbox can become error prone (or at least tedious) inAll the more reason why the toolbox must go. It is a coping mechanism for dealing with many singletons, but not a final solution.
>complex test cases and during refactorings
>Maybe they are experiences you (J.B. Rainsberg) could add to your article
>I have been thinking for a while if there could be any other way to solveI dislike this in principle, because the choice to use a singleton is almost always the wrong choice. In general, I dislike anything that enables poor choices.
>the singleton "testing problem" and the only solution I came across is to
>implement a testing framework where class loading is user-tailored:
>- in the source code there would not be any need to change the singleton
>- the tester class would need to setup the framework so that theInteresting. It could be another good coping strategy. A transition towards a more well-designed system.
>classloader would load a mock class instead of the singleton class
J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
telephone: +1 416 791-8603