Safe Haskell	None
Language	Haskell2010

Test.Tasty.Golden

Description

This module provides a simplified interface. If you want more, see Test.Tasty.Golden.Advanced.

Note about filenames. They are looked up in the usual way, thus relative names are relative to the processes current working directory. It is common to run tests from the package's root directory (via cabal test or cabal install --enable-tests), so if your test files are under the tests/ subdirectory, your relative file names should start with tests/ (even if your test.hs is itself under tests/, too).

Note about line endings. The best way to avoid headaches with line endings (when running tests both on UNIX and Windows) is to treat your golden files as binary, even when they are actually textual.

This means:

When writing output files from Haskell code, open them in binary mode (see openBinaryFile, withBinaryFile and hSetBinaryMode). This will disable automatic \n -> \r\n conversion on Windows. For convenience, this module exports writeBinaryFile which is just like writeFile but opens the file in binary mode. When using ByteStrings note that Data.ByteString and Data.ByteString.Lazy use binary mode for writeFile, while Data.ByteString.Char8 and Data.ByteString.Lazy.Char8 use text mode.
Tell your VCS not to do any newline conversion for golden files. For git check in a .gitattributes file with the following contents (assuming your golden files have .golden extension):

*.golden	-text

On its side, tasty-golden reads and writes files in binary mode, too.

Why not let Haskell/git do automatic conversion on Windows? Well, for instance, tar will not do the conversion for you when unpacking a release tarball, so when you run cabal install your-package --enable-tests, the tests will be broken.

As a last resort, you can strip all \rs from both arguments in your comparison function when necessary. But most of the time treating the files as binary does the job.

Synopsis

Documentation

goldenVsFile Source

Arguments

:: TestName	test name
-> FilePath	path to the «golden» file (the file that contains correct output)
-> FilePath	path to the output file
-> IO ()	action that creates the output file
-> TestTree	the test verifies that the output file contents is the same as the golden file contents

Compare a given file contents against the golden file contents

goldenVsString Source

Arguments

:: TestName	test name
-> FilePath	path to the «golden» file (the file that contains correct output)
-> IO ByteString	action that returns a string
-> TestTree	the test verifies that the returned string is the same as the golden file contents

Compare a given string against the golden file contents

goldenVsFileDiff Source

Arguments

:: TestName	test name
-> (FilePath -> FilePath -> [String])	function that constructs the command line to invoke the diff command. E.g. \ref new -> ["diff", "-u", ref, new]
-> FilePath	path to the golden file
-> FilePath	path to the output file
-> IO ()	action that produces the output file
-> TestTree

Same as goldenVsFile, but invokes an external diff command.

goldenVsStringDiff Source

Arguments

:: TestName	test name
-> (FilePath -> FilePath -> [String])	function that constructs the command line to invoke the diff command. E.g. \ref new -> ["diff", "-u", ref, new]
-> FilePath	path to the golden file
-> IO ByteString	action that returns a string
-> TestTree

Same as goldenVsString, but invokes an external diff command.

writeBinaryFile :: FilePath -> String -> IO () Source

Like writeFile, but uses binary mode

findByExtension Source

Arguments

:: [FilePath]	extensions
-> FilePath	directory
-> IO [FilePath]	paths

Find all files in the given directory and its subdirectories that have the given extensions.

It is typically used to find all test files and produce a golden test per test file.

The returned paths use forward slashes to separate path components, even on Windows. Thus if the file name ends up in a golden file, it will not differ when run on another platform.

The semantics of extensions is the same as in takeExtension. In particular, non-empty extensions should have the form ".ext".

This function may throw any exception that getDirectoryContents may throw.

It doesn't do anything special to handle symlinks (in particular, it probably won't work on symlink loops).

Nor is it optimized to work with huge directory trees (you'd probably want to use some form of coroutines for that).