Repository navigation
v1.0.1
Two things, and the first is the one to look at: this release carries a documentation area,
published at alegauss.github.io/winwright/docs and
written for a reader who has installed nothing.
Every figure on it is read out of the engine's own C# at build time, never typed: the 121 verbs with
what each needs of the application, the case format straight from the loader's schema, the locator
grammar out of the parser, every winwright.json key with what leaving it out does, and all four
verdicts with their exit codes. A retyped table is wrong at the first rename and silent about it, so
the build fails rather than publishing a figure that drifted. The reference lines an adopter copies
ask nuget.org for the version as the page loads, because the site deploys on demand and cutting a
release does not trigger it — so a generated number would be a version behind from the next release
onward, on exactly the line somebody pastes into a csproj.
The second is the launch, and it carries changes an adopter may notice.
A launch now has a working directory
Found adopting a case for a terminal client. A fixture passing ["--import", "cases/fixtures/profile.ini"] was passing a path the launched application resolved against
whichever directory the test runner happened to be in, so the same argument named three different
files under run-tests.cmd, under dotnet test and in CI.
A launch now starts in the project's root — the directory winwright.json sits in, which is
already what every path that file declares resolves against. A fixture may name another with the new
workingDirectory key, resolved against that same root.
A fixture can give the application a store of its own
The other half of the same problem: a case that needs a known data file had two choices, both bad —
a command-line flag that exists only for the harness, which the application's users then see, or
writing into the real user profile before launching, which the next case tramples.
{
"fixtures": [
{
"name": "with sessions",
"variables": { "APPDATA": "{files}" },
"files": ["cases/fixtures/sessions.json"]
}
]
}files are copied into a directory made for that launch and emptied first, and {files} names
that directory from a variable or from workingDirectory. So a Windows application needs no flag
for the harness at all. The directory is under the system temp rather than in your checkout, because
an engine that writes into your working tree is one that turns up in your git status.
The trace says more about the desk
A step whose keystroke was delivered and one whose desk check passed because an ancestor merely
shared a top-level window used to leave the same record: ok. Trace lines now carry a met field
saying who held the foreground and which of the two findings made it ours — the mirror of the
detail a step that did not run has always carried. Nothing about a verdict changed.
Also: every reading a step may name now ships with the sentence an author needs to pick one, so
picked and selected can be told apart without reading the source.
If you are upgrading
Source-compatible for a case file — workingDirectory and files are both optional, and a fixture
that declares neither behaves as before, except that the launch now starts in the project root
instead of wherever the runner stood. If a fixture argument carries a relative path, check what it
used to resolve against.
Two public API signatures moved, for callers driving the engine directly rather than through a case
file:
FixtureDeclaration.Starting(executable)now takes the project root as well. A default there
would have been the defect this release removes, spelled as a choice nobody made.FixtureDeclaration.Stage(root)hands back aStagedFixture, and composing a launch from it is
what guarantees the files are in place before the process reads them.Startingrefuses where a
fixture needs the staged directory and nothing has staged it.
<PackageReference Include="Winwright" Version="1.0.1" />
<PackageReference Include="Winwright.InApp" Version="1.0.1" />Full Changelog: v1.0.0...v1.0.1