So far, we have manually invoked a GitHub workflow to run fake test automation, and then we executed a pre-canned (also fake)
Spec. The Testspace project is being used for:
- capturing the test automation results via publishing
- executing manual test specs
- and managing the status of both types of testing, providing an aggregated view of the health of a project
A Testspace project can be used for publishing test automation results, executing manual tests, or both.
But now, let's implement some Specs.
Specs are maintained in the code section of a
repo using markdown files (e.g. file.md). The default folder to maintain the test files is
specs. This default can be changed, see manual configuration.
root └─ .github └─ specs └─ hello.md └─ syntax.examples.md └─ use.setup.fixture.md └─ .testspace.yml ..
A spec requires the following:
Spec Name, and at least one
Header. A spec requires a front matter header block. This is used to uniquely identify the markdown file as a spec. There are other unique features for front matter that will be covered later. But for now, each spec requires the following:
--- testspace: ---
Spec Name. The spec's name is defined using a
# textstring. This is H1 in markdown.
# My Spec
Case Name. A case name is defined using a
## textstring. This is H2 in markdown. There is no limit to the number of cases within a test spec.
## My Case1
Minimum requirements for a spec file below.
--- testspace: --- # My Spec ## My Case1
Of course, you can and should leverage the syntax provided by markdown. There are also additional features such as automated
includes with parameters. Refer here for more details.
Go ahead and create a set of test specs, each consisting of multiple cases. Check out the different syntax options that can help in communicating the test instructions:
- External Links
For an example of different markdown syntax, take a look at this syntax examples test spec.
Once you have finished adding your test specs, commit and push the changes:
git add . git commit -m "1st cut at tests" git push
Note that you can always verify a spec first in GitHub. Testspace has been designed to match the markdown syntax rendering of GitHub.
Go to your Testspace project and click on the
Now that you have implemented a few new specs let's run them.
- Select the
Manualtab. A listing of all the specs will be presented
- Go ahead and execute each of the new specs
This section covered the process of implementing test specs.
- A spec requires a
spec name, and at least one
- There are many markdown features that can be leveraged for communicating test instructions