ff318a58

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Let a scenario carry whether it is a file or a directory

scenarioDir, scenarioDirRecur and scenarioDirOfDirs took a FilePath and handed
the callback a FilePath, so the one thing the caller had to know about a
scenario, whether it was a file or a directory, was the one thing the type
would not tell them. scenarioDirOfDirs handing out a directory and scenarioDir
handing out a file had the same signature.

They now take a Path b Dir and hand over a Path Rel File or a Path Rel Dir.

The scenario is relative to the directory given rather than to the working
directory. That way it is the name to say the test is about, and joining it to
the directory is what reads it: neither has to be recovered from the other,
where a joined path made a caller wanting the name split it back apart.

The directory stays polymorphic in its base, so a scenario over a
withSystemTempDir still works with the absolute path it hands you, which is
what ScenarioSpec does.

Test descriptions are unchanged, separator and all, so a --filter over them
still selects the same tests.

sydtest-test no longer depends on filepath: joining a scenario directory to a
file in it was the only thing it wanted System.FilePath for, and Path's own </>
does that with the types lined up.

The examples in the it, itWithOuter and itWithBoth documentation use path and
path-io too, since they were the other place the docs spelled a path as a
string. Two of them did not typecheck: they joined the Path Abs Dir from
withSystemTempDir to a String with System.FilePath's </>. One generated a
FilePath with forAllValid, which mostly generates strings that are not
filenames.

Timeline