Thursday 15.40 - 16.30
Room: Keyboard Cat

Automated functional tests provide valuable feedback to developers by notifying them when they break functionality. Additional value can be derived from the tests by providing fast feedback, as the problem is likely to be fresh in the developers mind and quicker to fix.

A Typical functional test suite can take many hours to run because the tests can only be run sequentiality. The main cause for the sequential tests is the dependence on data, common practice has tests clear the application under tests database and populate it with the required data before a test starts. This high level of database manipulation does not allow the tests to run in parallel because each test will interfere with the database at different times causing false positive test failures.

The common solution for long running serial only test suites is to break them into multiple groups and run each group on a separate machine with its own instance of the application under test. This is not true parallelism and has scalability issues which will be discussed during the session introduction.

The real solution is to solve the creation of test data and interference of data created during other test executions. This can be done for most applications by creating data unique to each test. A simple way of achieving this is the creation of a API based on the Data Builder Pattern to create this unique data.

Tags: Hard Core Test