Skip to content

Archive for


Create a WebDeploy Package on Team Foundation Service

I love continuous deployment to Windows Azure from Team Foundation Service!

Often though we need the flexibility of building and working directly with the WebDeploy package.

2013 02 11 a
Figure: To create the package, edit the build process template and add “/p:DeployOnBuild=true” to the MSBuild Arguments to have a deployment package created (as you would with on-premise TFS).

2013 02 11 b
Figure: The package is now available in the Drops folder under source control.

2013 02 11 c
Figure: Once you have the package it can be imported directly into IIS (providing Web Deploy 3.0 is installed).


Use a ‘Precision Mocker’ like Moq instead of a ‘Monster Mocker’ like Microsoft Fakes!

Using a precision mocking framework (such as Moq or NSubstitute) encourages developers to write maintainable, loosely coupled code.

Mocking frameworks allow you to replace a section of the code you are about to test, with an alternative piece of code.
For example, this allows you to test a method that performs a calculation and saves to the database, without actually requiring a database.

There are two types of mocking framework.

The Monster Mocker (e.g. Microsoft Fakes or TypeMock)

This type of mocking framework is very powerful and allows replacing code that wasn’t designed to be replaced.
This is great for testing legacy code (tightly coupled code with lots of static dependencies) and SharePoint.

Figure: Bad Example – Our class is tightly coupled to our authentication provider, and as we add each test we are adding *more* dependencies on this provider. This makes our codebase less and less maintainable. If we ever want to change our authentication provider “OAuthWebSecurity”, it will need to be changed in the controller, and every test that calls it.

The Precision Mocker (e.g. Moq)

This mocking framework takes advantage of well written, loosely coupled code.

The mocking framework creates substitute items to inject into the code under test.

Rule20130204-Image3Figure: Good Example – An interface describes the methods available on the provider

Figure: Good Example – The authentication provider is injected into the class under test (preferably via the constructor) Rule20130204-Image5

Figure: Good Example – The code is loosely coupled. The controller is dependent on an interface, which is injected into the controller via its constructor. The unit test can easily create a mock object and substitute it for the dependency. Examples of this type of framework are Moq and NSubstitute.