Continuous Delivery with psake and TeamCity - Reusing the Local Build to Create a CI Build

In my previous two posts I have shown how you can compile your solution and run your tests with psake, effectively creating a simple local build. Building upon my last two posts, this time we will reuse our local build script to create a CI build with TeamCity 6.5. Assuming that you have already installed TeamCity, create a new build configuration called CI and setup your VCS. I’ve set it up with Git:



Add a Powershell build step:



Choose “Source code” and paste in this:

& .\tools\psake\psake .\build\build.ps1

It is also important to add

-NoProfile -ExecutionPolicy unrestricted

as “Additional command line parameters” because execution of PowerShell scripts are disabled by default. Now make sure that you have set up “Build Triggering” in TeamCity to “VCS Trigger”:



If we now run our build we should get a green “Success”.



Since we have executed the tests as a part of the build script and not through TeamCity we are missing a test report. We can easily report the test results to TeamCity by using a Service Message. Add the following to
the exec function of the test task:

Write-Output "##teamcity[importData type='nunit' path=`'$test_dir\tests_results.xml`']"

If the path to the test report is very long PowerShell will automatically wrap the service message and the message will not be picked up. To alleviate this problem we can increase the PowerShell UI buffer size. Replace the “"Script source” in the Powershell build step in TeamCity with this:

&  {$host.UI.RawUI.BufferSize = new-object System.Management.Automation.Host.Size(512,50); .\tools\psake\psake .\build\build.ps1}

Check in and watch the test being reported to TeamCity!



At this point you should consider creating a ci task that depends on compile and test. You probably want to add other tasks which ci is dependent on, for instance swapping out the config file for your test project, migrating a database, deploying, etc., etc. Just add the ci task as an argument to build.ps1 in TeamCity:

&  {$host.UI.RawUI.BufferSize = new-object System.Management.Automation.Host.Size(512,50); .\tools\psake\psake .\build\build.ps1 ci}

That’s all for now!

Download the code from GitHub.

Creating a Local Build with psake, Part 2: Testing

In my last post Creating a Local Build with psake, Part 1: Compiling I showed how you could compile a solution with psake. This time we will expand our build script and include a task that will run all the tests in our solution using NUnit 2.5.10.

The output from building is often referred to as build artifacts. I like to configure the output of the projects in my solution so that they output to a folder called “build_artifacts”. In my example solution I have two projects. An WPF application and a test class library:

I have configured them so that the output from building with Debug is output to the “build_artifacts”-directory:

‘

Now that the compilation outputs to our build artifacts folder we can make a psake task that finds all the test assemblies in “build_artifacts\Debug\Tests” and runs them with NUnit:

properties {
    $base_dir = resolve-path .\..
    $source_dir = "$base_dir\src"
    $build_artifacts_dir = "$base_dir\build_artifacts"
    $tools_dir = "$base_dir\tools"
    $config = "Debug"
    $test_dir = "$build_artifacts_dir\$config\Tests"
}

task test {    
    $testassemblies = get-childitem $test_dir -recurse -include *tests*.dll
    exec { 
        & $tools_dir\NUnit-2.5.10\nunit-console-x86.exe $testassemblies /nologo /nodots /xml=$test_dir\tests_results.xml; 
    }
}

Here I have defined some extra properties to make the script more readable and maintainable. We now have to remember to make the “local” task dependent on “test”. Let’s also add a “clean” task that deletes the build artifacts folder and recreates it:

task clean {
    rd $build_artifacts_dir -recurse -force  -ErrorAction SilentlyContinue | out-null
    mkdir $build_artifacts_dir  -ErrorAction SilentlyContinue  | out-null
}

Our build script now loos like this:

$framework = '4.0'

properties {
    $base_dir = resolve-path .\..
    $source_dir = "$base_dir\src"
    $build_artifacts_dir = "$base_dir\build_artifacts"
    $tools_dir = "$base_dir\tools"
    $config = "Debug"
    $test_dir = "$build_artifacts_dir\$config\Tests"
}

task default -depends local
 
task local -depends compile, test

task compile -depends clean {
    exec { msbuild  $source_dir\ContinuousDelivery.sln /t:Clean /t:Build /p:Configuration=$config /v:q /nologo }
}

task clean {
    rd $build_artifacts_dir -recurse -force  -ErrorAction SilentlyContinue | out-null
    mkdir $build_artifacts_dir  -ErrorAction SilentlyContinue  | out-null
}

task test {    
    $testassemblies = get-childitem $test_dir -recurse -include *tests*.dll
    exec { 
        & $tools_dir\NUnit-2.5.10\nunit-console-x86.exe $testassemblies /nologo /nodots /xml=$test_dir\tests_results.xml; 
    }
}

If we run build.bat we now get the following output:

We have now successfully run our tests with psake! This concludes how you can create a local build with psake. There might more to this than what I’ve shown, but I think this should be enough to get you going.

You can download the source code from GitHub.

Creating a Local Build With psake, Part 1: Compiling

Often there is more to building a solution than just compiling with Visual Studio. If you’re strict about your Continuous Integration process you’d probably want to make sure that the solution compiles, migration of the database doesn’t fail (if you have one), all the tests are green etc before you check in. For this reason I like to create a local build, something very similar to the build running on a CI server. My preferred choice for build automation is psake, a tool written in PowerShell. “It avoids the angle-bracket tax associated with executable XML by leveraging the PowerShell syntax in your build scripts.” Since PowerShell is a programming language in itself you can pretty much do everything you would possibly like, including integration with the .NET Framework.

Now, let’s compile our solution with psake.

Assuming that I have the following folder structure.

Download psake from https://github.com/psake/psake/zipball/master and put the content (just the files) in \tools\psake\ . There is a bug in the current version of psake where it’s not possible to set framework version through $framework global variable in the build script. You therefore have to edit \tools\psake\psake.ps1 and set line 13 to:

[string]$framework = '4.0'

if you have a .NET 4.0 solution.

Create a file called build.ps1 in the build folder and include this in the file:

$framework = '4.0'

properties {
    $base_dir = resolve-path .\..
    $source_dir = "$base_dir\src"
    $config = "Debug"
}

task default -depends local
 
task local -depends compile

task compile {
    exec { msbuild  $source_dir\ContinuousDelivery.sln /t:Clean /t:Build /p:Configuration=$config /v:q /nologo }
}

With psake you can set up tasks with dependencies between them. If you run this with psake without specifying a task it will run the “default” task. As you can see I have created a task “local” in which “default” is dependent on. “local” is then dependent on the task “compile” where we call out to msbuild to actually do the compilation. The call is wrapped in an exec-function defined by psake. If the command line program we call out to fails, psake will automatically throw an exception and fail the build.

To make it easier to run the build script I like to wrap the invocation in a simple bat-file called build.bat at the root of the project:

@echo off
powershell.exe -NoProfile -ExecutionPolicy unrestricted -Command "& { .\tools\psake\psake .\build\build.ps1 %*; if ($lastexitcode -ne 0) {write-host "ERROR: $lastexitcode" -fore RED; exit $lastexitcode} }" 
pause

Now, open a command line and navigate to your project directory and run build.bat:

Congratulations! You’ve compiled your solution with psake.

You can download the source code from GitHub.

A simple BDD “framework”

Last month I held a WPF presentation at work where I created a ViewModel class doing TDD. This got a little buzz because of the way I integrated BDD concepts in the tests. I have since then recieved a few question about how I actually did it. Let’s first have a look at what I did:

namespace Specifications_for_customer_search
{
    [Scenario]
    public class When_user_searches_for_customers : ScenarioBase
    {
        private RhinoAutoMocker<CustomerSearchViewModel> _mocks;
        private List<Customer> _customers;
        private string _customerName;

        public override void Given()
        {
            _mocks = new RhinoAutoMocker<CustomerSearchViewModel>();
            _customerName = "goran";
            _customers = new List<Customer> { new Customer(_customerName) };
            _mocks.Get<ICustomerRepository>().Stub(me => me.FindCustomerByName(Arg<string>.Is.Anything)).Return(_customers);
            
        }

        public override void When()
        {
            _mocks.ClassUnderTest.SearchCommand.Execute(_customerName);
        }

        [Then]
        public void should_query_customer_repository_for_matching_customers()
        {
            _mocks.Get<ICustomerRepository>().AssertWasCalled(me => me.FindCustomerByName(_customerName));
        }

        [Then]
        public void should_list_customers_found()
        {
            Assert.That(_mocks.ClassUnderTest.Customers, Is.EqualTo(_customers));
        }
    }
}

This was all done by using the base class from my previous post and renaming Arrange and Assert to Given and When. In this example I used NUnit, so I inherited from NUnit’s test attributes:

public class ThenAttribute : TestAttribute{}
public class ScenarioAttribute : TestFixtureAttribute { }

That was all. Happy testing! :)

An AAA style BDD specification base class

Lately I have written a lot of Arrange, Act, Assert style tests using Rhino Mocks. I’ve also started to write more readable tests with a dash of BDD style naming like this:

[Fact]
public void Should_find_projects_when_user_searches()
{
 //Arrange
 var projectRepository = MockRepository.GenerateMock<IProjectRepository>();
 var projects = new List<Project> { ProjectMother.CreateProject("project 1"), ProjectMother.CreateProject("project 2") };
 projectRepository.Stub(me => me.FindByName(null)).IgnoreArguments().Return(projects);
 var presentationModel = new ProjectSearchPresentationModel(projectRepository);
 //Act
 presentationModel.SearchCommand.Execute("");
 //Assert
 projectRepository.AssertWasCalled(me => me.FindByName(""));
 Assert.Equal(projects.Count, presentationModel.Projects.Count);
}

The scenario for this test is “When the user searches”. If we look closely we see that it have two asserts. When the user searches it should ask the repository for projects and the result should be “displayed” in a list. This feels a bit odd. I have to create a name for the test that captures everything that has to be done when the user searches. This is hard and I’m likely to loose some of the intent. The solution is to split the test in a test for every assert. However, this means that I have to set up each test in an equal manner and call the serach command. This is DRY! To solve this I’ve created a test base class called Specification that enables me to write the above test like this:

namespace Specifications_for_project_search_presentation_model
{
 public class When_user_searches_for_projects : Specification
 {
     private ProjectSearchPresentationModel _presentationModel;
     private List<Project> _projects;
     private IProjectRepository _projectRepository;

     public override void Arrange()
     {
         _projectRepository = MockRepository.GenerateMock<IProjectRepository>();
         _projects = new List<Project> { ProjectMother.CreateProject("project 1"), ProjectMother.CreateProject("project 2") };
         _projectRepository.Stub(me => me.FindByName(null)).IgnoreArguments().Return(_projects);
         _presentationModel = new ProjectSearchPresentationModel(_projectRepository);
     }

     public override void Act()
     {
         _presentationModel.SearchCommand.Execute("");         
     }

     [Fact]
     public void should_search_repository()
     {
         _projectRepository.AssertWasCalled(me => me.FindByName(""));         
     }

     [Fact]
     public void should_show_result()
     {
         Assert.True(_presentationModel.CanShowProjects);
     }

     [Fact]
     public void should_list_projects_found()
     {
         Assert.Equal(_projects.Count, _presentationModel.Projects.Count);
     }
 }
}

I have now set up the context and called the search command only once, but have a seperate test for each assert. I think these kind of tests read nicely. I have a test class for each scenario and tests that reads like the specification for the scenario. This also look very good in ReSharper.

The base class is implemented like this for xUnit:

public abstract class Specification
{
 protected Specification()
 {
     Arrange();
     Act();
 }

 public abstract void Arrange();
 public abstract void Act();
}

.NET RIA Services is for RAD only!

A bit late to comment, but .NET RIA Services was announced at MIX09. I recently spent some minutes to see what the fuzz was all about.

.NET RIA Services is a framework proclaimed for Line of Business development which is supposed to make it easy to build N-tier application. The framework makes it easy to expose your domain logic on the server to the client, with validation, authorization, querying and so on. You do this by defining a DomainService like this (taken from the RIA Services Overview):

[EnableClientAccess()]
public class CityService : DomainService
{
  private CityData _cityData = new CityData();
  public IEnumerable<City> GetCities()
  {
      return _cityData.Cities;
  }
}

The EnableClientAccess attribute exposes proxies of your entities to the client by code generation. It also generates client access to your operations.

Sounds intriguing? Not really. I wouldn’t have an enterprise application rely so much on magic, but hey, it could maybe be done..

As you can see from the service, an entity called City is exposed to client:

public partial class City
{
  [Key]
  public string Name { get; set; }
  [Key]
  public string State { get; set; }
}

Why is the class partial you wonder..? As I said the framwork lets you validate your domain logic both on the server and client. To be able to do this you have to create a metadata class, also known as a buddy class:

[MetadataType(typeof(CityMetadata))]
public partial class City
{
  internal sealed class CityMetadata
  {
      [Required]
      public string Name;

      [Required]
      [StringLength(2, MinimumLength = 2)]
      public string State;
  }
}

Metadata classes provide a way to attach metadata to an entity without actually modifying the corresponding members on the entity itself. When you generate the client proxy you also get the validation attributes. Sounds intriguing? Not in my wildest dreams. To get validation you actually have to repeat every property of City. This is as DRY as it can possible get. Add the shared code functionality to the soup and you have yourself a maintainability nightmare. .NET RIA Services is for RAD only; prototypes and applications that never reach a satisfactory production quality. I would never ever use this in a production system.

WPF and the Presentation Model Pattern

Over the last 6 months I've been working on a several projects where we have used Windows Presentation Foundation as our technology for creating GUI. When we started I began looking for presentation pattern that would best utilize the Data Binding capabilities in WPF and and at the same time could best interact with my domain model. In search for a suitable pattern I came across the Presentation Model by Martin Fowler. The Presenation Model, aka Application Model, aka Model-View-ViewModel pattern pulls the state and behavior of the view out into a model class that is part of the presentation layer. Since the presentation model holds the data that the view is going to render, there needs to be some kind of synchronization between the two. Based on the behaviour of the view, the presentation model changes it's state and automatically updates the view through Data Binding.

One can look at the view as a projection of the data in the Presentation Model. The Presentation Model has poperties for the information in the view and properties for state, typically disabling/enabling of buttons based on the current state of the view. The Presentation Model interacts with and updates the domain model through its properties. The following code illustates a typical presentation model for a project search view (in the context of my standard scrum application):

public class ProjectSearchPresentationModel : PresentationModel
{
private List<Project> mProjects = new List<Project>();
private DelegateCommand<string> mSearchCommand;

private DelegateCommand<Project> mSelectCommand;

public DelegateCommand<string> SearchCommand
{
 get
 {
     if (mSearchCommand == null)
         mSearchCommand = new DelegateCommand<string>(FindProjects);
     return mSearchCommand;
 }
}

public DelegateCommand<Project> SelectCommand
{
 get
 {
     if (mSelectCommand == null)
         mSelectCommand = new DelegateCommand<Project>(SelectProject);
     return mSelectCommand;
 }
}

public List<Project> Projects
{
 get { return mProjects; }
 set
 {
     mProjects = value;
     this.Notify(() => Projects);
     this.Notify(() => CanShowProjects);
 }
}

public bool CanShowProjects
{
 get { return Projects.Count() > 0; }
}

public void FindProjects(string searchText)
{
 var repository = IoC.Get<IProjectRepository>();
 Projects = repository.Query(project => project.Name == searchText);
}


public void SelectProject(Project project)
{
 ApplicationController.Instance.SelectProject(project);
}

public override void Refresh()
{
}
}

In the code behind of my view I instantiate a new ProjectSearchPresentationModel and set the DataContext of the view to my presentation model object:

public partial class ProjectSearchView : IView
{
private PresentationModel mPresentationModel;

public void Init()
{
 InitializeComponent();
 mPresentationModel = new ProjectSearchPresentationModel();
 DataContext = mPresentationModel;
}
}

The view now binds to the Projects property of the ProjectSearchPresentationModel and displays a list of Project objects based on the search criteria:

<StackPanel>
<Label Content="Enter customer name" />
<StackPanel Orientation="Horizontal">
 <TextBox Name="searchText" Width="100" />
 <Button Command="{Binding .SearchCommand}" CommandParameter="{Binding Text, ElementName=searchText}" Margin="5,0,0,0" Content="Search" />
</StackPanel>
</StackPanel>

<ListView Grid.Row="1" ItemsSource="{Binding .Projects}" Visibility="{Binding .CanShowProjects, Converter={StaticResource boolConverter}}">
<ListView.View>
 <GridView>
     <GridViewColumn Header="Action">
         <GridViewColumn.CellTemplate>
             <DataTemplate>
                 <Label>
                     <Hyperlink Command="{Binding RelativeSource={RelativeSource AncestorType={x:Type Views:IView}}, Path=DataContext.SelectCommand}" CommandParameter="{Binding .}">Select</Hyperlink>
                 </Label>
             </DataTemplate>
         </GridViewColumn.CellTemplate>
     </GridViewColumn>
     <GridViewColumn Header="Name">
         <GridViewColumn.CellTemplate>
             <DataTemplate>
                 <Label Content="{Binding .Name}" />
             </DataTemplate>
         </GridViewColumn.CellTemplate>
     </GridViewColumn>
 </GridView>
</ListView.View>
</ListView>

Note that I’m not using any event handlers in the code behind of the view. Instead I’m binding to Command properties defined in the ProjectSearchPresentationModel, which is hooked up to methods in the presentation model:

<Button Command="{Binding .SearchCommand}"
 CommandParameter="{Binding Text, ElementName=searchText}"
 Margin="5,0,0,0"
 Content="Search" />

public DelegateCommand<string> SearchCommand
{
get
{
 if (mSearchCommand == null)
     mSearchCommand = new DelegateCommand<string>(FindProjects);
 return mSearchCommand;
}
}

public void FindProjects(string searchText)
{
var repository = IoC.Get<IProjectRepository>();
Projects = repository.Query(project => project.Name == searchText);
}

The generic DelegateCommand is a class that implements the ICommand interface and is similar to the DelegateCommand found in the Prism framework. With commands I can keep the code behind of the view almost free from code. In my opinion the Presentation Model pattern is extremely powerful in combination with WPF. I find it both effective and easy to work with and lets me seperate the view from the domain model in an elegant way, which in turn makes it easy to test the view. This is how I do it. Stay tuned for more!