Using Integration Tests
Integration tests, also known as system tests, pose a different problem to testers than the standard unit tests. JUnit was designed with unit tests in mind: if any part of the test fails, then the unit as a whole fails. Likewise, JUnit works best when the tests are broken into the smallest possible minutae for better granularity and clarity into where a unit breaks.
On the other hand, integration tests lie in a different realm in testing. Each test generally takes some part of the application for a spin, examining how each part influences each other, and looking for places where this communication happens incorrectly. These tests can bring in user input and other outside events to the application.
An integration test may fail at some point in the run, but that generally doesn't mean that the run itself needs to stop. Integration tests introduce the concept of failure severity. One can break failures into two general categories: failures that immediately stop the run, and those that allow the test to continue. The JUnit concept of failures falls into the former.
The GroboUtils JUnit extention class net.sourceforge.groboutils.junit.v1.IntegrationTestCase introduces "soft" failures; those that are a failure, but don't stop the test. The underlying design creates a new test object that runs the specified test, but it is executed outside the context of the owning test run, so that the new test object's failure status will be recorded on its own. This also allows for a more accurate depiction of the number of tests actually executed, as opposed to the number of runs executed.
This space graciously provided by the SourceForge project
2002-2004 GroboUtils Project.|
All rights reserved.