Getting Started

To get started with golden testing and this library, see Introduction to golden testing. This module provides a simplified interface. If you want more, see Test.Tasty.Golden.Advanced.

Filenames

Filenames 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).

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.

Linking

The test suite should be compiled with -threaded if you want to avoid blocking any other threads while goldenVsFileDiff and similar functions wait for the result of the diff command.

Windows limitations

When using goldenVsFileDiff or goldenVsStringDiff under Windows the exit code from the diff program that you specify will not be captured correctly if that program uses exec. More specifically, you will get the exit code of the original child (which always exits with code 0, since it called exec), not the exit code of the process which carried on with execution after exec. This is different from the behavior prescribed by POSIX but is the best approximation that can be realised under the restrictions of the Windows process model. See Process for further details or https://github.com/haskell/process/pull/168 for even more.

The base object type for all glib objects

This module constains helpers for dealing with GObject-derived types.

Deprecated: Google+ is being shut down, please migrate to Google Sign-in https://pbrisbin.com/posts/googleemail2_deprecation/

Golden tests store the expected output in a separated file. Each time a golden test is executed the output of the subject under test (SUT) is compared with the expected output. If the output of the SUT changes then the test will fail until the expected output is updated. We expose defaultGolden for output of type String. If your SUT has a different output, you can use Golden.

This object class is derived from AtkObject and can be used as a basis implementing accessible objects. This object class is derived from AtkObject. It can be used as a basis for implementing accessible objects for GObjects which are not derived from GtkWidget. One example of its use is in providing an accessible object for GnomeCanvasItem in the GAIL library.

"Golden tests" using ediff comparison.

Functions for golden testing.

Internal module, use at your own risk.

Internal module, use at your own risk.

This is an implementation of Goertzel's algorithm, which computes one bin of a DFT. A description can be found in Oppenheim and Schafer's Discrete Time Signal Processing, pp 585-587.

This module provides a Google monad and common set of operations which can be performed against the remote Google Service APIs. Typically you will import this module along with modules from various gogol-* libraries for the services you wish to communicate with.

Things that seem like they could be clients of this library, but are instead included as part of the library.

OAuth2 plugin for http://www.google.com

• Authenticates against Google
• Uses Google user id as credentials identifier

If you were previously relying on email as the creds identifier, you can still do that (and more) by overriding it in the creds returned by the plugin with any value read out of the new userResponse key in credsExtra. For example:

data User = User { userEmail :: Text }

instance FromJSON User where -- you know...

authenticate creds = do
-- 'getUserResponseJSON' provided by "Yesod.Auth.OAuth" module
let Right email = userEmail <$> getUserResponseJSON creds
updatedCreds = creds { credsIdent = email }

-- continue normally with updatedCreds

A limited Grammar of Graphics-like interface.

myPts :: [(Double, Double)]
myPts = [(1,2), (1.2, 3), (1.4,3.5)]



myTrace :: Trace
myTrace = points (aes & x .~ fst
& y .~ snd)
myPts

Overview

This is the main module of the spacecookie library. It allows to write gopher applications by taking care of handling gopher requests while leaving the application logic to a user-supplied function. For a small tutorial an example of a trivial pure gopher application:

{-# LANGUAGE OverloadedStrings #-}
import Network.Gopher
import Network.Gopher.Util

cfg :: GopherConfig
cfg = defaultConfig
{ cServerName = "localhost"
, cServerPort = 7000
}

handler :: GopherRequest -> GopherResponse
handler request =
case requestSelector request of
"hello" -> FileResponse "Hello, stranger!"
"" -> rootMenu
"/" -> rootMenu
_ -> ErrorResponse "Not found"
where rootMenu = MenuResponse
[ Item File "greeting" "hello" Nothing Nothing ]

main :: IO ()
main = runGopherPure cfg handler

There are three possibilities for a GopherResponse:

• FileResponse: file type agnostic file response, takes a ByteString to support both text and binary files.
• MenuResponse: a gopher menu (“directory listing”) consisting of a list of GopherMenuItems
• ErrorResponse: gopher way to show an error (e. g. if a file is not found). An ErrorResponse results in a menu response with a single entry.

If you use runGopher, it is the same story like in the example above, but you can do IO effects. To see a more elaborate example, have a look at the server code in this package.

This module implements a parser for gophermap files. Example usage:

import Network.Gopher.Util.Gophermap
import qualified Data.ByteString as B
import Data.Attoparsec.ByteString

main = do
file <- B.readFile "gophermap"
print $ parseOnly parseGophermap file