Replies: 7 comments 1 reply
|
Here is more real example I'm seeing: expected to equal <[field(title: "Amount", value: "<positive>+</positive> 60.00 GBP"), field(title:
"Date completed", value: "Monday, January 1, 2001")]>, got <[field(title: "Amount", value: "
<positive>+</positive> 60.00 GBP"), field(title: "topup.details.dateCmpleted", value: "Monday,
January 1, 2001"), action(title: "Repeat this pay-in", type:
CustomControls.TWButtonStyle.secondary, action:
Transfer.ActivityDetailsViewModel.Action.repeatTransfer(1)), field(title: "Transfer number", value:
"#1")]> |
|
I agree this could be improved, excellent suggestion.
|
|
I've got a similar issue with Realm objects, and the error messages are pretty monstrous: I feel like the issue here isn't arrays per se, but anything with a long and unhelpful string representation. For reference, here's what Java's AssertJ does (comparing two vavr In both cases, you get, first, an abbreviated version that concentrates on the spots that differ, and then the full version of expected and actual on separate lines, so they're (relatively) easy to compare. |
|
I'm presently running into an issue using Nimble to equate strings that are quite large, and the output that's produced is pretty unusable. I wanted to throw my support for this style of diffing to be added to nimble. I have some spare bandwidth to make these changes if no one else is going to be working on this. |
|
IMO the best would be to fix this in a generic way with diffs as discussed in #899 |
|
Is there any plan to fix this problem? |
Uh oh!
There was an error while loading. Please reload this page.
Consider the following examples:
It is kinda readable, but the thing is that in my experience arrays could contain long strings and / or enums with associated values, and it makes it impossible to understand what actually went wrong.
In this particular case failure message could be
"expected array to have 5 elements, but got 4".Another case:
Which is again, readable but only if we operate with short values.
In this case message could be
"expected to have "4" at index 1, got "2"".Of course, one could resort to per-element comparison, but it does not feel right (or, maybe I'm just overthinking, please let me know)
Exact messages text could be reconsidered, but I hope you get the idea.
All reactions