There are two issues that often vex Java developers when they attempt to unit test their code. The first one is whether to design their systems in a manner that facilitates testing. The second is how to test non-deterministic code. This article offers helpful tips for handling these dilemmas.
by Bryan Dollery
October 21, 2002
evelopers write unit tests to check their own code. Unit testing differs from integration testing, which confirms that components work well together, and acceptance testing, which confirms that an application does what the customer expects it to do. Unit tests are so named because they test a single unit of code. In the case of Java, a unit usually equates to a single class.
A unit test is fully automated, non-interactive, and binary—that is, it either succeeds or fails. So running your code and examining its output to see if it works is not a test. Neither is writing a little "test driver" that drives your code and allows you to check logs to see if it's working correctly.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
evelopers write unit tests to check their own code. Unit testing differs from integration testing, which confirms that components work well together, and acceptance testing, which confirms that an application does what the customer expects it to do. Unit tests are so named because they test a single unit of code. In the case of Java, a unit usually equates to a single class.
