Some failure messages are a bit backwards about goconvey HOT 9 CLOSED

👍 +1

from goconvey.

@mholt Can you take a look at the messages.go file in the assertions package and tell me which groupings of messages you would change? The "Equality" and "Type checking" groupings are a given--it's easy to arrange those messages like this:

Expected: <expected_value>
Actual: <actual_value>

But I'm not sure if the others need to change and if they do, what the changes should be.

from goconvey.

Right, I think just a couple like ShouldResemble and ShouldBeEqual and a few others merit a change.

from goconvey.

Okie, done.

from goconvey.

I think I'd like to re-open this issue and modify all of the failure messages toward something more in line with mspec (which is what we've been using in the 'magical' land of .Net and was a big inspiration for goconvey):

https://github.com/machine/machine.specifications/blob/master/Source/Machine.Specifications/ExtensionMethods.cs

What do you think @mholt and @joliver?

This is what I'd like to do with ShouldEqual when comparing strings (and maybe even arrays/slices when compared with ShouldResemble):

https://github.com/machine/machine.specifications/blob/869509569dc0b3bc49311e88a9bd39494b273291/Source/Machine.Specifications/Utility/Internal/PrettyPrintingExtensions.cs

from goconvey.

Now we have to be very careful when changing output messages like this, because the web UI does some mild parsing of the expected/actual strings.

from goconvey.

Which is kind of why I wanted to make the failure messages so easy to understand as presented in console-mode that we could just show them as-is in the web UI... The JSON contract will be pretty standard, but banking on a contract within a failure string is inherently fragile.

Maybe we could think about an additional step in the web server parser that turns certain failure messages into json so that the client won't break. Or maybe there could be JSON failure strings when the json flag is provided to GoConvey. I'd really like to adopt a scheme that allows us to improve failure messages without consequence to the web UI.

from goconvey.

If the JSON had fields especially for what was Expected and Actual (when applicable), that would eliminate the need for parsing.

from goconvey.

Yes that is one of the options. Stay tuned for the redesigned failure strings. That might be the clearest way, both from the perspective of the code to get it done as well as the user experience.

from goconvey.