First or all, thank you for this project, looks very useful. Second, sorry if this is a duplicate, I've tried to look around in the open or closed issues.
Description
When converting an Assert.AreEqual(variableExpression, constantExpression) to Should().Be(...), the constant expression is placed in front.
EDIT: I do see and understand that the arguments in formal signature of Assert.AreEqual are in order of expected and actual, however, in many codebases I've met with, these two are exchanged consequently, so some kind of an auto-detection of this exchange covering at least most of the cases would be very nice.
Expected behavior:
I would expect keeping the convention of the form variableExpression.Should().Be(constantExpression)
Actual behavior:
It rewrites to opposite, constantExpression.Should().Be(variableExpression)
Versions
0.30.0
netcoreapp3.1
Additional Information
If this is by design, could there be any kind of configuration or any other alternative option to prefer this rewrite format?
Meir017
commented
7 months ago
First or all, thank you for this project, looks very useful. Second, sorry if this is a duplicate, I've tried to look around in the open or closed issues.
Description
When converting an
Assert.AreEqual(variableExpression, constantExpression)toShould().Be(...), the constant expression is placed in front.EDIT: I do see and understand that the arguments in formal signature of
Assert.AreEqualare in order ofexpectedandactual, however, in many codebases I've met with, these two are exchanged consequently, so some kind of an auto-detection of this exchange covering at least most of the cases would be very nice.Expected behavior:
I would expect keeping the convention of the form
variableExpression.Should().Be(constantExpression)Actual behavior:
It rewrites to opposite,
constantExpression.Should().Be(variableExpression)Versions
Additional Information
If this is by design, could there be any kind of configuration or any other alternative option to prefer this rewrite format?