Team City PowerShell and Parameters

There are times when its really annoying, you get technology x up and running on your development machine and then try to integrate it into the wider enterprise system and fall at what is really the first hurdle, this has happened to me again, hence this post about what on the surface is a simple task, but has taken me some days to sort out.

The task:
Getting a PowerShell script to run within a Team City build where the PowerShell script needs a couple of parameters handed in.  told you it was simple! lets have a quick look at the script.

    [parameter(Mandatory=$true)] [string]$arg1,
    [parameter(Mandatory=$true)] [string]$arg2,
    [parameter(Mandatory=$false)] [int]$arg3=2,
    [parameter(Mandatory=$false)] [int]$arg4=3

Function ParameterTest
    $total = $arg3+$arg4
    Write-Host $arg1
    Write-Host $arg2
    Write-Host $total


Nothing scary, the important bit is the parameters at the top, these must be the first executable lines of the script and when the script is called the first two are mandatory so its off to team city to setup the build step.

teamcity blog picture

For me the thing to remember is to set the script execution mode to file, this shows the additional script arguments block where we can add the script arguments and there values, note we can use the team city environment variables here as usual.

This post is mainly for the future me who can’t get the script to run in Team City, remember that power shell must have execution permissions set.

Posted in Programming | Tagged , | 11 Comments

Mocks in Ruby and Zen Test on windows with Growl

These are notes mainly for me, so excuse the jumping around of topics in this post, I have been re-reading the book “Continuous Testing” by Ben Randy and Rod Coffin.

The Twitter gem used in the first example has changed quite a bit since the version used in the book, this was not a problem as a quick read of the documentation showed the way to achieve a similar result using the new API.

require 'twitter'

class User
  attr_accessor :twitter_username

  def last_five_tweets
    return"from:" + @twitter_username, :count => 5).map do |tweet|

The line “Twitter.Search” should return 5 tweets from the user with the given user name.

The fun bit came when trying to mock the Twitter call as the original code was totally different, reading the ruby mocking documentation, I discovered that RSpec adds the mocking functions to every object in the application, not sure how this is achieved yet one of those magic bits of Ruby and its ability to extend classes on the fly, but it means that the test code for the above is very simple once the concept is understood.

 it "provides the last five tweets from Twitter" do
      tweets = [
          {:text => 'tweet1'},
          {:text => 'tweet2'},
          {:text => 'tweet3'},
          {:text => 'tweet4'},
          {:text => 'tweet5'},


      @user.last_five_tweets.should == %w{tweet1 tweet2 tweet3 tweet4 tweet5}

The line “Twitter.should_receive” is the setup for the mock “Twitter” being the object to be mocked and “search” the method that is expected to be called the “.with” is the arguments expected by the call, “and_return” defines what the mock should return for valid calls. 

Getting the auto test to run was as simple on my windows machine as in the book now we have the excellent rails installer which makes setting up Ruby and Rails on windows easier than any other environment, the first time I read this book, Bundler and “Jeweler” just wouldn’t work on windows at all and required a virtual machine, now everything simply just works, the only bit that caused problems was getting the auto test to call growl for windows to display the results in a nice popup display.

The documentation for “AutoTest Growl for Windows” slightly out of date and the suggested gem installs an older version which didn’t work on my machine throwing an error when autotest was run. 

After some digging around, I cloned this git repository for the growl auto-test project and got my Ruby Mine environment to build and deploy the gem for me, which has worked fine, a quick note growl auto-test sends failing tests messages as priority “Emergency”, and passing test messages as priority “Very Low” so setting the colours for these two priority settings gives the visor a helpful colour

autotest growl setup

Also in the root of the project, same place as the other configuration files like the gem file there needs to be a file called “.autotest” this must have the require for the growl auto-test gem

require 'autotest/growl'

now to carry on reading!

Posted in Uncategorized | 1 Comment

Building the Right thing Right

Its what we developers aim for and what the business hopes for, doing anything else costs money both at the time of development and into the future with maintenance and the cost of change.

A few weeks ago I introduced SpecsFor to a colleague who was looking for an alternative to the traditional NUnit style tests, I was worried when he later said that he liked the framework and did he now need to use the SpecFlow tests! 

This is caused by a misunderstanding on what each framework it trying to address, SpecFlow and the Gherkin based frameworks are communication enabling tools, the fact that the results of the communication can be turned into automated tests is almost an aside, whilst SpecsFor and the traditional XUnit frameworks are designed to test actual code and require a level of competence in the relevant programming language.

So the answer to the question should we stop using SpecFlow? The answer is an definite no, we should always be aiming to further integrate the use of SpecFlow into the business process, because as a communication tool the more people throughout the business who use and contribute to the feature files the more the business and products benefit.

The feature files become the definition of what is required, allowing more accurate estimations of time to delivery and the engineers get a full description of what it is they should build.

Using SpecFlow feature style communication frameworks are enablers and foster direct and focused communication between the engineering departments and the rest of the business, providing the scaffold for the developers to build the right thing in the right way.

Posted in Programming, Project Management | Leave a comment

SpecSalad and Tables

I started a new home project the other day, a small website and started to write the features that I wanted, now I knew that SpecSalad supported tables in the usual Scenario Outline format as I had used them when writing the calculator example, but this time I wanted to include the table as part of the scenario for example

Scenario: a simple table in the given statement
Given I am a table specification
And I can see the table whats your favourite colour
| answer | vote |
| Red | 1 |
| Cucumber green | 1 |
| blue | 1 |
When I attempt to up vote the answer, Cucumber green
Then I should see the favourite colour is 'Cucumber green'

So simply expecting it to ‘Just Work’ I created my specification and watched it fail with some very interesting error messages! As it turned out there was actually no provision for the step definitions to take SpecFlow tables, so some time later I now have a couple of scenarios that can cope with tables both in the Given part of a scenario and the Then part, I didn’t add anything to the when syntax as I think currently this should be a unique call and probably won’t need tables.

So how does it work? using the above example first the given  line above uses the new SpecSalad syntax

Given I can see a table Table Name
Given you can see a table Table Name
Given the Role Name can see a table Table Name

Then I should see Table Name table
Then you should see Table Name table
Then the Role Name should see Table Name table

For the Given steps unusually you don’t create a task as the framework simply saves the table into the current scenario context using the table name supplied as the key. 

In the above scenario the rest of the steps are just the usual Spec Salad syntax, resulting the the following task code.

   1: public class UpVoteTheAnswer : ApplicationTask

   2:     {

   3:         public override object Perform_Task()

   4:         {

   5:             Role.UpVoteAnswer(Details.Value());


   7:             return null;

   8:         }

   9:     }

this calls the role to add a vote for the selected colour, the role in this case is TableSpecification

   1: public class TableSpecification : ApplicationRole

   2:     {

   3:          public void UpVoteAnswer(string answer)

   4:          {

   5:              var currentVoting = (Table)Retrieve("whats your favourite colour");


   7:              foreach (TableRow row in currentVoting.Rows)

   8:              {

   9:                  if (row["answer"] == answer)

  10:                  {

  11:                      int voteCount = Convert.ToInt32(row["vote"]);

  12:                      voteCount++;


  14:                      row["vote"] = voteCount.ToString(CultureInfo.InvariantCulture);

  15:                  }

  16:              }


  18:              StoreValue("whats your favourite colour", currentVoting);

  19:          }

  20:     }

this simply loops through the table stored in the scenario context looking for the given colour and adds one to the vote for that colour, re-saving the table back to the scenario context.

The then step

   1: public override object Perform_Task()

   2:         {

   3:             var votes = (Table)Retrieve("whats your favourite colour");


   5:             string winningColour = "";

   6:             int[] winningVoteCount = {0};


   8:             foreach (var row in votes.Rows.Where(row => Convert.ToInt32(row["vote"]) > winningVoteCount[0]))

   9:             {

  10:                 winningColour = row["answer"];

  11:                 winningVoteCount[0] = Convert.ToInt32(row["vote"]);

  12:             }


  14:             return winningColour;

  15:         }

this loops through the stored table looking for a row with the highest vote count storing the winning colour, this is then returned from the task to the framework to compare to the value in the specification.

I also wanted a syntax that could compare multiple results, so I could have a draw and two winning colours, the scenario looks like.

Scenario: a simple table in the then statement
Given I am a table specification
And I can see the table whats your favourite colour
| answer | vote |
| Red | 1 |
| Cucumber green | 1 |
| blue | 1 |
When I attempt to up vote the answer, Cucumber green
And I attempt to up vote the answer, blue
Then I should see the favourite colours table
| answer | vote |
| Cucumber green | 2 |
| blue | 2 |

Most of the steps are the same, but now the then step also has a table with the expected results in, the There task looks like.

   1: public class TheFavouriteColours : ApplicationTask

   2:     {

   3:         public override object Perform_Task()

   4:         {

   5:             var table = (Table)this.Retrieve("whats your favourite colour");


   7:             int maxCount = table.Rows.Select(row => Convert.ToInt32(row["vote"])).Concat(new[] {0}).Max();


   9:             var result = new Table(table.Header.ToArray());


  11:             foreach (var row in table.Rows.Where(row => Convert.ToInt32(row["vote"]) == maxCount))

  12:             {

  13:                 result.AddRow(row);

  14:             }


  16:             return result;

  17:         }

The then task first retrieves the table stored in the context, then goes through the table to find the top vote. 
A new table is created that has the same shape as the table in the context and into that table each row that has the max score is added, it is then this new table that is returned  to the framework to be compared to the expected results.

This last part is interesting as I am attempting to compare one table with another, not knowing if the two tables are even the same shape!

   1: private void ValidateTableAnswers(Table actualAnswers, Table expectedAnswers)

   2:         {

   3:             Assert.That(actualAnswers.RowCount, Is.EqualTo(expectedAnswers.RowCount), "row counts do not match");


   5:             var expectedValues = new List<string>();


   7:             foreach (TableRow row in expectedAnswers.Rows)

   8:             {

   9:                 var builder = new StringBuilder();

  10:                 foreach (var key in row.Keys)

  11:                 {

  12:                     builder.Append(row[key]);

  13:                     builder.Append(",");

  14:                 }


  16:                 expectedValues.Add(builder.ToString());

  17:             }


  19:             foreach (TableRow row in actualAnswers.Rows)

  20:             {

  21:                 var builder = new StringBuilder();

  22:                 foreach (var key in row.Keys)

  23:                 {

  24:                     builder.Append(row[key]);

  25:                     builder.Append(",");

  26:                 }


  28:                 string found = (from v in expectedValues where v == builder.ToString() select v).FirstOrDefault();


  30:                 Assert.That(found, Is.Not.Null, "values not found in expected table");

  31:             } 

  32:         }

First up the framework asserts that the two tables have the same number of rows, after which the framework builds a list containing line contains the combined row values in the expected table. 
The framework then iterates over the actual answers table and builds a string of the row values which is checked against the list form the expected values to ensure it exists. 

I am not sure if this is the best way to achieve this, but currently it works!

This new syntax is available on Nuget as version 1.9.1

Posted in Programming | Tagged | Leave a comment

Updating SpecSalad

I have missed a couple of updates to SpecFlow recently and decided to do a catch up for my little testing framework SpecSalad.  With this update the framework now supports the latest version of both SpecFlow (1.9.0) and also the latest version of NUnit (2.6.1).

There has also been a couple of tidy up which I have been meaning to do for a while, most notably the ability to now save and retrieve values from both Roles and Tasks which should make tasks more flexible in the future.

As usual its all available on Nuget, and surprisingly this little framework is now heading towards its first 1000 downloads!

Thanks to all those who have been using the framework

Posted in Programming | Leave a comment

New update to SpecSalad

It has been a while since I have blogged, and actually done any development outside of work, the joys of releasing a new product to market; but with the holiday I took the opportunity to have a look at some of my home projects, among them SpecSalad.

The other day Mick Hanson blogged about SpecSalad, saying some very nice things about the framework, thanks Mick its great to see the framework being used and proving useful; but not only has he used the framework he has contributed some new scenario syntax, expanding what is a very limited vocabulary.

Mick’s changes bring eight new ‘Then’ scenario syntax sentences

Then I can Task Name (: or ,) Expected Context
Then you can Task Name (: or ,) Expected Context

Then I am able to Task Name (: or ,) Expected Context
Then I are able to Task Name (: or ,) Expected Context

Then you am able to Task Name (: or ,) Expected Context
Then you are able to Task Name (: or ,) Expected Context

Then the Role can Task Name (: or ,) Expected Context
Then the Role is able to Task Name (: or ,) Expected Context

which brings some much needed flexibility to the framework.

Along with Mikes updates I have also updated the wiki with the new syntax, and released a new Nuget package and upping the version number to 1.6.0.

Posted in Code | Tagged | Leave a comment

Test Driven Development

I am planning on giving a talk, tutorial, lecture, rant (take your pick), about my take on the whole test driven development movement, how to do it, the pitfalls to avoid and the improvements in production that can be achieved, so for those that are going to see the talk, this is a sort of primer, over the next few posts I hope to give a taste for where I will be going, and for everyone else, I hope it is helpful, inspirational or at lest interesting.

First up a warning, driving production code from tests is a paradigm shift in thinking and not to be taken lightly. Looking up paradigm in the Oxford English Dictionary it says

                                    “a pattern or model, an exemplar”

So I am going to be messing with your model of programming, its not an easy journey and its not a silver bullet that will solve all your development woes, in fact it can add to them if used incorrectly, but the results can be breath taking and well worth the journey. 

Like a lot of systems the rules appear simple, but to implement them successfully takes practice, and discipline, so don’t expect to get it right first time, like all good things it takes practice, practice, practice,

The rules for test driven development were defined by Robert C. Martin some time ago, and work for any of the test driven methodologies.

1. You are not allowed to write any production code, unless it is to make a failing test pass.

2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

3. You are not allowed to write any more production code than is sufficient to pass the one failing test.

So what does this actually look like in the real world of programming?

Notice we are not writing the test first that’s important! We are writing the test and production code stubs ( a stub in this context is the outline of a method, function, class, property as required to get code to compile.) along side each other so the test code leads the production code by a very few keystrokes. 

Once the test assertion is written, then we have a truly failing test because the production code has no inner core, which we can now fill out in the simplest way possible to make the test pass before moving on to the next test. 

Notice I said the simplest way possible, this is also important!

What we want to do is write the smallest, and simplest code that will make the test (and any previously passing tests) work, don’t worry about method size, single responsibility etc. they get sorted in the next stage, we want the test to pass first, and fast.

Watching others and myself work, it is this last stage when things start to go wayward, I have a failing test, and I begin to make it pass using what I know in my mind will be the final version of the code, ( I just know I am going to need that service for login and the logging to record and the service to the database etc. etc.) and before I look around I have been writing code for 30 minutes and the test is still failing!

I actually think it is at this point your coding partner should be shouting YAGNI (You Aren’t Going To Need It) in your ear.

Rule 3 is one of the most difficult to follow successfully.  Is adding all that extra stuff the simplest thing?  Or  am I adding what I think I know I will need? 

One of the tenets of test driven development is that the tests drive the design of the code, yes you will have an idea that you will probably need x and y services and the REST schema will help define how the controllers in your MVC application will be laid out. 

But these ideas should be born out by the tests. I have found that if the tests are allowed to drive the final design then surprising things happen, the code I arrive at is not the code I would have written! It is cleaner, readable and simpler that my original thoughts, and its always easier to maintain and extend.

What makes this transformation? once a test passes, we pause, we have working code, sit back, review it, read it and then look at the code from a totally different angle, what methods are doing more than one thing? does the class have the correct responsibilities? is the naming correct?

Now dive in and refactor it.

I am a big believer in small methods and the single layer of abstraction within a method, a method should do one thing, so I use the extract method refactoring until essentially I cant do it any more. 

The class with all these methods in should have one reason to exist, and only have a single reason to change, if any of the methods don’t conform to this then it’s a clue that I need a new class to handle that responsibility, and so again I refactor, all the time the tests are being run to ensure that I have not broken anything. 

During this period of change or moulding I will change the names of methods to reflect what they actually do, ensuring that the public facing method names are small and concise and that the internal private methods are long and descriptive. 

For each class and method in my project this refactoring can take place many times, each time a test passes, I can if I want to review the whole of my code base, this refactoring is not just limited to my production code either, the test code can be reviewed and cleaned up as well, here I am aiming for readability above all else and ensuring that any new classes created by the refactoring of the production code are now covered by new or moved tests. 

Readability in the test code is paramount, if having some code duplication in the tests improves readability I will have duplication, but in the production code, I will remove any sense of duplication, for production code I am looking for clean, concise, fast code, in the tests I am looking for readability, first and foremost.

This process of writing simple code that with each test provides functionality is what makes test driven development different and difficult to do.  Forcing the simplest thing that can possibility work, knowing that the next test will probably change it, can be difficult to grasp, why then am I writing the simple one line? why not write the more complex code that I know is going to be there?

Because I know I am going to change it, the act of writing it, then changing it a few moments later is what makes test driven code so unique, the code is being moulded by the tests and refactoring, code being changed is alive and dynamic, working in the fashion produces code that is simple, easily extendable and productive, and never what you originally thought of.

Like modelling clay, code is kept moving by the process, changing its shape all the time, never settling too long in any one pattern, but improving by design as the product evolves. 

This ability to change is what makes the practice special and fit the agile mould.  Code is not a static concept, test driven code is not written and left, it is forever being added to, amended and moulded, keeping the code clay moving means change is not only expected but welcomed. 

The codes ability to absorb change means the business is not going to expend money re-writing an application to adapt to new conditions, the current application can be changed to match the new business requirements.

Keeping the code moving is the developers job, we are responsible to the businesses for the source code, we should not want the code to “set”, because code that is left, rots and is difficult to change which impedes the business we are employed to support.

It is the use of tests, the practice of refactoring and test driven metrologies that allow a developer to keep the code mobile, meeting the business needs and supporting not preventing growth.

So that’s the advert over, next post we can actually get down to some code

Posted in Programming | Tagged , , | Leave a comment