Integration testing configuration question

So, I have been using NCrunch for a while now, and I liked it so much I had to buy it and I am now trying to get my company to get it for every developer.

My only issue is that I am not sure exactly the best way to configure NCrunch to do what I want.

NCrunch is working flawlessly for unit tests. So, we turned it on for our integration tests, which go against a database, require a logged on user, and use a security class that is linked between the logged in user and the database.

The problem is that NCrunch likes to run each test in parallel, and that is bad for our set of unit tests due to the static security class and the fact that we attach a new copy of our test database for run through of the integration tests. MSTest handles this just fine because we set up some deployment items and it deploys the assembly and runs all tests in the assembly.

I was able to get NCrunch to work by adding an ExclusivelyUses property to all my integration tests so they do not interfere with each other. But, now I have to attach a new database and set up our security context for each individual test It would be much nicer if I could get to NCrunch to run all those tests in the assembly using the same database and security context. Is that possible?

Bob

Hi Bob,

Is my understanding correct in that you wish to try and make sure NCrunch uses the same test runner process to execute all integration tests, avoiding spinning up or using different processes in order to avoid creating a different security context?

If so, I think I may be able to suggest a way that this is possible.. it's a little indirect, but should work.

NCrunch will tend to call in and out of test runner processes to execute the tests queued up inside the tasks you'll find in the processing queue. The pattern of re-use of these processes has a number of rules around it - one of which involves the project used to host them. If you have all of your integration tests situated within the same project/assembly and all of these tests have been marked with ExclusivelyUsesAttribute (which can now be specified at assembly level if you find this convenient), then NCrunch will use and re-use the same physical process to execute these tests.

There may still be some recycling of the process depending upon the resource needs of NCrunch and which tests it needs to run, but you can influence this by setting the 'Process pool size' to a high value, thus preserving the life of your integration test process.

That is exactly what I am trying to do.

All of my integration tests are in the same project/assembly, or at least I only want one security context spun up for each project/assembly. Currently, I have each unity test marked with the ExclusivelyUsesAttribute, but I will move that up to the assembly level to save typing and insure that no developer forgets to add it.

It sounds like, though, that since I have this configured like this already, NCrunch should already be behaving this way? I haven't checked in a while, let me analyse the situation.

Thanks for the response!

It should, in theory :)

In practice, the success of the arrangement may depend on how you initialise the database and the security context. If this is done via a load-on-demand static member of some kind, then I think it should be OK.

Setting the process pool size to something a bit higher is quite important, as NCrunch will need to keep this process alive long enough to continue to re-use it. Of course, it will still need to spin it up and reinitialise it every time you change any code involved.. but I guess that's the same as any other test run. If it performs badly or doesn't work right, just post back here and I'll see if we can work it out.