Change Details

Currently the lister are partially tested, mostly through mocks (and easily debugged when something goes wrong). Sometimes, they do not break because the coverage is not enough. Now that a `swh-listers` fixture got introduced (D2077), we should at least add one integration test per lister.

Currently the lister are partially tested, mostly through mocks (and not easily debugged when something goes wrong). Sometimes, after a refactoring, they do not break because the coverage is not enough. Now that a `swh-listers` fixture got introduced (D2077), we should at least add one integration test per lister for the basic listing use case. Plan (so far): - all listers: 1 basic listing (checking the lister's output in the scheduling db) Ideally, adding those would be best: - all listers: 1 basic listing failure (e.g lister misconfiguration ; phabricator lister requires api.token set or otherwise it fails, etc...) - all listers: 1 listing with filtering on already seen origins - pagination listers: multiple page calls

Currently the lister are partially tested, mostly through mocks (and not easily debugged when something goes wrong). Sometimes, after a refactoring, they do not break because the coverage is not enough. Now that a `swh-listers` fixture got introduced (D2077), we should at least add one integration test per lister. for the basic listing use case. Plan (so far): - all listers: 1 basic listing (checking the lister's output in the scheduling db) Ideally, adding those would be best: - all listers: 1 basic listing failure (e.g lister misconfiguration ; phabricator lister requires api.token set or otherwise it fails, etc...) - all listers: 1 listing with filtering on already seen origins - pagination listers: multiple page calls