ReSharper treats all steps as a single test in SDK style projects #373
Comments
Thanks for reporting this @michael-wolfenden. I don't have R# to hand right now (I run it in a VM on another machine) but I'll look into this ASAP. /cc @citizenmatt - any ideas? |
Click on the "OK" in the top right of that window - it should show you a log file. It might provide some useful information. I'll try and take a look tomorrow, but I'm trying to get a lot done before vacation... |
This was the info from the log file
|
I'm not going to get a chance to look at this before vacation, sorry. You can raise an issue at youtrack.jetbrains.com if you'd like. What do you get when you run it in the command line? I'm surprised it returns "ignored" - that means ReSharper has been directly told that it's been ignored/skipped. If a test is expected to run but doesn't, it usually gets "Inconclusive". |
I have raised an issue with jetbrains |
@adamralph just a quick update on this issue, I'm still waiting on a response from jetbrains. |
Thanks @michael-wolfenden! |
@citizenmatt Have I logged the issue correctly? There doesn't appear to have been any activity on the issue. |
Yep, great issue, thanks. I've had a look and I think it's working as expected, surprisingly. It looks like xbehave will run each step as a separate xunit test case. However, each step is being reported as the same test method, so ReSharper doesn't know that each step is different - it sees the same test being run 5 times. And when one step fails, the remaining steps are marked as skipped, but because the same test is being reported to ReSharper, the last write wins and ReSharper shows that test as having been skipped, even though one step passed, one failed and the rest were skipped. To fix this, you can report each step like a theory row, and ReSharper will add the node into the tree. However, this will probably do weird things if someone selects step 3 in the tree and hits run, because xbehave won't support this. Alternatively, don't report steps as multiple tests, but as a single test, one for the scenario itself. If you only report one test result (passed, failed or skipped) then ReSharper will display it correctly. |
Thanks for investigating @citizenmatt Thoughts @adamralph? |
@michael-wolfenden I'm travelling currently but will chime in ASAP. |
Hey @adamralph, have you been able to look at this? I just noticed the issue too. At some point, R# showed each step of Xbehave scenarios, but now it doesn't; I suspect this is related to this problem. I don't know if the regression is in R# or in Xbehave. Did anything change in how Xbehave reports scenario steps? |
@thomaslevesque that problem was raised in #366. As far as I can tell, it's a bug in ReSharper. In fact, I think this issue is the same problem. Because ReSharper is not treating each step separately, the result of the last step is used as the result of the entire scenario. |
This is the same issue as #366 so I'm going to merge them. |
@citizenmatt you are correct, but what xbehave is doing is no different to an xunit theory (in the case where the arguments do not serialize). More on that here.
Again, that is exactly what is happening. An xbehave scenario behaves just like an xunit theory which evaluates tests at execution time and not discovery time, which is a recognised behaviour in xunit that test runners should respect.
I wouldn't worry about it. As you can see from the screenshot here, ReSharper is already reporting them separately for old-style csproj. If people see weird things happening when trying to run a single step then they'll soon learn to run the entire scenario instead. Or perhaps, that does indeed kick off the entire scenario already.
The reporting of each step as a separate test (with a natural language description) is the whole idea behind xbehave. 😄 |
@citizenmatt I've pushed a repro to https://github.com/adamralph/resharper-xunit-theory-bug Here you can see the problem in all its gory details: For the "classic" csproj (bottom), everything works perfectly. xunit theories are reported with all tests as separate leaves in the tree, as are xbehave scenarios. For "SDK style" csproj, only the xunit theories which have tests evaluated at discovery time have the tests reported as separate leaves. xunit theories which have tests evaluated at execution time have all the tests collapsed into a single leaf, as do xbehave theories. BTW - I checked to see what the behaviour is when a single xbehave step is executed from this UI and, indeed, the entire scenario is run, so we don't have to worry about any weird behaviour in that case. |
Ah, so it stopped working in FakeItEasy when we migrated the specs to the new csproj... In this case, I agree that the problem is probably in ReSharper. |
The repro was very useful, thanks. Turns out this is a known issue - RSRP-464565, scheduled for a fix in 2017.3 (next release). I've run the tests with tracing enabled, and from what I can tell the dotnet test API looks like it's sending the wrong information. The I don't know if this is a fault of the vstest platform, the xunit test adapter, or if I'm reading the trace wrong... |
👍 thanks @citizenmatt. I've added an entry for this in the known issues in the xBehave.net wiki. Thank you @michael-wolfenden for opening this issue. |
@michael-wolfenden I've confirmed this from my end too. Great work @citizenmatt and team! I've updated the FAQ. |
Given the following packages
and Resharper version
When running the follow test via resharper
Resharper's test runner is marking the test as inconclusive (not failed)
I have a repository that reproduces the issue at:
https://github.com/michael-wolfenden/xbehave-issue
The text was updated successfully, but these errors were encountered: