Note:

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

Plugin QA prechecks: Difference between revisions

From MoodleDocs
(Create the page)
 
(Wording improvements)
Line 1: Line 1:
{{Plugins development}}
{{Plugins development}}


Plugin QA prechecks are tests of the basic functionality of plugins submitted for approval in the Moodle Plugins directory. Together with [[Plugin code prechecks|code prechecks]], they are part of the plugin [[Plugin contribution|approval process]].
Plugin QA prechecks are for testing the functionality of plugins submitted for approval in the Moodle Plugins directory. Together with [[Plugin code prechecks|code prechecks]], they are part of the plugin [[Plugin contribution|approval process]].


These QA prechecks can be performed by any Moodle community member. They allow the developers to focus fully on the code review and so they significantly contribute to the fluent flow of the plugin approval reviews.
Moodle community members with experience in setting up a local Moodle test environment can help with plugin QA prechecks. They are added to the [[Plugins guardians]] group and can view plugins awaiting approval in the Moodle plugins directory.


The main areas covered by the plugin QA include:
== QA environment setup ==


* Checking the plugin description and some other plugin's meta-data.
To perform plugin QA prechecks, you need to have a test Moodle site (normally the latest stable version) installed locally. Your test site should have
* Installing the plugin to see that it does not break or otherwise negatively affect the site functionality (anti-regression test). This also checks that all eventual dependencies are already available in the plugins directory.
* If possible (e.g. if no complex integration with an external system is needed), test the actual functionality of the plugin to see it works as described (feature test).


See [[Plugin contribution checklist#Meta-data|Meta-data]] and [[Plugin contribution checklist#Usability|Usability]] sections at the plugin contribution checklist page for details.
* Developer debugging enabled with debugging messages displayed in order to report all PHP notices, warnings and errors spotted during plugin installation and usage.
* <tt>$CFG->prefix</tt> set to a non-default value, such as "m_" or "mqa_". This allows to catch cases when the default "mdl_" prefix is hard-coded in PHP.


=== QA environment setup ===
In addition, if possible the site should run on the PostgreSQL database engine to catch potential MySQL-specific SQL statements in the code.


* Have developer debugging enabled with debugging messages displayed.
== Process ==
* Report all PHP notices, warnings and errors spotted durign the plugin installation and usage.
* It is recommended to test on a site running on PostgreSQL database engine to catch potential MySQL-specific SQL statements in the code.
* Have the <tt>$CFG->prefix</tt> set to a non-default value, such as "m_" or "mqa_". This allows to catch cases when the default "mdl_" prefix is hard-coded in PHP.


=== Process ===
# Choose a plugin needing an initial review from the [https://moodle.org/plugins/report/index.php?report=pendingapproval_plugins list of plugins awaiting approval].
# Download and install it on your test site then perform the QA prechecks as listed below.
# Add a comment to the plugin approval issue (CONTRIB-xxx as mentioned at the plugin page comments area) with your findings using the 'Plugin QA checklist' canned response.


# Pick a plugin from the list of plugins awaiting approval.
==QA prechecks==
# Perform the QA prechecks.
 
# Comment on the relevant plugin approval issue (CONTRIB-xxx as mentioned at the plugin page comments area, or at its development tab) and report your findings.
# Does the plugin have all the appropriate metadata as described in the [[Plugin contribution checklist]]?
# Does the plugin install nicely and not break or otherwise negatively affect the site functionality (anti-regression test)? This also checks that all eventual dependencies are already available in the plugins directory.
# If possible (e.g. if no complex integration with an external system is needed), test the actual functionality of the plugin to see it works as described (feature test).

Revision as of 06:51, 25 October 2021


Plugin QA prechecks are for testing the functionality of plugins submitted for approval in the Moodle Plugins directory. Together with code prechecks, they are part of the plugin approval process.

Moodle community members with experience in setting up a local Moodle test environment can help with plugin QA prechecks. They are added to the Plugins guardians group and can view plugins awaiting approval in the Moodle plugins directory.

QA environment setup

To perform plugin QA prechecks, you need to have a test Moodle site (normally the latest stable version) installed locally. Your test site should have

  • Developer debugging enabled with debugging messages displayed in order to report all PHP notices, warnings and errors spotted during plugin installation and usage.
  • $CFG->prefix set to a non-default value, such as "m_" or "mqa_". This allows to catch cases when the default "mdl_" prefix is hard-coded in PHP.

In addition, if possible the site should run on the PostgreSQL database engine to catch potential MySQL-specific SQL statements in the code.

Process

  1. Choose a plugin needing an initial review from the list of plugins awaiting approval.
  2. Download and install it on your test site then perform the QA prechecks as listed below.
  3. Add a comment to the plugin approval issue (CONTRIB-xxx as mentioned at the plugin page comments area) with your findings using the 'Plugin QA checklist' canned response.

QA prechecks

  1. Does the plugin have all the appropriate metadata as described in the Plugin contribution checklist?
  2. Does the plugin install nicely and not break or otherwise negatively affect the site functionality (anti-regression test)? This also checks that all eventual dependencies are already available in the plugins directory.
  3. If possible (e.g. if no complex integration with an external system is needed), test the actual functionality of the plugin to see it works as described (feature test).