You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are lacking automatic testing mechanism due to many historical reasons, especially for the very essential functionalities of our system, that is subtasks and helper, up till this point, we have been always testing them manually, which is time consuming and unreliable. it's important for us to build up a automatic testing mechansim to make sure they do what we expect them to do.
Describe the solution you'd like
Testing mechanisms
unit test: white box testing, focus on functional verification, modules/classes/functions are tested separately, employe mocking/injection technique if subject had dependencies. Able to simulate some hard to reproduce scenarios
e2e test: black box testing, in contrast to unit test, e2e-test is more about how subject interacts with other parts of the system as whole, e2e-test focus on the correctness of the output rather than logical correctness.
Strategy for Devlake
All subtasks should have e2e-test, given records from input table, we expect a certain set of reccords from output table, CI would execute these test-cases automactically. Except for collection subtasks, because they depend on 3rd API to function. And most problems we ran into in the past were defects from api_collector which can be covered by follwoing unit-test plan
All helpers (api_collector/api_extractor/data_converter) and other complex modules/classes/functions should have unit-test. Unit test should at least cover following situations:
Positive Cases: in a normal condition, subject must be able to execute and return expected result
Recoverable Cases: when tolerable errors occured, subject should be able to function correctly (i.e. retry mechanism)
Unrecoverable Cases: subject should be able to break out when things go really really wrong.
Race condition: carefully create some race condition if subject would be executed in a parallel context.
Description
We are lacking automatic testing mechanism due to many historical reasons, especially for the very essential functionalities of our system, that is
subtasksandhelper, up till this point, we have been always testing them manually, which is time consuming and unreliable. it's important for us to build up a automatic testing mechansim to make sure they do what we expect them to do.Describe the solution you'd like
Testing mechanisms
hard to reproducescenariosStrategy for Devlake
subtasksshould havee2e-test, given records from input table, we expect a certain set of reccords from output table, CI would execute these test-cases automactically. Except forcollection subtasks, because they depend on 3rd API to function. And most problems we ran into in the past were defects fromapi_collectorwhich can be covered by follwoing unit-test planhelpers(api_collector/api_extractor/data_converter) and other complex modules/classes/functions should haveunit-test. Unit test should at least cover following situations:Plan of attack
api_collector#1656issuerelated e2e test implementation for gitlab plugin #1765Has the Feature been Requested Before?
Maybe