Creating & Editing Specs
This page covers how a spec actually gets created and changed day to day. For the spec format itself (front matter, cases, Liquid), see Writing a Spec.
| Standalone | Connected | |
|---|---|---|
| Create a spec | "New Spec" button, in-app editor | Add a .md file to the repo |
| Edit a spec | Open it, edit, save | Edit the file locally, commit, push |
| Preview | Live Preview tab in the editor | No in-app preview today — see Desktop Preview |
| History | Version History dialog — restore any past version with one click | Your repo's own git history |
Standalone
Creating a spec
Click New Spec. The form has a Folder field (optional — see Organizing into folders below) and a content editor. Your spec's <H1> title is what Testspace uses to derive its internal identity — see Renaming vs. moving below for what that means in practice. Save, and the spec exists immediately — no separate publish step.
Live Preview
The editor has Write and Preview tabs. Preview renders Liquid for real: variables resolve, {% include %} pulls in actual include content, conditionals and loops run — it's exactly what a tester will see, not a raw-markdown guess. If you're previewing something that depends on a value normally supplied at run time (like an include being tried on its own), an unresolved field shows up as a visible {{ spec.foo }} placeholder rather than silently rendering blank, so a preview gap is obvious rather than looking like the real thing is broken.
Use Preview before you save — it's the fastest way to catch a Liquid mistake or a bad include reference before it ever reaches a test session.
Organizing into folders
The New Spec form's Folder field is optional and only shown at creation. A spec with a folder set appears under that folder's own tab in the left nav, alongside ·Overall· (everything) and No folder (everything without one).
Editing, saving, and moving
Open a spec and edit its content directly. Saving supports an optional Edit message — a short note about what changed, shown later in that spec's version history.
Editing content never moves a spec between folders, even if you change the title — to relocate an existing spec, use Move from the spec row's options menu, which opens a small dialog with just a Folder field.
Renaming vs. moving
Changing a spec's <H1> title is always safe — Testspace tracks a spec by an identifier assigned once, at creation, so renaming later doesn't break anything referencing it. Moving a spec to a different folder is a separate, explicit action (above) — editing content alone never does it.
When a spec won't parse
A spec with a structural error, or one referencing a missing include, can't be selected into a test session at all — it shows a red error indicator in place of its checkbox, both in the Specs list and in session-selection dialogs. This is by design: broken specs are caught before a session starts, not mid-run. Preview (above) is how you catch this while you're still writing.
Version history
Click History on a spec row to open its Version History dialog. Every save creates a new entry (duplicating and merging a space do too). Pick any past version and restore it with one click.
Connected
A Connected spec's canonical content lives in your repo, not in Testspace — you edit it with your own tools and it reaches Testspace through your normal git workflow.
Adding or changing a spec
Add or edit a .md file under your project's specs folder (specs/ by default — see Spaces) and commit and push as usual. Testspace picks up the change automatically. To disable or remove a spec without deleting the file, see Front Matter. Moving a spec is just moving the file — git mv, like anything else in the repo.
Previewing before you commit
There's no live in-app preview for a Connected spec today. Desktop Preview covers using Jekyll locally to render specs before you push.
History
A Connected spec's history is your repo's own — commits, blame, pull requests. There's no separate Testspace-side version history dialog for Connected specs the way there is for Standalone.