Giters

hspec / hspec-expectations

Catchy combinators for HUnit

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is it a good idea to add `shouldThrow` for pure values?

temyurchenko opened this issue · comments

commented

The would have to be two options, one using just evaluate to WHNF and one using force from deepseq.

Does it make sense to have it as a part of hspec-expectations? If so, I can submit a PR

commented

Thoughts:

  1. We would need three versions of shouldThrow, increasing the API surface for all users of Hspec. At this point it's not clear to me how we would name these, and if it would be easier to remember those names instead of using evaluate and force explicitly.
  2. Exceptions from pure code is something that I try to avoid. For that reason I rarely need to test for exceptions from pure code. For the odd case when I actually need it I am happy to use evaluate and force explicitly.

If you still feel there is value in adding these primitives and if you can come up with good names, then please open a PR and I may change my position. As a fallback I may still be OK to add those to the .Contrib module.

commented

Thoughts:

1. We would need three versions of `shouldThrow`, increasing the API surface for all users of Hspec. At this point it's not clear to me how we would name these, and if it would be easier to remember those names instead of using `evaluate` and `force` explicitly.

2. Exceptions from pure code is something that I try to avoid. For that reason I rarely need to test for exceptions from pure code. For the odd case when I actually need it I am happy to use `evaluate` and `force` explicitly.

If you still feel there is value in adding these primitives and if you can come up with good names, then please open a PR and I may change my position. As a fallback I may still be OK to add those to the .Contrib module.

Exceptions from pure code is something that I try to avoid. For that reason I rarely need to test for exceptions from pure code. For the odd case when I actually need it I am happy to use evaluate and force explicitly.

To provide justification, I personally encountered this when making mock interpreters for DSLs for inspectable testing. While it is possible to make them total and not-throwing, the cost doesn't seem to be worth paying, given that they are only used in tests.
Maybe this justification isn't enough.

As for the names, I also don't see a candidate without flaws. I guess it is better to just leave the decision to each user.