How do we separate testing vlei-verifier-worflow utilities, steps, and workflows

[2byrds]

In the legacy reg-pilot project we have a mix of unit tests, integration tests, and workflow integration tests. How do we separate these in this new vlei-verifier-workflow project?
The highest priority is unit testing all underlying code and integration testing common workflows.
Should we be marching towards:

• unit test all non-workflow utilities and functions
• unit test workflow related functionality
• unit test mixtures of workflow steps
• integration test common workflows
• integration test mixtures of workflow steps
• integration test all api, etc. functions
• integration test pairs or sub-sets of workflows

[aydarng]

I think we can approach testing as follows:

1. Unit tests for everything not related to KERIA or the verifier. For example, functions like getIdentifierData, getAgentSecret, buildCredentials, and buildAidData can be covered here.
2. Integration tests for anything involving KERIA or the verifier.
3. Integration tests for entire workflows.
4. Integration tests for subsets of workflows are more challenging because steps often depend on each other (e.g., creating an AID depends on creating a client, creating a registry depends on creating an AID, etc.). We’ll need to find a way to build such subsets, considering these dependencies.
5. While we can’t add an API integration test in the vlei-verifier-workflows, we can add one for the verifier using mocked requests (CESRs, AIDs, etc.).

[2byrds]

I think we can approach testing as follows:

1. Unit tests for everything not related to KERIA or the verifier. For example, functions like getIdentifierData, getAgentSecret, buildCredentials, and buildAidData can be covered here.
2. Integration tests for anything involving KERIA or the verifier.
3. Integration tests for entire workflows.
4. Integration tests for subsets of workflows are more challenging because steps often depend on each other (e.g., creating an AID depends on creating a client, creating a registry depends on creating an AID, etc.). We’ll need to find a way to build such subsets, considering these dependencies.
5. While we can’t add an API integration test in the vlei-verifier-workflows, we can add one for the verifier using mocked requests (CESRs, AIDs, etc.).

Looks good to me @aydarng. Lets make sure we have the first 3 for PRs in the near term. In the medium term we can shoot for 4 and 5. Just a thought but perhaps vlei-verifier-client will provide a mock vlei-verifier as part of its own testing. And then projects like vlei-verifier-workflows can leverage that mock if needed.

[aydarng]

Yes, it sounds good @2byrds