Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Tests fail due to NCrunch internal conditions
davydm
#1 Posted : Friday, March 8, 2013 5:56:52 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/8/2013(UTC)
Posts: 2
Location: South Africa

I'm seeing this error a lot:

SetUp : System.Configuration.ConfigurationErrorsException : The configuration file has been changed by another program.

followed by a path to a .config.ncrunchconfig file.

I'm getting the above error when ncrunch runs a lot of tests (eg when forcing re-run all or when ncrunch determines that the code I've changes potentially affects a lot of tests). Configuring ncrunch to not run my tests threaded reduces the error count but doesn't remove it completely. We have paid licenses for ncrunch based on our usage during the beta time period.

I'd REALLY appreciate this getting sorted out. My current project has around 3800 tests and the only resolution to this is to manually run the failing tests (sometimes I can run groups of 4-8 without issue, but still, if you have a hundred or so that are all failing for this reason, it's a bit of a PITA. This is a project I've inherited, and I have a feeling that there are some test assemblies that are referencing each other for shared functionality and perhaps the build process is modifying one of the assemblies after the tests for it have already kicked off? Just taking a stab in the dark here.
Remco
#2 Posted : Friday, March 8, 2013 10:51:53 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,989

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi, thanks for posting!

My guess would be that this problem is being caused by tests changing files at runtime (i.e. the .config file?). Something that may be worth trying is to run a build of your solution, then go to the bin\Debug directory of your test project(s), and mark ALL the output files (especially the configuration files) as read-only. Try running your tests using a standard test runner (not NCrunch), and see which of them fail. This may give an indication of which tests are causing the concurrency issue.

NCrunch creates the config.ncrunchconfig file as the primary config file for the test environment, so it's basically the app.config file.

A few other questions that may help narrow this down:

- Does the problem go away completely if you set the 'Max number of processing threads' to 1, then reset the NCrunch engine?
- From your statement above, I'm guessing you've tried this, but what if the 'Max number of processing threads' is set higher than one, but parallel execution for the solution is disabled?
- Have you identified any pattern to where this exception is being thrown? i.e. does it come with a stack trace?
- Are you using any custom/exotic build tools or steps outside the typical MS stack?
davydm
#3 Posted : Tuesday, March 12, 2013 1:51:35 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/8/2013(UTC)
Posts: 2
Location: South Africa

Hi

First of all, thanks for the response. I kind of forgot I posted this and came back here to post the problem again :/

To answer your questions:
1) I think so -- though I've only tried this once.
2) I get errors, but not as many
4) No
3) I have plenty of stack traces; they all quite similar, and now that I've read your answer, I think I know what was going on. We use Habanero to map our business objects and our tests spin up the required Habanero stuff at initialisation of each fixture. The default configuration storage for Habanero is, as far as I can tell, a file -- and the messages I'm getting back point at that file being the application config file. Creating a completely substituted settings manager using NSubstitute and making sure that's in use for every test fixture has resolved the issue.

I don't have any really good suggestions, but it would be nice if this error was a little easier to figure out: the error which comes back is that the .ncrunchconfig file has changed, not the app.config, so it seems as if NCrunch is getting lost; it's not immediately obvious that the problem is with tests themselves. It's especially difficult when working with a codebase you aren't familiar with. So perhaps can you add some messaging to that effect to the thrown exception? And also perhaps don't throw if the more recent file is actually unchanged (I know, this won't be trivial to solve) -- I'm actually quite sure that the file generated each time would have been the same.

Thanks again for replying (:
Remco
#4 Posted : Wednesday, March 13, 2013 6:05:08 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,989

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Nice work in figuring out what was happening. Running a parallel test runner on tests within an inherited codebase can often bring up obscure problems, and I'm glad you managed to find the root cause of the problem. It is particularly abnormal behaviour for a test to modify the config file of its own working environment, so I'm not sure if there's much I can add in the way of special behaviour to NCrunch to make this sort of issue easier to troubleshoot. Thanks for the suggestions and I hope your experience with the test runner is a good one from here on out.


Cheers,

Remco
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.047 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download