However, we started running into issues with JsUnit tests. The test failure information was not detailed enough to get an idea why the tests failed. Also, it was hard to create tests in JsUnit that validated asynchronous behavior, typical in our AJAX calls.
First we added functionality to the QUnit test runner that harvested the results of each test run and posted the results to the same ASP.NET server component we used for the JsUnit test runner.
Take a look at this code in our source folder: Source\RI\MusicStore.Web.Tests\Scripts\TestRunner\testRunner.js
Second, we added additional MSTest style assertions.
Check out the code here: Source\RI\MusicStore.Web.Tests\Scripts\TestRunner\qunitExtensions.js
Running the tests in MSBuild
Once we had the test runner configured with our unit tests, we then automated running the tests in a browser. We accomplished this using an MSBuild task similar to the following:
<Exec Command=""%(QUnit_BrowserPaths.Identity)" "file:///$(QUnit_TestRunnerFilePath)?&submitResults"" ContinueOnError="true"/>
<QUnit_TestRunnerFilePath> $(SourceWorkingDir)RI\MusicStore.Web.Tests\Scripts\TestRunner\testRunner.html </QUnit_TestRunnerFilePath>
Notice the ContinueOnError=”true”. This is necessary because the test runner automatically closes the browser instance after a test suite run. Internet Explorer raises an error when we force it to close, whether or not the tests ran successfully.
The server component receives the test run results that was posted by the testRunner.html. This data is translated into XUnit style XML and saved to disk. If there is a failing test, the server component will also save a file to disk named FailingJSTest.xml. When our CI build is run, it will look for this file and raise an error if it is found.