When generating assert the right side should be the "correct" side. #125
Comments
|
@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. |
|
I can't find formal note of this as style, but it is the style of basically all rust examples.
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 So yeah: strong +1 for switching the order. left = calculated |
|
@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. |
|
Yes, I saw that after posting, and, just looking now found a couple more. 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 My personal defaults also just map TLDR: |
… cases
Now the right side is the 'expected' one, and the left side is the 'input'. Example:
```rust
#[test_case(2, 2 => 2 + 3)]
fn result_which_panics(x: u32, y: u32) -> u32 {
x + y
}
```
Previously, the output was:
```
Left: 5
Right: 4
```
Now, it is:
```
Left: 4
Right: 5
```
Refs: frondeus#125
Now the right side is the 'expected' one, and the left side is the 'input'. Example:
```rust
#[test_case(2, 2 => 2 + 3)]
fn result_which_panics(x: u32, y: u32) -> u32 {
x + y
}
```
Previously, the output was:
```
Left: 5
Right: 4
```
Now, it is:
```
Left: 4
Right: 5
```
Refs: frondeus#125
Now the right side is the 'expected' one, and the left side is the 'input'. Example:
```rust
#[test_case(2, 2 => 2 + 3)]
fn result_which_panics(x: u32, y: u32) -> u32 {
x + y
}
```
Previously, the output was:
```
Left: 5
Right: 4
```
Now, it is:
```
Left: 4
Right: 5
```
Refs: frondeus#125
|
@ethanmsl @max-ishere FYI, fixed this specific problem on the open PR #140 |
Now the right side is the 'expected' one, and the left side is the 'input'. Example:
```rust
#[test_case(2, 2 => 2 + 3)]
fn result_which_panics(x: u32, y: u32) -> u32 {
x + y
}
```
Previously, the output was:
```
Left: 5
Right: 4
```
Now, it is:
```
Left: 4
Right: 5
```
Refs: frondeus#125
Now the right side is the 'expected' one, and the left side is the 'input'. Example:
```rust
#[test_case(2, 2 => 2 + 3)]
fn result_which_panics(x: u32, y: u32) -> u32 {
x + y
}
```
Previously, the output was:
```
Left: 5
Right: 4
```
Now, it is:
```
Left: 4
Right: 5
```
Refs: frondeus#125
|
I tested this on Was the change reverted? |
|
@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. |
|
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. |
|
@max-ishere, yes and no. The code internally has a match that handled the syntax for different structures.
|
|
I don't understand. The |
|
Sorry @max-ishere, maybe I misunderstood. Can you give a real example of what you're testing, please? The scenario described in the issue description was resolved, but maybe you expected an underlying modification that I wasn't aware of. |
This was the output of |
|
As you can see LHS and RHS in |
|
Actually, I just noticed that there wasn't a release with the PR I've made. Please reach out to @frondeus, as I'm not really aware of when the next release will be. |
|
Alright then. Since you already pinged them I won't. Just gonna wait for the release then |
|
@luke-biel, is there an estimate on the next release date? |
|
Can't we just release a patch with this change? |
|
@max-ishere that's why I marked @luke-biel. I'm no maintainer. |
|
It's been a year |
|
@max-ishere, yeah... It seems the maintainers are not available |
I have this testcase:
And the error I get is this:
It would be nice if when I read "right" it would be the corrent (right) expression.
The text was updated successfully, but these errors were encountered: