This post originated from an RSS feed registered with Java Buzz
by Jon Tirsen.
Original Post: Unit-test patterns in QDox
Feed Title: jutopia
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Ramblings on Java, AOP, TDD, agile and so on. some like it jutopic!
I took some time to browse the source of QDox (who just moved to Codehaus.org). QDox has an exceptionally beatiful test-suite. A test like the ParserTest illustrates some of my hard-learned lessons about high-quality unit-tests, for example:
Long test names that says it all Who needs comments when you got method names? A test called ParserTest.testOneMultiLineJavaDocTag() really says it all doesn't it?
Inline test-data Notice how each test starts with enumerating what data the test work on? There's no need to context-switch and open a text-file, binary-file in a hex-editor, or whatever. This might not always be possible, but more often than might be expected. You think you really need a .gif-file to test a gif-parser? Why not just inline it using the defined constants?
Use mock-objects Directly after the test-data the expectations on what should happen are enumerated. The usage of the above three idioms in the ParserTest makes it possible to grasp the entire purpose of a test in one quick glance. If a test fails, you will in a short amount of time know exactly what doesn't work and probably how to fix the problem too. (I'll have to admit though, I haven't really started using mock-objects extensively yet.)
Test as close as possible to the source Don't try to test a class by controlling it through another class. Even if you're not gonna be using the "class behind" for anything else (most likely, you will anyway). It's harder to write tests indirectly through another class. It's harder to easily see what the test is about. The tests will end up more brittle since more things can break it. There will be more places to look if a test fail.
Test one and only one thing This makes it easy to realise the purpose and find the root of a problem. So if a test called ParserTest.testPackageWithMultipleWords() fails you immediately know that the parser has a problem parsing packages with multiple words. No debugging needed, just fix the problem.
Try to create orthogonal tests Ideally any change to the code should result in one, only one and not less than one tests failing. Following some of the other advises will lead you closer to this perfect world.
Unit-testing is white-box testing Don't write tests based on the API of a class, write tests based on the knowledge you have of a class. An algorithm that's complex needs more extensive testing than a simple one even if the latter has a more complex API. One of the main purposes of unit-testing is for you to be confident in your code. One of my pair-programming mates usually say to me "Okay, you feel confident with this? You trust the code? No? Okay, write another test.". You heard about Continuous Integration, right? Well, unit-tests are Continuous Therapy (don't tell anybody I said this, it's one of the more well-hidden secrets of XP). It's what allows us to stay at the mind-breaking pace that only XP can give you.
Don't depend on a specific execution order
Isolated independent tests These two are really close to the same thing. For one thing JUnit doesn't allow you to order the execution of tests, so that'll help you. There should be no communication between tests whatsoever. You're running tests against an RDBMS? Try mocking it with hsqldb and redeploy the entire schema for every test. One test should not affect any other test. Minimize the set up of a facet to the bare minimum. Minimize the use of "globals"/static-fields (that's good for you anyway).
Joe is really my unit-test guru. Read the rest of the test-suite too. A work of masters.
Previous Topic
