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
Currently all offchain tests are crafted in test/Tests/Main.purs These tests include both :
unit tests of offchain code
integration tests for the trustless-sidechain
The tests are executed as one nix target from CI.
The idea here is to separate the offchain unit tests, similar to what we have in the haskell onchain code. This separation has allowed us to get a quick feed back cycle when we modify the haskell code. We would like the same approach for the offchain code as well. Here is the proposed approach:
create a separate integration test module in purescript.
create a separate nix target for those test
pipeline the ci/cd such that integration tests are run after the uni tests.
Why should we do this:
Not all projects/initiatives require integration tests. This will allow us to iterate faster as we can lower the threshold for merging to the master branch. For instance, we might agree the requirement for merging to master is for all unit tests to pass and have nightly jobs that run the integration tests against the master branch
we might agree the requirement for merging to master is for all unit tests to pass and have nightly jobs that run the integration tests against the master branch
I don't like this proposal. Firstly, due to the nature of our project unit tests have minimal coverage of the code. There is no way to unit-test whether a transaction is correct - it must be run on the blockchain to actually check that. And so all the real testing happens in the integration tests. Disabling it for the purposes of PR merging essentially means not testing before the merge.
Currently all offchain tests are crafted in test/Tests/Main.purs These tests include both :
The tests are executed as one
nix
target from CI.The idea here is to separate the offchain unit tests, similar to what we have in the haskell onchain code. This separation has allowed us to get a quick feed back cycle when we modify the haskell code. We would like the same approach for the offchain code as well. Here is the proposed approach:
Why should we do this:
IOG Jira: https://input-output.atlassian.net/browse/ETCM-7665
The text was updated successfully, but these errors were encountered: