Closed catriuspham closed 7 years ago
@NhanHo @hieueastagile Please take a look
Looks good to me so far, but I want to see is the explanation for comparing 2 objects (do the diff like what sure
does)
@oyster Could you please somehow turn off the comments from coveralls
every time one pushes his code? It spams too much and I think the checks
table at the end of the PR has enough information.
It should be configurable in Coveralls settings. Please check if you can do that, @catriuspham. Or you can ask @hieueastagile to use our open source account to do it if you don't have privilege. Thanks.
lol, it's quite useful to me :)). Anyway, let me see if we can turn off it tomorrow.
@hieueastagile @NhanHo @nhanbt I finished this PR, please take a look when you guys have time
@seri-ea would you like to take a look? :stuck_out_tongue_closed_eyes:
I will @catriuspham
@catriuspham I made some minor suggestions, but as a potential user of EA-robber.py, I find the explanation format a bit unfriendly.
I mean, why:
BadExpectation:
A = 123
B = "123"
Expected A to equal B.
Instead of this:
Expected <int>123 to equal <string>123
And yet it doesn't support what @hieueastagile was looking for (explanation for comparing 2 objects). Sure we can and should do that in another PR as a detailed implementation of the build_diffs
method, but for now I wonder if we could take a step back and re-think the message format.
@seri-ea the reason for the messages to have the format
BadExpectation:
A = 123
B = "123"
Expected A to equal B.
is that sometimes the represented string of A and B can be super long, so we need to find a consistent way to make them look as clear as possible.
For example, this message
Expected <string>"Some super long texts that make your eyes bleed a lot until you faint" to equal <string>"Some super long texts that make your eyeballs bleed a lot until you faint"
look awkward.
But it's a lot better with the new format:
BadExpectation:
A = Some super long texts that make your eyes bleed a lot until you faint
B = Some super long texts that make your eyeballs bleed a lot until you faint
Expected A to equal B.
@catriuspham Thanks for the explanation. The counter argument is that while your format makes it clear for when the string representations are long, it makes most cases harder and longer to parse (the reader has to look up A, B, C... kind of awkward), and that's probably why no popular testing library is using your failure message format yet.
Maybe only break down into lines for special cases such as the equality matcher, where you are going to have to do deep comparison and handle it exceptionally anyway.
@seri-ea Actually, the idea of this format is taken from how unittest
display its failure message, it's not something that I make up myself though. I agree with you that in some cases when the represented strings of the objects are short, the message looks awkward. But on the larger scale, to me, this is the best format I can think of to cover all the cases. To detect when to use the new format, when to keep the old one would require a lot of effort though.
@catriuspham Actually, you don't need a format which works for all cases, most of the messages are specific to its own assertion, we don't need to make it generic like you did. Anyway, I feel what you did are already good enough, not the best but usable, just let me know when you finish the diff for object/array, then we can merge it. I really want it to be merged soon and we will deploy it to pypi as robber 1.2.0. We should do another refactor later for robber 2.0, where we can think more carefully about the architecture.
@hieueastagile Please give me 1-2 day to with the none
param issue. Gonna notice you as soon as I finish it.
Take your time, no rush then @catriuspham
@hieueastagile All things are done. However, I guess we have to wait for coverage
, it's been 4 hours though...
@hieueastagile Everything's good. Please take a look and merge this PR whenever you want.
@catriuspham Let me test it a bit first, I will tell anh Quang to merge when I finished. @NhanHo @nhanb @steadykhoi @hotay please help take a look on this PR also.
Status
Done
Related issues
https://github.com/EastAgile/robber.py/issues/39
Description
Let's implement an explanation system, where all the failure messages will have the following format, from which the second and the third line can be omitted.