Testing: Difference between revisions
Tim Barker (talk | contribs) |
No edit summary |
||
| Line 1: | Line 1: | ||
This page is the top level page regarding all testing activities around the Moodle project. Testing is essential to make sure that developed code does what it is meant to do, without causing new problems. | This page is the top level page regarding all testing activities around the Moodle project. Testing is essential to make sure that developed code does what it is meant to do, without causing new problems. | ||
== | ==Manual testing== | ||
===Code testing=== | |||
==Code testing | |||
Code is tested as part of reviewing at some key parts of the [[Process|Moodle development process]]. | Code is tested as part of reviewing at some key parts of the [[Process|Moodle development process]]. | ||
| Line 14: | Line 10: | ||
* Peer review - developers often test each others work early in the development process | * Peer review - developers often test each others work early in the development process | ||
* Integration reviews - Our integration team tests code weekly while they are evaluating suitability for integration into Moodle. | * Integration reviews - Our integration team tests code weekly while they are evaluating suitability for integration into Moodle. | ||
===Integration functional testing=== | |||
On Wednesday (all timezones) our Moodle HQ developers spend the day to manually test the functionality of all the issues that have been integrated that week. | |||
* [[Testing of integrated issues]] | |||
===QA regression testing=== | |||
For versions up to 2.4 all the [[QA testing]] was conducted manually before each major release. This process will soon be replaced by automated systems (see below). | |||
* [[QA testing]] | |||
==Automated testing== | |||
===Unit tests=== | |||
Moodle 2.3 and later fully supports PHPUnit tests as part of the code. These are automated tests of very low-level code functionality that a developer should write as part of any new code. | |||
* [[PHPUnit_integration]] | |||
==Continuous integration testing | ===Continuous integration testing=== | ||
As soon as code is added to the integration repository, our continuous integration server tests the new code for: | As soon as code is added to the integration repository, our continuous integration server tests the new code for: | ||
| Line 29: | Line 47: | ||
A failure here notifies the integrators that the build has failed. | A failure here notifies the integrators that the build has failed. | ||
===QA regression testing=== | |||
==QA regression testing | |||
Every week an automated build and test server runs a large number of tests on key functions in Moodle to make sure everything still works and that some new fix in Moodle hasn't caused problems elsewhere. | Every week an automated build and test server runs a large number of tests on key functions in Moodle to make sure everything still works and that some new fix in Moodle hasn't caused problems elsewhere. | ||
| Line 44: | Line 56: | ||
* [https://docs.moodle.org/dev/Behat Selenium based functional testing using the Behat framework] | * [https://docs.moodle.org/dev/Behat Selenium based functional testing using the Behat framework] | ||
* Performance testing using JMeter. | * Performance testing using JMeter. | ||
Revision as of 03:17, 4 October 2012
This page is the top level page regarding all testing activities around the Moodle project. Testing is essential to make sure that developed code does what it is meant to do, without causing new problems.
Manual testing
Code testing
Code is tested as part of reviewing at some key parts of the Moodle development process.
- Development - the developer of some code should test their own work on a wide variety of environments for correctness and performance
- Peer review - developers often test each others work early in the development process
- Integration reviews - Our integration team tests code weekly while they are evaluating suitability for integration into Moodle.
Integration functional testing
On Wednesday (all timezones) our Moodle HQ developers spend the day to manually test the functionality of all the issues that have been integrated that week.
QA regression testing
For versions up to 2.4 all the QA testing was conducted manually before each major release. This process will soon be replaced by automated systems (see below).
Automated testing
Unit tests
Moodle 2.3 and later fully supports PHPUnit tests as part of the code. These are automated tests of very low-level code functionality that a developer should write as part of any new code.
Continuous integration testing
As soon as code is added to the integration repository, our continuous integration server tests the new code for:
- Coding guidelines
- PHPUnit tests
- SimpleTest unit tests on older versions of Moodle
- Detect unresolved merge conflicts
- Compare databases upgraded from previous versions
- Check the version.php is correct
A failure here notifies the integrators that the build has failed.
QA regression testing
Every week an automated build and test server runs a large number of tests on key functions in Moodle to make sure everything still works and that some new fix in Moodle hasn't caused problems elsewhere.
These tests must pass completely before a release can be made.
- Selenium based functional testing using the Behat framework
- Performance testing using JMeter.
