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

Question: stop tests on first failure (--fail-fast) #55

Open
schoettl opened this issue Aug 15, 2020 · 3 comments
Open

Question: stop tests on first failure (--fail-fast) #55

schoettl opened this issue Aug 15, 2020 · 3 comments

Comments

@schoettl
Copy link

What's the best way to cancel the test runner on the first failure (like bash's -e/-o errexit)? Is it even possible?

I looked in RunnerOptions, but I didn't find it here.

In my case, the Tests are actually HUnit Tests which are IO actions (-> shelltestrunner).

I can't even just use die or fail in the IO action because the test runner continues on error:

image

I'd be glad if an experienced Haskeller could give me a hint!

@sol
Copy link
Member

sol commented Aug 15, 2020

Hspec provides this functionality with --fail-fast. If converting your tests to Hspec is not feasible, you can try to run your existing tests with Hspec by using

(not sure how well either of these options will work in the context of shelltestrunner, though)

I can't even just use die or fail in the IO action because the test runner continues on error:

Alternatively: If your are set on test-framework, try throwIO UserInterrupt (from Control.Exception). At least HUnit will not catch these. So provided that test-framework behaves sane, it should terminate the process.

@schoettl
Copy link
Author

Thanks for your answer! Oh, you are the author of hspec, what an honor :) I used it (and also QuickCheck2) a lot in an early project.

Hspec provides this functionality with --fail-fast. If converting your tests to Hspec is not feasible, you can try to run your existing tests with Hspec by using

That looks good. As far as I understand, I would have to convert the tests to Hspec and then just call hspec convertedTests in the shelltestrunner's main function. It should work but yield different output than current shelltestrunner.

I've found the options page, some are similar to what shelltestrunner/test-framework use.

But I fear it would be much refactoring work in shelltestrunner, for me. It would probably be less work to add a --fail-fast option in test-framework.

I have to think about if or how shelltestrunner could combine or allow both alternatives: hspec and test-framework. Maybe a --use-hspec option for shelltestrunner which then uses hspec instead and accepts some hspec options.

Alternatively: If your are set on test-framework, try throwIO UserInterrupt (from Control.Exception). At least HUnit will not catch these. So provided that test-framework behaves sane, it should terminate the process.

Good idea, that would be a simple approach. shelltestrunner reports shelltest: user interrupt and stops, but it does not exit until I press Ctrl-C. Don't know if that is a test-framework or shelltestrunner problem. From the output, it looks like test-framework passes the exception to shelltestrunner. Pressing Ctrl-C directly works and does not print the shelltest: user interrupt. Anyway, it's not perfect when shelltestrunner cannot distinguish between user interrupt and first failed test...

@schoettl schoettl changed the title Question: cancel tests on first failure Question: stop tests on first failure (--fail-fast) Aug 16, 2020
@sol
Copy link
Member

sol commented Aug 16, 2020

Good idea, that would be a simple approach. shelltestrunner reports shelltest: user interrupt and stops, but it does not exit until I press Ctrl-C.

I think the issue here is that test-framework runs your tests on a worker thread and does not propagate the exception to the main thread. So my suggestion won't work without modifications to test-framework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants