Testing
Check test coverage and ensure all tests pass
When is this needed?
When changing/refactoring existing code
Details
- Ensure the code being worked on has test coverage.
- No patch can be marked RTBC if there are outstanding test failures, since core has a 100% pass rate policy.
- If the issue might affect specific environments differently (such as a change affecting how database queries are built), the test-only patch should be tested against all supported environments in the automated testing infrastructure.
Resources
Drupal core automated testing results
Add new tests
When is this needed?
When adding new features
Details
- New features should be accompanied by automated tests.
- If the feature does not have an implementation, provide a test implementation.
- Use UnitTestCase, KernelTestBase, BrowserTestBase or WebDriverTestBase as appropriate.
Resources
Upload a test case that fails
When is this needed?
When fixing bugs in PHP code
Details
Bug fixes should be accompanied by changes to a test (either modifying an existing test case or adding a new one) that demonstrate the bug. This can be shown by running the 'tests only' job in the GitLab merge request pipeline interface. The failing test's output should be documented on the issue.
If a bug fix is not accompanied by tests, there should be an explanation in the issue for why no tests are needed (usually only for trivial bugs where testing would be convoluted) before it is marked RTBC.
Merge requests that need tests written can have the Needs tests tag added.
If the issue might affect specific environments differently (such as a change affecting how database queries are built), the test-only patch should be tested against all supported environments in the automated testing infrastructure.
See Add new tests for documentation about test types.
Check if a test may not be needed
An automated test for a bug fix may not be needed if the following are true and if the majority of answers to the questions below is 'Yes'.
- The issue has clear ‘Steps to reproduce’ in the Issue Summary.
- The fix is 'trivial' with small, easy to understand changes.
Questions
- Is the fix is easy to verify by manual testing?
- Is the fix in self-contained/@internal code where we expect minimal interaction with contrib? Examples are plugins, controllers etc.
- Is the fix achieved without adding new, untested, code paths?
- Is an explicit 'regression' test needed?
- Does the issue expose a general lack of test coverage for the specific subsystem? If so, is it better to add generic test coverage for that subsystem in a separate issue?
- If this fix is committed without test coverage but then later regresses, is the impact likely to be minimal or at least no worse than leaving the bug unfixed?
Resources
Add JavaScript test
When is this needed?
When making JS changes
Details
Add a PHPUnit JavaScript test must be included with the patch (preferred) or a followup filed to add a JavaScript test.
Resources
Manually test in browsers and provide screenshots or screencasts
When is this needed?
When making markup or CSS changes
Details
Drupal core does not have automated visual regression testing. Changes to CSS or markup should normally be accompanied by confirmation that this has been tested in the browsers Drupal core currently supports. For large changes or bug fixes, screenshots or screencasts are ideal for demonstrating the impact of the changes.
Resources
...
Provide an example module
When is this needed?
When a new feature is not implemented by Drupal core/p>
Details
When adding major new features that are not implemented by core (i.e. API-only features), example code should be provided that demonstrates the feature (typically in a test module in core).
Resources
Review
2011: Original discussion: http://groups.drupal.org/node/158774
Help improve this page
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion
