{ blog: 'Gøran Sveia Kvarv' }

Continuous Delivery with psake and TeamCity - Visualizing a pipeline REVISED

2012-10-11T23:02:00.001+02:00

The series so far:

In one of my pervious post, Continuous Delivery with psake and TeamCity - Visualizing a pipeline I wrote about how you could sync build numbers between build configuration. In that post I suggested to create a file that contained the build number which would be published to the artifact repository in TeamCity and used by dependent build configurations to set the build number. That was not exactly an optimal solution.
In Continuous Delivery with psake and TeamCity - Time for Some Refactoring I talked about how you could use the inherited build number from the “parent” build configuration and pass that into the build script and then set the build number in TeamCity. This was certainly a better solution, but it would be better to just let TeamCity handle setting the build number. To fix this, go to General Settings in the dependent build configuration and put dep.btX.build.number in the “Build number format” text box.

Actually I have been doing it this way for a long time now, so I should have written this post much sooner. Sorry.

Continuous Delivery with psake and TeamCity - Config Templates

2012-02-13T23:18:00.001+01:00

The series so far:

When we are deploying we always do some config transforms so that the application is configured for the right environment. In Nant we got xmlpoke, in msbuild 4.0 we got XmlPoke and there's also web.config transforms in .Net 4.0 which has been transformed to a general config transformation tool. In psake there isn’t something like this available, however as James Kovacks himself says, it’s very easy to do with PowerShell. I’ve created a little PowerShell script called Replace-Tokens, which you can find on GitHub, that does the work. Given a file some.template:

hello #{world}

and a file some.data.ps1:

@{
    world = 'world'
}

When we run:

replace_tokens_with_file "some.data.ps1" "some.template" "output.txt"

The output is the file output.txt:

hello world

The main idea here is that we pass in a hash table who's keys will be located in the template file and swapped by the value. We can also pass in a hash table directly instead of a file. So referring to my former post, if we were to change the app.config of the application when deploying to Test and Acceptance Test we could use the script and do the transformation. Change the test.ps1 properties file to:

$database_server = "Server 2"

$app_config_data = @{
    "database_connection_string" = "Data Source=$database_server;Initial Catalog=App;Integrated security = true";
}

Then change the deploy task of deploy.ps1 to:

task deploy -depends set_build_number{
    Write-Output "deploying to $env => database is deployed to $database_server"
    $app_path = "$build_artifacts_dir\Debug\ContinuousDelivery.WpfApplication"
    $config_file = "ContinuousDelivery.WpfApplication.exe.config"
    replace_tokens $app_config_data "$configs_dir\$config_file.template" "$app_path\$config_file"
}

Note that we pass in the $app_config_data from the test environment properties file. Now we just need to create a template of the app.config called ContinuousDelivery.WpfApplication.exe.config.template and place in in folder called configs under the build folder:

<?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <add name="database" connectionString="#{database_connection_string}"/>
  </connectionStrings>
</configuration>

This will overwrite the app.config based on the values found in the environment specific properties file when we deploy. Download the code from GitHub.

Continuous Delivery with psake and TeamCity - Time for Some Refactoring

2012-02-07T23:55:00.001+01:00

Refactoring is not just something you do with code. It’s also something you do with the build scripts and build process. Today we will split up our build script in nested builds and do some changes to how we pass on the build number to the next build configuration in the pipeline.

My previous installments in this series:

First up, I want to change how I pass in the task to run and the environment to the build script. It looked something like this for the CI configuration:

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

See how ci gets passed in, both for the task and the env parameter. I want to change this so the build script gets these values from TeamCity through Configuration Parameters. By doing that it’s a little bit easier to see and change these values. Let’s define some configuration parameters. Go to Build Parameters and add this:

Change the PowerShell build step to:

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

TeamCity let’s you access the parameters that you have defined by typing %parameter_name%. Do the same changes for the Test and Acceptance Test build configuration.

Next we’ll do something similar to pass in the build number from CI to Test and Acceptance Test. When you set up a dependent build you get access to all the build parameters passed and set by the build a build configuration is dependent on. So if C is dependent on B and B is dependent on A, C gets access to both A’s and B’s build parameters. So the build number of CI gets passed to Test and Acceptance Test as %dep.bt2.build.number% where bt2 is the build configuration id of CI. For Test and Acceptance Test add the following build parameter:

and change the PowerShell build step to:

&  {$host.UI.RawUI.BufferSize = new-object System.Management.Automation.Host.Size(512,50); .\tools\psake\psake .\build\build.ps1 %task% -parameters @{env='%environment%'; build_number='%build_number%'}}

The final thing I want to change how we call the task deploy and set_build_number. Both these tasks are relevant only to deployment so we’ll move them to a separate file called deploy.ps1:

$framework = '4.0'

include .\..\tools\psake\teamcity.ps1

task default -depends deploy

task deploy -depends set_build_number{
    Write-Output "deploying to $env => database is deployed to $database_server"
}

task set_build_number {
    TeamCity-SetBuildNumber $build_number
}

and then we’ll add a new deploy task in build.ps1 which calls the the deploy build script so that we get nested builds, a feature in psake. Here we also pass along all the parameters and properties so that the nested build can access the same variables:

task deploy {
    invoke-psake .\deploy.ps1 -properties $properties -parameters $parameters
}

Remember to always refactor your build scripts and build process. It’s just as important as code refactorings :)

Download the bits from GitHub.

Continuous Delivery with psake and TeamCity - Environment Configuration Management

2012-01-29T23:39:00.001+01:00

Happy New Year! I’ll start of the year by adding another post to the series about continuous delivery with psake and TeamCity. So far we’ve covered:

Today we’ll look at how to take care of configuration settings when we are deploying to different environments.

Let’s say that we have set up three environments; “CI”, “Test” and “Acceptance Test”:

Each of these environments need to have specific settings, for example which server to deploy a database to.

Powershell has the concept of dot sourcing. Basically it lets you include a PowerShell script from within another script and then you get access to all those variables and methods you defined in the script you included. We’ll use this feature to load an environment specific file into our build script based on an environment parameter that we pass into the build.

Modify the build script called build.ps1 from the previous post and add the highlighted line to the properties section:

properties {
    $base_dir = resolve-path .\..
    $build_dir = "$base_dir\build"
    $properties_dir = "$build_dir\properties"
    $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"
    
    . "$properties_dir\$env.ps1"
}

Next we’ll add three environment specific files to the path “.\build\properties”:

# ci.ps1
$database_server = "Server 1"

# test.ps1
$database_server = "Server 2"

# acceptance_test.ps1
$database_server = "Server 3"

One of these files will be loaded when we pass in the env parameter to the build script from TeamCity.

Copy the Test build configuration and call it Acceptance Test. Remember to republish the artifacts downloaded in the Test build configuration and make Acceptance Test dependent on the last pinned build of Test:

Change the Powershell build step (see picture below) in TeamCity and add

-parameters @{env='ci'} to the CI build configuration,
-parameters @{env='test'} to the Test build configuration and
-parameters @{env='acceptance_test'} to the Acceptance Test build configuration.

Let’s modify the deploy task in build.ps1 and print out some information about the environment:

task deploy -depends set_build_number{
    Write-Output "deploying to $env => database is deployed to $database_server"
}

and also add the following to the compile task:

Write-Output "Integrating database changes for $env at $database_server"

to simulate that we integrate database changes. Since we defined the variable database_server in the environment specific files we can now access it in the build file.

We should now be able to verify in the build log that we have “deployed” to our specified server:

We can also see that builds flow between the different environments and be able to see which build is deployed to which environment:

As always, download the code from GitHub.

Continuous Delivery with psake and TeamCity - Visualizing a pipeline

2011-11-30T00:17:00.001+01:00

So far we’ve covered:

Today I will show you how to update the build number of a deployment build with the build number of the build it is dependent on.

So if we were to deploy to test and the build number of the dependent build is 1.0.0.24, we want to visualize that this build number is actually deployed to test by updating the build number from our build script. One strategy for implementing this is to let the CI build output a file with the build number and publish it to the artifact repository in TeamCity.
The first thing we have to do is to create a task that outputs a file with the build number:

task create_build_number_file {
    "$env:build_number"  | out-file "$base_dir\build.number" -encoding "ASCII" -force  
}

# Add this task as a dependency to ci
task ci -depends compile, test, create_build_number_file

$env:build_number is an environment variable set by TeamCity containing the build number of the running build.
Next we have to publish this file to the artifact repository. Add build.number to the Artifact paths in TeamCity:

If we now run the CI build we should see something like the following under the Artifacts tab of the build:

So far, so good! Next up is to read this file when we deploy to test and set the build number.

task set_build_number {
    $script:build_no = get-content "$build_artifacts_dir\build.number"
    TeamCity-SetBuildNumber $script:build_no
}

# Add this task as a dependency to deploy
task deploy -depends set_build_number{
    Write-Output "deploying to test!"
}

# Make sure to add this line after the properties declarations
include .\..\tools\psake\teamcity.ps1

TeamCity-SetBuildNumber is a helper function that is defined in teamcity.ps1 which comes bundled with psake.

We also have to tell TeamCity to download the build.number file when Deploy to Test is run:

If we run Deploy to Test the TeamCity dashboard should look similar to this:

We have now seen how we can visualize which build number is deployed to which environment. Happy days!
As always you can download the source from GitHub.

Continuous Delivery with psake and TeamCity - Creating a pipeline with artifact dependencies

2011-11-02T23:55:00.001+01:00

In my last post we learned how to publish artifacts from a build that we can use to create a continuous delivery pipeline. So far in this series we’ve covered:

Today we’ll create a build that has an artifact dependency on the CI build that we’ve already setup. This let’s us reuse the artifacts that we published in CI so that we don’t have to compile our solution once again. First, we’ll have to create a deploy task in our build script so that we can simulate a deployment. Edit build/build.ps1 and add this task:

task deploy {
    Write-Output "deploying to test!"
}

Let’s create a build configuration called "Deploy to Test” where we will use our newly created task and simulate a deployment to a test environment. Add a Poweshell Build Step with script source:

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

This tells TeamCity to run psake with the specified deploy task. Next we’ll have to setup the dependency between the “Deploy to Test”-configuration and the “CI”-configuration. Go to the Dependency tab in TeamCity and click Add new artifact dependency. This brings up the following dialog where you can specify the properties of the dependency:

Here I have specified that I want to get the artifacts from the last successful build of CI and that I want to download the file app.zip and extract it to the folder build_artifacts. You can read more about this configuration and wildcards here.

By now you might think that we're ready for running the build. However, running it would fail. The reason for this is that TeamCity wouldn’t find psake or our build script. We have to have a strategy for getting the build scripts and tools. One option is to publish them to the artifact repository from the CI build and download them from there. Another option is to download the build scripts and tools from source control. With the latter option you could potentially try to deploy new deployment items, say a web service, from a build that hasn’t got it yet. In other words, you have to be very careful if you update the build script because you always get the latest version, whereas the binaries you get from the artifact repository could be older and not contain what the build script expects. With the former option you have to go through every step in the pipeline to get an update of the build script. Say you find out that you have an error in the build script regarding deployment to production. To fix it you have to go through every step in the pipeline. This is time consuming and it also means that you cannot deploy the original build to production. You now how to deploy the new version. At my current client I have taken the former approach, but based on my experiences I would personally recommend that you download the build scripts and tools from source control. This makes it a lot easier to fix errors and do refactoring.

Back to TeamCity, attach the VCS root that is used in CI to the build configuration under Version Control Settings, click edit checkout rules and add this:

-:.
+:build
+:tools

The first line says that TeamCity should exclude everything from the checkout. The next two lines add the build folder and tools folder respectively. If we save and run our build now you should get something similar to.

To add additional steps to the pipeline you could just publish the same downloaded binaries to the artifacts repository and make the next deployment dependent on “Deploy to Test”. Let’s say the next step is deployment to staging. Then you could say that the build that is deployed test has to be verified by QA before it’s deployed to staging by setting up a dependency where you get the last pinned build from “Deploy to Test”. This feature in TeamCity is extremely useful for adding build verification to the process.

Next time I will show you how to label the deployment builds with the build number from CI. See ya!

Download the source code from GitHub.

Continuous Delivery with psake and TeamCity - Preparing for a pipeline

2011-10-14T10:12:00.001+02:00

In my previous three posts I have shown how you could set up a Continuous Integration build with psake and TeamCity 6.5. This time I will show you how to prepare for continuous delivery where the artifacts from the CI build flows through several steps and environments that together form a pipeline of builds which culminates in deployment to production. It seems like this is developing into a series, so here are my previous installments:

One of the core principles of continuous delivery is that the deployment process should be repeatable and reliable. To achieve this we have to make sure that every bit of the deployment process is automated and that we deploy in the same manner to every environment. I urge you to read Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. It’s a fantastic book!

The output produced from build is usually referred to as the build artifacts. This includes all the compiled binaries and other packages, for example installers and migration scripts for a database. It is very important that you compile you binaries only once and use the same binaries to deploy to each environment in the pipeline. To enable this the artifacts needs to be stored somewhere so that the deployment process can get it. TeamCity comes bundled with an artifact repository which can be configured in the Build Configuration. This feature allows us to associate the artifacts from a build to the build id and reuse them by setting up an artifact dependency between the different builds in the pipeline. By doing this we can say that the deployment build to for example test has a dependency on the CI build. Whenever the deployment-to-test build runs, TeamCity will automatically download the artifacts from the specific CI build you configure it to get it from, for example the last successful build of CI. In this manner we can chain or builds to create a full continuous delivery pipeline.

Let’s get on with it and configure our CI Build Configuration to publish artifacts. Open the Build Configuration and look for “Artifact paths”:

Here you can specify files and folders that you want to publish to the artifact repository. For a detailed explanation of the format see TeamCity’s documentation. Let’s make TeamCity zip our WpfApplication so that we can deploy and distribute it in successive builds. Add the following to the “Edit artifact paths”:

build_artifacts\Debug\ContinuousDelivery.WpfApplication => app.zip!ContinuousDelivery.WpfApplication

This statement takes all the files in the ContinuousDelivery.WpfApplication folder and zips it to a ContinuousDelivery.WpfApplication folder inside app.zip. If we now run the CI build we should see that an artifacts tab has appeared and that our zip-file is displayed.

That concludes this post. Next time we will reuse the artifacts and setup a dependent build to deploy to a test environment.

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

2011-09-16T00:00:00.001+02:00

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

2011-09-02T15:53:00.001+02:00

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

2011-09-02T13:05:00.001+02:00

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”

2010-03-29T15:18:00.005+02:00

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

2009-10-24T19:35:00.005+02:00

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!

2009-06-09T20:26:00.005+02:00

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

2009-02-12T13:33:00.010+01:00

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!

Test Data Builder

2008-12-21T20:23:00.043+01:00

In every project you reach a point where you need test data for unit testing. Having a reasonably complex domain model can make this task "difficult" because testing an entity in many cases means that you also have to setup associations to other entities. Intializing objects per test is cumbersome and any changes to constructor arguments will break your tests. One of the solutions to this problem is to use the Object Mother pattern. It's basically a class with factory methods that helps you setup an object for testing. The object creation code is moved out of the tests so that it can be reused and making the test data more maintainable. So if you are developing a scrum application and want to create a project with a sprint and a user story you would do something like this:

public static class ProjectMother
{
 public static Project CreateProjectWithSprint()
 {
     Project project = new Project();
     Sprint sprint = new Sprint();
     UserStory userStory = new UserStory();
     userStory.Name = "User story";
     userStory.StoryPoints = 8;
     sprint.AddUserStory(userStory);
     project.AddSprint(sprint);
     return project;
 }
}

Project project = ProjectMother.CreateProjectWithSprintAndUserStories();

However as time goes by you end up with a lot of factory methods for the slightest variation in the test data beacuse of the heavy coupling that exists since many tests use the same method. This make the Object Mother class hard to maintain. To solve this problem I usually write a fluent interface (embedded domain specific language) that I use to initalize my objects for testing. This is heavily based on the Expression Builder pattern. For each class I want to test I write a builder for that class. So when I want to create a Project object I just write:

Project project = ProjectBuilder.Create.Project
              .WithName("Test Project")
              .WithSprint(SprintBuilder.Create.Sprint
                  .WithName("Sprint 1")
                  .WithUserStory(UserStoryBuilder.Create.UserStory
                      .WithName("Story 1")
                      .WithStoryPoints(13)
                      .WithTask(TaskBuilder.Create.Task
                          .WithName("Task 1")
                          .WithHours(3))));

Behind the scenes the ProjectBuilder takes care of everything adding sprints and so on. In each method the builder just returns itself after having done some setup on the private Project instance. The ProjectBuilder is finally casted to Project using an implicit cast operator which returns the private Project instance.

public class ProjectBuilder
{
 private static Project mProject;

 public static ProjectBuilder Create
 {
     get { return new ProjectBuilder(); }
 }

 public ProjectBuilder WithName(string name)
 {
     mProject.Name = name;
     return this;
 }

 public ProjectBuilder Project
 {
     get
     {
         mProject = new Project { Name = "Test Project" };
         return this;
     }
 }

 public ProjectBuilder WithSprint(Sprint sprint)
 {
     mProject.AddSprint(sprint);
     return this;
 }

 public ProjectBuilder WithBacklog(Backlog backlog)
 {
     mProject.Backlog = backlog;
     return this;
 }

 public static implicit operator Project(ProjectBuilder builder)
 {
     return mProject;
 }

}

Still, I don't feel that the Object Mother and the Builder are mutually exclusive. If I have a lot of tests that use the same test data I often create an Object Mother with a factory method that uses the builders. When I need a specialized initialization of an object for a test I just use the builders directly in my tests.

I find this way of creating test data really useful and hopefully you do too! Feel free to download and use the code. The builders are located in the tests project.

Merry Christmas!!

Presentation at NNUG Vestfold

2008-11-20T23:17:00.001+01:00

Last night I held a presentation at NNUG Vestfold. I primarily held demos showing usage of Dependency Properties, Attached Dependency Properties and ControlTemplates in WPF.

Making SharpDevelop compile and debug Boo programs on a 64-bit machine

2008-09-10T21:37:00.007+02:00

Recently I've started looking at Boo. As of now the only decent development tool for Boo is SharpDevelop. BooLangStudio, a Visual Studio plugin, recently came out in an alpha release. However, at the moment it's way too immature. Back to SharpDevelop... I'm running a 64-bit version of Vista which resulted in some problems compiling and debugging Boo programs. Since the compiler (booc.exe) is marked to run on AnyCPU it will start as a 64-bit process. SharpDevelop runs as 32-bit only. Therefore it will use the 32-bit version of MSBuild which in turn picks up a 32-bit version of System.dll and passes this version too booc.exe. Unfortunately this means that the 64-bit booc.exe process will crash when it tries to load the 32-bit System.dll. A solution to this is to use CorFlags to mark booc.exe as 32-bit only. However, this breaks the strong name so you'll have to resign it. Do the following:

Open Visual Studio Command Prompt and run CorFlags "path\SharpDevelop\3.0\AddIns\AddIns\BackendBindings\BooBinding\booc.exe" /32BIT+ /Force.
Download boo.snk from http://svn.codehaus.org/boo/boo/trunk/src/. Still in VS Command Prompt run sn -R "path\SharpDevelop\3.0\AddIns\AddIns\BackendBindings\BooBinding\booc.exe" "path\boo.snk".

You can now build your Boo programs!! A new problem suddenly arises when you try to debug your program. The debugger crashes because your program is compiled to run on AnyCPU. So the 32-bit only compatible debugger will launch a 64-bit program and crash. SharpDevelop suggests that you set the target cpu of your program to 32-bit. This is not possible to do; The only option is AnyCPU. So we'll have to hack some more:

Open the property page of your project and go to the Build Events tab. In the Post-build event command line text box type "path\Microsoft.NET\SDK\v2.0 64bit\Bin\CorFlags.exe" "$(TargetPath)" /32BIT+

Now build and debug your program. Voila!!

Balsamiq Mockups: Taking the evilness out of prototypes

2008-07-28T22:54:00.009+02:00

Everyone that has heard Odd Helge Gravalid's presentation "Gui prototyper Onde" (GUI Prototypes Are Evil) knows why prototypes are evil shit. The main point is that proptypes create expectations about the functionality in the GUI that may not be fully implemented or may not be present at all, but it seems like it is. So what's wrong about that? Well, as I recently experienced; A couple of weeks after you presented the prototype, when you actually have implemented the functionality, the customer's project manager says: "What have you guys really been doing lately? This is nothing more than you showed me two weeks ago". And then you are in trouble. So the moral is that you should never make a prototype that actually looks like it's really implemented. It will most certainly backfire! Last Friday I came across this great GUI mockup tool called Balsamiq Mockups. The tool makes it really easy to create mockups by using the more than 60 pre-built controls. The cool thing is that it looks like they're actually drawn by hand, "so that people don't get attached to “that pretty color gradient”". This can certainly help us out not going in that prototype trap and rather let us concentrate on the important aspect of prototyping: Discussing functionality! Check it out: You can even try it out here!

70-502: WPF Exam

2008-07-28T21:53:00.002+02:00

It's been a long time since I've blogged. What have I been up to lately? For the most part I've been working and tried to enjoy the summer as much as possible. I've also managed to pass the 70-502 - Microsoft .NET Framework 3.5 – Windows Presentation Foundation Application Development exam. For the last month and a half I've been working on a WPF project and I would recommend everyone that has done some work with WPF to give the exam a shot. It's actually quite easy.

Refactoring: Later? Continuously!

2008-04-23T23:42:00.014+02:00

A couple of days ago I attended a meeting about refactoring. Some of the attendants were unfamiliar or felt unsecure about refactoring. One of the questions that arose was; "When is it time to refactor? Is it a joint descision in the developer team that it's time to refactor or is it an independent descision?" There is NEVER a special time for refactoring. You don't create a task that says refactoring. Refactoring goes hand in hand with coding and should be performed CONTINUOUSLY. ALWAYS. You should always take into account refactoring when estimating a task, if not you're in deep shit. The customers generally don't care if you build a house with duct tape, as long as it looks good enough. And they will certainly not pay for later changes not visible from the outside. But as a professional developer you know that the house will fall apart when the rainy day comes. So ALWAYS refactor and estimate accordingly!

DataGrid revisited

2008-04-22T23:10:00.023+02:00

Today I held a little presentation at work showing off some of the DataGrid capabilities in Silverlight 2.0 beta. It's basically based upon my last post, but I added some new functionality that shows use of the DataGridCheckBoxColumn and the DataGridTemplateColumn.

<Data:DataGridCheckBoxColumn Header="Is done" DisplayMemberBinding="{Binding IsDone, Mode=TwoWay}" />
<Data:DataGridTemplateColumn Header="Due date">
  <Data:DataGridTemplateColumn.CellTemplate>
      <DataTemplate>
          <TextBlock Text="{Binding DueDate, Mode=TwoWay}" />
      </DataTemplate>
  </Data:DataGridTemplateColumn.CellTemplate>
  <Data:DataGridTemplateColumn.CellEditingTemplate>
      <DataTemplate>
          <DatePicker SelectedDateFormat="Short" FirstDayOfWeek="Monday" SelectedDate="{Binding DueDate, Mode=TwoWay}" />
      </DataTemplate>
  </Data:DataGridTemplateColumn.CellEditingTemplate>
</Data:DataGridTemplateColumn>

You can download the source code here

Silverlight 2.0: Two-way data binding with DataGrid

2008-03-30T23:36:00.001+02:00

I've written a little Master/Detail demo application using the DataGrid control in Silverlight 2.0 beta 1. The application shows usage of data binding, styles and definition of custom columns for the DataGrid control. You can download the source code here.

The following code fragment shows how to define your own columns for the data grid:

<data:datagrid name="lstTasks" isreadonly="False" headersvisibility="Column" style="{StaticResource TaskList}" selectionchanged="lstTasks_SelectionChanged"> <data:datagrid.columns>  <data:datagridtextboxcolumn displaymemberbinding="{Binding Title, Mode=TwoWay}"> <data:datagridtextboxcolumn.header> <textblock text="Title"> </Data:DataGridTextBoxColumn.Header> </Data:DataGridTextBoxColumn>  <data:datagridtextboxcolumn displaymemberbinding="{Binding Estimate, Mode=TwoWay}"> <data:datagridtextboxcolumn.header> <textblock text="Estimate"> </Data:DataGridTextBoxColumn.Header> </Data:DataGridTextBoxColumn>  <data:datagridtextboxcolumn displaymemberbinding="{Binding Backlog.Name, Mode=TwoWay}"> <data:datagridtextboxcolumn.header> <textblock text="Backlog Name"> </Data:DataGridTextBoxColumn.Header> </Data:DataGridTextBoxColumn> </Data:DataGrid.Columns> </Data:DataGrid>

The next generation rule engines are pure C#

2008-03-04T01:48:00.005+01:00

The project I'm currently working on is based on a rather narrow domain, but with a high density of business rules that comes along. Currently we are writing the rules directly in code, but there have been some pressure about using an in house created XML based rule engine. As the rule base becomes bigger and bigger the more the pressure. As I see it there are two reasons for using a rule engine:

Separate the rules from the code so it can be edited without recompiling the application.
Let the rules be edited by a domain expert.

Does an XML based rule engine support this? Sure, a rule engine certainly separates the rules from the code and makes it editable. However, I don't really see how rules in XML are much better than rules written in code. Rules in XML can certainly become as complex syntactically as code and I would argue that as the rules get more complex, rules written in code actually get more easy to read and understand. So at my point of view a rule engine doesn't provide a domain expert much more support in editing rules than plain code. Now comes the real pain with a rule engine; Testing. As the rules are written in XML it becomes real hard testing them incorporating your domain objects. Sure, the XML is often used to generate code, but I don't see how this improves the testability much. The generated code will normally be complex and hard to use as the XML and code generator tries to capture and provide functionality for general purpose problems and scenarios in non specific domains. Refactoring the code won't update the XML and suddenly you find yourself in a maintainability hell. This is why I would rather have my rules in code. Now the problem with writing rules in code isn't that it is impossible to separate the rules from the rest code. Writing rules in code suffers in the same matter as rules written in XML in that it is extremely hard for a non technical domain expert to read, edit and verify rules. Lets not forget create new rules. I can understand those who argue that rules in XML are more maintainable for a non technical than rules in code, and the fact that there are some stakeholders driven against a XML based rule engine really got me thinking. As I most certainly want to keep my business rules in code for testability and maintainability I started thinking about an alternative way that could let us keep the rules in code and at the same time make them easy to edit, which in turn would satisfy all parties. A couple of days ago, on my way to work, I was talking to a colleague who had attended a meeting at the Norwegian .Net User Group (NNUG) where Anders Norås, a former employee at my company held at talk about fluent interfaces and domain specific languages. I immediately associated this concept with my rules problem and started digging around on the Internet. In my search I found at great article by Anders Norås where he shows an example of an DSL implementation. I would also recommend an article by Martin Fowler where he discusses the pros and cons of internal and external DSLs. Although external DSLs can be evaluated at runtime, which has made XML so popular, and the fact that internal DSLs are limited by the syntax of the language of choice, I would still go for an internal DSL. I don't have to learn a new language and I can take advantage of my existing skills. The idea of fluent interfaces seems very interesting. Writing a fluent interface would mean that the domain expert editing the rules could use IDEs and even get intellisense while he/she is typing the rules. Writing the rules in a language like Boo, which runs on the .Net CRL could even let the rules be evaluated runtime. However, I don't see this as an requirement for my problem. Writing a fluent interface in C# would probably satisfy all my needs. Extension methods would most certainly become handy. Still, I'm a little bit concerned about the effort and cost of creating such a DSL. Hopefully I soon will find the time to implement a little prototype and write a part 2 of this post. I'll keep you posted!