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 binarythat 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.
For years, unit testing languished in the "I know I should be doing it" category, but now it finally has become part of the Java developer's professional toolkit. Being a guru-level java programmer is no longer good enough. Now you have to know how to properly unit test the code you write, which is a good thing because it leads to higher-quality code, higher productivity, and lower maintenance and evolution costs.
In this article, I will discuss two issues that often vex Java developers when they attempt to unit test their code: whether to design their systems in a manner that facilitates testing, and how to test non-deterministic code.