Spaces

A space is where you run tests and collect results. For Manual testing, it's also where the underlying content comes from — either specs and includes managed in-app, or a checkout point in a connected repo.

	Standalone	Connected
A space is	Created manually	A branch in your repo
Enable Manual Testing	A checkbox on the space	A .testspace.yml file in the repo
Release vs. Sandbox	Set explicitly when creating/editing the space	Default branch = release; others = sandbox, or configured via release:
"Branching"	Duplicate a space	Create a branch
Merging changes	Merge a space into another	Merge a pull request

Standalone

Enabling Manual Testing

When creating (or editing) a space under a Standalone project, check Enable Manual Testing. The Manual tab appears immediately — no further setup needed. See Standalone Projects for the rest of a space's settings (Name, Description, Sandbox, etc.).

note

Enable Manual Testing is a per-space setting, not project-wide — different spaces in the same project can differ. A space duplicated from a manual-enabled space stays manual-enabled automatically.

Publish Path

Nested under Enable Manual Testing (hidden until it's checked) is an optional Publish Path — where this space's results nest in the results tree. Blank by default. This is Standalone's equivalent of Connected's .testspace.yml publish_path setting (see Connected below).

Release vs. Sandbox

Every space is either a release space (used for real test execution and its results) or a sandbox space (used to develop and try out tests in isolation). See Standalone Projects for what Sandbox changes for a Standalone space specifically.

If you're coming from git

Spaces are Standalone's equivalent of branches:

If you think in git terms...	...the Standalone equivalent is
Branch	Space
Default branch (main)	Primary release space
Feature branch	Sandbox space duplicated from a release space
git checkout -b feature	Duplicate a space
Merge a pull request into main	Merge a space into another space
git log <file>	A spec/include's Version History dialog
git revert	Restore a version from history

Duplicate a Space

Space options → Duplicate creates a full copy of a space's specs and includes into a new space. The duplicate defaults to Sandbox mode.

Merge a Space

Space options → Merge into… pushes spec and include changes from one space into another. Before you confirm, the merge preview shows counts by type (Specs: X added… / Includes: Y added…).

For each spec and include, merging compares its current content in the source and target spaces against the state when the target was duplicated from the source:

Since duplication...	What happens on merge
Neither side changed	Nothing — content is already identical
Only the source changed	Target is updated to match the source
Only the target changed	Nothing — the source has nothing new to contribute
Both sides changed	Target is overwritten with the source's version, and flagged as a conflict
New in the source (or deleted from the target)	Added to the target
New in the target (or deleted from the source)	Left untouched

info

Deleting a spec/include from the target doesn't survive a later merge from its source. Merge detects what's "new in the source" by whether a matching item currently exists in the target — not by comparing against the duplication baseline. So if you delete something from the target and then merge from a source that still has it (even unchanged since duplication), it gets silently re-created in the target, undoing your deletion. To remove something from the target for good, delete it from the source too before merging.

info

A conflict means someone edited this spec/include in the target space after it was duplicated — and that edit is about to be silently overwritten by the source's version, not merged line-by-line. It's the same shape of problem as a conflicting git merge: both sides moved on from a common ancestor, and one side has to win. Here, the source always wins — the target's prior version isn't lost (it's in Version History), but it's no longer what's live unless you restore it. See Resolving merge conflicts below.

note

Specs and includes are merged as two separate steps. If a merge fails partway through, it's possible for specs to be merged without their includes (or vice versa) — worth a re-check if a merge looks incomplete.

Resolving merge conflicts

1. A flagged row shows an orange alert icon — hover for "Merge conflict — both sides were edited."
2. Open History on that row. The Version History dialog shows a conflict banner.
3. Restoring an earlier version resolves it — the conflict flag clears automatically.
4. If the current (overwritten) content is actually fine as-is, use Mark as resolved to clear the flag without changing anything.
5. Editing and saving the spec/include normally also clears the conflict flag.

Connected

.testspace.yml

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

manual:

info

For the full .testspace.yml configuration reference, see here.

Branches are Spaces

When a Testspace project is connected to a repository, each space maps to a branch. Spaces are automatically created and deleted based on repository activity.

A space is either in release or sandbox mode. A repo's default branch (e.g. main) is always a release space; all other branches are sandbox unless explicitly configured. The example below sets any branch containing release_ as a release space:

.testspace.yml

manual:

release:
  - "*release_*"  # i.e. "release_56" branch used for test execution

tip

See Branch Workflow for recommended branching strategies (main flow, release flow, hotfixes, carrying results forward).

Folders

Specs can be organized using repo source folders. Testspace automatically recognizes the folders and presents them in the listings.

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

tip

For a Standalone project, a spec's folder is set per spec, at creation — see Creating & Editing Specs.

info

For more information on Folders, refer here.