-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Erroneous TeamCity service messages with multiple test assemblies and (default) parallel execution #14
Milestone
Comments
This was referenced Aug 17, 2016
NikolayPianikov
pushed a commit
to NikolayPianikov/teamcity-event-listener
that referenced
this issue
Sep 8, 2016
…mblies and (default) parallel execution - use test's id as a base for flowId for TC service messages in the case when NUnit 3 console runs test for nunit.framework.dll v2 in parallel mode
NikolayPianikov
pushed a commit
to NikolayPianikov/teamcity-event-listener
that referenced
this issue
Sep 9, 2016
…blies and (default) parallel execution - remove some tests to fix CI issue "Build execution time has reached the maximum allowed time for your plan (60 minutes)."
NikolayPianikov
pushed a commit
to NikolayPianikov/teamcity-event-listener
that referenced
this issue
Sep 9, 2016
…blies and (default) parallel execution - fix CI
NikolayPianikov
added a commit
that referenced
this issue
Sep 12, 2016
#14 Erroneous TeamCity service messages with multiple test assemblies and (default) parallel execution
Fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@einert commented on Mon Aug 15 2016
When running nunit3-console.exe for a list of several (six) test assemblies and with the
--teamcity
flag, like so:nunit3-console.exe --teamcity first.test.dll second.test.dll ... last.test.dll
, the service messages produced are incomplete. Specifically, the output does not contain more than onetestSuiteStarted
message, and onetestSuiteFinished
message, which does not match the start one. Which suite/flow is reported seems to be arbitrary.One consequence of this is that the report in TeamCity is different from run to run in terms of suite placement, even if nothing has changed. This can really mess with test report consistency if some assembly and/or test names are very long, considering the 255 character limit on the combined suite + assembly + test name.
The expected output is a full set of matching start/finish messages, one for each assembly, each with their own
flowId
.Adding '--agents=1' yields the expected (correct) output.
Incidentally, the first attempt, using the
--inprocess
argument with--teamcity
, did not really work out, but produced:@CharliePoole commented on Mon Aug 15 2016
Please indicate the version of the console runner you are using.
@einert commented on Mon Aug 15 2016
Issue observed with 3.4.1 as well as 3.5.0-dev-03126.
@NikolayPianikov commented on Mon Aug 15 2016
@CharliePoole I will try to reproduce it in integration tests
@einert commented on Mon Aug 15 2016
Note that all tests seem to be executed and listed, but the suites (assemblies) have unpredictable representation in the report. This produces structural differences in the reported test results when picked up by TeamCity.
@CharliePoole commented on Mon Aug 15 2016
The problem using
--inprocess
is due to #1742 - sincedomain=Multiple
is the default when running more than one assembly in the same process.@NikolayPianikov commented on Mon Aug 15 2016
@einert could you attach TC build log file, could you reproduce it from the command line and attach the console ouput too.
@CharliePoole I found another problem while reproducing it. I've received "Could not load file or assembly 'nunit.framework' or one of its dependencies. The system cannot find the file specified." message when I added "--domain=None" to the command line.
@CharliePoole commented on Mon Aug 15 2016
See issue #1741. The --domain=None option is an obscure one and should really only be used in special cases, where some code being tested can only run in a primary AppDomain. It requires all files, including NUnit's, to be accessible in the AppDomain. Is there a reason to use it here?
@NikolayPianikov commented on Mon Aug 15 2016
@CharliePoole I've added integration tests for all variants including --domain=None.
It works when nunit.framework.dll is located in the same directory as the nunit3-console.exe only
@einert commented on Mon Aug 15 2016
@NikolayPianikov I'm afraid I can't easily attach the full TC build log verbatim due to IP restrictions. However, I can show the structure here before and after restricting agents by anonymizing a little.
Original build, only running with --teamcity argument:
After setting --agent=1, assemblies/suites are run consecutively and identified as "started" and "finished", which manifests like this when captured by TeamCity:
@CharliePoole commented on Mon Aug 15 2016
@NikolayPianikov Yes. That's what I would expect.
@NikolayPianikov commented on Mon Aug 15 2016
@einert could you attach the output including TC service messages for the case 1.
@einert commented on Mon Aug 15 2016
@NikolayPianikov This is not necessarily identical to case #1, but is a fresh run with the same symptomatic behavior (no agent restriction):
As you can see:
@NikolayPianikov commented on Mon Aug 15 2016
@einert what version of nunit.framework.dll do you use?
It looks strange, the output should contain elements like ##teamcity[flowStarted flowId='1-1001' parent='1-1004']
Could you create a request on https://jbs.zendesk.com/ and attach a full console output from the command line? Is it possible to attach your test assemblies - as I see you've created a set of assemblies reproducing this issue.
@einert commented on Mon Aug 15 2016
@NikolayPianikov Nailed it! Turns out that the project in question had had a partial tool update done. All test assemblies were built against nunit.framework.dll 2.6.1. Tests were run with nunit3-console 3.4.1.
After upgrading all references, things are looking much better.
The text was updated successfully, but these errors were encountered: