一个java应用程序的单元测试的遗产不知道record-n-run测试工具.zip

jrunr - Java Record Unit test data N Replay/Reuse =================================================== Table of Contents: ----------------- 1. Concepts 1.1 What is jrunr 1.2. Why 1.3. How does it work? 2. User Guide 2.1 Requirements 2.2 Installation 2.2.1 Installation in a Web Container 2.2.2 Installation in a standalone app 2.2.3 Installation in an EJB Container - TBD 2.3 Using jrunr 2.3.1 Deciding what to record and how 2.3.1.1 <Usage scenarios go here> 2.3.2 Configuring the methods to record data from 2.3.3 Recording data 2.3.4 Using the data in your unit tests 3. Dev guide/notes 3.1 Requirements/Feature List 3.1.1 Project Roadmap 3.1.2 Status 3.2 Analysis 3.2.1 Issues 3.2.2 Status 3.3 Architecture/Design 3.3.1 Design 3.3.2 Tools/libraries used 3.3.3 Issues/todos 3.3.4 Status 3.4 Construction 3.4.1 Issues/todos 3.4.2 Status 3.5 Project Management 4. FAQ 4.1 Why not jdk 1.5 4.2 Why not aspectj 6. Colophon # Concepts # ## What is jrunr ## jrunr 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. ## Why ## Unit 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: 1. 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. 2. The code to be tested depends on a rather costly setup of other objects 3. The code to be tested depeneds 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"] (todo: link to xunit here). 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 works ## Jrunr is implemented as two compoents: - *Recording* is implemented as an [aspect] (todo: link here) 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 the test case. # User Guide ## Requirements ## Installation ### Installation in a Web Container - Add jrunr.jar to the classpath - Add dependent jars (if required) - Add reference to the spring config required - if the app doesnt use spring, how: - if the app does use spring, how: - modify the config to setup methods to be recorded ### Installation in a standalone app ### Installation in an EJB Container - TBD ## Using jrunr ### Deciding what to record and how ### <Usage scenarios go here> ### Configuring the methods to record data from ### Recording data ### Using the data in your unit tests # Dev guide/notes ## Requirements/Feature List 1. Record data for use in unit tests 1.1 Provide a means to record data for a method under test; ie, the input and output parameters should be recorded. 1.2 Provide a means to store the recorded data, identified by the method under test. 1.3 Allow the user to choose whether the input, output or both should be recorded via declarative configuration. 1.4 Record timestamp information for reference and/or comparison of data 2. Use recorded data in unit tests 2.1 Provide an easy to use interface/class to access the stored data 2.2 The interface should allow use of any/all data stored 2.3 The interface should have minimal impact on the setup of the test case/suite. 3. Manage Recorded Data 3.1 Provide the ability to edit/modify data to change it to suit a particular test case. 3.2 Provide the ability to aggregate data from multiple recordings related to a single method 3.3 Provide the ability to consolidate data from multiple recording sessions and methods so as to create a database of such test data. 3.4 Provide a GUI to do all requirements under this section. 4. Use recorded data to generate more data This requirement is to be fleshed out. The general idea, however is to use the recorded data as a template to generate more data either for functional tests, or for load testing. 5. Documentation 5.1 Provide documentation for end users 5.2 Demonstrate use of tool in sample applications and include the source as part of distribution. 5.2.1 For standalone apps 5.2.2 For web applications 5.2.3 For enterprise containers. 6. Non-functional 6.1 The tool should not be invasive: 6.1.1 It shouldnt require code changes to record data 6.1.2 It shouldnt require major changes in the build system 6.2 The tool shouldnt impact the performance of the system majorly. It is understood that the record phase will be a non-production run of the application for the specific purpose of recording data. 6.3 Data storage must be in a format amenable to both human and tool manipulation; ie it must enable both humans and tools to easily read and modify the data. 6.4 The tool should provide for jdk versions 1.3 onwards. 6.5 The tool could provide a jdk 1.5-specific version. 6.6 The configuration of the tool must follow DRY principles. ### Project Roadmap <table> <td> Version </td> <td> Features </td> <td> 1.0 (Basic) </td> <td> Requirement #s 1.1-1.3,2.1-2.3,3.1 by satisfying 6.3,5.1,5.2.1-5.2.3,6.1,6.2 implicitly,6.3,6.4</td> <td> 1.1 (DRY) </td> <td> Requirement #s 6.6</td> <td> 2.0 (JDK1.5) </td> <td> Requirement #s 1.4,5.2.3,6.5</td> <td> 3.0 (GUI) </td> <td> Requirement #s 3.1-3.4, verify 6.2</td> <td> 4.0 (DataGen) </td> <td> Requirement #s 4</td> </table> ### Status 10/6/2007 All requirements except #4 fleshed out. ## Analysis The implementation will need solutions for the following sub problems: - how to record without changing source too much or at all - how to record enough information of the original context for use in the test - how to view and modify the stored information to suit the same test context or a different one, or to create bulk test data from the single recorded data - how to use the stored information in a test case Each is detailed below: - how to record without changing source too much or at all some form of aop annotations: might not work as we need the object values passed from the running context to the annotation processor(ap) any around advice aspect would work, but to make it generic, we'd need a declarative way of defining the variable(s) that the aspect would be tracing. - how to record enough information of the original context for use in the test ie, how to record which m