Open kindaro opened 5 years ago
Changing the existing module is indeed not an option.
However, I am all for a redesign (under a new name — say, Test.Tasty.HUnit2) with better names etc.
There are also some functions/operators that I miss:
assertLeft :: Either a b -> (a -> Assertion) -> Assertion
and assertRight :: Either a b -> (b -> Assertion) -> Assertion
So if you feel like having a go at redesigning the HUnit module with the above considerations in mind, please do.
So if such a patch were to appear, there is a reasonable expectation that it will be merge? If such is the case, then I am putting it in my to do list.
Yes, I think we've been stuck with the original HUnit design for too long, so a well designed replacement would be welcome.
I would like to second more assertion primitives, e.g. appreciate something like hspec
's shouldReturn
, similarly shouldThrow
, etc...
Additionally, in my opinion real names are preferable to infix operators. Especially when others such as shouldReturn
, shouldSatisfy
and shouldThrow
are added which maybe have no nice infix operator.
So, I would at least would like to have synonyms for infix operators such as =?
and ?=
.
Is this still open to PRs? I'd like to implement hspec
-style predicates for tasty-hunit
.
hspec-expectations
builds on top of HUnit
and it does not depend on hspec-core
or any other parts of hspec
.
This is by design so that hspec-expectations
can be used with any testing library that uses HUnit
.
Instead of reimplementing hspec-expectations
for Tasty it may make sense to revisit #327 instead.
Yes, that was what I initially thought... the divide between tasty-hunit
and hunit
is really confusing. But then I read that this change was intentional (#230). Some years have passed since though, and it's possble that @UnkindPartition will change their mind.
I know there is a strong sentiment in the Haskell community towards legacy support, backwards compatibility and so on, and I am prepared to discover that this is a "wontfix", but I would like to express my vote anyway.
HUnit has operators
@?=
and@=?
. I propose we change them to?=
and=?
— it would be so much more readable and intuitive. (Which side the question, the same side the value being checked.) Hoogle does report a couple of packages using these names, but I claim that a test engine is used far more widely (ideally, in every package) and so it is fair to have the shorter names.Let us redefine
QuickCheck.===
to mean extrinsic equality for functions:f === g = \x -> f x == g x
. Properties are quite often expressed as equality of functions anyway — think of the laws of any standard class.Consider that any function benefits from an example and, better, a property too. So these operators might be used more often than any other function at all, and every small nuisance is magnified.