tags:

views:

48

answers:

3

I have a C#/ASP.NET website that has some code (*.cs) files in the App_Code directory. I would like to test them using NUnit. I have written a test file with the proper [TestFixture] and [Test] annotations and have put it here: App_Code/Test/TestClassName.cs.

I load up the NUnit GUI to run it but it wants me to select a .exe or .dll file. There is none in the bin folder of my project. My project does successfully run and is built and everything, but still no exe or dll file. How can I get the NUnit Gui to just run the test in that class?

+3  A: 

I don't recommend putting test code in the same package you'll be deploying to production.

You may want to move the test classes to a library project, something like Business.UnitTest(there may be a built in way to create an nUnit specific project, if there is, use that). Then move the business classes that are in your App_Code directory into another project called Business. Have Business.UnitTest reference the Business library. That should get nUnit to run(I don't believe that nUnit runs against websites, only libraries, but I'm not 100% sure).

For your website add a reference to the business library you just created so your production code can access the business objects in the business library. You may have to work out some namespace issues, but that shouldn't be too bad.

Chris L
This sounded like a great solution but when I moved the code from App_Code to the class library, it could no longer access the HttpContext.Current. I have lots of error logging that automatically pulls relevant info from this object. Without that, I need to add several extra input params to each method with this info pulled out OR I need to put try/catch outside the class library and let the exception bubble up to there. Both of those options seem like unecessary duplication and general ugliness. Is there a workaround or do people just not use or log web state frequently?
Amber Shah
I don't know how often people log web state, try taking the info from the HttpContext.Current and passing it as variables as you mentioned(you could make them properties in objects in the library). If you really don't like passing the extra variables, try passing the HttpContext.Current itself as a parameter(although I'm not too fond of this approach, bad coupling), just add a using System.Web to the top of the page(make sure there's a reference to the assembly in the library).
Chris L
+2  A: 

The trick with .NET Website projects is that the code files are not normally compiled up front, they are compiled on execution of the respective pages. This presents a challenge where testing is concerned, since as you mentioned NUnit wants to run a .exe or .dll for testing.

One way to deal with the issue is to convert the website project to a web application; they sound similar, but work in different ways. In contrast to a website not requiring up-front compilation, a web application requires it. So you would have one or more projects that compile to assemblies (.dll) or executables (.exe). NUnit could then hook into those to run the tests.

To make this work, you would want to separate testable code into another project; your front-end web application can refer to this other project to make use of the code within. Ideally, the front-end would be a thin layer of logic and user interaction, and the real work can be sent to the second project. Therefore, the second project is what you will want to test.

You'll want to have one more project to contain the tests - general wisdom is to not have your tests in the same project as the code being tested. This project refers to the project being tested, and to NUnit, and contains the tests themselves. This assembly is what you would direct NUnit to run for testing.

Grant Palin
A: 
  1. First, you want to create a new project for your tests. If you happen to have any internal classes or attributes, you should use InternalsVisibleToAttribute in order to be able to test these from within your testing project, outside your "real" project. This attribute is suitable for the entire assembly, so I recommend putting it into your Assembly.info file of your "real" assembly.

  2. From within your tests project, add a reference to your "real" assembly.

  3. Make sure to exactly know the path to your binary (assembly.dll);

  4. Open your TestsProjectAssembly.dll from within your NUnit GUI, makeing sure you are browsing to the right folder;

  5. You might also want NUnit GUI to reload your assembly on each tests run (there is an option for doing so in the options properties);

  6. Run your tests.

Absolutely make sure your path or browsable folder is the one in which your testing project is generated.

Will Marcouiller