Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

localOption is ignored by defaultMain #32

Open
andreasabel opened this issue Sep 8, 2021 · 3 comments
Open

localOption is ignored by defaultMain #32

andreasabel opened this issue Sep 8, 2021 · 3 comments
Labels
bug option Concerning options (OptionSet)

Comments

@andreasabel
Copy link
Collaborator

I am trying to set a local option for a test but it seems to be ignored by the test runner (defaultMain) of tasty-silver.

#!/usr/bin/env GHC_ENVIRONMENT=- runhaskell -packagetasty-1.4.2 -packagetasty-silver-3.2.2

{-# LANGUAGE OverloadedStrings #-}

import Test.Tasty (TestTree, localOption)
import Test.Tasty.Silver
import Test.Tasty.Silver.Advanced
import Test.Tasty.Silver.Interactive as Silver

main :: IO ()
main = Silver.defaultMain $ localOption (Interactive true) testGolden
  where
  true = error "This error should be triggered!"

testGolden :: TestTree
testGolden =
  goldenTest1
    "wrongOutput"
    (return $ Just "golden value")
    (return "actual value")
    (DiffText Nothing)   -- always fail
    ShowText
    (const $ return ())  -- keep the golden file no matter what

When applying and then querying the option, this script should crash with error. But it simply runs the test non-interactively.

@phile314: You implemented the test runner. Where should PlusTestOption be usually handled?

@andreasabel andreasabel added bug option Concerning options (OptionSet) labels Sep 8, 2021
andreasabel added a commit that referenced this issue Sep 8, 2021
If not for #32, we could leasily enable interaction for some tests
using (localOption $ Interactive true).  Instead, we turn it on in the
CI, breaking generability of haskell-ci.yml.
@phile314
Copy link
Owner

phile314 commented Sep 8, 2021

The actual test running is done by launchTestTree from tasty:

r <- launchTestTree opts tests' $ \smap ->
However, the tasty-silver code does some slightly "hackish" stuff to be able to customize running golden tests in interactive mode. I suspect that code does interfere somehow with the options.
wrapRunTest' :: TestPath

For a normal tasty test case (e.g. hspec, hunit, ...), does this option cause the crash?
What happens if you use the tasty default test runner?

EDIT: I think the interactive option is only checked at the top-level:

Interactive isInteractive = lookupOption opts

@phile314
Copy link
Owner

phile314 commented Sep 9, 2021

For some more context, the basic idea was to have the interactive runner for the developer and the non-interactive for e.g. CI build servers or users who just want to run the test suite. The interactive runner assumes that e.g. git diff is available, whereas the non-interactive runner has no external dependencies. I think having the non-interactive runner suddenly pop up an interactive question would be rather strange. The other way round, using the interactive runner but reverting to non-interactive mode for certain test cases sounds more feasible and useful. It might still require some thinking to get the output to align nicely.

@andreasabel
Copy link
Collaborator Author

My aim is to test the interactive mode also in CI, esp. since there were problems on the Windows side. My current take is to assume answer "y" when run in interactive mode but stdin isn't connected to a terminal that could request interactive input from the user. This way, I can cover a lot of code from the interactive mode on CI as well.
The easiest way to get this into the testsuite was (after trying other ways like calling runInteractiveTests directly) to pass option Interactive True to the desired tests. Alas, the option is ignored.

In general, I think that tasty-silver should preserve as much of the functionalities of tasty and tasty-golden as possible. It would have thus made sense to start with their testsuites, to not accidentially break features. Maybe it is not too late to adopt their testsuites, but it is of course easier to fix breakage while developing a fork, than to retroactively find out what broke tests.

andreasabel added a commit that referenced this issue Sep 13, 2021
If not for #32, we could leasily enable interaction for some tests
using (localOption $ Interactive true).  Instead, we turn it on in the
CI, breaking generability of haskell-ci.yml.
andreasabel added a commit that referenced this issue Sep 20, 2021
If not for #32, we could leasily enable interaction for some tests
using (localOption $ Interactive true).  Instead, we turn it on in the
CI, breaking generability of haskell-ci.yml.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug option Concerning options (OptionSet)
Projects
None yet
Development

No branches or pull requests

2 participants