Access options from HUnit assertion?

[dag]

I have a package for adding support for diffing on failure for HUnit equality assertions, and it uses ansi-terminal to add coloring. I'd like to integrate it into test-framework so that the coloring is aware of the --plain option. Is there a way to access the test-framework options from a HUnit assertion?

[batterseapower]

Interesting. If you are doing this then it will anyway only work on Unix because the HUnit assertion failure message is a simple String, and Windows doesn't support ANSI escape codes.

How about another line of attack: we could add a function:

{{{
assertFailureDoc :: Doc -> IO a
}}}

And then test-framework could catch the new sort of exception it would throw (containing a Doc, not a String). It would then be possible for test-framework to remove any colorisation from the error message thus throw before actually displaying it.

Would this suit your needs?

[dag]

I don't actually have a Doc at the moment, since I'm using ansi-terminal directly, but perhaps I should use ansi-wl-pprint instead?

[batterseapower]

Oh I see, your assertion method doesn't throw an exception like the ones built into HUnit - it just writes to stdout immediately?

Unfortunately, writing directly to stdout won't work nicely with test-framework - your assertion failure messages will be interleaved with other information output by the framework (such as test name and test failure/success status). This occurs because test-framework buffers its output so that output comes out without any interleaving even if tests are being run on multiple threads.

Do you think the assertFailureDoc solution would work for you? This would indeed involve building a Doc for your error message using ansi-wl-pprint (which is already a dependency of test-framework, IIRC).

[dag]

I'm using assertBool, see code, so I don't think it writes to stdout directly but it's still limited to strings. Your proposed solution appears sound.

[batterseapower]

On 27 January 2012 14:43, Dag Odenhall
reply@reply.github.com
wrote:

I'm using assertBool, see code, so I don't think it writes to stdout directly but it's still limited to strings. Your proposed solution appears sound.

Now I understand! I thought you were using the functions from
ansi-terminal with IO type like hSetSGR. Yes, your code does not write
to stdout directly.

I'll implement some new assertions that take Docs and you should be
able to do what you want. The code will even be nicer since you don't
have to screw around with setSGRCode with ansi-wl-pprint :-)

[dag]

Cool!

[dag]

I think I'll port HUnit-Diff to ansi-wl-pprint and make a separate test-framework-hunit-diff package for the test-framework integration. Does that sound good?

[batterseapower]

That seems reasonable. Now I'm wondering if I should break out a new package like hunit-color that just provides the extras on top of HUnit that are necessary to throw ansi-wl-pprint Docs as exceptions. That way your package would not have to depend on test-framework-hunit to throw exceptions.

The main problem with the approach we're taking here is that if you use our new assertDoc functions in a HUnit assertion and then run it under regular HUnit (rather than test-framework-hunit) you will see that the test threw an exception, not that an assertion failed. This doesn't matter too much in practice but it is irritating.

I wonder if I should submit a patch to HUnit that would use the exception-hierarchy mechanism to post-hoc extend HUnit with more types of assertion failure, all of which gracefully degrade to a simple string? I will contact the maintainer, Dean Herington, about this idea.