Currently if you have more than one or two assertEquals in a single test stanza it's infuriating to figure out why a test failed.
Simply reporting the values themselves via Show would be wunderbar. I'm using a helper function to work around this.
Better still would be to use a pretty-printing function that uses Show. I've had great luck with pretty-show.
I'm going to file an issue for a more elaborate version of this that uses diffing + pretty-printing as a wishlist item. There's really no reason for us to not have the kind of polish that Ruby, Python, etc. users are accustomed to. We should not settle for this.
Here's an example of what my test failure currently looks like with assertEqual:
can report on stats FAILED [1]
Failures:
./Yesod/Test.hs:319:
1) MyProject.Integration can report on stats of rows for all related data
active rows
I've stripped the descriptions themselves a little, but the point is, a number from the stats wasn't equal to what we expected (3 /= 0 or somesuch) and we're told little beyond the message attached to the assertEqual itself ("active rows").
Currently if you have more than one or two
assertEquals in a single test stanza it's infuriating to figure out why a test failed.Simply reporting the values themselves via
Showwould be wunderbar. I'm using a helper function to work around this.Better still would be to use a pretty-printing function that uses Show. I've had great luck with
pretty-show.I'm going to file an issue for a more elaborate version of this that uses diffing + pretty-printing as a wishlist item. There's really no reason for us to not have the kind of polish that Ruby, Python, etc. users are accustomed to. We should not settle for this.
Here's an example of what my test failure currently looks like with
assertEqual:I've stripped the descriptions themselves a little, but the point is, a number from the stats wasn't equal to what we expected (3 /= 0 or somesuch) and we're told little beyond the message attached to the
assertEqualitself ("active rows").