tasty-expected-failure-0.11.1.1/0000755000000000000000000000000013251474317014516 5ustar0000000000000000tasty-expected-failure-0.11.1.1/Setup.hs0000644000000000000000000000005613251474317016153 0ustar0000000000000000import Distribution.Simple main = defaultMain tasty-expected-failure-0.11.1.1/LICENSE0000644000000000000000000000204413251474317015523 0ustar0000000000000000Copyright (c) 2015 Joachim Breitner Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. tasty-expected-failure-0.11.1.1/README.md0000644000000000000000000000352513251474317016002 0ustar0000000000000000tasty-expected-failure ====================== What is this? ------------- With the function `expectFail` in the provided module `ExpectedFailure`, you can mark that you expect test cases to fail, and not to pass. This can for example be used for test-driven development: Create the tests, mark them with `expectFail`, and you can still push to the main branch, without your continuous integration branch failing. Once someone implements the feature or fixes the bug (maybe unknowingly), the test suite will tell him so, due to the now unexpectedly passing test, and he can remove the `expectFail` marker. The module also provides `ignoreTest` to avoid running a test. Both funtions are implemented via the more general `wrapTest`, which is also provided. Why is this not provided by tasty? ---------------------------------- `` The author of the tasty library prefers to provide a minimal experience in the tasty library, instead of a batteries-included approach, and chose not to include these 39 lines of code in tasty. See the [issue](https://github.com/feuerbach/tasty/issues/114) for the discussion. Instead I wrote 37 lines of cabal file, a similar number of lines of README, created a git repository, created a travis file, run travis to figure out on what versions it builds (something that would have happened automatically with a pull request for tasty), upload to hackage, add to stackage. Furthermore, there is little discoverability: If it were part of the tasty API, users would stumble over it. Now they likely won’t. And if they do, they have to worry about whether it is still in sync with `tasty`, they have to add it to their build-depends, they have to import yet another module. Distribution packagers will have yet another package where they have to create the packaging, check the copyright, and run autobuilders for. Sigh. `` tasty-expected-failure-0.11.1.1/tasty-expected-failure.cabal0000644000000000000000000000330213251474317022070 0ustar0000000000000000name: tasty-expected-failure version: 0.11.1.1 synopsis: Mark tasty tests as failure expected description: With the function 'Test.Tasty.ExpectedFailure.expectFail' in the provided module "Test.Tasty.ExpectedFailure", you can mark that you expect test cases to fail, and not to pass. . This can for example be used for test-driven development: Create the tests, mark them with 'Test.Tasty.ExpectedFailure.expectFail', and you can still push to the main branch, without your continuous integration branch failing. . Once someone implements the feature or fixes the bug (maybe unknowingly), the test suite will tell him so, due to the now unexpectedly passing test, and he can remove the 'Test.Tasty.ExpectedFailure.expectFail' marker. . The module also provides 'Test.Tasty.ExpectedFailure.ignoreTest' to avoid running a test. Both funtions are implemented via the more general 'Test.Tasty.ExpectedFailure.wrapTest', which is also provided. homepage: http://github.com/nomeata/tasty-expected-failure license: MIT license-file: LICENSE author: Joachim Breitner maintainer: mail@joachim-breitner.de copyright: 2015 Joachim Breitner category: Testing build-type: Simple extra-source-files: README.md cabal-version: >=1.10 tested-with: GHC == 7.4.2, GHC == 7.6.3, GHC == 7.8.4, GHC == 7.10.2, GHC == 7.11.*, GHC == 8.0.* library exposed-modules: Test.Tasty.ExpectedFailure build-depends: base >= 4.5 && <4.12, tagged >= 0.7 && < 0.9, tasty >= 0.11 default-language: Haskell2010 source-repository head type: git location: git://github.com/nomeata/tasty-expected-failure tasty-expected-failure-0.11.1.1/Test/0000755000000000000000000000000013251474317015435 5ustar0000000000000000tasty-expected-failure-0.11.1.1/Test/Tasty/0000755000000000000000000000000013251474317016541 5ustar0000000000000000tasty-expected-failure-0.11.1.1/Test/Tasty/ExpectedFailure.hs0000644000000000000000000000763113251474317022155 0ustar0000000000000000{-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-} module Test.Tasty.ExpectedFailure (expectFail, expectFailBecause, ignoreTest, ignoreTestBecause, wrapTest) where import Test.Tasty.Options import Test.Tasty.Runners import Test.Tasty.Providers import Data.Typeable import Data.Tagged import Data.Maybe import Data.Monoid data WrappedTest t = WrappedTest (IO Result -> IO Result) t deriving Typeable instance forall t. IsTest t => IsTest (WrappedTest t) where run opts (WrappedTest wrap t) prog = wrap (run opts t prog) testOptions = retag (testOptions :: Tagged t [OptionDescription]) -- | 'wrapTest' allows you to modify the behaviour of the tests, e.g. by -- modifying the result or not running the test at all. It is used to implement -- 'expectFail' and 'ignoreTest'. wrapTest :: (IO Result -> IO Result) -> TestTree -> TestTree wrapTest wrap = go where go (SingleTest n t) = SingleTest n (WrappedTest wrap t) go (TestGroup name tests) = TestGroup name (map go tests) go (PlusTestOptions plus tree) = PlusTestOptions plus (go tree) go (WithResource spec gentree) = WithResource spec (go . gentree) go (AskOptions f) = AskOptions (go . f) -- | Marks all tests in the give test as expected failures: The tests will -- still be run, but if they succeed, it is reported as a test suite failure, -- and conversely a the failure of the test is ignored. -- -- Any output of a failing test is still printed. -- -- This is useful if, in a test driven development, tests are written and -- commited to the master branch before their implementation: It allows the -- tests to fail (as expected) without making the whole test suite fail. -- -- Similarly, regressions and bugs can be documented in the test suite this -- way, until a fix is commited, and if a fix is applied (intentionally or -- accidentially), the test suite will remind you to remove the 'expectFail' -- marker. expectFail :: TestTree -> TestTree expectFail = expectFail' Nothing -- | Like 'expectFail' but with additional comment expectFailBecause :: String -> TestTree -> TestTree expectFailBecause reason = expectFail' (Just reason) expectFail' :: Maybe String -> TestTree -> TestTree expectFail' reason = wrapTest (fmap change) where change r | resultSuccessful r = r { resultOutcome = Failure TestFailed , resultDescription = resultDescription r <> "(unexpected success" <> comment <> ")" , resultShortDescription = "PASS (unexpected" <> comment <> ")" } | otherwise = r { resultOutcome = Success , resultDescription = resultDescription r <> "(expected failure)" , resultShortDescription = "FAIL (expected" <> comment <> ")" } "" `append` s = s t `append` s | last t == '\n' = t ++ s ++ "\n" | otherwise = t ++ "\n" ++ s comment = maybe "" (mappend ": ") reason -- | Prevents the tests from running and reports them as succeeding. -- -- This may be be desireable as an alternative to commenting out the tests. This -- way, they are still typechecked (preventing bitrot), and the test report -- lists them, which serves as a reminder that there are ignored tests. -- -- Note that any setup/teardown actions executed by 'Test.Tasty.withResource' -- are still executed. You can bypass this manually as in the following example: -- -- @ -- askOption $ \\(MyFlag b) -> if b -- then withResource mytest -- else ignoreTest . mytest $ return junkvalue -- @ ignoreTest :: TestTree -> TestTree ignoreTest = ignoreTest' Nothing -- | Like 'ignoreTest' but with additional comment ignoreTestBecause :: String -> TestTree -> TestTree ignoreTestBecause reason = ignoreTest' (Just reason) ignoreTest' :: Maybe String -> TestTree -> TestTree ignoreTest' reason = wrapTest $ const $ return $ (testPassed "") { resultShortDescription = "IGNORED" <> maybe "" (mappend ": ") reason }