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

add relation stuff ala === and /== #196

Merged
merged 2 commits into from
Apr 21, 2019

Conversation

chessai
Copy link
Contributor

@chessai chessai commented May 15, 2018

This PR adds 4 functions, that have similar behaviour to === and /==, except they correspond to different relations.

(<==) ~> (<=)
(>==) ~> (>=)

(>>>) ~> (>)
(<<<) ~> (<)

As for naming, I tried to keep them to three characters while making sure their names didn't conflict with anything popular.

The reason I wanted this is that I was doing some numerical computations and wanted to test that the result of a computation was less than or equal to a particular value.

@andrewthad
Copy link
Contributor

The names >>> and <<< conflict with some stuff from Control.Arrow. I find those names confusing, but I like the idea here. Maybe non-infix names would be better here, but that's just my two cents as a very casual user of hedgehog. The project maintainers probably have better vision for this kind of thing.

@chessai
Copy link
Contributor Author

chessai commented May 16, 2018

I considered Control.Arrow; but I weigh that pretty low, since it isn't used much. Other people might weigh that higher.

As far as the names being confusing, I agree that they definitely may be. I considered (<<=)hedgehog_pr, but that looks too close to (=<<)base, and its counterpart (>>=)hedgehog_pr is nominally (in the linguistic sense) equivalent to (>>=)base. If anyone has any idea for a better name for those, I certainly wouldn't object. I don't know if it's necessary to continue the trend of three characters - it's possible that they could be english character names.

@thumphries
Copy link
Member

thumphries commented May 16, 2018 via email

@chessai
Copy link
Contributor Author

chessai commented May 18, 2018

@thumphries Would you be in favour of a non-infix operator name?

@chessai
Copy link
Contributor Author

chessai commented Sep 28, 2018

ping

@jacobstanley
Copy link
Member

Not a fan of this I'm sorry, I'd like to keep operators to a minimum. I think this is prettier anyway:

assert $ x > y

Of course it doesn't do the diff, but that's mainly useful for large data structures and I wouldn't have though comparing those for ordering is common enough to include dedicated functions. Maybe you have an example?

Also there's no way I'd merge operators which clash with both Control.Category and Control.Arrow (i.e. >>> and <<<)

@jacobstanley
Copy link
Member

jacobstanley commented Apr 17, 2019

I apologize for the tone of the last message I think I was in a bit of a bad mood when I wrote it.

I've been considering this PR since I last replied, and I think I found something I'm happy with. I pushed an update to to your branch which renames the operators to use an @ prefix which I pronounce "assert" and then the standard haskell name for the operator. I kind of like this even though it's a bit ugly because once you learn the rule (prefix with @) then you know how to get all the rest. Because of this, I added @==, and @/= even though they are redundant just for completeness.

I would appreciate everyone else's input on this though.

@chessai great work on hedgehog-classes by the way, I think we're going to try and use it to remove our QuickCheck / checkers dependency from our test code. /cc @moodmosaic

@jacobstanley
Copy link
Member

jacobstanley commented Apr 17, 2019

As discussed with @amosr @HuwCampbell, I've added function to assert relations directly.

Arguably the operators are no longer required, but they do have the advantage of perhaps slightly nicer failure output. Any opinions either way on whether we should keep the operators given the new relation function is appreciated.

Failure using operators

Screenshot 2019-04-17 at 7 26 56 PM

^ I'm not sure this extra info is a big win?

Failure using relation

Screenshot 2019-04-17 at 6 53 29 PM

@moodmosaic
Copy link
Member

Keeping the function that @jystic added should be good enough, perhaps I'd consider giving it a different name (I think I've actually never seen relation as a function name in any testing tool out there).

Basically we have this already which is good enough

assert $ x > y

perhaps the proposed relation one could be renamed, e.g. → relate, but really not sure about adding more operators 😕


The issue I see with adding more operators is that it makes it hard(er) to draw a line; where do we stop adding more assertion-specific stuff?

I often see assertions packed on separate libraries (see Groovy Power Assert, Unquote, etc). It's just the Unix philosophy at the end; do one thing and do it well...

@jacobstanley
Copy link
Member

think I've actually never seen relation as a function name in any testing tool out there

That is what it's called though https://en.wikipedia.org/wiki/Relational_operator

@moodmosaic
Copy link
Member

That is what it's called though https://en.wikipedia.org/wiki/Relational_operator

That's great then 👍


infix 4 @==

-- | Fails the test if the two arguments provided are equal.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"not equal"? (And I think the @/= comment is the wrong way around too)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, you're right oops

i think i might remove the operators anyway after chatting to a few people about this PR

relation x (<=) 'r'

relate y (<) 87
relate x (<=) 'r'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would appreciate some comments on which name people like best or some other one? The main point of this is to provide a diff, otherwise you'd just use assert and annotate.

Also is the infix style crazy? it's kind of non-haskellish but it does read pretty nice.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no strong opinions, but comparison is my favourite. I like the infix style, I think it makes the meaning pretty obvious.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like diff and relate, I like how they sound, diff this with that, relate this with that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing @moodmosaic and I discussed with comparison is that it's not a verb, like if we could use compare that would be awesome but it's already taken by Ord

@chessai
Copy link
Contributor Author

chessai commented Apr 18, 2019

I apologize for the tone of the last message I think I was in a bit of a bad mood when I wrote it.

I didn't pick up on any rudeness, so it's ok.

Thanks for picking up some work on the branch


relate :: (MonadTest m, Show a, Show b, HasCallStack) => a -> (a -> b -> Bool) -> b -> m ()
relate = diff

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think diff sounds more clear than all the others, short and sweet, diff this with that 🚀 🚀 🚀

@jacobstanley
Copy link
Member

Looks like diff is the winner 📜

I am still willing to change it if someone has better ideas / good arguments as long as it's prior to the next release.

@moodmosaic
Copy link
Member

👍

import Hedgehog.Internal.Source
import Hedgehog.Internal.Property (MonadTest, Diff(..), success, failWith)
import Hedgehog.Internal.Show (valueDiff, mkValue, showPretty)
import Hedgehog.Internal.Source (HasCallStack, withFrozenCallStack)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch 👍

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

Successfully merging this pull request may close these issues.

None yet

7 participants