Good day team. The unit test `\core_grades\output\general_action_bar_test::test_export_for_template_admin` has the data provider `\core_grades\output\general_action_bar_test::test_export_for_template_provider`. This data provider has hard coded values for specific 'gradereport' plugins. This goes against a plugin architecture, because the moment you add a new 'gradereport' plugin, this unit test breaks.

This test can be viewed on file 'grade/tests/output/general_action_bar_test.php', or https://github.com/moodle/moodle/blob/master/grade/tests/output/general_action_bar_test.php. This unit test was created by @Mihail Geshoski in ticket https://tracker.moodle.org/browse/MDL-72873. I'm naming him directly in hopes that maybe he can come up with an alternative for this test, that doesn't involve hard coding the values of the existing 'gradereport' plugins.

A possible solution would be to change the focus of the test a little bit. The following are the two failing PhpUnit assertions:

$this->assertEquals(count($expectedoptions[$groupname]), count($groupoptions));

// And:

$this->assertTrue(in_array($option['name'], $expectedoptions[$groupname]));

When adding a new 'gradereport' plugin, the first assertion fails because the `count` of 'gradereport' plugins is hard coded. The second assertion fails if one of the plugins is renamed.

For example, inside the data provider, the dataset identified by 'Gradebook general navigation for admin; outcomes disabled.' contains exactly 5 View values:

'View' => [    'Grader report',    'Grade history',    'Overview report',    'Single view',     'User report',],

If you add a new 'gradereport' plugin, for example 'My Grader report', this test fails, because the expected `count` is of 5 plugins, but the observed one is of 6. In order to uphold Moodle's plugin architecture, this test should not fail when adding new 'gradereport' plugins.

Thank you so much for your attention to this issue.