Loading ...
Sorry, an error occurred while loading the content.
 

RE: [junit] TestCase Dependency Hierarchy

Expand Messages
  • bernd
    Hi, ... I cannot tell you what most ordinary folks use, I am just one single of the ordinary folks ;-) When I started with junit i built my suites by hand
    Message 1 of 106 , Aug 1, 2003
      Hi,

      > What test runners do most ordinary folks [and not just the
      > 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?

      I cannot tell you what "most ordinary folks" use, I am
      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 generates
      > listener events on things found, I test that. I have a class that listens
      to
      > 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)
      > the second for not finding anything. The tests are (I believe) unit tests
      of
      > 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
      event?
      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
      independently.

      Bernd
    • J. B. Rainsberger
      ... 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
      Message 106 of 106 , Aug 6, 2003
        >So said carlos.manzanares@... on 2003-08-06 --------------------
        >Hi,
        >
        >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

        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 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) in
        >complex test cases and during refactorings
        >Maybe they are experiences you (J.B. Rainsberg) could add to your article

        All the more reason why the toolbox must go. It is a coping mechanism for dealing with many singletons, but not a final solution.

        >I have been thinking for a while if there could be any other way to solve
        >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
        >code

        I 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 tester class would need to setup the framework so that the
        >classloader would load a mock class instead of the singleton class

        Interesting. It could be another good coping strategy. A transition towards a more well-designed system.


        J. B. Rainsberger,
        President, Diaspar Software Services
        Let's write software that people understand.
        http://www.diasparsoftware.com/
        telephone: +1 416 791-8603
      Your message has been successfully submitted and would be delivered to recipients shortly.