|
Loading topic...
|
|
WebAii and Design Canvas and CruiseControl.NET
1 What is CruiseControl.NET
CruiseControl.NET is an automated integration server. The Server automates the integration process by monitoring the team's source control repository directly. Every time a developer commits a new set of modifications, the server will automatically launch an integration build to validate the changes. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not.
For more information about what CruiseControl.NET is and isn't and how to obtain it refer to their website at http://confluence.public.thoughtworks.org/display/CCNET.
It's pretty easy getting your test code to build using CruiseControl.NET but there are a couple of tricks to getting it to run your WebAii tests as unit tests. Don't fear however, the way to get your tests to run and viewable in the Web Dashboard Application is all done by adding or changing a few things in two configuration files.
2 Install TFS Plug-in
If you're using TFS as your source code repository, you'll need to install the TFS plug-in for CruiseControl.NET. This can be found at http://www.codeplex.com/TFSCCNetPlugin/. Just follow the instructions given there.
3 Create Required Directories
You'll need to create a couple of directories before doing your first build. It appears that CruiseControl.NET does not automatically create them yet they are required for the build to succeed.
- Create a unique directory for your project builds to run in. Don't try to mix different builds in the same folder. There's a potential that different builds can interfere with each other (especially if filenames are the same between the two projects). Make the directory name unique enough to identify it from all other project builds such as 'C:\Project builds\Sydney v1.1'. Later you'll enter this folder path into the ccnet.config file.
- Create a build logs folder to hold your build results. This needs to be created under the CruiseControl.NET's server folder for wherever you installed CruiseControl.NET. For example: 'C:\Program Files\CruiseControl.NET\server\Sydney\Artifacts\buildlogs'. Just replace 'Sydney' with the name for your project.
4 Modifying the Server's ccnet.config File
This paper was written referencing CruiseControl.NET version 1.4.3. Hopefully whatever version you're running is compatible with what I'm about to describe. Also to understand the changes I'm about to describe you need to have a basic understanding of where the ccnet.config file is and what belongs in it.
This configuration file controls the builds for all of the projects CruiseControl.NET projects. First we need to get the server building our test code.
4.1 Adding a Build Task to Your Project
I'll assume you're using some version of VisualStudio. With CruiseControl.NET you've got two different build configurations you can use. It doesn't really matter as far as building and running WebAii tests. Choose whichever method you feel most comfortable with (but don't add both to ccnet.config because CruiseControl.NET will blindly execute both build tasks).
4.1.1 Building Using the DevEnv Task in Your ccnet.config File
To build using the DevEnv task, you simply add the task configuration to your project file. The following example assumes you're using Visual Studio 2008. Refer to the CruiseControl.NET documentation for other settings to make it work with other versions of Visual Studio. It should look something like this:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<project name="WebAii Unit Tests For Project Sydney">
<sourcecontrol type="enter your type here">
... Configure CruiseControl.NET per their documentation to use whatever source control system you have.
</sourcecontrol>
<tasks>
<devenv>
<solutionfile>
"c:\projects\SydneyTests\SydneyTests.sln"
</solutionfile>
<configuration>Debug</configuration>
<version>VS2008</version>
<buildTimeoutSeconds>90</buildTimeoutSeconds>
<description>Building Sydney WebAii unit tests</description>
</devenv>
... We'll talk about another necessary task later.
</tasks>
<publishers>
... We'll talk about the necessary publishers configuration later
</publishers>
</project>
</cruisecontrol>
4.1.2 Building Using the MSBuild Task
This method is pretty much the same but instead of a DevEnv task we replace it with a MSBuild task. It should look something like this:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<project name="WebAii Unit Tests For Project Sydney">
<sourcecontrol type="enter your type here">
... Configure CruiseControl.NET per their documentation to use whatever source control system you have.
</sourcecontrol>
<tasks>
<msbuild>
<executable>
C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe
</executable>
<workingDirectory>
c:\projects\SydneyTests
</workingDirectory>
<projectFile>SydneyTests.csproj</projectFile>
<buildArgs>
/noconsolelogger /p:Configuration=Debug /v:diag
</buildArgs>
<timeout>900</timeout>
<logger>
C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll
</logger>
</msbuild>
... We'll talk about another necessary task later.
</tasks>
<publishers>
... We'll talk about the necessary publisher configuration later
</publishers>
</project>
</cruisecontrol>
4.2 Adding a Run Tests Task
The program that runs VisualStudio unit tests is Microsoft's MSTest utility. This utility comes with VisualStudio. It is a command line utility. It has many command line options for specifying what project to run, what tests in that project to run, and where to log the results to. For more information about MSTest including command line options go to http://msdn.microsoft.com/en-us/library/ms182486(VS.80).aspx.
If you're using NUnit or something similar you can skip this section but be sure to add an appropriate NUnit (or whatever testing framework you use) test task to your project.
An MSTest task is an "Exec" task to CruiseControl.NET. It should look something like this:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<project name="QuickStarts_VSTS_CS_1.1">
<sourcecontrol type="...">
...
</sourcecontrol>
<tasks>
<msbuild>
...
</msbuild>
<exec>
<!-- Call mstest to run the tests contained in the TestProject -->
<executable>C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\mstest.exe</executable>
<baseDirectory>c:\projects\SydneyTests</baseDirectory>
<!-- testcontainer: points to the DLL that contains the tests -->
<!-- runconfig: points to solutions testrunconfig that is created by vs.net, list what test to run -->
<!-- resultsfile: normally the test run log is written to the uniquely named testresults directory -->
<!-- this option causes a fixed name copy of the file to be written as well-->
<buildArgs>/testcontainer:bin\debug\SydneyTests.dll /test:LogInTest /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>30</buildTimeoutSeconds>
</exec>
</tasks>
<publishers>
...
</publishers>
</project>
</cruisecontrol>
4.3 Publishing Test Results
You need to merge the generated .trx file from MSTest into the build results. Add something like this to the 'publishers' section of your project configuration:
<publishers>
<!--to get the test results in the dashboard we have to merge the results XML file -->
<merge>
<files>
<file>c:\projects\QuickStarts_VSTS_CS_1_1\testResults.trx</file>
</files>
</merge>
<xmllogger />
</publishers>
4.4 Deleting Previous Test Results
One caveat to using MSTest is that you must delete the .trx file it creates before doing another test run. Otherwise MSTest will fail indicating it was unable to create the output file.
This is done via another "Exec" task in ccnet.config. Place this section just in before your Exec task that runs MSTest. It probably would be best to place it at the beginning of the build because if a build fails (which causes CruiseControl.NET to skip any remaining tasks) to compile, CruiseControl.NET will still pick up and merge any left over .trx file into the build log:
<exec>
<!--Delete the testResults.trx first. This is required as MsTest will not create the file if
it exists this could be merged with the mstest action in a single batch file-->
<executable>$(windir)\system32\cmd</executable>
<baseDirectory>c:\projects\QuickStarts_VSTS_CS_1_1</baseDirectory>
<buildArgs>/c if exist testResults.trx del testResults.trx /f</buildArgs>
<buildTimeoutSeconds>30</buildTimeoutSeconds>
</exec>
4.5 Running the Server
Now you're ready to run your CruiseControl.NET server and let it start building and running tests. CruiseControl.NET can be run in two modes:
- Command line mode
- Windows service mode
There is a problem with using Windows service mode. WebAii tests require the browser be able to run and interact with the desktop. When running builds and tests under a Windows service, desktop interaction is disabled. As a result virtually no WebAii test can successfully run in this environment.
It is best to log onto your server using an account that has access to your source control and VisualStudio permissions and start the CruiseControl.NET server in command line mode. Leave this user logged on all the time. If you logoff this user the CruiseControl.NET server will shut down and you won't get any builds.
Most WebAii unit tests work just fine if you leave the computer locked (displaying the logon screen) so long as CruiseControl.NET is running under a user account with desktop interaction privileges (which all regular users have). The only tests that may have a problem with this are those that interact directly with the desktop (Mouse.Click, Window.GetBitmap, etc.). Tests that exclusively interact directly with the Browsers DOM will run just fine this way. Unfortunately there's no way around this. This is simply the way that Windows works.
In order for WebAii tests that interact directly with the desktop to work you'll need to leave your CruiseControl.NET machine logged on and displaying the desktop all the time. This means you'll have to disable the screensaver and never lock the computer. Yes this does present a security risk to your company. If you can lock this computer up into a secure room (such as a datacenter) you can minimize this security risk.
5 Making the Web Dashboard Work With IIS 7
CruiseControl.NET comes configured to work with IIS 6. Things changed a bit with IIS 7 (i.e. Windows Vista and Windows Server 2008). Fortunately the dashboard still works out of the box once you make one small change to the applications configuration within IIS.
- First you'll need to manually create a virtual directory for Web Dashboard. The .EXE installer for CruiseControl.NET. You can give the virtual directory any name you like' ccnet is common. Point it to the physical path for where the Web Dashboard application is installed. The default installation puts it at C:\Program Files\CruiseControl.NET\webdashboard.
- In the advanced settings (right click on the website, go to Manage Web Site, click on Advanced Settings') change the Application Pool to Classic .NET AppPool as shown here:
Without this trying to run the WebDashboard will display an error.
- Alternatively, if you really want it to run with the new 'Integrated Managed Pipeline Mode' feature modify Web Dashboards web.config file by following the instructions here: http://mahfuzulislam.blogspot.com/2008/06/cruise-control.html.
6 Modifying the Web Dashboard's dashboard.config File
As configured out of the box, CruiseControl.NET's Web Dashboard is preconfigured to work with VisualStudio 2005 and NUnit. If you're using VS 2005 and/or NUnit, there's nothing you need to do.
Unfortunately Web Dashboard will not display the test results from MSTest that's part of VisualStudio 2008. This is because the .trx format changed slightly with the new version. The good news is that CruiseControl.NET comes with the necessary XSL translation files for VS 2008. All we need to do is configure the Web Dashboard to use these alternate XSL files.
6.1 Modifying the xslFileNames Section
This section is a list of .xsl files that will be used after every build to generate the build's Build Report that's displayed in Web Dashboard. CruiseControl.NET runs them in sequence as listed in this section. What we need to do is replace the MsTestSummary.xsl with MsTestSummary2008 so that it looks something like this:
<dashboard>
<remoteServices>
...
</remoteServices>
<plugins>
...
<buildPlugins>
<buildReportBuildPlugin>
<xslFileNames>
<xslFile>xsl\header.xsl</xslFile>
<xslFile>xsl\modifications.xsl</xslFile>
<xslFile>xsl\compile.xsl</xslFile>
<xslFile>xsl\compile-msbuild.xsl</xslFile>
<!-- <xslFile>xsl\unittests.xsl</xslFile> This is only for NUnit -->
<xslFile>xsl\MsTestSummary2008.xsl</xslFile>
<xslFile>xsl\fxcop-summary.xsl</xslFile>
<xslFile>xsl\NCoverSummary.xsl</xslFile>
<xslFile>xsl\SimianSummary.xsl</xslFile>
<xslFile>xsl\fitnesse.xsl</xslFile>
</xslFileNames>
</buildReportBuildPlugin>
...
</buildPlugins>
</plugins>
</dashboard>
6.2 Modifying the xslReportBuildPlugin Section
This section is used to generate a menu of the different detail reports you can display. After you make these changes you'll get something that looks like this:
Note the last entry in the list. To obtain this entry we need to modify this section in the dashboard.config file to look something like this:
<?xml version="1.0" encoding="utf-8" ?>
<dashboard>
...
<plugins>
...
<buildPlugins>
...
<buildLogBuildPlugin />
<xslReportBuildPlugin description="NUnit Details" actionName="NUnitDetailsBuildReport"xslFileName="xsl\tests.xsl" />
<xslReportBuildPlugin description="NUnit Timings" actionName="NUnitTimingsBuildReport"xslFileName="xsl\timing.xsl" />
<xslReportBuildPlugin description="NAnt Output" actionName="NAntOutputBuildReport"xslFileName="xsl\NAnt.xsl" />
<xslReportBuildPlugin description="NAnt Timings" actionName="NAntTimingsBuildReport"xslFileName="xsl\NAntTiming.xsl" />
<xslReportBuildPlugin description="FxCop Report" actionName="FxCopBuildReport"xslFileName="xsl\FxCopReport.xsl" />
<xslReportBuildPlugin description="NCover Report" actionName="NCoverBuildReport"xslFileName="xsl\NCover.xsl" />
<xslReportBuildPlugin description="Simian Report" actionName="SimianBuildReport"xslFileName="xsl\SimianReport.xsl"/>
<xslReportBuildPlugin description="Fitnesse Report" actionName="FitnesseBuildReport"xslFileName="xsl\FitnesseReport.xsl"/>
<xslReportBuildPlugin description="MSBuild Report" actionName="MSBuildBuildReport"xslFileName="xsl\msbuild.xsl"/>
<xslReportBuildPlugin description="MSTest 2008 Detail Report" actionName="MSTEST2008DetailReport"xslFileName="xsl\MsTestReport2008.xsl"/>
</buildPlugins>
</plugins>
</dashboard>
After making the above two changes, the next build will successfully display test results from VS 2008.
|