An Early Look at JUnit 4

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."

Comments

Too bad

[cached]

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.

Java 5, JUnit4

[ReformedExCon]

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.

Re:Java 5, JUnit4

[Surt]

The @Test annotation allows you to drop the test from your test method name. This is a minor help it:

a) reduces the method name length slightly, there are various tools that aren't up to handling super long method names.

b) more importantly, can simplify your naming conventions

way way way more important is that
extends TestCase

is no longer necessary, which since Java is single inhertiance model now means you can extend something else with your test classes. As one significant example, think about writing tests that extend the tested class, and how that helps to better maintain the protection mechanism.

No doubt about it, this will be a big step forward in JUnits power.

The Holy Grail

[Catamaran]

The Holy Grail of test automation is Automated Test Generation, in other words the ability to have your application record inputs and outputs in a way that can be easily played back or transformed into a test. Pro/Engineer has this capability. Are there other applications that can do that?

Re:I don't know if I am the only one thinking this

[FooAtWFU]

I was actually thinking more Moon Unit, myself.

Useless

[MSBob]

The change that all unit test frameworks need is to address the issue of creating complex setups that your code typically relies upon to execute its tasks properly. Whether it be through mock objects or proper environment setup, at the moment it is the biggest PITA and many, many developers question whether the effort of maintaining those setup fixtures is worth the benefit of unit testing.

Fixtures is something that JUnit has been ignoring since its inception and thus it is much less appealing than it could be if the test fixture dillemma is ever solved.

Re:Maybe, but it doesn't work with databases...

[prisonercx]

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.

mock objects

[willCode4Beer.com]

Interesting you've judged something impossible that thousands of professional developers perform daily.

Using mock objects makes unit testing servlet code pretty easy. Keeping your objects reasonable in size and single purposed in function also simplifies testing. If a servlet is so complex that its hard to test then, that is a sign that it should be broken up and delegate to smaller classes with simpler methods that are easy to test.

JSP's should not have any logic in them, or if they do, it should be trivial. With no logic, there is nothing to test. Move the logic into a servlet (or Action for struts) or for presentation logic, put it in a custom tag. Then you have java that can be validated with the compiler and easily tested.

HttpUnit is very easy to use for testing live web applications but, its reaching beyond the scope of Unit testing and getting into the realm of Acceptance and Integration testing (better tool for qa than a developer).

Stuff in the rights places? Page formatted correctly? Sounds like you want screen capture and image analysis, maybe NASA can help you. JK, really, at some point you just have to look at your pages in the various browsers.

Check this paper

[gustgr]

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