Limitation of Junit

• Tests that verify the integrity of a small unit are useful but limited. Experience has taught us that most bugs are found in the integration phase. These problems range from two modules that fail to work together, all the way to two separate applications that are acting up. Whether it is two application servers, a client/server environment, or even a peer-to-peer scenario, it is highly important to test these complex scenarios because of the tricky bugs that can be found in them. But it is nearly impossible to do so with JUnit.

• Although Java is platform-independent, it is wise to check an application on more than one operating system. Your application may work very well on all operating systems, but it may not function exactly the way you expect it to work on some of them. Running the same set of tests over and over again for every OS is time-consuming, and with JUnit you cannot perform distributed tests, so you don't have a way to run the same series of tests simultaneously on several JVMs each running on different OSes.

• Some units of code can only be tested in a multiple-JVM scenario. For example, testing the opening of a connection (TCP socket or HTTP connection) and the integrity of the information retrieved from it is not possible (or very hard) to test with only one JVM, which is the only option that exists with JUnit.

• JUnit was designed to have all tests run within a single process within a single class. It is also designed with the constraint that all tests are atomic and independent of any other code outside the test being run and that the lifecycle for these tests are independent for each test. This is all great for testing low level units of code, but not for client/server scenario tests.

• http://jroller.com/page/cbeust/20030425
• http://www.jroller.com/page/cbeust/20030317
• http://www.beust.com/weblog/archives/000173.html
• http://www.beust.com/weblog/archives/000082.html