Skip to main content

Configuration

Manual tests, known as test specs, are written using Markdown files (*.md) are maintained in the code section of the repo. By default, test specs are stored in a folder named specs.

To enable manual testing, a .testspace.yml configuration file is required at the root of your repo with the following minimum content: 

manual:

The following is a simple example directory structure containing 2 test specs:

root
├─ README.md
├─ .testspace.yml
└─ specs
     └─ myspec1.md
     └─ myspec2.md
     ..
..

The .testspace.yml file is the main mechanism used to configure how Testspace discovers and manage testing sessions.

important

Without the .testspace.yml file, test specs will not be visible in Testspace

In addition to the YML file, Folders and Branches are also automatically discovered and used by Testspace.

.testspace.yml​

To enable manual testing a .testspace.yml configuration file is required at the root of your repo with the following minimum content: 

manual:

The full .testspace.yml configuration format is:

manual:
  path: "/path/to/thespecs" # optional path to specs root, defaults to "specs"
  publish_path: "path/to/report" # optional Testspace result's path to publish status to, defaults to ""
  issues:
    provider: "jira:project-key" # optional, defaults to "github:" (current org/repo)
    label: # optional, defaults to "testspace"

release: "*_rel" # optional one or more branch-wildcard entries

path​

The path represents the root folder for spec files. It the path is omitted, the root defaults to specs.

manual:
  path: "/path/to/thespecs" # optional path to specs root, defaults to "specs"

publish_path​

The publish_path represents the folder-path to publish status. It the publish_path is omitted, the root defaults to "".

manual:
  publish_path: "/path/to/report" # optional path to specs root, defaults to "specs"

Note that the publish_path is typically only used when publishing automated results into the same space.

Issues​

The provider used to configure which provider to use. Defaults to GitHub and the current repo.

The label used for automatic setting of the generated issue. Defaults to testspace.

Release​

Testspace can be customized to manage "non" default branches as release branches, enabling the space to be used for manual execution vs test development. 

release: 
  - "*_rel.1*" # optional one or more branch-wildcard entries
  - "*_rel.2*"
important

When using * or &, at the beginning of a wildcard, make sure to use quotes.

Example​

Following shows publishing manual results to a unique folder at the root called "manual tests". All branches created using the string "_release" in its name, will be used for test execution. 

manual:
  path: "manual-tests"
  publish_path: "manual results"
  issues:
    label: "testspace-bot"
release:
  - "*_release*"

Folders​

Test specs can also be organized into groups using repo source folders. When a large number of test specs are required, it is often useful to group similar tests in folders. Testspace automatically recognized the folders and presents them in the listings. 

root
├─ README.md
├─ .testspace.yml
└─ specs
     └─ folder1
        └─ myspec1.md
        └─ myspec2.md
     └─ folder2
         ..
..
info

For more information on Groups refer here.

Branches​

A repo's default branch (i.e. main) is always a release space. All other branches are sandbox spaces unless explicitly configured as a release branch. The example configuration below sets all branches with the string release_ in its name as a release space:

.testspace.yml
manual:
  
release:
  - "release_*"

A branch - Sandbox space - is used to isolate new test development without affecting other release branches in the repository. Sandbox spaces do not persist spec runs.

important

Sandbox spaces do not persist spec runs.