Summary of features to be tested There are four main ways how plugin packages can get installed into Moodle via the admin web interface. New plugin can be explicitly uploaded via "Install plugins" tool. This can happen either by (a) uploading the ZIP file manually, or (b) clicking the "Install" button in the Moodle Plugins directory at moodle.org/plugins. Installing available update. Either (a) in single package mode (install one plugin at a time, as it works in current stable versions), or (b) in a bulk mode (installing all available updates in one step). Installing available missing dependency. Again either (a) one at a time or (b) all missing dependencies at once. Restoring previously archived version when the "Cancel upgrade" feature is used, again in either (a) single plugin mode or (b) multiple plugins mode. When cancelling the plugin upgrade, the admin is actually installing a zipped version that was archived before the update happened. Additionally, the admin is able to Cancel installation / Cancel all installations. That allows the admin to clean up all unzipped packages (being reported as "To be installed") given that the database upgrade did not happen yet. There are three situations where these new features are available: During the Moodle core upgrade: Increase the main $version and visit admin/index.php. After confirming the core upgrade, you should end up on the "Plugins check" page where these features are available. If the core is not being upgraded but any plugin's version is increased or a new plugin is manually unzipped and you visit the admin/index.php page, then you should end up on the "Plugins check" page again. However, internally in the code, this case has always been a separate code flow branch and should be tested separately. By visiting the "Plugins overview" page at admin/plugins.php. This is typically visited to check for available updates and to eventually trigger their installation. Once the available update / updates are installed, the user is redirected to admin/index.php as described in previous use case. Testing environment and setup The easiest way to test for dependencies-related features is to have a simple local plugin that depends on multiple other plugins. Attempting to install this "wrapper" or "collection" plugin should pull in all declared dependencies, given they are available. See an example of such a plugin attached. You can interactively play with it, edit the dependencies info etc. Please note that version numbers in the $plugin->dependencies declaration in a plugin's version.php have always been interpreted as minimal required version. Therefore, if there is more recent version available than the one declared, it will be used. The ANY_VERSION picks the most mature most recent version available for the given Moodle branch. Following $CFG variables affect the plugins management behaviour and should be tested: $CFG->disableonclickaddoninstall (see config-dist.php) - if set, then all the plugins code management features must be disabled. $CFG->upgradekey (see config-dist.php) - added recently and successfully tested in MDL-51261 . However, the affected area of the code has been changed a bit and having the upgrade key working is fundamental security related feature, so it should be tested in the combination with the new features again. Testing and debugging available updates has always been tricky on the master dev versions of Moodle, because the version 3.0 does not exist yet in the Plugins directory. To make it testable, I came up with a simple proxy script (see attached) that you can use as your $CFG->alternativeupdateproviderurl. The script simply accepts the request from your Moodle 3.0, converts it so that it looks like a request from Moodle 2.9 site and fetches real data for you. So you can test these features with plugins from the plugins directory that have 2.9 set as supported version and they will be reported as available updates for your 3.0dev site. Additionally, there are some useful setting for config.php that bypass the updates checker cache so that testing is much more pleasant (in normal behaviour, the information about available updates is cached with certain TTL and is not re-fetched immediately): // Use our fake available updates info provider. $CFG->alternativeupdateproviderurl = $CFG->wwwroot.'/alternativeupdateprovider.php';   // Force the available updates appear as last checked a week ago. $CFG->forced_plugin_settings = array('core_plugin' => array('recentfetch' => time() - 60 * 60 * 24 * 7));   // Display available updates of all maturity levels. $CFG->updateminmaturity = 0; Other notes When installing an older version from the plugins directory, do not use the "Install" button but always download the ZIP. See just discovered MDLSITE-4190 for details. Tricky scenarios to test Two plugins requiring same other plugin, but with different versions: Manually install plugin P1 which requires plugin P2 from the plugin directory with version V1. Manually install plugin P3 which requires P2's higher version V2. Make sure that the higher V2 is resolved as a missing dependency to be installed. Plugin requiring higher version of another already present plugin: Manually install plugin P1 from the plugins directory with older version V1. Manually install plugin P2 that depends on more recent P1's version V2. Make sure that V2 is resolved as a missing dependency. Note that if the maturity of V2 is lower that the set threshold for update notifications, it may not be displayed as available update. Still, it must be possible to install it as a dependency. Dependencies chain: plugin P1 depending on P2, which itself requires P3 etc. This may require repeated use of "Install missing dependencies". If at the end the dependencies resolution fails (e.g. because P8 depends on some P9 that does not exist in the plugins directory, or because P9 cannot be installed due to write permissions to that particular plugin type directory), the admin either has to provide P9 manually (somehow), or cancel the installation of all new plugins that were pulled as missing dependencies.