launchpad development|
Size: 532
Comment: Placeholder page.
|
Size: 1714
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Writing tests = For each part of an application there are 2 level of testing: * unit testing * comprehensive testing, including cornerstone cases * written in python files (no doctest) * smoke/functional/integration testing * testing normal use cases, simple or comples * written using doctest format 1. Model 1. Unit testing * Files locate in lib/lp/<application>/scripts/tests 1. Smoke testing * Files locate in lib/lp/<application>/doc 1. View 1. Unit testing * Files locate in lib/lp/<application>/browser/tests 1. Smoke testing * Files locate in lib/lp/<application>/stories * More details: PageTests 1. Javascript 1. Unit testing * More details: TestingJavaScript JavascriptUnitTesting 1. Smoke testing * Files locate in lip/lp/<application>/windmill (if written in Python) and lib/canonical/launchpad/windmill/jstests (if written in JS) * More details: [[Windmill]] 1. Scripts * Files locate in lib/lp/<application>/scripts/tests 1. API * ??? |
|
| Line 5: | Line 37: |
| Obviously, you've already tested your changes manually and confirmed that they do what you expect. | The normal pattern for testing your changes is to run the tests you ''think'' will be affected locally, and then (possibly just before submission) run '''all''' the tests [[EC2Test|in the cloud]] before landing your changes on [[Trunk|trunk]]. |
| Line 7: | Line 39: |
| But how do you know they don't do anything you ''don't'' expect? | To run the tests, you run the {{{./bin/test}}} script, which is produced by {{{make build}}}. |
| Line 9: | Line 41: |
| Hence the test suite :-). | You can see all the options you have by running {{{./bin/test --help}}}, but usually you will run {{{./bin/test -vvct $pattern}}} where {{{$pattern}}} is a regular expression that is used to filter the tests that will be run. |
| Line 11: | Line 43: |
| The test suite runs remotely, in Amazon's EC2 computing cloud. ''TODO: we need to set up some way to give EC2 time to non-Canonical developers. Our internal instructions for testing on EC2 are not well-suited to external contributors.'' | ---- CategoryTesting |
Writing tests
For each part of an application there are 2 level of testing:
- unit testing
- comprehensive testing, including cornerstone cases
- written in python files (no doctest)
- smoke/functional/integration testing
- testing normal use cases, simple or comples
- written using doctest format
1. Model
- Unit testing
Files locate in lib/lp/<application>/scripts/tests
- Smoke testing
Files locate in lib/lp/<application>/doc
1. View
- Unit testing
Files locate in lib/lp/<application>/browser/tests
- Smoke testing
Files locate in lib/lp/<application>/stories
More details: PageTests
1. Javascript
- Unit testing
More details: TestingJavaScript JavascriptUnitTesting
- Smoke testing
Files locate in lip/lp/<application>/windmill (if written in Python) and lib/canonical/launchpad/windmill/jstests
(if written in JS)
More details: Windmill
1. Scripts
Files locate in lib/lp/<application>/scripts/tests
1. API
- ???
Testing Your Launchpad Changes
This page is very much still in progress.
The normal pattern for testing your changes is to run the tests you think will be affected locally, and then (possibly just before submission) run all the tests in the cloud before landing your changes on trunk.
To run the tests, you run the ./bin/test script, which is produced by make build.
You can see all the options you have by running ./bin/test --help, but usually you will run ./bin/test -vvct $pattern where $pattern is a regular expression that is used to filter the tests that will be run.
