JTestMe automatically defines smoke test suites for Java applications - dramatically improving the continuous integration cycle time. When a test runs, any application Classes which are executed are recorded into a repository. Super-classes and classes that are not directly called by tests are included. When you change any application code, the repository is inspected to determine which tests should be run. These tests can then be run whenever you save a file, as an automatic pre-commit build test suite, or as an automatic smoke test suite for a Continuous Integration tool like CruiseControl. Rather than running the whole test suite, or pre-defined test suites, only the tests that need to be run to exercise the changed code are the ones that are run, dramatically reducing the feedback cycle for most applications. Once the smoke test suite has passed, the full unit, integration, and functional test suites would be executed as is current practice, in order to fully assure the behaviour of the application (as some changes are beyond the view of the executing code). The granularity of the recorded data is the TestCase class and the application code Class. Although method-level recording of both is possible we feel the granularity is too low for safe testing. Nonetheless, if the feature is requested it is easy enough to engineer. We intend similar tools for Ruby and .Net (RTestMe and NTestMe). We looked at perhaps extending code-coverage tools like Cobertura and Emma but these tools don't appear to provide the calling context to capture the running test names, and also are not as pervasive as JUnit. There is a Google/SourceForge Project called "Testar" which has similar goals, but approaches the solution in a different way - it also does not appear to work with the JUnit Ant task, JUnit4, or 1.5 classes. We are open to merging projects if suitable. Initial Committers: * Joshua Graham (ThoughtWorks) * Stacy Curl (ThoughtWorks) * Gianny Damour (ThoughtWorks) Maturity: Alpha (currently working, test-driven code - available for the perusal of the Despots if required for approval) Dependencies: * AspectJ * Derby DB To do: * Ant tasks * JUnit runner integration * JUnit4 annotation awareness * CruiseControl "modificationset" integration * Classification of tests (unit, integration, functional) and finer control of smoke test suite definition * Eclipse plugin * IntelliJ IDEA plugin * Continuous Testing plugin integration (http://www.pag.csail.mit.edu/continuoustesting/) * Integration to other advanced testing tools which manipulate the ordering of tests to reduce feedback delay * Non JUnit-based runner integration * Use a 3rd-party persistence framework if the captured data gets more sophisticated
Issues: 30 Day Summary
Issues: 0 created and 0 resolved
- Workload Pie Chart Report A report showing the issues for a project or filter as a pie chart.
- User Workload Report This report shows the details of a user's current workload, showing the number of unresolved iss...
- Version Workload Report This report shows the details of the current workload for the specified version - showing the number...
- Time Tracking Report This report shows the time tracking details for a specific project.
- Single Level Group By Report This report allows you to display issues grouped by a certain field
- Created vs Resolved Issues Report A report showing issues created vs issues resolved.
- Resolution Time Report A report showing the length of time taken to resolve issues for a project or filter.
- Pie Chart Report A report showing the issues for a project or filter as a pie chart.
- Average Age Report A report showing the average age of unresolved issues for a project or filter.
- Recently Created Issues Report A report showing the number of issues recently created.
- Time Since Issues Report A report showing time since a chosen field for each issue for a project or saved filter.