Slashdot Mirror

← Back to Stories (view on slashdot.org)

An Early Look at JUnit 4

Posted by ScuttleMonkey on from the still-just-java dept.

An anonymous reader writes "Elliotte Harold, proclaimed 'obsessive code tester', took an early look at JUnit4 and shows how to best utilize the framework in your own projects. Many feel that this is one of the most important third-party Java libraries ever developed. It promises to simplify testing by exploiting Java 5's annotation feature to identify tests rather than relying on subclassing, reflection, and naming conventions."

4 of 147 comments (clear)

  1. Too bad by cached · · Score: 5, Interesting

    After reading this, I noticed it was great but the most obvious omission is a GUI test runner. Fortunately, it is possible that if you want to see a comforting green bar when your tests pass or an anxiety-inducing red bar when they fail. you'll need an IDE with integrated JUnit support such as Eclipse. Neither the Swing nor the AWT test runners will be updated or bundled with JUnit 4.

    --
    +1 funny, -2 overrated. Life isn't fair.
  2. Java 5, JUnit4 by ReformedExCon · · Score: 3, Interesting

    It would be nice if they synchronized the version numbers so that it was obvious which version of JUnit worked with which version of Java.

    I'm looking at the samples and am left scratching my head. I don't see any difference in the various example tests they show. Maybe someone can explain this "annotation" and how it is better (it's certainly more verbose!) than the normal way of doing things.

    --
    Jesus saved me from my past. He can save you as well.
  3. Re:Maybe, but it doesn't work with databases... by prisonercx · · Score: 4, Interesting
    I understand your frustration. One workaround I've seen uses the Spring framework's annoyingly-named AbstractTransactionalDataSourceSpringContextTests. Your test classes subclass that monstrosity, and after each test method is run the transaction is rolled back to avoid mucking up the DB for subsequent tests. When you test DAOs, you have to have a custom method for inserting test data before or during each test. Once you get above the data access layer, you just use your now-tested DAOs.

    It requires you to define the way you get your database connection through Spring, but that abstraction is necessary for unit testing DB-driven apps anyway. On one of my projects, I have one set of bean descriptions for unit testing which connects right to the DB and one set of beans for when the app is running in a Tomcat container. It's not a perfect method, that's for sure, but it allows me to unit test my code pretty painlessly once it's set up.

  4. Check this paper by gustgr · · Score: 4, Interesting

    Some of my professors have developed a tool to help structual testing. JaBUTi (Java Bytecode Unterstanding and Testing) can test java applications and components even it the original java source code isn't available. It is possible to do the structural test through several approachs, like control-flow (all-nodes, all-edges) and data-flow (all-uses, all-potential-uses).

    I have used this tool during some time and it is amazing. It generates graphs of the code you are testing and it can be integrated with junit.

    Check this paper for more details: http://portal.acm.org/citation.cfm?id=1072118.1072 131