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