Guidelines for automated test contributions

Contribute to DKG by growing the automated test suite for the ot-node!

Welcome to the automated tests contribution guidelines! By contributing to the ot-node automated test suite, you help further develop the OriginTrail technology and increase the robustness of the DKG implementation. Detailed instructions on how you can participate are described below. However, if you need any assistance, feel free to jump into Discord and ask for help from the community or core developers there.

This guide applies to the DKG node GitHub repo, particularly for the v8 branches (v8/develop being the default branch). If you are creating a contribution, branch off from v8/develop.

We use Cucumber.js for running automated tests. This framework uses the Gherkin language, which allows expected software behaviors to be specified in a logical language that can be easily understood.

For a detailed guide on how to write BDD scenarios, visit Cucumber docs.

Tests need to cover errors listed on the GitHub discussions page. Different errors are thrown in different commands, all of which are executed by the command executor. To learn what the command executor is and how it works, please visit Command Executor.

Steps to contribute BDD tests

1. Check out GitHub discussions to see current test requirements. Check out the existing steps available in ./ot-node/test/bdd/steps.

2. Create a feature file where you'll define new scenarios. Features should be located in test/bdd/features directory with the appropriate file name format: <operation>-errors.feature (e.g., publish-errors.feature, get-errors.feature).

3. When you're done with the scenarios that you've created, following the Contribution guidelines, create a draft pull request (PR) and tag at least two core developers (and as many other community members as you wish). The team members will review the feature files and either give approval or request for changes. Once you get a confirmation that the feature files are satisfactory, you can continue with the corresponding step definitions. This helps provide feedback on the contribution early on.

4. Put step definitions in the ./ot-node/test/bdd/steps directory.

5. Implement the steps and ensure that both old tests and the new ones you just created are passing locally (use the npm run test:bdd command). Node logs can be found in ./ot-node/test/bdd/log/<scenario-name>/origintrail-test-<index>.log(e.g. test/bdd/log/Publishing-a-valid-assertion/origintrail-test-0.log).

6. When you're satisfied with the scenarios and their step definitions, you may now mark your PR draft as "Ready for review".

7. There will likely be feedback on your PR before it gets approved, so make sure to follow the status of your PR contribution. After PR approval, your changes will be merged.

8. Congratulations! You've just made ot-node more robust 🎉