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.
[x] 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
[x] TextRevisions
[x] FileRevision
[] FileRevisionFromRemoteUrl
[x] TextRevision
[] DuplicateFileRevisionChecker
[] ImportPlan
[] See https://doc.wikimedia.org/cover-extensions/FileImporter/dashboard.html for more.