How to Automate Unit Testing with TeamCity (Part 2)

Please notice that this is a multi-part, step-by-step guide, on how to automate builds in TeamCity CI Server. You can find part 1 of this series here.

Part 2: Creating the TeamCity Build (building the unit test project)

The next thing we need to do is to setup a TeamCity project for our new MVC application. In this case, we want to setup a new TeamCity project for this second MVC application sample (we created a previous MVC application in the previous article series).

You can follow the steps that I explained in my previous post. Alternatively, you can just add the unit test project to the existing MVC app we created before, and update TeamCity from here.

To create a new Build configuration, follow the steps:

1. Login into TeamCity admin page
2. Click on the Administration link on the top right link, next to the search box.
3. Your projects and associated build configurations will be displayed here.
   
   
   
4. Click on the “Create build configuration” link, below the project we created before (“MVCApplication”).
   
   
   
5. Enter the general details for the new Build as we did before.
   
   
   
6. Configure the version control settings. Notice that now you can attach the new build to the existing VCS root we created before. You can leave the other fields with their default settings.
7. Click on the “Add Build Step” button to add the build steps.
   
   
   
8. As we did before, we will use MSBuild as our build mechanism. This will enable TeamCity to build our project as if we were building it in Visual Studio.
   
   
   
9. Fill in the steps to build the solution as we did before. Notice that you need to enter the correct relative path to the MSBuild script. If you created a new MVC solution as I did, you can copy the same MSBuild script we created before to the new solution (create a new folder named Build, and add the existing script). The script is generic, so it will work for this project without issues.

Now that we have the Build step configured and the MSBuild script in place, let’s finish the rest of the steps of the build configuration in TeamCity.

1. Add the build trigger, so the build step is executed when changes are committed.
   
   
   
2. We don’t have dependencies to add, so jump to the build parameters. Again we need to add SolutionDir, SolutionFile, ProjectName, Configuration and BuildFilePath parameters.
3. Nothing to do for the last step, Agent Requirements so we are ready.

To test our work so far, we need to commit our local changes with the new (or updated) solution and verify that TeamCity is able to pick the changes and execute the Build successfully. You could just run the build manually from the TeamCity admin panel, but if you haven’t done your initial commit, there’s nothing for TeamCity to build.

To commit your changes in SVN:

1. Right click on the solution root folder and Add the files to source control.
   
   
   
   
   
2. Remove the bin and obj folders from source control by adding them to the ignore list (for both the web project and the Test project)
   
   
   
   
   
3. Commit the changes to the SVN server
4. Verify the build execution in TeamCity

Notice that since both projects are attached to the same VCS root, both build projects will run when changes are committed to the repo.

You can always add rules to the VCS triggering to avoid compiling unwanted projects when committing changes to the repo. Because of this, the build might take some more time, since it will need to perform a new checkout of the new changes, containing the new app.

You need to make sure the the MSTest binaries are available on the server. If you have Visual Studio and the .NET Framework (the versions you are targeting with your app) installed on the server, everything should work. If you have issues building the test project or want to know how to have MSTest working on the server without Visual Studio, check my post about the subject.

Next Article: Part 3: Configuring Automated Testing