|
Project Information
Featured
|
What jrunr isjrunr is a tool that can be used to non-intrusively record and store unit test data from a running instance of an existing java application, which can be reused later on in unit tests. It is specifically intended for use in maintenance scenarios of java applications that are not TDD aware, which as a result cannot be easily unit tested. WhyUnit tests play a role in not just from-scratch development projects, but also in maintaining existing applications by providing the test base that can be used to validate new builds, ie, enhancements. However, adding to existing code that is not written in a test-aware fashion makes it difficult to narrow creation of any new test cases to the specific problem that is being fixed. Some of these scenarios are: - The code to be tested is a small part of a large method, ie only one of the flows has been modified and needs to be tested. The rest of the code is known to be correct to the extent verified by non-junit methods such as human testing and given that its in production already.
- The code to be tested depends on a rather costly setup of other objects
- The code to be tested depends on calls to other layers/applications, which are not (desirable to be) available in the unit test scenario.
The traditional methods of attacking these problems is to mock out everything except the "System under test (SUT)" . However in scenarios 2 and 3 above, the mocking approach might lead to an overly-complex mock layer or mock-calling-mock situation. Jrunr aims to avoid this, and provide an easier (if hackish) way of increasing legacy app test creation efficiency. It is not intended to replace test driven development or mocking; more to complement them in situations where the cost of elegance is too high :) Jrunr itself, however, aims to be an elegant tool, and therefore does all its work without any change to application code. How it worksJrunr is implemented as two compoents: - Recording is implemented as an aspect that intercepts all configured method calls in the SUT. The configuration specifies whether to store the arguments passed to the method, or its return value, or both.These values are then stored in a configured location as json files keyed on the method's fully qualified name.
- Replay/Reuse is implemented as a class that can read the json files and return any value stored which can be directly used in a normal junit test case.
|