Do not depend on directory

[Bodigrim]

This is a necessary prerequisite for #316: if we want to move tests to the bytestring package itself, test components should avoid packages, which depend on bytestring. Except replacing test-framework with something having smaller dependency footprint (there is a good progress on this), the only remaining offender is directory, which depends on bytestring transitively via unix and Win32 packages.

This PR unties bytestring-tests from directory:

• removeFile can be replaced with a POSIX c_unlink.

• Not sure what exactly renameFile was meant to test in LazyHClose.hs (this file was not run for ages, and only recently salvaged and integrated in the test suite). If the purpose was to ensure, that a file is properly closed, opening it for write should be enough (and better).

• I had to sacrifice getTemporaryDirectory call in builder tests. Given that all other test components do not bother with it and create files in the current folder, it seems to be an acceptable tradeoff.

[sjakobi]

How about defining our own removeFile instead of using c_unlink directly in multiple places?! I think that might be more readable and would help keep our tests accessible for future contributors.

[Bodigrim]

@sjakobi good point, done. I also switched from hardcoded filenames to openTempFile everywhere.

[sjakobi]

Thanks! I guess we could have a shared TestUtils module, so we don't need multiple removeFile definitions. I don't mind too much though.

[Bodigrim]

These are all different test components, so it is a bit cumbersome to share a hypothetical TestUtils between them. Ideally one could unify them under one umbrella to produce a single test executable and reuse utility functions.

[sjakobi]

These are all different test components, so it is a bit cumbersome to share a hypothetical TestUtils between them.

Wouldn't it be as easy as listing the TestUtils module in each test component's other-modules? Again: It's not too important to me though.

Ideally one could unify them under one umbrella to produce a single test executable and reuse utility functions.

We've considered doing this in unordered-containers (haskell-unordered-containers/unordered-containers#284). A potential downside to having a single unified testsuite is that recompilation might take a bit longer when one only wants to run a single test. I'm generally 👍 on the idea though. It sounds like it might help reduce mental overhead.

[Bodigrim]

Wouldn't it be as easy as listing the TestUtils module in each test component's other-modules?

It will work, but IMHO too much churn for a single helper function.

A potential downside to having a single unified testsuite is that recompilation might take a bit longer when one only wants to run a single test.

Could probably be the case for more diverse or extremely large test suites. On the other hand, it saves linking time and generates a single, aggregated test report.