So far, we have manually invoked a GitHub workflow to run fake test automation, and then we executed a pre-canned (also fake) test spec. The Testspace project is being used for:
- capturing the test automation results via publishing for the workflow file
- executing a manual test
- 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 test specs.
Test 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.
A quick note. The reason there is an extra
sub-folder, called manual, in our repo is that we want to store the published results for manual testing and automated testing is separate locations (i.e. folders).
root └─ .github └─ specs └─ manual └─ hello.md └─ syntax.examples.md └─ use.setup.fixture.md └─ .testspace.yml ..
A test spec requires the following:
Suite Name, and at least one
Header. A test spec requires a front matter header block. This is used to uniquely identify the markdown file as a test spec. There are other unique features for front matter that will be covered later. But for now, each test spec requires the following:
--- testspace: ---
Suite Name. The suite name is defined using a
# textstring. This is H1 in markdown.
# My Test
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 Test ## My Case1
Of course, you can and should leverage the syntax provided by markdown. There are also additional features such as
Template Steps, and
Suite Fixtures. 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 own 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 test 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 test specs let's run them.
- Select the
Manualtab. A listing of all the test specs will be presented
- Create a new test Session by clicking the "New Test Session" button and select your new test specs
- Go ahead and execute each of the new tests
- Once all of the tests have been executed Complete the session
This section covered the process of implementing test specs.
- A test spec requires a
suite name, and at least one
- There are many markdown features that can be leveraged for communicating test instructions
- Any number of test specs can be executed within a test session