See which of your colleagues or former colleagues are already on Testing Link: Check out the Contact Finder
News »Browse Articles » Test Runner - How it works
0
Vote Vote

Test Runner - How it works

Views 1 Views    Comments 0 Comments    Share Share    Posted 16-06-2009  
The blerby test runner is a fairly configurable system, and will become mostly configurable in the following releases up to 1.0. Due to its requirement on being properly configured, it is difficult to explain the differences between the processes while maintaining various contexts without generalizing some of the terms. The following sections are brief descriptions on the basic workflow that the test runner follows.

Configuration

Configuration is the heart of blerby test runner. It controls how tests are detected, when they are detected, what tests are allowed to be run, how to run the tests, how tests are connected to source code, and last but not least how file updates are tracked. Due to the highly flexible nature of the configuration it would take too much room on this page to properly describe every aspect and combination of allowed configuration. The following is a list of resources in which you will find helpful in getting your project under testing.

Configuration Samples - Listing of various helpful configuration samples.

Core Configuration - Allowed sections of configuration and functional representations.

Web Front

The BTR menu is a simple way to manually run tests, clear all server sided caches, or jump back to the documentation page on this site. When navigating the "Available Tests" you may notice that each item in the tree is a link. This is because you can run the tests below that point by simply clicking on the item. All associated tests will be added to the end of the current test queue. After the tests are run the results will be merged with previous results and displayed.

Runner results are displayed in the following form:

* % success - calculated from passes/total tests (forced >=0% )
* Total Tests - total tests encountered before fatal errors in files
* # of passes - number of items not in the following categories
* # of errors - fatal errors / warnings / debug messages
* # of failures - assert failures
* # of skipped - number of encountered test cases marked skipped

Source:
http://www.blerby.com/project/testrunner/documentation/introduction
0
Vote  Vote
Enter your comment:
No Comments For This News

Search News

What's the News?

Post a link to something interesting from another site, or submit your own original writing for the Testing community to read.

Most Popular News

Most Recent User Submitted News