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

Nicer infix operators? #262

Open
kindaro opened this issue Aug 31, 2019 · 7 comments
Open

Nicer infix operators? #262

kindaro opened this issue Aug 31, 2019 · 7 comments

Comments

@kindaro
Copy link

kindaro commented Aug 31, 2019

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.

  1. 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.

  2. 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.

@UnkindPartition
Copy link
Owner

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:

  • shouldSatisfy from HSpec
  • something like assertLeft :: Either a b -> (a -> Assertion) -> Assertion and assertRight :: Either a b -> (b -> Assertion) -> Assertion
  • go through hunit and hspec and see if there's anything else worth borrowing

So if you feel like having a go at redesigning the HUnit module with the above considerations in mind, please do.

@kindaro
Copy link
Author

kindaro commented Sep 2, 2019

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.

@UnkindPartition
Copy link
Owner

Yes, I think we've been stuck with the original HUnit design for too long, so a well designed replacement would be welcome.

@fendor
Copy link
Contributor

fendor commented Mar 12, 2021

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 ?=.

@re-xyr
Copy link

re-xyr commented Apr 26, 2022

Is this still open to PRs? I'd like to implement hspec-style predicates for tasty-hunit.

@sol
Copy link

sol commented Apr 26, 2022

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.

@re-xyr
Copy link

re-xyr commented Apr 26, 2022

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.

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

No branches or pull requests

6 participants