Change Details

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.

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.

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.