Possible Solutions


Business systems need access to enterprise data. In traditional business systems, queries are made against databases for such data. In testing such systems, we have experienced slow test execution because of the latency of queries and updates caused by disk I/O. The time to execute a single query or update may be only a fraction of a second, but we have often had to do several such queries and updates in each test as text fixtures are set up, tests are performed, and test fixtures are torn down.

Running Fewer Tests

One way to reduce the time required to obtain useful feedback is to limit the number of tests that are run. The JUnit Cookbook describes how to organize your tests so that subsets can be run. Unfortunately, this strategy suffers from the need for developers to choose an appropriate subset of the tests to use. If they choose poorly, they may be in for a nasty surprise when they run the full test suite just before integration. Nevertheless, there is value in these techniques. The key challenge is to know which tests to run at a particular time.

Faster Execution Environment

Another approach is to increase test execution speed by using faster hardware, dedicated IP subnets, more or better indexes for the database, and so on. However, these techniques tend to yield percentage increases, while we need guaranteed improvements measured in orders of magnitude.

In-memory Testing

Because the problem preventing running many tests is the time required to query or update a database, the ideal solution is to somehow avoid having to do this whenever possible. Another approach is to continue to perform queries but to replace the database with something faster. We have replaced a relational database with a simple in-memory "object database." To obtain rapid feedback from test suites, developers run against the in-memory database while coding. The development process focuses on the use of in-memory testing during development and then switches to database testing before a task is integrated and considered complete.

Although our experiences are with relational databases, this approach could also be used to speed up testing with object databases or simple file-based persistence.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net