Skip to main content

Implement

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
tip

A Testspace project can be used for publishing test automation results, executing manual tests, or both.

But now, let's implement some Specs.

Basics​

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: Header, Spec Name, and at least one Case Name.

  • 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 # text string. This is H1 in markdown.

    # My Spec

  • Case Name. A case name is defined using a ## text string. 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
tip

See Desktop Preview for developing and reviewing Test Specs on your desktop before committing to the repo.

Of course, you can and should leverage the syntax provided by markdown. There are also additional features such as automated fixtures, variables, and includes with parameters. Refer here for more details.

Implement​

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:

  • Lists
  • Tables
  • Images
  • External Links
note

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 main space.

Run​

Now that you have implemented a few new specs let's run them.

  • Select the Manual tab. A listing of all the specs will be presented
  • Go ahead and execute each of the new specs

Recap​

This section covered the process of implementing test specs.

  • A spec requires a header, a spec name, and at least one case name
  • There are many markdown features that can be leveraged for communicating test instructions