Automatically running unit tests in Haskell - haskell

Is there a way to run my test suites with my build command? All I can find is that I can run e.g. cabal test after cabal build. What I want is a way to automatically run my tests when running e.g. cabal build.
I want a solution that will automate this for anyone building the package without requiring them to run a different script. An analogy would be a java build script where the default build target runs unit tests after compiling.

You can use a cabal.project.local to do this when using cabal v2 projects (as in, cabal v2-build which is the default and thus the same as cabal build for cabal version 3.0 and up).
The strategy is just to place a cabal.project.local file in the build directory with contents of:
tests: true

I find this a really bad idea since it's unexpected, non-canonical behavior that breaks cross-compilation, but you can probably hack it together with a Custom build type.
Here's an example mypackage.cabal:
cabal-version: >=2.0
name: mypackage
version: 0.1.0.0
author: None
maintainer: none#example.com
build-type: Custom
custom-setup
setup-depends:
base >= 4.5,
Cabal >= 2.0
executable mypackage
main-is: Main.hs
build-depends: base >= 4
default-language: Haskell2010
test-suite test
type: exitcode-stdio-1.0
build-depends: base >= 4
main-is: Test.hs
and a corresponding Setup.hs:
import Control.Monad
import Distribution.Simple
import Distribution.Simple.Setup
import Distribution.Simple.Test
import Distribution.Simple.Build
main = defaultMainWithHooks simpleUserHooks {
postBuild = myPostBuild
}
myPostBuild args flags desc info =
when ("exe:mypackage" `elem` buildArgs flags) $ do
build desc info defaultBuildFlags { buildDistPref = buildDistPref flags } []
test ["test"] desc info defaultTestFlags {
testDistPref = buildDistPref flags
}
This does result in a project where cabal build also builds and runs the tests on my Cabal 3.0.0.0 system, but I don't know which additional caveats this has.

Related

How to redirect cabal haddock output to a different folder?

I have a test project with the following structure:
Test
Test
Test.hs
Test.cabal
Test.hs is an empty module:
{-|
Description: Test
Test
-}
module Test.Test () where
Test.cabal:
cabal-version: 3.0
name: Test
version: 0.0.0
library
build-depends: base
exposed-modules: Test.Test
When I run cabal haddock it puts the docs in dist-newstyle/build/x86_64-windows/ghc-8.10.1/Test-0.0.0/doc.
Is there any way to redirect the output of cabal haddock to some other directory instead of burying it five layers deep in dist-newstyle?

Dependency issues running "cabal test" for Haskell

I'm running my first "cabal test" for Haskell, but I get the error:
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring sample-0.1.0.0...
cabal: At least the following dependencies are missing:
base ==4.7.*
sampel.cabal:
-- Initial sample.cabal generated by cabal init. For further
-- documentation, see http://haskell.org/cabal/users-guide/
name: sample
version: 0.1.0.0
build-type: Simple
cabal-version: >=1.10
executable SampleTest
main-is: SampleTest.hs
build-depends: base >= 4.7 && <4.8, HUnit >=1.2 && <1.3
hs-source-dirs: test, src
default-language: Haskell2010
Any help appreciated.
Versions of GHC come bundled with versions of base. GHC 7.10.2 uses base 4.8.1.0.
Your cabal must be using a slightly out of date template....
You should either change the range of acceptable base version (as you did in your comment above), or use a different version of GHC.

Shared cabal "build-depends" (Haskell) [duplicate]

Here's a .cabal file:
Name: myprogram
Version: 0.1
-- blah blah blah
Cabal-version: >=1.9.2
Executable myprogram
HS-source-dirs: src
Main-is: Main.hs
Build-depends: attoparsec == 0.10.*,
base == 4.3.*,
-- long long list of packages
Test-Suite test
HS-source-dirs: test, src
Type: exitcode-stdio-1.0
Main-is: Main.hs
Build-depends: attoparsec == 0.10.*,
base == 4.3.*,
-- long long list of packages
QuickCheck == 2.4.*
Is there any way I can replace the long list of build-depends packages for the test suite with "same as for the executable, plus QuickCheck"?
Edit: version information.
cabal-dev 0.9
cabal-install 0.10.2
Cabal library 1.10.2.0
GHC 7.0.4
Haskell Platform 2011.4.0.0
NOTE: superseded by phadej's answer suggesting common stanzas.
Is there any way I can replace the long list of build-depends packages for the test suite with "same as for the executable, plus QuickCheck"?
Not that I know of. However, there is a way to only mention the list of build-depends packages once, by structuring your project into three targets:
a library that contains all your code, and needs the long build-depends list.
an executable that consists of only one file, and depends on base and the library from above.
a test-suite that depends on the library from above, and the testing packages you are using.
Maybe this approach is what indygemma's answer proposes, but the Cabal file proposed there will not quite achieve it, as Norman Ramsey points out in a comment. Here's the main points of what you need in a Cabal file. For a full example that works for me, you can look at this Cabal file.
name: my-program
version: ...
library
hs-source-dirs: src-lib
build-depends: base, containers, ...
exposed-modules: My.Program.Main, ...
executable my-program
hs-source-dirs: src-exec
main-is: my-program.hs
Build-depends: base, my-program
test-suite tests
type: exitcode-stdio-1.0
hs-source-dirs: src-test
main-is: tests.hs
other-modules: ...
build-depends: base, my-program, test-framework, ...
Important points:
There are three separate source directories for the three targets. This is necessary to stop GHC from recompiling library files when building the other targets.
All of the application code is in the library. The executable is just a wrapper, like this:
import My.Program.Main (realMain)
main = realMain
The library exposes all modules that are necessary for testing.
The last point highlights the drawback of this approach: You end up having to expose internal modules. The main benefit of this approach is that you have less duplication in the Cabal file, and maybe more importantly, less duplication in the build process: The library code will be built only once, and then linked into both the executable and the test-suite.
Since version 2.2 Cabal supports common stanzas, to dedup build info fields:
https://cabal.readthedocs.io/en/latest/developing-packages.html#common-stanzas
cabal-version: 2.2
name: myprogram
version: 0.1
-- blah blah blah
common deps
build-depends: base ^>= 4.11,
-- long long list of packages
ghc-options: -Wall
library
import: deps
exposed-modules: Foo
test-suite tests
import: deps
type: exitcode-stdio-1.0
main-is: Tests.hs
build-depends: foo
You could also consider using hpack instead of writing the .cabal file by hand:
In hpack's package.yaml format, you can specify a common dependencies field whose entries are added to every components' build-depends field when generating the .cabal file.
For example, see hpack's own package.yaml and the generated hpack.cabal.
To start using hpack with an existing package, you can use hpack-convert which will generate the package.yaml from an existing .cabal file.
To create a new package that uses hpack, you can use stack's simple-hpack template like so: stack new mypkg simple-hpack.
If you use stack for development, you don't have to call hpack manually to regenerate the .cabal file from an updated package.yaml – stack will do that automatically.
No easy way:
you can use m4 and specify your dependencies once, but then you will need to reprocess your Cabal file through m4 whenever you change it.
you can move the code you are testing out to a library, and then specify the library in your Build-depends for the test. That requires you to install a library even just to run the test.
You can just not put the test in the cabal file at all. Build it with ghc --make, which will pull in dependencies. But then you lose cabal integration.
There is an optional library section for .cabal files, which solves your problem.
name: myprogram
version: 0.1
-- blah blah blah
cabal-version: >=1.9.2
library
build-depends: attoparsec == 0.10.*
, base == 4.3.*
-- long long list of packages
executable myprogram
hs-source-dirs: src
main-is: Main.hs
test-suite test
hs-source-dirs: test, src
type: exitcode-stdio-1.0
main-is: Main.hs
build-depends: QuickCheck == 2.4.*

plugins package unknown symbol when using cabal

I'm messing around with the plugins package however I bumped into a problem.
Here's the code:
Util/Header.hs
module Util.Header(PT(..)) where
data PT a = PT a deriving Show
Plug.hs
module Plug(helloPlugin) where
import Util.Header
helloPlugin :: PT Int
helloPlugin = PT 1
Main.hs
module Main where
import Util.Header
import System.Plugins
main :: IO ()
main = do
mv <- load "Plug.o" ["."] [] "helloPlugin"
case mv of
LoadFailure msg -> print msg
LoadSuccess _ v -> print $ show (v :: PT Int)
This all works fine then compiling with ghc. Building with Cabal works fine as well, but when I run the executable I get this error:
plugintest: /home/kevin/.cabal/lib/plugins-1.5.4.0/ghc-7.6.3/HSplugins-1.5.4.0.o: unknown symbol `ghczm7zi6zi3_ErrUtils_zdsinsertzuzdsgo5_info'
plugintest: user error (resolvedObjs failed.)
My very minimalistic cabal file:
name: plugintest
version: 0.1.0.0
license-file: LICENSE
build-type: Simple
cabal-version: >=1.8
library
hs-source-dirs: src
exposed-modules: Util.Header
build-depends: base ==4.6.*, plugins ==1.5.*
executable plugintest
main-is: Main.hs
build-depends: base ==4.6.*, plugins ==1.5.*, plugintest == 0.1.0.0
hs-source-dirs: src
Now I assume the problem is that it can't find the "ErrUtils" module which is part of the ghc package installed in /usr/lib/ghc-7.x.x.
Since it's using cabal it'll use the $HOME/.cabal/lib/ instead.
Now I obviously wouldn't want to use /usr/lib if I wanted to make it distributable. Sadly I'm not very familiar with how packages are managed nor am I familiar with the plugins package.
I have a feeling this is extremly nooby but I wasn't able to find a solution myself.
So a few questions:
How can I get my dependencies to work in a way to make this distributable?
It seems I'll need to know beforehand what my Plugin.o files will depend on before actually being able to use them (If I understand correctly).
Is there a way to package a .o files that I wouldn't have to worry about this problem? (Sorry if this question is too vague, feel free to ignore)
Thanks in advance!
Ok, so I had the exact same problem.
Here is a workaround I found
Change the load call to
load "Plug.o" [".","dist/build/plugintest/plugintest-tmp"] [] "testplugin"
Make sure you compile the thing with -c or by using the "make" library from plugins.
Quite annoyed by this... The error suggests it is having issues linking against the standard libs, so why does showing it these .o files fix it?
Anyways, this worked for me, and didn't require a ton of mucking around with .cabal files.
You must declare your exported- and other- modules in order for Cabal to package them all together. For instance (from https://github.com/tel/happstack-heroku-test)
name: hktest -- note the name here names
-- the *library* which is a package name
-- in scope when building the executable
...
library
exposed-modules:
HKTest
other-modules:
-- there aren't any, but there could be some
build-depends: base >= 4.6 && <4.7
...
, mtl >= 2.1.2
hs-source-dirs: src
executable server
main-is: Server.hs
other-modules:
-- there might be some use to having these here,
-- but they'll be harder to get into GHCi, so I wouldn't
-- recommend it---just put them in the library part
build-depends: base >=4.6 && <4.7
, hktest -- note that I grab all the hktest
-- modules here
hs-source-dirs: exe
If I leave out one of those modules I'll likely get a build error as Cabal compiles files which expect to be able to find symbols that haven't been packaged.
In your case, since you're building an executable, the common pattern exemplified above is to put all of your code into a library and then have the executable side depend upon that library. For instance, in this example the complete text of exe/Server.hs is
module Main where
import qualified HKTest as HK
main :: IO ()
main = HK.main

Creating a Full Haskell Stack with Tests

I'm new to Haskell and I'm trying to structure a program under test. I have decided to use HUnit and Cabal.
From what I have seen a well strucutred project looks the following:
src/
AppName/
Appname.hs
testsuite/
tests/
AppName/
TestRunner.hs
AppName.cabal
Setup.hs
The parts that are a mystery to me are the TestRunner.hs and the AppName.cabal.
What would a testrunner look like that runs all of the test under the testsuite/tests directory and sub directories? And how can it be integrated with Cabal?
Also, how do you put the hackage dependencies in the AppName.cabal and build them from the command line?
I am having a hard time finding a full example building an application from scratch with tests and dependencies.
Thanks
Here's a fragment of the .cabal file I used for one of my recent libraries.
...
Library
Build-depends: base >= 4 && < 5, bytestring, directory, filepath, hslogger,
SHA, zlib
Ghc-options: -Wall
Exposed-modules: Ltc.Store
Test-suite reference
Hs-Source-Dirs: Test, .
Main-Is: ReferenceProps.hs
Type: exitcode-stdio-1.0
Build-Depends: base >= 4 && < 5, bytestring, directory, filepath, hslogger,
SHA, zlib
Ghc-Options: -Wall
Build-Depends: test-framework, test-framework-hunit, test-framework-quickcheck2,
HUnit, QuickCheck
As we can see the cabal file defines a library and a testsuite. The library defines the modules it exports, the packages it depends on, and sets some custom GHC options.
We can easily build and package the library for distribution with:
% cabal configure
% cabal build
% cabal sdist
The testsuite looks a lot like the the library: first off, it has the same dependencies as the library (see the first Build-Depends line), and it then adds some extra test dependencies (see the second Build-Depends line). The testsuite here is a combination of HUnit and QuickCheck tests, and it uses Test-Framework as the runner. The test proper is Test/ReferenceProps.hs. It's a exitcode-stdio type test. This means that cabal will say that the tests pass if ReferenceProps exits with code 0. Otherwise, it will say the tests failed.
The testsuite looks like this (but, here, we're going to use some simple tests for list reversals):
import Data.Monoid
import Test.Framework
import Test.Framework.Providers.HUnit
import Test.Framework.Providers.QuickCheck2
import Test.HUnit
import Test.QuickCheck
main :: IO ()
main = defaultMainWithOpts
[ testCase "rev" testRev
, testProperty "listRevRevId" propListRevRevId
] mempty
testRev :: Assertion
testRev = reverse [1, 2, 3] #?= [3, 2, 1]
propListRevRevId :: [Int] -> Property
propListRevRevId xs = not (null xs) ==> reverse (reverse xs) == xs
The main is just a harness. You can also set various options for test-framework by replacing the mempty. The function testRev is a HUnit test, and propListRevRevId is a QuickCheck test; see the relevant docs on how to write these.
Finally, we can run the tests:
% cabal configure --enable-tests
% cabal test

Resources