Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Testing: Difference between revisions

From MoodleDocs
m (Protected "Testing": Developer Docs Migration ([Edit=Allow only administrators] (indefinite)))
 
(21 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{Template:Migrated|newDocId=/general/development/process/testing}}
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.


==Unit tests (AUTOMATED)==
==Manual testing==
 
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]]


==Code testing (MANUAL)==
===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 15: Line 13:
* 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. Developers submitting patches should always cover the patch with unit tests and/or Behat behavioural tests. Still, all issues are tested by a human and it is usually worth it.
* [[Testing of integrated issues]]
===QA testing===
Volunteer testers from the Moodle community systematically try each feature in Moodle and test that it works in the current version of the Moodle code. These tests are repeated in series of cycles, usually 4 weeks before a major release, once all major features have landed.
* [[QA testing]]


==Continuous integration testing (AUTOMATED)==
For major theme changes, additional manual tests may be run.


As soon as code is added to the integration repository, our continuous integration server tests the new code for:
==Automated testing==


* Coding guidelines
===Unit tests===
* PHP unit tests
* xxx
* xxxx


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.


==Integration functional testing (MANUAL)==
* [[PHPUnit_integration]]


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.
===Continuous integration testing===


* [[Testing of integrated issues]]
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


==QA regression testing (AUTOMATED)==
A failure here notifies the integrators that the build has failed.


Every week an automated Selenium-based system tests a large number of key functions in Moodle to make sure everything still works and that some new fix in Moodle hasn't caused problems elsewhere.
===Regression testing===


This test must pass completely before a release can be made.
Every day, an automated build in a test server runs a large number of tests concerning key functions of Moodle, to make sure that everything still works and that some new fix in Moodle hasn't caused problems elsewhere.


* Functional testing
These tests must pass completely before a new release can be made.
* Performance testing


==QA regression testing (MANUAL)==
* [[Acceptance testing]] using the Behat framework
* Performance testing using JMeter.


For past versions all the [[QA testing]] was conducted manually before each major release.  This process will soon be replaced by the above automated systems.
Moodle uses a sponsored version of [https://www.browserstack.com BrowserStack] for testing on multiple browsers.


* [[QA testing]]
[[Category:Quality Assurance]]

Latest revision as of 07:27, 6 May 2022

Important:

This content of this page has been updated and migrated to the new Moodle Developer Resources. The information contained on the page should no longer be seen up-to-date.

Why not view this page on the new site and help us to migrate more content to the new site!


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. Developers submitting patches should always cover the patch with unit tests and/or Behat behavioural tests. Still, all issues are tested by a human and it is usually worth it.

QA testing

Volunteer testers from the Moodle community systematically try each feature in Moodle and test that it works in the current version of the Moodle code. These tests are repeated in series of cycles, usually 4 weeks before a major release, once all major features have landed.

For major theme changes, additional manual tests may be run.

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.

Regression testing

Every day, an automated build in a test server runs a large number of tests concerning key functions of Moodle, to make sure that everything still works and that some new fix in Moodle hasn't caused problems elsewhere.

These tests must pass completely before a new release can be made.

Moodle uses a sponsored version of BrowserStack for testing on multiple browsers.