2019-02-04 22:52:31 +01:00
|
|
|
{- |
|
|
|
|
Module : Tests.Command
|
2022-01-01 20:02:31 +01:00
|
|
|
Copyright : © 2006-2022 John MacFarlane
|
2019-02-04 22:52:31 +01:00
|
|
|
License : GNU GPL, version 2 or above
|
|
|
|
|
|
|
|
Maintainer : John MacFarlane <jgm@berkeley@edu>
|
|
|
|
Stability : alpha
|
|
|
|
Portability : portable
|
|
|
|
|
|
|
|
Run commands, and test results, defined in markdown files.
|
|
|
|
-}
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
module Tests.Command (runTest, tests)
|
2017-02-04 17:38:03 +01:00
|
|
|
where
|
|
|
|
|
2021-09-21 19:10:25 +02:00
|
|
|
import Data.Maybe (fromMaybe)
|
2017-03-04 13:03:41 +01:00
|
|
|
import Data.Algorithm.Diff
|
2021-03-20 07:35:47 +01:00
|
|
|
import System.Environment (getExecutablePath)
|
2017-10-28 05:28:29 +02:00
|
|
|
import qualified Data.ByteString as BS
|
Switch to new pandoc-types and use Text instead of String [API change].
PR #5884.
+ Use pandoc-types 1.20 and texmath 0.12.
+ Text is now used instead of String, with a few exceptions.
+ In the MediaBag module, some of the types using Strings
were switched to use FilePath instead (not Text).
+ In the Parsing module, new parsers `manyChar`, `many1Char`,
`manyTillChar`, `many1TillChar`, `many1Till`, `manyUntil`,
`mantyUntilChar` have been added: these are like their
unsuffixed counterparts but pack some or all of their output.
+ `glob` in Text.Pandoc.Class still takes String since it seems
to be intended as an interface to Glob, which uses strings.
It seems to be used only once in the package, in the EPUB writer,
so that is not hard to change.
2019-11-04 22:12:37 +01:00
|
|
|
import qualified Data.Text as T
|
2021-02-03 06:09:10 +01:00
|
|
|
import Data.List (isSuffixOf)
|
2017-02-04 17:38:03 +01:00
|
|
|
import System.Directory
|
|
|
|
import System.Exit
|
2021-03-20 05:17:13 +01:00
|
|
|
import System.FilePath ((</>))
|
2017-10-28 05:28:29 +02:00
|
|
|
import System.IO (hPutStr, stderr)
|
|
|
|
import System.IO.Unsafe (unsafePerformIO)
|
2017-03-04 13:03:41 +01:00
|
|
|
import System.Process
|
2017-03-14 17:05:36 +01:00
|
|
|
import Test.Tasty
|
|
|
|
import Test.Tasty.HUnit
|
2020-10-08 07:04:29 +02:00
|
|
|
import Test.Tasty.Golden.Advanced (goldenTest)
|
2017-03-04 13:03:41 +01:00
|
|
|
import Tests.Helpers
|
2017-02-04 21:07:03 +01:00
|
|
|
import Text.Pandoc
|
2017-03-04 13:03:41 +01:00
|
|
|
import qualified Text.Pandoc.UTF8 as UTF8
|
2017-02-04 17:38:03 +01:00
|
|
|
|
2020-10-08 07:04:29 +02:00
|
|
|
-- | Run a test with and return output.
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
execTest :: String -- ^ Path to test executable
|
2020-10-08 07:04:29 +02:00
|
|
|
-> String -- ^ Shell command
|
|
|
|
-> String -- ^ Input text
|
|
|
|
-> IO (ExitCode, String) -- ^ Exit code and actual output
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
execTest testExePath cmd inp = do
|
2021-03-20 05:17:13 +01:00
|
|
|
env' <- setupEnvironment testExePath
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
let pr = (shell (pandocToEmulate True cmd)){ env = Just env' }
|
2017-05-25 11:51:50 +02:00
|
|
|
(ec, out', err') <- readCreateProcessWithExitCode pr inp
|
2017-02-04 17:38:03 +01:00
|
|
|
-- filter \r so the tests will work on Windows machines
|
2017-05-25 11:51:50 +02:00
|
|
|
let out = filter (/= '\r') $ err' ++ out'
|
2020-10-08 07:04:29 +02:00
|
|
|
case ec of
|
|
|
|
ExitFailure _ -> hPutStr stderr err'
|
|
|
|
ExitSuccess -> return ()
|
|
|
|
return (ec, out)
|
|
|
|
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
pandocToEmulate :: Bool -> String -> String
|
|
|
|
pandocToEmulate True ('p':'a':'n':'d':'o':'c':cs) =
|
|
|
|
"test-pandoc --emulate" ++ pandocToEmulate False cs
|
|
|
|
pandocToEmulate False ('|':' ':'p':'a':'n':'d':'o':'c':cs) =
|
|
|
|
"| " ++ "test-pandoc --emulate" ++ pandocToEmulate False cs
|
|
|
|
pandocToEmulate _ (c:cs) = c : pandocToEmulate False cs
|
|
|
|
pandocToEmulate _ [] = []
|
|
|
|
|
2020-10-08 07:04:29 +02:00
|
|
|
-- | Run a test, return True if test passed.
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
runTest :: String -- ^ Path to test executable
|
|
|
|
-> String -- ^ Title of test
|
2020-10-08 07:04:29 +02:00
|
|
|
-> String -- ^ Shell command
|
|
|
|
-> String -- ^ Input text
|
|
|
|
-> String -- ^ Expected output
|
|
|
|
-> TestTree
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
runTest testExePath testname cmd inp norm = testCase testname $ do
|
|
|
|
(ec, out) <- execTest testExePath cmd inp
|
2017-02-04 17:38:03 +01:00
|
|
|
result <- if ec == ExitSuccess
|
2018-01-20 06:25:24 +01:00
|
|
|
then
|
2017-02-04 17:38:03 +01:00
|
|
|
if out == norm
|
|
|
|
then return TestPassed
|
|
|
|
else return
|
|
|
|
$ TestFailed cmd "expected"
|
|
|
|
$ getDiff (lines out) (lines norm)
|
2020-10-08 07:04:29 +02:00
|
|
|
else return $ TestError ec
|
2017-02-04 17:38:03 +01:00
|
|
|
assertBool (show result) (result == TestPassed)
|
|
|
|
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
tests :: TestTree
|
2018-01-20 06:25:24 +01:00
|
|
|
{-# NOINLINE tests #-}
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
tests = unsafePerformIO $ do
|
2017-02-04 21:07:03 +01:00
|
|
|
files <- filter (".md" `isSuffixOf`) <$>
|
|
|
|
getDirectoryContents "command"
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
testExePath <- getExecutablePath
|
|
|
|
let cmds = map (extractCommandTest testExePath) files
|
2017-02-04 21:07:03 +01:00
|
|
|
return $ testGroup "Command:" cmds
|
|
|
|
|
|
|
|
isCodeBlock :: Block -> Bool
|
|
|
|
isCodeBlock (CodeBlock _ _) = True
|
2017-03-04 13:03:41 +01:00
|
|
|
isCodeBlock _ = False
|
2017-02-04 21:07:03 +01:00
|
|
|
|
|
|
|
extractCode :: Block -> String
|
Switch to new pandoc-types and use Text instead of String [API change].
PR #5884.
+ Use pandoc-types 1.20 and texmath 0.12.
+ Text is now used instead of String, with a few exceptions.
+ In the MediaBag module, some of the types using Strings
were switched to use FilePath instead (not Text).
+ In the Parsing module, new parsers `manyChar`, `many1Char`,
`manyTillChar`, `many1TillChar`, `many1Till`, `manyUntil`,
`mantyUntilChar` have been added: these are like their
unsuffixed counterparts but pack some or all of their output.
+ `glob` in Text.Pandoc.Class still takes String since it seems
to be intended as an interface to Glob, which uses strings.
It seems to be used only once in the package, in the EPUB writer,
so that is not hard to change.
2019-11-04 22:12:37 +01:00
|
|
|
extractCode (CodeBlock _ code) = T.unpack code
|
2017-03-04 13:03:41 +01:00
|
|
|
extractCode _ = ""
|
2017-02-04 21:07:03 +01:00
|
|
|
|
2021-09-21 19:10:25 +02:00
|
|
|
dropPercent :: String -> Maybe String
|
|
|
|
dropPercent ('%':xs) = Just $ dropWhile (== ' ') xs
|
|
|
|
dropPercent _ = Nothing
|
2017-02-04 21:07:03 +01:00
|
|
|
|
2020-10-08 07:04:29 +02:00
|
|
|
runCommandTest :: FilePath -> FilePath -> Int -> String -> TestTree
|
2021-09-21 19:10:25 +02:00
|
|
|
runCommandTest testExePath fp num code = do
|
2021-07-31 01:23:46 +02:00
|
|
|
goldenTest testname getExpected getActual compareValues' updateGolden
|
2020-10-08 07:04:29 +02:00
|
|
|
where
|
|
|
|
testname = "#" <> show num
|
|
|
|
codelines = lines code
|
|
|
|
(continuations, r1) = span ("\\" `isSuffixOf`) codelines
|
2021-09-21 19:10:25 +02:00
|
|
|
cmd = fromMaybe (error "Command test line does not begin with %")
|
|
|
|
(dropPercent (unwords (map init continuations ++ take 1 r1)))
|
2020-10-08 07:04:29 +02:00
|
|
|
r2 = drop 1 r1
|
|
|
|
(inplines, r3) = break (=="^D") r2
|
|
|
|
normlines = takeWhile (/=".") (drop 1 r3)
|
|
|
|
input = unlines inplines
|
|
|
|
norm = unlines normlines
|
|
|
|
getExpected = return norm
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
getActual = snd <$> execTest testExePath cmd input
|
2021-07-31 01:23:46 +02:00
|
|
|
compareValues' expected actual
|
2020-10-08 07:04:29 +02:00
|
|
|
| actual == expected = return Nothing
|
|
|
|
| otherwise = return $ Just $ "--- test/command/" ++ fp ++ "\n+++ " ++
|
|
|
|
cmd ++ "\n" ++ showDiff (1,1)
|
|
|
|
(getDiff (lines actual) (lines expected))
|
|
|
|
updateGolden newnorm = do
|
|
|
|
let fp' = "command" </> fp
|
|
|
|
raw <- UTF8.readFile fp'
|
|
|
|
let cmdline = "% " <> cmd
|
|
|
|
let x = cmdline <> "\n" <> input <> "^D\n" <> norm
|
|
|
|
let y = cmdline <> "\n" <> input <> "^D\n" <> newnorm
|
Text.Pandoc.UTF8: change IO functions to return Text, not String.
[API change] This affects `readFile`, `getContents`, `writeFileWith`,
`writeFile`, `putStrWith`, `putStr`, `putStrLnWith`, `putStrLn`.
`hPutStrWith`, `hPutStr`, `hPutStrLnWith`, `hPutStrLn`, `hGetContents`.
This avoids the need to uselessly create a linked list of characters
when emiting output.
2021-02-22 20:30:07 +01:00
|
|
|
let updated = T.replace (T.pack x) (T.pack y) raw
|
2020-10-08 07:04:29 +02:00
|
|
|
UTF8.writeFile fp' updated
|
2017-02-04 21:07:03 +01:00
|
|
|
|
2017-03-14 23:39:28 +01:00
|
|
|
extractCommandTest :: FilePath -> FilePath -> TestTree
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
extractCommandTest testExePath fp = unsafePerformIO $ do
|
2017-06-11 21:18:42 +02:00
|
|
|
contents <- UTF8.toText <$> BS.readFile ("command" </> fp)
|
2017-02-04 21:07:03 +01:00
|
|
|
Pandoc _ blocks <- runIOorExplode (readMarkdown
|
2017-06-11 21:18:42 +02:00
|
|
|
def{ readerExtensions = pandocExtensions } contents)
|
2018-01-20 06:25:24 +01:00
|
|
|
let codeblocks = map extractCode $ filter isCodeBlock blocks
|
Test suite: a more robust way of testing the executable.
Mmny of our tests require running the pandoc
executable. This is problematic for a few different reasons.
First, cabal-install will sometimes run the test suite
after building the library but before building the executable,
which means the executable isn't in place for the tests.
One can work around that by first building, then building
and running the tests, but that's fragile. Second,
we have to find the executable. So far, we've done that
using a function findPandoc that attempts to locate it
relative to the test executable (which can be located
using findExecutablePath). But the logic here is delicate
and work with every combination of options.
To solve both problems, we add an `--emulate` option to
the `test-pandoc` executable. When `--emulate` occurs
as the first argument passed to `test-pandoc`, the
program simply emulates the regular pandoc executable,
using the rest of the arguments (after `--emulate`).
Thus,
test-pandoc --emulate -f markdown -t latex
is just like
pandoc -f markdown -t latex
Since all the work is done by library functions,
implementing this emulation just takes a couple lines
of code and should be entirely reliable.
With this change, we can test the pandoc executable
by running the test program itself (locatable using
findExecutablePath) with the `--emulate` option.
This removes the need for the fragile `findPandoc`
step, and it means we can run our integration tests
even when we're just building the library, not the
executable.
Part of this change involved simplifying some complex
handling to set environment variables for dynamic
library paths. I have tested a build with
`--enable-dynamic-executable`, and it works, but
further testing may be needed.
2021-02-03 02:09:16 +01:00
|
|
|
let cases = zipWith (runCommandTest testExePath fp) [1..] codeblocks
|
2021-05-26 18:52:23 +02:00
|
|
|
return $ testGroup fp
|
|
|
|
$ if null cases
|
|
|
|
then [testCase "!!" $ assertFailure "No command tests defined"]
|
|
|
|
else cases
|