When generating assert the right side should be the "correct" side.

[max-ishere]

I have this testcase:

#[test_case(false => true; "Should invert")]
fn foo(statement: bool) -> bool {
    statement
}

And the error I get is this:

left: `true`,
right: `false`,

It would be nice if when I read "right" it would be the corrent (right) expression.

[AugustoFKL]

@max-ishere, is there any reason for this besides it being "nice"?

The left item being the expected one is is the conventional ordering used in many popular testing frameworks such as JUnit, NUnit, and Python's unittest. In this convention, the expected value is placed first, followed by the actual value.

[dream-dasher]

@AugustoFKL

I can't find formal note of this as style, but it is the style of basically all rust examples.

assert!(result, expected)

see, for example here in Rust std docs

//Doc Test

let a = [1, 2, 3];
assert_eq!(a.iter().count(), 3);

let a = [1, 2, 3, 4, 5];
assert_eq!(a.iter().count(), 5);

I agree with max, it's very jarring to have <result, expected> everywhere, and then reversed specifically in test_cases where an output is specified. I know I have to spend enough mental cycles that I use the library much less than i otherwise would.

(And it's not helped by the fact that the macros is literally #[test_case( input, input => expected)], which also, visually, matches the 'calculated, expected' layout.)

So yeah: strong +1 for switching the order.

left = calculated
right = expected

[AugustoFKL]

@ethanmsl, the problem is that the same reference you sent me uses both:

let a = [1, 2, 3];

let mut iter = a.iter();

// A call to next() returns the next value...
assert_eq!(Some(&1), iter.next());
assert_eq!(Some(&2), iter.next());
assert_eq!(Some(&3), iter.next());

// ... and then None once it's over.
assert_eq!(None, iter.next());

// More calls may or may not return `None`. Here, they always will.
assert_eq!(None, iter.next());
assert_eq!(None, iter.next());

But I see where @max-ishere is coming from. Indeed, the order that we use is left as input and right as expectancy, inverting it seems confusing, considering the absense of a set-to-stone rule regarding assertion positioning in Rust.

Therefore, I agree that in this scenario it would be more reasonable to invert them. I can work on having a PR for this in the next 2-3 weeks.

[dream-dasher]

Yes, I saw that after posting, and, just looking now found a couple more.
These are very much int he minority style, but it prompted me to search a bit more for the rust documentation style guide and ... there's no mention either way.

I've reached out to the #docs channel to see if they have any thoughts on norms or expectations.

So, there's no hard guideline I can point to. But my own background eyeball stats (not 100% reliable) suggest that
( calculated, expected ) is very much the style norm and what people will tend to expect in rust.

My personal defaults also just map input1, input2 => output to calculated => expected, so I think it's worth considering.
(also, if I'm hammering on a problem, the top or leftmost element is most significant and it will be the calculation that I'm looking at in these cases -- though granted that's a more minor point probably)

TLDR:
still a strong vote for expected on the right from me :) , but no formal standard for rust that I've yet found

[AugustoFKL]

@ethanmsl @max-ishere FYI, fixed this specific problem on the open PR #140

[AugustoFKL]

@ethanmsl @frondeus I think we can close this, no?

It is already fixed by #140

[max-ishere]

I tested this on 3.3.1 and the output is still

assertion `left == right` failed
  left: "expected"
 right: "calc"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Was the change reverted?

[AugustoFKL]

@max-ishere, the affected scenario was 'a => b'. 'a == b' still has the same behavior.

I'd love to add a patch for that, but sadly I'm quite overwhelmed at the moment.

[max-ishere]

I don't understand... I haven't read the code but isn't it all the same macro? It should always have right as the correct side if this was actually implemented.