Since adding full-fledged Selenium tests is proving difficult (see https://phabricator.wikimedia.org/T220758 for an example), I propose that we lean more heavily on headless JS unit tests to ensure that the basic happy-paths in the Filepage UI are functioning.
Some things that we could test (assuming we mocked the appropriate aspects of the environment):
- When the StatementsPanel is toggled into edit mode by the user clicking a "make prominent" link, the cancel/publish widget also appears in the correct state
- Statements: user can add, remove, promote, and demote (in terms of prominence) by clicking the appropriate links
- Captions: user can add, remove, and expand/collapse a list of captions
- Validation: overly long/short inputs are appropriately rejected
Testing with a mocked API endpoint will not be as good as testing against the real API but it will at least allow us to catch UI bugs and regressions (a non-trivial subset of tickets).
For some trivial features (like the LicenseDialogWidget) we can do this now. But much of this work will require the re-factoring of parts of the codebase (like the Statements code) in order to use PackageFiles & require statements (so that components can be easily isolated for testing).