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).