This project was originally developed as part of the diploma thesis "Framework zur Aufzeichnung automatisierter Integrationstests auf Systemtestebene" (2008) by Rainer Weinhold, supervised by Prof. Dr. Johner from HTWG - Konstanz in cooperation with SEITENBAU GmbH . If you can read german, get the original diploma thesis: Diplomarbeit.pdf . Otherwise the following text briefly describes the basic principles.
Assumed you have a project and want to write Tests. The classical way is to write tests by hand. With JUnitRecorder you can just record them. As first step you instrument the project in a way that parameter and return values of methods are recorded. Now when the project is executed all input/output pairs are stored and can later be used to generate (JUnit-) tests, to verify the functionality.
The complete process is based on Patterns from the 2007 Book "XUnit Test Patterns - Refactoring Test Code" by Meszaros. You can find all patterns online at : http://xunitpatterns.com .
The project follows mostly the
Recorded Test Pattern
For easier reading the sketch is directly included
here:
The original pattern describes how to record test data by putting a kind of proxy between the user and the SUT ( S ystem U nder T est). The proxy can therefore record all inputs and corresponding outputs. These pairs were then saved as Test Scripts.
The JUnitRecorder varies from the original pattern in the 'location' where the test data are recorded. Originally this is proposed on the 'System' level directly between user and SUT. JUnitRecorder is instead working on method level. Therefore you can record and test a single method. This gives the ability to record integration-tests and in future also component-tests.
The recorded inputs and outputs are written into the repository in a raw format not as Test Scripts. Therefore a additional step for transforming the recorded test data to actual tests are necessary.
The primary work flow is:
As mentioned you can just record tests. At the moment recording of specified methods is supported. Practically this equals to Integration testing , because you record/simulate inputs and outputs, but not any other parts of the system.
In the future the idea is also to record interactions/changes in the rest of the system. Then generated tests should be able to simulate the environment. Which then enables us to do Unit testing .
So at the current state you can easily record simple integration tests. The advantage is that if you have a all-ready running project it is quite easy and fast to record a bunch of tests. In general the best results can be retrieved by recording stateless methods, this makes it interesting for testing stateless services of your SOA system.
To try out, setup your development Environment as described in Requirements and test it with a small sample project ( Usage ). Or to modify the project for your special needs, read the Development section.