Now, I know we promised to release these features this week, but we didn't make it. Gearing up for release we found a couple of issues and took the decision to postpone it so we'll have better confidence in the version's quality.
We will work to release during next week - sorry about the delay :(
We upgraded our build server to NCover 3.0. I know that this version is not officially supported by TypeMock, but it displays "NCover 2.0" in the list of supported coverage tools and actually works. Sort of. What happens is this link is not sticky and reset after every build. So the build runs fine, calls are mocked and coverage is generated. But after the build is finished, link to NCover is cleared and unless somebody manually restores it the next build will fail in all mocked calls.
Then how should we configure build for parallel executions of several builds (in different source code branches)? We often run several builds at once (triggered by check-ins). Looks like we did not experience this problem earlier because only recently we started running selected unit tests on evey check-in.
So what's the purpose of TypeMockStop in such scripts? I checked examples, and they all have it. Documentation says that this command unregister TypeMock. Do we really need it?
TypeMockStop disables the Isolator and unlink it from whatever profiler is linked with it. You should use it if you have tests that doesn't need the Isolator.
Now the difference is that enabling the Isolator is in the process level. while linking is in the machine level (the registry is involved).
Parallel builds sure make things complicated :( Can you send a mail to our support and describe the build configuration (Are all running tests using the Isolator? Are all tests linked with NCover? etc) We'll try to help you out with it.
Thank you for the clarification. I will try to describe our configuration. I don't think it's exceptional, it's just that like many other teams we use unit testing more agressively now and recently enabled execution "pure" unit tests (fast tests that don't touch file system or database) on every build. And we have several branches in our source control, so these build can be triggered independently.
Too bad :-(
ReplyDeleteWe upgraded our build server to NCover 3.0. I know that this version is not officially supported by TypeMock, but it displays "NCover 2.0" in the list of supported coverage tools and actually works. Sort of. What happens is this link is not sticky and reset after every build. So the build runs fine, calls are mocked and coverage is generated. But after the build is finished, link to NCover is cleared and unless somebody manually restores it the next build will fail in all mocked calls.
Hope to get is stable in 5.3.
Hi Vagif
ReplyDeleteHow do you link with NCover? (Typemock MSBuild task? TMockRunner?)
Can you please post the relevant section of the build script?
Here is the section from our build script.
ReplyDelete<TypeMockStart Link="NCover2.0" ProfilerLaunchedFirst="true"/>
<Exec Command="$(NCoverTool) $(NCoverToolOptions) $(NUnitTool) %(ProjectsToCover.FullPath) /xml:$(CCNetArtifactDirectory)\test-results\%(ProjectsToCover.Filename).xml //x $(CCNetArtifactDirectory)\coverage-results\%(ProjectsToCover.Filename).xml //a %(ProjectsToCover.AssemblyName)" ContinueOnError="true">
<!-- Accumlate the error codes-->
<Output TaskParameter="exitcode" ItemName="exitcodes"/>
</Exec>
<TypeMockStop/>
Hi Vagif
ReplyDeleteUsing TypeMockStop unlinks you from the profiler so actually you should end the run unlincked from NCover.
Hm,
ReplyDeleteThen how should we configure build for parallel executions of several builds (in different source code branches)? We often run several builds at once (triggered by check-ins). Looks like we did not experience this problem earlier because only recently we started running selected unit tests on evey check-in.
So what's the purpose of TypeMockStop in such scripts? I checked examples, and they all have it. Documentation says that this command unregister TypeMock. Do we really need it?
Better late than wrong. Is there a link to what has been addressed in this version?
ReplyDeleteHi Vagif
ReplyDeleteTypeMockStop disables the Isolator and unlink it from whatever profiler is linked with it.
You should use it if you have tests that doesn't need the Isolator.
Now the difference is that enabling the Isolator is in the process level. while linking is in the machine level (the registry is involved).
Parallel builds sure make things complicated :(
Can you send a mail to our support and describe the build configuration (Are all running tests using the Isolator? Are all tests linked with NCover? etc)
We'll try to help you out with it.
Hi Ohad,
ReplyDeleteThank you for the clarification. I will try to describe our configuration. I don't think it's exceptional, it's just that like many other teams we use unit testing more agressively now and recently enabled execution "pure" unit tests (fast tests that don't touch file system or database) on every build. And we have several branches in our source control, so these build can be triggered independently.
I will soon provide more info.