I have a standard ASP.NET MVC (version 2 preview 2) solution with the actual project and server-side unit tests in separate projects.
Because this project is very clie
I like your idea of placing the QUnit tests in a separate project. What about using XCOPY
to copy the scripts in the pre-build event?
Say your MVC project is MyProj.Web and your QUnit test project is MyProj.ClientTest (replace with your project names).
Create a Scripts folder in your ClientTest project.
From Project > MyProj.ClientTest Properties > Build Events, add the following to Pre-build event command line:
XCOPY "$(SolutionDir)MyProj.Web\Scripts" "$(ProjectDir)Scripts" /S /Y
Then in your HTML just include the appropriate JavaScript files from the Scripts folder.
Note: You will have to rebuild your ClientTest project to refresh JavaScript files when you want to rerun tests. Adjust folder names, paths and XCOPY
options as needed.
Perhaps you could pick and choose techniques from this article, including using the command-line, harnessing NUnit with WatiN, and scraping test results for reporting. This solution wouldn't require a separate WebForms project to harness the tests in, since it's all handled by WatiN.
It's not too clear to me why using MVC makes a difference - if you want to integrate your tests into a CI build then gWiz's suggestion is the route to go.
If your requirement is that you want to run your tests interactively directly on the real page without affecting the look of that page then you could check out the FireUnit plugin for Firebug. You can also wrap FireUnit around QUnit as described on John Resig's blog.
If you're concerned about including test stuff then include the relevant scripts in your test/debug builds and disable/remove them in your production builds.