Different styles have been used in packages/rangelink-vscode-extension/qa/qa-test-cases-v1.1.0.yaml and in tests under packages/rangelink-vscode-extension/src/integration-tests.
The goal is to have tests be as direct as possible in instructions. They must not state what has been done/prepared in the test's setup.
Many tests have - 'Extension installed from .vsix build' as a preconditions -- those are a waste and noise given all tests are about testing the extension.
In some tests, the steps in YAML file do not say the same as the waitForHuman() or waitForHumanVerdict() calls. status-bar-menu-001 test is one example of so many in the same situation.
What can we do to improve this duplication/drift ? Feels like automated: assisted tests could simply omit the preconditions and steps YAML arrays given the integration test will cover it ? Perhaps same for automated: true ?
What else can we improve/streamline ?
Different styles have been used in packages/rangelink-vscode-extension/qa/qa-test-cases-v1.1.0.yaml and in tests under packages/rangelink-vscode-extension/src/integration-tests.
The goal is to have tests be as direct as possible in instructions. They must not state what has been done/prepared in the test's setup.
Many tests have
- 'Extension installed from .vsix build'as apreconditions-- those are a waste and noise given all tests are about testing the extension.In some tests, the
stepsin YAML file do not say the same as thewaitForHuman()orwaitForHumanVerdict()calls.status-bar-menu-001test is one example of so many in the same situation.What can we do to improve this duplication/drift ? Feels like
automated: assistedtests could simply omit thepreconditionsandstepsYAML arrays given the integration test will cover it ? Perhaps same forautomated: true?What else can we improve/streamline ?