Change Details

Currently, the unit tests of swh-web heavily rely on mocking the methods of the swh.storage.Storage class. While the approach works, there is a couple of drawbacks with it: - tests implementation are hard to read and maintain for a newcomer - tests data are hardcoded and can end up not synchronized with the latest swh-storage schema - maintaining tests full of mocks is painful and too much time consuming If the tests could be executed using a dedicated storage database containing sample data, their writing will be much easier while using the current swh-storage schema. Maybe the new feature implemented in D538 could be used. I do not have a solution so far but I open that task to keep track of what is feasible.

Currently, the unit tests of swh-web heavily rely on mocking the methods of the swh.storage.Storage class. While the approach works, there is a couple of drawbacks with it: - tests implementation are hard to read and maintain for a newcomer - tests data are hardcoded and can end up not synchronized with the latest swh-storage schema - maintaining tests full of mocks is painful and too much time consuming These tests must be rewritten using the new in memory storage.

Currently, the unit tests of swh-web heavily rely on mocking the methods of the swh.storage.Storage class. While the approach works, there is a couple of drawbacks with it: - tests implementation are hard to read and maintain for a newcomer - tests data are hardcoded and can end up not synchronized with the latest swh-storage schema - maintaining tests full of mocks is painful and too much time consuming If the tests could be executed using a dedicated storage database containing sample data, their writing will be much easier while using the current swh-storage schema. Maybe the new feature implemented in D538 could be used. I do not have a solution so far but I open that task to keep track of what is feasible. These tests must be rewritten using the new in memory storage.