Verify Assert Argument Order #114
Conversation
|
Anyone have any thoughts about this one? |
|
This seems like it should be in the XUnit formatter vs. the code formatter. The code formatter is generally domain agnostic and focussed on coding style. This is focusing on the correctness of a single domain. |
|
Where is the "XUnit formatter"? I see the XUnitConverter, but that appears to be specifically about moving tests from one framework to another... not something you'd run on existing XUnit code... Though I could be mistaken. |
|
That is what I meant. That should be idempotent as well. This may also be better as an analyzer / code fix. |
|
Ah. I didn't realize it was intended to be run on already XUnit projects. I should be able to move it fairly quickly. |
Test assert methods assume that the "actual" value is a variable and the "expected" value is a constant for the most part. Inverting these arguments causes misleading test failure messages that hinder the ability to quickly diagnose test failures. Detecting obvious mistakes (where "actual" is constant, and "expected" is variable) can be done and the arguments swapped. Fix dotnet#105
ChadNedzlek
force-pushed
the
verify-order-submit
branch
from
352309d to
0c6d48d
Compare
|
There. I've moved it to the XUnit converter project. |
Test assert methods assume that the "actual" value is a variable
and the "expected" value is a constant for the most part. Inverting
these arguments causes misleading test failure messages that hinder
the ability to quickly diagnose test failures.
Detecting obvious mistakes (where "actual" is constant, and
"expected" is variable) can be done and the arguments swapped.
Fix #105