Testing for Pull Requests

When submitting pull requests to Draft.js, contributors are asked to follow the Pull Request Template. The template includes a “Test Plan” field, which should be used to detail the testing process used by the developer.

The details of the test plan help determine that the request resolves the relevant issue and does not introduce new issues. Changes within this framework have a direct impact on users across browsers, platforms, and locales, at Facebook and elsewhere. The burden for thorough testing falls on developers (and their tests!) to ensure that users have a smooth and error-free experience.

This document describes the desired testing approach to include with your pull request, depending on the types of changes being made.

Changes to /src

Changes to /model should generally be testable strictly via unit tests, since they do not involve browser-specific behavior. Changes to /component may be more challenging since cross-browser and cross-platform quirks are difficult to automate, but should still be covered by unit tests whenever possible.

• Unit tests

  • If your change modifies logic that is currently covered by a test spec, it must pass the spec or the spec must be modified with the pull request.
  • If your change is not currently covered by a test spec, please add one or more specs to thoroughly cover it.
  • If your change modifies a module that does not currently have a test, please add a test for the module, as well as any specs relevant to your change. <3

• Flow

  • Draft.js uses the Flow typechecking system. Your changes must include Flow typechecks throughout, and your pull request must pass Flow checks.
  • Whenever possible, please avoid generic types like Object and any, and instead define strict Flow types as needed.

• Sanity check

  • Consider loading Draft.js examples in the browser to verify that your changes do not affect basic loading and rendering.

Component changes tend to be more challenging to test, since they often require manual browser testing. For that reason, we provide an extensive manual test plan for component changes. Please use it as a guide for testing your change in the browser.

Changes to /examples

• Load the example in the browser.
• Manually test relevant changes.
• If your change may affect rendering or behavior across browsers or platforms, perform manual testing to verify proper behavior.

Changes to /docs

• Visually verify that markdown changes are correct.
• Check for typos.
• If making changes to markdown headers of doc files, please load the website to verify that doc pages render properly and remain correctly linked.