Merge pull request #37 from sarjona/testing

Add Testing pages

docs/apis/access.md

@@ -32,7 +32,6 @@ User access is calculated from the combination of roles which are assigned to ea
 
 All users that did not log-in yet automatically get the default role defined in `$CFG->notloggedinroleid`, it is not possible to assign any other role to this non-existent user id. There is one special guest user account that is used when user logs in using the guest login button or when guest autologin is enabled. Again you can not assign any roles to the guest account directly, this account gets the `$CFG->guestroleid` automatically. All other authenticated users get the default user role specified in `$CFG->defaultuserroleid` and in the frontpage context the role specified in `$CFG->defaultfrontpageroleid`.
 
-
 <AcademyLink
   subject="Contexts and the Roles API"
   courseName="securityEssentials"

general/development/process.md

@@ -55,7 +55,7 @@ During each week the testers look at all the issues in the testing queue, trying
 
 If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.
 
-See [[Testing of integrated issues]] for more details.
+See [Testing of integrated issues](/general/development/process/testing/integrated-issues) for more details.
 
 ### Production maintainers
 
@@ -113,11 +113,11 @@ The process of [[#New_feature_development|new feature development]] is described
 
 During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.
 
-In the last month before the release, a feature freeze is called (no new features can be added) and volunteer testers from the Moodle community perform manual QA testing of Moodle features. The current set of functional tests is listed in {tracker}`MDLQA-1`. The list of tests is extended as new features are added, though we're also trying to reduce the number as more automated [[Acceptance_testing|acceptance tests]] are developed.
+In the last month before the release, a feature freeze is called (no new features can be added) and volunteer testers from the Moodle community perform manual [QA testing](/general/development/process/testing/qa) of Moodle features. The current set of functional tests is listed in {tracker}`MDLQA-1`. The list of tests is extended as new features are added, though we're also trying to reduce the number as more automated [[Acceptance_testing|acceptance tests]] are developed.
 
 There is also a set of tests for manually testing any major theme changes - {tracker}`MDLQA-11592`.
 
-For more details, see [[Testing]].
+For more details, see [Testing](/general/development/process/testing).
 
 ### Sprints
 
@@ -128,18 +128,24 @@ At Moodle HQ, development takes place in sprints. The sprints are two or three-w
 During each cycle there are a periods and events that occur between and around sprints.
 
 ![The Development sprint calendar](./process/_files/sprintcalendar.png)
-; *Planning and bug fixing*
-: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
-; *End sync period*
-: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
-; *Personal projects*
-: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
-; *Code freeze*
-: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
-; *QA, bug fixing, continuous integration*
-: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
-; *Release candidate*
-: A point prior to the full release where a candidate is made public for wider testing.
+
+**Planning and bug fixing** <br/>
+A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
+
+**End sync period** <br/>
+During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
+
+**Personal projects** <br/>
+Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
+
+**Code freeze** <br/>
+A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for [QA testing](/general/development/process/testing/qa).
+
+**QA, bug fixing, continuous integration** <br/>
+A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
+
+**Release candidate** <br/>
+A point prior to the full release where a candidate is made public for wider testing.
 
 ## New feature development
 

general/development/process/integration-review.md

@@ -91,12 +91,12 @@ The integrators adhere to the following schedule: (links here should convert the
 
 All the flow of issues to current integration is automatically controlled by the [Manage queues on normal job](https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/) that keeps the current queue fed with issues, moves important ones and priotitises long awaiting issues. Issues are picked in strict integration order.
 
-- Monday to Thursday until [12:00 (UTC+8)](http://time.unitarium.com/utc/4): Integration and [Testing](https://docs.moodle.org/dev/Testing_of_integrated_issues#The_testing_process) happen. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction.
+- Monday to Thursday until [12:00 (UTC+8)](http://time.unitarium.com/utc/4): Integration and [Testing](/general/development/process/testing/integrated-issues#the-testing-process) happen. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction.
 - Thursday after 12:00 (UTC+8): Integrators duties during this time are to monitor, facilitate and 'problem solve' the testing process.
 - Friday: Testing should be completed before (the sooner the better) 12:00 (UTC+8) at which time remaining testing failures will be reverted/rewritten and reopened. The release process follows.
 - Friday after [12:00 (UTC+8)](http://time.unitarium.com/utc/4): Should be kept free from integration. Integration systems are maintained during this time.
 
-Note that under the strict schedule above, it is specially important **to be as responsive as possible**, both when the issue is being integrated and when [testing](https://docs.moodle.org/dev/Testing_of_integrated_issues#Expectation_from_tester). Any significant delay by any of the actors involved will result in the issue being moved out from current integration.
+Note that under the strict schedule above, it is specially important **to be as responsive as possible**, both when the issue is being integrated and when [testing](/general/development/process/testing/integrated-issues#expectation-from-tester). Any significant delay by any of the actors involved will result in the issue being moved out from current integration.
 
 ### During continuous integration/Freeze/QA period
 
@@ -112,8 +112,8 @@ Throughout:
 So, basically, once under continuous integration, we do organize work as follows:
 
 - Continuous officially begins. Everybody is on integration. Until end of on-sync period.
-- Monday: Integration and [testing](https://docs.moodle.org/dev/Testing_of_integrated_issues#Differences_in_test_process_during_continuous_integration_periods) happens.
-- Tuesday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to [achieve 100% 'Test Passed'](https://docs.moodle.org/dev/Testing_of_integrated_issues#Differences_in_test_process_during_continuous_integration_periods) and stop integrating any untested changes until a master release is produced.
+- Monday: Integration and [testing](/general/development/process/testing/integrated-issues#differences-in-test-process-during-continuous-integration-periods) happens.
+- Tuesday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to [achieve 100% 'Test Passed'](/general/development/process/testing/integrated-issues#differences-in-test-process-during-continuous-integration-periods) and stop integrating any untested changes until a master release is produced.
 - Wednesday: [Assuming a master release has been rolled] Integration and testing continues
 - Thursday: Integration and testing continues
 - Friday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to achieve 100% 'Test Passed' and stop integrating any untested changes until a master release is produced. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction.

general/development/process/testing.md

@@ -0,0 +1,100 @@
+---
+title: Testing
+description: All the information related to testing during the Moodle development.
+tags:
+  - Processes
+  - Core development
+  - Testing
+  - Quality assurance
+---
+
+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](/general/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 review`. The integration team tests code weekly while they are evaluating suitability for integration into Moodle.
+
+:::info More info
+
+We recommend that you follow the [[Testing instructions guide]] to help you write clear manual testing instructions.
+
+:::
+
+### Integration functional testing
+
+Moodle has a dedicated team of testers who perform most of the manual testing for integration issues. Developers submitting patches **should always cover the patch with unit tests and/or Behat behavioural tests**.
+
+:::info More info
+
+We recommend that you follow the [Testing of integrated issues guide](/general/development/process/testing/integrated-issues) to get a better understanding of how testing integrated issues works.
+
+:::
+
+### QA testing
+
+Once all major features for a new Moodle release have landed, Moodle performs a Quality Assurance test cycle. This test cycle is typically performed by volunteers from the Moodle community who systematically test each available feature to ensure that it still works as intended. This process typically lasts 4-6 weeks and happens once per Major release.
+
+:::info More info
+
+We recommend that you follow the [QA testing guide](/general/development/process/testing/qa) to know more about the Quality Assurance test cycle.
+
+:::
+
+For major theme changes, additional manual tests may be run.
+
+## Automated testing
+
+### Unit tests
+
+PHPUnit tests are supported as part of the code from Moodle 2.3 onwards. These are automated tests of very low-level code functionality that a developer should write as part of any new code.
+
+:::info More info
+
+We recommend that you follow [[PHPUnit integration]] to help you run and write unit tests.
+
+:::
+
+### Acceptance tests
+
+Moodle uses a framework called Behat to automatically test the user-interface. Tests can be written for each plugin, and for Moodle core.
+
+- To run the existing tests, read [[Running acceptance test]]. You really need to do this first.
+- To write new tests, read [[Writing acceptance tests]].
+- To define new steps that can you used when writing tests, see [[Writing new acceptance test step definitions]].
+
+:::tip
+Because Behat tests work through the Moodle user interface, they are a bit slow. Therefore, you should probably also use PHPUnit to test the detailed edge cases in your code.
+:::
+
+### Continuous integration testing
+
+As soon as code is added to the integration repository, the 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.
+
+- [[Unit tests]] using the PHPUnit framework
+- [[Acceptance testing]] using the Behat framework
+- Performance testing using JMeter.
+
+:::note
+Moodle uses a sponsored version of [BrowserStack](https://www.browserstack.com/) for testing on multiple browsers.
+:::