-
Notifications
You must be signed in to change notification settings - Fork 45
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
Add support for running & reporting doctest tests #40
Comments
@fushunpoon We once had test-framework integration for Doctest, but it has been deprecated, mainly because it was much slower than running doctest from the command-line. The recommended way to run Doctest is to add a separate A basic usage example is included in Doctest's repository (have a look at the corresponding cabal file!). For other useful stuff (that we should probably include with Doctest at some point) look at some of @ekmett packages. |
@sol thanks for your response. However, I maintain that we should supply an integration for doctests. I mightn't fully understand actually caused the performance situation that motivated the creation of another command line runner called However, the mission of test-framework (or so I presume) is to be THE de-facto test runner framework for Haskell. I for one would like to see test-framework be as prominent as 'JUnit' or 'TestNG' is to Java. With test standardisation, you open the doors to running tests selectively in IDE's, test parallelisation, have a single entry point for CI (e.g. What's more, you still can choose to execute Solution? If a previous project already exists for this, then we have a simple solution: let's just merge the deprecated package into this code-base. My argument for this is: slow is far far better than non-existent. Even if the final solution calls EDIT: one thing that immediately comes to mind with this sort of delegation is that |
I found the relevant issue on Or perhaps we've raised another question altogether here:
Cabal Test-Suite declarations For the record, I think that one Cabal Simply put, you end up with test-suites organised around the kind of test being written, rather than what it really should be: you organise your test code around the structure of your actual Haskell software modules! On the contrary, if Contrast this with the way Cabal runs tests, which is... well, blindly. |
Supporting doctest-haskell can be an invaluable feature for the Haskell development experience, as well as for the development of
test-framework
itself.This is because test-framework itself has a number of test reporters that output test results onto the consoles. However, currently there are no tests documenting what the console would actually output.
The text was updated successfully, but these errors were encountered: