v1.0.2

Most of this release came from adopting cases in a terminal client: its tab strip, its connection
states and its session store. Everything below is new format, and three changes are ones an
existing suite may notice. They are marked.

Drag one element onto another

{ "locator": "TabItem#firstTab", "act": "drag", "to": "TabItem#secondTab" },
{ "locator": "Text#tabOrder", "act": "read", "reads": "name", "expect": "Second, First, Third" }

drag presses on the step's element, moves past the system drag threshold in paced steps, and
releases over the element to names in the same window. It is for the gesture no UI Automation
pattern expresses, such as a tab strip reordered by dragging. Like click, it needs the foreground,
and a desk that won't give it is a hole rather than a red. A drag with no to is refused at load,
and so is a to beside any other act.

Read the state an element publishes, and find an element by it

"reads": "status" returns UI Automation's ItemStatus: the words a screen reader announces for a
coloured dot, such as Connected or Reconnecting. An element that publishes none reads as the
empty string, not as nothing observed. A locator can select by it, so a case finds the connected tab
without knowing its title:

{ "locator": "TabItem[status=\"Connected\"]", "act": "read", "reads": "name", "answers": true }

Claim that a reading is empty

"empty": true claims the element is there and its reading says nothing, such as a field a form
must leave blank or a tab with no state to report. Unlike absent, a locator that matches nothing
fails it. It is refused beside a reading such as focused that answers for every element.

A reading the element cannot give fails at once (may notice)

A step reading value off a ComboBox that is not editable used to poll its whole deadline and fail
with "nothing answered". That ComboBox offers no Value pattern, so the step now fails immediately,
naming the missing pattern and the readings the element does give:

ComboBox #SignIn has no Value pattern, so 'value' can never answer for it, and what it does offer
reads as 'picked', 'expanded', 'name'

The verdict is the same red as before. What changes is that it arrives seconds sooner, and its
sentence tells you which reading to use instead.

A case that stops short closes what it expanded

When a case stops partway (a step threw, or an act was never sent), it now collapses whatever its
expand steps opened and its own collapse steps had not closed. This goes through the pattern, so
the tidy needs no foreground, and each collapse is a line in the trace. Before this, a drop-down left
open by one red case could hold the desk and degrade the next case. A case that runs to its end is
left exactly as its last step left it.

Fixtures: servers, staged layouts, and filled stores

reaches names what the application connects to outside itself, as a host:port or a
%VARIABLE%. Before every launch the run opens a TCP connection to each one, using
timeouts.reach (2000 ms by default). If any is not listening, the application is never
launched, and every check in the case is a hole naming the address. If all are, {reach0},
{reach1} and so on in arguments and variables become the addresses that were reached.
winwright starts no server; that stays the project's job.

A files entry can say where it lands under the staged directory, for a store one folder down:

"files": [
  { "from": "cases/fixtures/sessions.json", "to": "YourApp/sessions.json", "fill": true },
  "cases/fixtures/theme.json"
]

A to that is absolute, or climbs out with .., is refused. (May notice.) Two entries landing
on the same path are now refused at load, naming both. That includes two plain files with the same
name from different folders, which used to overwrite each other silently. A suite that did this was
reading whichever file was declared last.

"fill": true replaces {reach0} and so on, and {files}, inside the staged copy's text, so a
store names its server once, in reaches. A file landing as .json has every replacement
JSON-escaped, so "store": "{files}" parses. Any other file is filled raw. A file asked to be filled
that is not UTF-8 is refused by name.

One declaration for every build

A path in winwright.json may carry {configuration}:

{ "executable": "bin/{configuration}/net10.0-windows/YourApp.exe", "configuration": "Debug" }

The value comes from, in order: the configuration passed to ProjectDeclaration.Load(path, configuration), then the WINWRIGHT_CONFIGURATION environment variable, then the file's own
configuration. CI sets the variable for its Release job, and a developer's runner gets the default
without doing anything. A path whose token nothing fills is refused when it is asked for, naming the
key and the variable, so a run never launches a path with a brace in it.

A redirected profile says it only reaches some applications (may notice)

A fixture that sets APPDATA, LOCALAPPDATA, USERPROFILE or HOME now says so on its own line
and on every case line run against it. The sentence is setting APPDATA as a variable only — an
application asking Windows for that known folder still reads the real profile. Most Windows
applications find their data through the known folder, which ignores the variable. A case that
staged a store that way could be green about the real profile's store. Nothing is refused, because
winwright cannot tell the two kinds of application apart, but the report no longer reads as though
the redirect covered both.

What's Changed

• chore(deps): bump sharp from 0.35.4 to 0.35.5 in /site/docs by @dependabot[bot] in #4
• chore(deps): bump smol-toml from 1.8.0 to 1.9.0 in /site/docs by @dependabot[bot] in #3
• chore(deps): bump source-map-js from 1.2.1 to 1.2.2 in /site/docs by @dependabot[bot] in #2

Full Changelog: v1.0.1...v1.0.2