This section explains the nature or quality of code that makes unit testing difficult. Automated tests help us develop software quickly, even when we have a large code base to work on. Automated unit tests should be executed very fast so that the tests can give us quick feedback, however we cannot unit test code when it exhibits any of the following symptoms:
- Performs long running operations
- Connects to a database and modifies database records
- Performs remote computing—RMI
- Looks up JNDI resources or web/application server objects
- Accesses filesystems
- Works with native objects or graphical widgets (UI components, Windows alerts, JAVA Swing components, and so on)
- Accesses network resources (LAN printer, downloads data from the Internet, and so on)
Unit tests should not wait for a long running process to complete; it will defeat the purpose of quick feedback.
Unit tests should be reliable and they should fail if, and only if, the production code breaks. However, if your unit test verifies an I/O operation, such as connecting to a LAN printer, which is slow, error prone, and unpredictable, your unit test may fail for some network issue, but it will incorrectly signal that the code is broken. So unit testing a network operation defeats the test reliability principle. If you depend on anything in your unit tests that's unreliable (such as LAN connections, databases, random numbers, and so on), in turn, you make your tests unreliable. Testing is about getting confidence that your code is correct, and unreliability destroys confidence.
Unit tests run automatically, so it doesn't make any sense to open a modal dialog or show an alert message during test execution, because the test will wait, unless the UI dialog or the alert is closed.