Skip to main content

Lazy Testing in Java

Posted by garysweaver on August 28, 2008 at 7:33 AM PDT

Do you have almost no test coverage or perhaps none at all? Join the crowd. Although no one wants to admit it, a good part of the world runs on untested code. Here are a few tips for "lazy testing" your Java application, for those many of us that have nowhere to go but up.

Unit test the stuff you are unsure of the behavior of that is easy to test

For example, if you have a utility class that is doing something funky- that would be a good place for one or more unit tests.

Keep tests fast

You've probably heard this before. For those few tests you actually do add, make sure they all run quickly, and if they don't then make sure they'll run as part of continuous integration or via some automated fashion, because otherwise they'll probably either just slow down the build (wasting time as developers go read slashdot, etc. while waiting on the build), or if they aren't run as part of the build, they'll likely be ignored and not of much use.

Use tools that make it faster to develop and maintain tests

Do you leave out tests because you're afraid of getting fired or shunned for being too slow to develop something? You think you'll be better off without writing tests? Well just a minute now- that's how we got into this "my code is poorly tested" position in the first place. If your code is buggy, then ignoring that fact isn't going to help, it's just going to mean time later to work out the kinks, which makes you slower.

There are all kinds of things out there to help you. Just spend a bit of time researching via Google, and you'll be able to develop the tests you need with a lot less code. In addition to JUnit, if you're using Spring, the Spring base classes for unit tests (look at the Spring documentation) are really helpful, and stuff like Unitils can help a lot with setting up Spring beans and DBUnit for testing. DBUnit can be used to test out the DAO stuff (albeit as more of a functional test) and I think H2 makes a good in-memory DB for testing (it's from the guy that did HSQL/Hypersonic), and EasyMock/JMock are ok for mocking objects if the mock objects provided by your framework (Spring, etc.) don't help (but I think you can end up spending too much time learning to mock stuff, so it isn't always good for the lazy programmer).

Setup a continous integration (CI) server

Having something telling you when you or someone else checked in something to source control (and if you don't have source control, good gracious! you are lazy- and stupid, I might add) that broke the build is a really good idea, and lazy (in a good way)! Bamboo kicks butt for CI.

Functional tests vs. unit tests

If it is a matter of having quick functional tests that test out much of the application vs. only a few parts, go for the functional ones and run them as part of the build.

For example, if you have an app that acts as an email reader, use GreenMail to setup an in-memory mail server as part of the build. If you can be lazy while doing it, try not to place dependencies on internal/work servers being up, but for internal projects, it might be easier. For open-source projects, (almost) anyone (almost) anywhere should be able to run the build, so don't place dependencies on internal/work servers, unless they are public and you can justify it.

Using unitils and DBUnit with H2 works for DAO checking functional tests, if you're really concerned/unsure about your DAO code.

Whenever possible, have a standardized build script (for example: ant, maven, maven 2) for all projects that call the tests

This is a must for open-source projects, and should usually be a given for internal projects. If you only use the IDE project or rely on it too heavily, you might be screwing your company or your fellow (or future) coworkers or replacement(s) who might want to build from command-line or use a continuous integration server (like Bamboo) to run the build. Also, the continuous integration build will likely call a script, ant, or maven/maven 2 build.

I totally welcome any and all comments, as I'm definitely not trying to speak as an authority on the subject. Hope this starts up a healthy conversation and helps get some of you lazy programmers (which includes me) into doing at least some testing.


Here's a great lecture on Unitils if anyone is interested.

Thought this was interesting... Just got a "spam" from nofluffjuststuff about upcoming event related to this topic, also mentioned on Jared's blog here. The headline is 'We all know that test automation is vital, But most of us "don't have time". Join us for Test Automation Training with Jared Richardson October 8 - 10, 2008 - Washington DC'

@dserodio - as for "Why Bamboo vs. Hudson or vs. CruiseControl"... I'm just partial to Bamboo and Atlassian products. Having spent a good deal of time in the last year getting awesome support from them and seeing them develop features so quickly that sometimes even the plugin developers can't keep up with them (at least for Confluence), we decided to give Bamboo a try, and I have been very impressed with it. If you're looking for a simple comparison of various CIs (if you're lazy like me) check out the CI comparison matrix. But I'd download Bamboo and give it a try if you think it might fit. Obviously Atlassian uses it but notable others like SpringSource use it as well.

Why Bamboo? Why did you choose it over Hudson or CruiseControl ?

Thanks for this post. Frankly, I'm sick of seeing too many posts by knee-jerk, TDD bigots that make you feel inadequate if your code coverage is less than 95 percent. Obviously, many of us in the real world know that deadline pressure often severely constrains the extent of testing we can do. And, to be sure, API and software-product code needs to be well tested to make sure that the code is rock solid. But most of us create software with a much shorter working life span. The deadine-driven development testing practices that you nicely articulate here need to be more widely seen and debated.