RCPTT is good enough to run tests occasionally, to keep quality of product milestones. To get more interactive results, to keep up with high development speed and agile techniques, project may require to run functional tests more than once a week. Once your test count reaches hundreds, whole run may take an hour or two and this may become time consuming and bothersome. This can be solved by continuous integration—automated run of integration tests on every commit or on a regular basis.
Runner is designed to cover this need and provides completely automated and unattended way of running testsuites on every build. Once you configure a build system to use it, you have no need to start and observe whole test suite manually anymore.
QA engineers can rely on Runner for regression testing and concentrate on new features. This saves a lot of time and hassle at the end of release cycle. Moreover if feature testing is automated as feature gets done, QA workload is evenly distributed over the cycle and release testing is reduced to final build procedure. It is possible to test more features with less people.
No human intervention
RCPTT is a great tool to design tests, but once your test count become thousands, managing testsuite execution can become a tedious task. AUT’s misbehaviors, hangups, inconsistent OS events and user actions, may cause some tests to run longer, hangup, or give inconsistent results. Runner requires no manual control during test run. It gracefully handles AUT hangups, logs internal errors, stores every test step and its result, ensuring that you get a complete and comprehensive test report in a predictable time, every time.
While Runner is a great tool to run your tests on a workstation, it gives much more benefits being a part of continuous integration. Running functional tests in the same way you do Unit, you get best possible test coverage within a reasonable time. Every error costs less with shortest possible error detection time.
Runner is perfectly suitable to run on Jenkins, Hudson and other CI tools. Maven users will find configuration even easier. Standard JUnit-formatted test reports make use of native test run representations in these systems and take part in statistical views.
Full GUI tests suite can be run as a verification for every changeset your developers contribute. Harmful changes are now covered by functional tests, leaving no broken commits to review.
Configuration of CI infrastructure can be cumbersome, but we are happy to answer your questions and help you find an optimal way of doing things. Get support now.
Command line interface
Runner has a versatile command line interface controlling many aspects of test execution. Every RCPTT execution option is covered by corresponding command line argument. Timeouts, variables, tag filtering are all configurable. See complete reference
Maven takes Runner's command line interface to the higher level of abstraction. With a single POM file you get platform independent test configuration integrated into your build process. Learn more with Maven plugin documentation.
Runner collects test results in a comprehensive report. Human readable HTML and Junit formats are supported out of the box and there is a freedom of extension. Every report contains a short and concise overview of whole test run, individual test results.
Default HTML reports also provide extensive details about state of application after each test failure. These include thread dump, SWT snapshots in text tree representation, screenshots and more.
Runner's report also includes platform log events and background operations, to get lower level details and, ease reproduction and debugging.
Runner also generates a report in RCPTT format, it can be conviniently viewed from RCPTT IDE, if human readable report is not enough.