views:

2931

answers:

7

I'm currently trying to run MSTest.exe from NCover, but I believe the question could apply generally to running MSTest.exe from the command line.

If I have the "/noisolation" argument, then MSTest.exe appears to find and use the app.config as expected. Without it, NCover doesn't capture any coverage information. From my research so far, it seems NCover needs /noisolation. So the question is how to get my *.config files to work when that argument is passed.

My NCover settings are:

Application to Profile
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe

Working Folder
C:\Documents and Settings\MyProfile\My Documents\Visual Studio 2008\Projects\XYZ\XYZ.CoreTest\bin\Debug

Application arguments
/noisolation /testcontainer:"C:\Documents and Settings\MyProfile\My Documents\Visual Studio 2008\Projects\XYZ\XYZ.CoreTest\bin\Debug\XYZ.CoreTest.dll"



Update: I added a trace showing that my config is (not surprisingly) trying to read from "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe.Config".

Update 2: If at all possible, I don't want to edit MSTest.exe.Config. That just isn't terribly portable.

A: 

In visual studio, mark the App.config file to property to CopyAlways. (right click on file, choose properties to get to the property panel)

Greg Ogle
Having done so, the (renamed) app.config is in my output folder right next to the assembly... which is what it has been doing. My app is still trying to read the MSTest.exe.config rather than MyAssembly.dll.config. If I omit the /noisolation switch, it reads teh correct file.
Larsenal
A: 

I've never before used NoIsolation, but if I am understanding it correctly, it literally runs all of your test code in the MSTest class. That being so, it does and should read the App config for MSTest. If you insist on using noisolation, I'm thinking you would have to merge your App.config into MSTest.exe.config. Of course, that is a hack.

It would probably be better to avoid the noisolation altogether. If it is due to an error, fix the error if possible. Work around the error if reorganizing (major refactoring) your app is not possible. I'm not sure there is an elegant alternative.

I found "I think we need to find the root cause of this issue in order to avoid the noisolation switch. You might need to modify your applicaton. Is it possible to create a simple solution that repro the same issue?" at this URL.

Greg Ogle
If this is the case, then perhaps my real question has to do with how to get NCover to correctly work with MSTest.exe without /noisolation.
Larsenal
Just some ideas; sorry that they sound critical. Not intentional.If you are using team system, maybe you could use code coverage from taht?http://blogs.vertigosoftware.com/teamsystem/archive/2006/02/06/nUnit_and_Team_System_Code_Coverage.aspx
Greg Ogle
+1  A: 

There's a technique where you can combine the contents of config files it's detailed here. You could add a fixed file inlcude line to MSTest.exe.Config, and then copy your app's app.config to that fixed file location. It's ugly, but more portable than hacking MSTest.exe.Config for every different eventuality.

MrTelly
+1  A: 

At http://docs.ncover.com/ref/2-0/whats-new-in-ncover-2-0/release-notes-for-ncover-2-1-0/ under NCover Fixes:

Running coverage on MSTest no longer requires the "/noisolation" flag. NCover correctly gathers coverage

If this is indeed fixed, then upgrade NCover to 2.1.0. Perhaps that will work.

Greg Ogle
I'll have to look into this.
Larsenal
@Greg Ogle: Looks like the link is changed to http://docs.ncover.com/ref/2-0/whats-new-in-ncover-2-0/release-notes-for-ncover-2-1-0/
Regent
+3  A: 

Ok, I'm running the risk that my post will devolve into a unit testing flamewar, but I think the problem is your tests and possibly even your code. You should refactor.

Unit tests should be atomic. A single test should have no external dependencies and a config file is such a dependency. No test should rely on the config file.

If you are testing a method that uses information from a config file, refactor your code so that the configured information is read outside of the method and either passed to the method or set as a property before the method is called. That way your test can either pass the value to the method, or set the property during test setup.

If you need your app.config for a database connection string, you're on your own. DALs are notoriously difficult to unit test. If it's for a web service connection string, don't use it -- mock the interface.

Randolpho
What I'm doing is probably better characterized as integration testing, not unit testing. In this particular case, I'm having to retroactively add some tests to an existing code base.
Larsenal
Oh, I hate doing that! Ah, well, I stand by my statement... if you have the opportunity to refactor your code to make it more testable, do it. If your hands are tied, your hands are tied. Also, if you can, look into mocking your integrations, it'll do wonders for you later on.
Randolpho
A: 

To clear up the confusion: not using /noisolation = if it finds a SameNameAsYourDll.dll.config file, it'll be deployed with the test dll automatically, and will be used for the app config for the app domain that runs the tests in that assembly

using /noisolation = All the isolation we do between tests, you, the host process, and everything else is out the window. We may still do some isolation, but you don't get the added benefit of the app domain being unique to your test dll. Thus, you dll's config won't help.

dhopton
+1  A: 

From Craig Stuntz in a comment at link text

How to do this with MSTest.

  1. In Solution Explorer, right-click the Solution (not the Project).

  2. Click Add, New Item

  3. In Categories, select Test Run Configuration

  4. Now choose the Test Run Configuration item and add it to your project

  5. In Solution Explorer, double-click the Test Run Configuration you just created

  6. Click the Deployment item

  7. Add your config file as a deployed file (or deploy the entire folder which contains it, if appropriate)

This took me a little while to figure out, but I'm in a similar situation and it does work for me.

Lucas B
This also only works for Visual Studio 2008 :(
daub815