The current coverage for the FileImporter extensions PHP code is about 40%. This is better than many other codebases, but not ideal. A good coverage of at least 60%, better 80% increases confidence and allows the team to apply changes to a codebase much faster, with much less fear.
Acceptance criteria for this task is a coverage of at least 80%, with a sensible mixture of unit and integration tests (this means a few integration tests that cover everything are not sufficient).
Currently highest ranked "project risks" according to https://doc.wikimedia.org/cover-extensions/FileImporter/dashboard.html, most critical first:
- T190821 ApiDetailRetriever is already tested with a line coverage of about 67%. The code is quite complex (long and deeply nested), that's why this is ranked higher than anything else.
- T190825 FileChunkSaver is technically part of HttpRequestExecutor::executeAndSave() and could be tested via HttpRequestExecutorTest, but current isn't.
- T190826 Importer is technically part of SpecialImportFile::doImport() and could be tested via SpecialImportFileIntegrationTest, but currently isn't.
- T190828 SpecialImportFile::doImport() is uncovered. See above.
- T190829 WikiTextEditor appears trivial, but interacts with the super-complex EditPage. Some kind of integration test should make sure this interaction can't break.
"Low hanging fruits" that don't need any integration testing, but a trivial unit test only. In order of significance, more critical first:
- HttpApiLookup should definitely have it's separate unit test.
- ImportDetails is quite small, but does have many methods. A separate unit test should be very easy to create.
- ImportOperations
- TextRevisions
- FileRevision
- FileRevisionFromRemoteUrl
- TextRevision
- DuplicateFileRevisionChecker
- ImportPlan
- See https://doc.wikimedia.org/cover-extensions/FileImporter/dashboard.html for more.