Welcome to Part 6 of this review of the Pluralsight course Automated ASP.NET MVC Testing: End to End by Jason Roberts.

With over 15 years industry experience, Jason is a Microsoft .NET MVP who has has written multiple books including Clean C#, and C# Tips. He is also an open source contributor and the creator of FeatureToggle.

Also in this series:

Part 1 – Automated ASP.NET MVC Testing

Part 2 – Testing the Model

Part 3 – Testing Controllers

Part 4 – Testing View Rendering

Part 5 – Automated Functional UI Testing

Part 6 – Running Tests on TeamCity Continuous Integration Server

Part 7 – Further Learning

Running Tests on TeamCity Continuous Integration Server

Overview of Continuous Integration

Jason describes Continuous Integration and why it is an important professional development practice.

A CI Server notices when any new changes are checked in, compiles the code and runs the test suite. It can also keep track of code metrics.

The important point that Jason emphasizes is it helps us find bugs sooner.

Introducing TeamCity

We typically have TeamCity running on a separate server than the Source Control server. These two servers are connected.

It’s recommended to setup a SQL Server Database for better reliability and performance.

The TeamCity server sends the source code to one or more TeamCity Build Agents, which build and run our tests. The build agents may be on the same machine as the server, or a different machine on the network.

Each Build Configuration contains a number of build steps:

• Building a solution
• Running NUnit tests
• Running MSTests
• Execute commands at the command line

For further details on TeamCity see jetbrains.com/teamcity

Build Pipelines

A Build Pipeline in a set of phases that happen when we do a code check-in.

Jason shows a line graph of elapsed time versus confidence that we haven’t broken anything. This visualizes the fact that UI tests take the longest to run, followed by Integration tests.

Using a Local Source Control Server

Here Jason uses Mercurial Server.

You can download Mercurial Server for your operating system. Most ASP.NET MVC developers will be on Windows, and Jason recommends the TortoiseHg with Windows Explorer shell package.

Jason shows that it is easy to run Mercurial up on localhost.

Creating Phase 1

In this demo we:

• Run TeamCity on localhost and create a new TeamCity project
• Create Phase 1 build configuration

We see that TeamCity supports a wide range of build steps such as Maven, MSBuild, MSpec, MSTest, NuGet installer, NUnit, Powershell etc.

We choose Visual Studio (sln), see our Build Agent successfully running it, and see the details in the build log.

Next we click the Triggers link and add a new trigger.

We also see how to commit the changes in Mercurial using the command line.

Adding Unit Tests to Phase 1

We modify the Phase 1 configuration, adding an NUnit build step.

In the New Build Step menu, we can specify our assembly DLL in the Run tests from section.

After we click Save, we have two steps; Visual Studio and NUnit. This completes the Phase 1 setup.

Creating Phase 2

In this demo we:

• Create a Phase 2 build configuration
• Run our integration tests
• Add a build trigger

Creating Phase 3

In this demo we:

• Create a Phase 3 build configuration
• Add an NUnit build step to run FunctionalUTTests.dll
• Select Phase 2 as a Snapshot dependency
• Add a finish build trigger with Phase 2 build configuration, and “Trigger after successful build only” checked
• Commit changes to source control
• Run our functional UI tests

We discard the auto-created build steps because we want to create our own.

This concludes our review of this TeamCity introductory module. We will look at the final module of this course soon.