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

Remove hspec-expectations #260

Merged
merged 1 commit into from
Jul 31, 2020
Merged

Conversation

lukel97
Copy link
Collaborator

@lukel97 lukel97 commented Jul 31, 2020

Use @? and @?= instead, since they give easier to read error messages. The shouldX functions all just end up dumping the Show instance of a HSpecFailure or what have you which is hard to read. It also doesn't look like hspec-expectations is that actively maintained anymore

Use @? and @?= instead, since they give much easier to read error
messages. The `shouldX` functions all just end up dumping the Show
instance of a HSpecFailure or what have you which is really hard to
read. It also doesn't look like hspec-expectations is that actively
maintained anymore
@lukel97 lukel97 requested review from jeffwindsor, jneira and fendor July 31, 2020 13:53
@jneira
Copy link
Member

jneira commented Jul 31, 2020

I think it was added for legibility reasons, continuing hie style. Iirc @alanz (ad @fendor?) did prefer to not use operators.
I am slightly inclined to shouldBe but not stronger opinion about

@fendor
Copy link
Collaborator

fendor commented Jul 31, 2020

According to https://hackage.haskell.org/package/hspec-expectations-0.8.2/docs/Test-Hspec-Expectations.html#v:shouldBe

shouldBe :: (HasCallStack, Show a, Eq a) => a -> a -> Expectation
actual `shouldBe` expected = actual @?= expected

I am confused why this displays differently?

I am the one most opposed to operators such as @?=, @=? and @?, as they all look the same for me at the first sight.

@alanz
Copy link
Collaborator

alanz commented Jul 31, 2020

I have no strong preference on this, but generally prefer idiomatic coding. So if we are using tasty, it makes.sense to use the tasty operators.

@lukel97
Copy link
Collaborator Author

lukel97 commented Jul 31, 2020

According to https://hackage.haskell.org/package/hspec-expectations-0.8.2/docs/Test-Hspec-Expectations.html#v:shouldBe

shouldBe :: (HasCallStack, Show a, Eq a) => a -> a -> Expectation

actual `shouldBe` expected = actual @?= expected

I am confused why this displays differently?

I am the one most opposed to operators such as @?=, @=? and @?, as they all look the same for me at the first sight.

It's using @?= from Test.HUnit, not Test.Tasty.HUnit, which unfortunately doesn't get caught by Tasty and pretty printed. Converting it was pretty simple, since we were only using a handful of the combinators. The vast majority of assertions were of the form shouldBe

@lukel97 lukel97 merged commit 0adf4bd into haskell:master Jul 31, 2020
@fendor
Copy link
Collaborator

fendor commented Aug 1, 2020

I see. I still very much dislike these operators and like avoid them.
However, I also see the argument for more idiomatic code. We can't get Tasty to catch and display correctly?
I guess it is merged

pepeiborra pushed a commit that referenced this pull request Dec 27, 2020
The process of searching for definitions is similar to the process of searching
for hover information. In the original code (much of which was written out twice
with occasional stylistic differences) the signal to noise ratio seemed pretty
poor.

Here is a refactoring which aims to make it easier to see the similarities and
differences between these two related functionalities.
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.

4 participants