Skip to main content
Azure DevOps stores a test case inside a suite, inside a plan. There is no free place to organize your cases the way you think about them, no easy way to find a case again, and a case linked to nothing is effectively invisible. The Repository tab fills that gap: a folder tree to organize and retrieve your test cases, the way Xray does for Jira — its organisation is saved in Extension Data without changing case content.
Test Repository tab on the Hygiene view before analysis

The Repository opens on the Hygiene view, before any analysis is run.

​
A tree of references, not a copy

The Repository is a TestPulse object, shared at the project level and stored in the extension’s own space. It files references to your test cases (testCaseId), never copies of their content: titles, steps and fields always stay the single source of truth in Azure DevOps. You can create, rename, move and delete folders at any depth, using native drag & drop or a keyboard-accessible “Move to…” menu. A case lives in at most one folder; removing it from its folder sends it back to Unfiled.
Because the Repository stores only references, nothing you do here changes a test case, a suite or a plan in Azure DevOps. Within the Repository, the action writing to plans and suites is generating a plan from a folder, and only after an explicit preview.

​
”Unfiled” — the cases not yet filed

The Unfiled node is not a folder you fill. It is computed: the full set of the project’s test cases, minus the ones already filed somewhere. It is recalculated on every load and never stored, so it always reflects reality. Filing a case removes it from Unfiled; removing a case from its folder puts it back. This is how you make sure no case is quietly forgotten.

​
Search across the whole project

Search by title, id or tag, case- and accent-insensitive, across the entire project — not just the current folder. It is the fastest way to answer “where did that case go?” without walking plans and suites by hand.

​
”Used in N location(s)”

Expand a case to see where it is planned — each plan › suite pair it belongs to. This reuses the same resolution as the coverage signal, so it costs no new permission. Note the deliberate separation: this panel shows planning locations only, never an execution status. Where a case is planned and how it last ran are two different questions, and the Repository answers only the first.

​
Orphans — a case that lives in no plan

A dedicated view surfaces orphans: test cases that exist in the project but sit in no plan at all. The scan is always explicit — you trigger it with a button, it shows progress and can be cancelled, and its result is cached and timestamped so you can re-run it when you want. An orphan is filed like any other case; being an orphan is a computed property, orthogonal to where you filed it. (This node is labelled “Not in any plan” — see Organize at scale for why the wording changed.)

​
Read-only by design

The organisation described on this page does not modify Azure DevOps cases, suites, plans or results. Folders, references and caches are nevertheless saved in Extension Data. It requires no new test write scope. The Repository reads the project’s test cases once and reuses primitives TestPulse already had. If a read genuinely fails, you get an error banner with the real message — a failure is never disguised as an empty project.

Organize at scale

Auto-seed, bulk operations, flat view and manual ordering.

Generate a plan from a folder

Turn a folder into a real ADO plan.

Read-only by design

Why TestPulse reads first.

Permissions

What scopes are used, and when.