Monday, September 21, 2009

Insert multiple word documents into another.

Just thought I would share this quick macro I wrote for our test team to let them join a bunch of documents together in word..

http://gist.github.com/190041

It's just simple enough to work.

Monday, August 24, 2009

Pit:: Manages your user config settings easily.

Pit is a real 'gem' of a gem.

I have a script that installs a bunch of gems to set up a development environment on rails. The problem is each user of the script needs to set up the proxy for their own specific user settings. I don't want to store that information in the script as everyone would be logged in as me. I don't want to have to remember to manually set up some config file for each user of the system either.

Pit acts like a repository for configuration data. In your code, just ask Pit for specific data and it will either return the known information OR prompt the user with an editor so they can fill in the missing information (which is then remembered). So simple!..

Install: gem install pit

Usage:

require "pit"
config = Pit.get("proxy.settings", :require => {
"username" => "default value",
"password" => "default value"
})


Install the gem and run gem server for more information.

The files are hosted at http://rubyforge.org/frs/?group_id=4607

Thanks LowReal whoever you are!

Thursday, July 09, 2009

StoryQ

I've been looking at BDD with .Net recently. I'm evaluating a few story runners... There seem to be a few...


  • NBehave
  • NSpecify
  • StoryQ
  • NSpec
  • Spec#
  • MSpec


It's still early days, so I haven't decided on a library yet.

One possibility is the StoryQ story definition library. It isn't a runner, but uses your existing test runner as you define your specs within a test.


[Test]
public void ExecutorRunsTests()
{
var story = new Story("Running a test script");

story.AsA("tester")
.IWant("to run a test script")
.SoThat("I can verify the release meets the acceptance criteria")

.WithScenario("A passing test script")
.Given(() => ThereIsATestFileWithASinglePassingTest())
.When(() => TheTestIsRun())
.Then(() => TheTestPassShouldBeReported())
.And("report no failures or errors")

.WithScenario("A failing test script")
.Given(() => ThereIsATestFileWithASingleFailingTest())
.When(() => TheTestIsRun())
.Then(() => TheTestFailureShouldBeReported())
.And("report the failure")

.WithScenario("An erroring test script")
.Given(() => ThereIsATestFileWithASingleErroringTest())
.When(() => TheTestIsRun())
.Then(() => TheTestErrorShouldBeReported())
.And("report the error")
;
story.Assert();
}


The Statements can be written as Given(() => ThereIsATestFileWithASingleErroringTest()) or .Given("There is a test file with a single erroring test")

This allows you to start by defining them as strings and later go back and introduce the code. This makes the development feel bite sized and focused.

To help with this I wrote a simple VBA Macro to convert from text to a lambda method. It also converts back, but it's not perfect as ToUpper is a lossy operation, but it's good enough.

You can grab the macros here.

Wednesday, May 27, 2009

Rack Up Some RSpec Tests

Here's a simple rack application to render the output from running RSpec.
(Note: this is tailored to work on windows..)


#\ -w -p 8765
use Rack::Reloader, 0
use Rack::ContentLength

app = proc do |env|
formatting = '--require "C:\\...\\Ruby RSpec.tmbundle\\Support\\lib\\text_mate_formatter" -f ' +
'Spec::Runner::Formatter::TextMateFormatter' if env["REQUEST_PATH"] == "/textmate"
formatting = '-f h' if env["REQUEST_PATH"] == "/html"

out = `spec.bat spec #{formatting} 2>&1`
format = out=~/\ [ 200, {'Content-Type' => format}, out ]
end

run app


How to use it



Install rack if you haven't already. gem install rack


  • To start it, save this code into a file called 'spec_rack.ru'.
  • Change the '...' to the path to your textmate bundles... (or just ignore it if you don't use E or textmate)
  • Run rackup spec_rack.ru
  • visit http://localhost:8765 http://localhost:8765/html or http://localhost:8765/textmate


Why Bother?


I'm using RSpec for testing, but the integration with E (the windows clone of Textmate) seems to hang sometimes when there is an error in my code.
Having explorer open with the results so I can just press refresh is working well for me.

I wanted to post a simple rack application as there don't seem to be many examples around.

Tuesday, April 21, 2009

Cucumber Syntax

Cucumber is the latest incarnation of the RSpec Story runner concept; A complete rewrite by Aslak Hellesoy.

I have been using Cucumber at work as a requirements parser to generate test scripts. Here is a quick guide to the content of the feature files.

Cucumber provides a simple way to parse feature/scenarios that have been written in a english (or whatever your native language is). For Cucumber to understand your features though you need to structure them in a certain way... here is how you do it.

A standard install has the following directory structure...

ProjectDirectory
+ bin
+ features
- XXX.feature
- ...
+ step_definitions
- XXX_steps.rb
- ...
+ support
- env.rb
+ lib
+ spec

Features


The features are documented in the files named [feature_name].feature in the features directory.

They follow this pattern:
Feature: [the features name]

In order to [goal]
As a [role]
I want to [action]

[...background...]

[...scenarioes...]


Scenarioes


Cucumber doesn't actually do anything with this information (except the scenarioes and background). It is intended to give a human reader context (and reveal the motivation for) for the scenarioes that follow.

Scenarioes are descriptions of the ways that that feature manifests itself within the application. You would have one scenario for each path through the feature. These are a lot like use cases, but you keep them high level, short and only exercising one path.

Scenarioes is made up of a several steps, and can take the following form:
Scenario: [name of the scenario]
Given [some statement]
When [some action]
Then [expected result of the action on the system]
And [another expectation]


Note: And can be used after Given, When or Then steps.

When you run cucumber against a file it will suggest code to put in your ..._steps.rb files to match any currently undefined steps.

Note: Steps can be parameterized to aid reuse. If you put "quotes" around some part of your step (e.g. Given I am on the "login" screen ), then when cucumber suggests the code for you, it will automatically suggest one that will pass what is between the quotes as an argument.

Given the following customer exist:
|name | age | email |
|rod | 32 | rod@somewhere.cool |
|jane | 35 | jane@somewhere.cool |
|freddy | 34 | freddy@somewhere.cool |

You can also have steps (Given, When, Then, or And) it this form. This will result in a table of information being passed to your step definition.

Background


Background defines the context that the scenarioes should be run in. In other words a set of Steps that will be executed before each scenario in this file is run.

Background takes the following form:
Background: 
Given ...
And ...
And ...


Scenario Outlines


Scenario Outline: [name of the scenario]
Given [some statement]
When [some action]
Then [expected result of the action on the system]

Examples: [name of example set]
| column A | column B | column C |
| row 1 A | row 1 B | row 1 C |
| row 2 A | row 2 B | row 1 C |


The scenario outline in infact defining several scenarioes. The Outline will be executed by Cucumber once for each row in the Examples table (excluding the first with is the column headings). Any steps within the scenario that include something of the form <column name> will have the <...> substituted with the contents of that column for the current row.

Note: You can include multiple Example tables if you like.

Cucumber uses the features/support/env.rb file to set up cucumber. This is a good place for your:
Before do  |scenario|
...
end

After do
...
end

...blocks to live. These are executed before and after (respectively) each scenario is run.

Wednesday, February 18, 2009

Can Distributed Agile Work?

Andy Singleton says yes!

Andy says that if you accept that development will be distributed and get on with making it efficient it leads you to question a bunch of common practices.

Don't do interviews.. and Don't do estimation.. were my favorites.

Andy's company Assembla pull together a bunch of open-source and internal tools to set up a tool chain that lets lots of people work on the same project at once, gives visibility to your customers and tracks progress.

Andy also suggests that when a project is just starting up you can pile on loads of people and let it settle into a good team. This goes against my current experiences with development teams. In my experience you need to get 2-4 really smart people to do some vertical stripes through your application to flesh out an architecture. Once that is done.. then you are ready to start scaling the team up. Bringing too many people on early leads to too much code before the architecture is set. This leads to lots of code to refactor as develop and understanding of the domain.

Having said that... the initial architecture decisions you are making tend to be... How should we separate the domain logic from the presentation logic? How should we use Technology X to implement the GUI?

These things seem like such solved problems to me at the moment. I can't understand why they take so long to get in place. For each technology stack there should be something like Rails where you just fill in the bits that are specific to your domain.

Back to Andy... I'd love to hear more about how the first few weeks of his projects go. He claims to be having good success, so I would love to know more :)

I guess I'll start reading his blog.

The OO light bulb goes on

I had a light bulb moment a few months ago that I want to share. Bare with me.

OO programs when running are a network of in memory 'object's each with specific behavior and state.

Traditional OO programming languages like C# 1.1 and Java allow you to specify classes of objects, defining generalizations about how certain types of object behave.

In C# an object is an instance of a class.

In True OO this is only one of many ways to get your running object in memory. Why limit yourself to this factory technique... Why not create a bare object and add methods to it at runtime? Why not mix together sub-class modules of functionality?

As long as at the end you have a network of objects in memory that behave the way you need them to, to model your domain, why limit yourself to this one technique of object creation?

Type safety?

I recently heard a podcast (can't recall which...) where the speaker said "type checking in the compiler is just a form of unit testing". Personally I am still letting that sink in.

I guess, if I were you, and I had read this far, I would get to this point and have one question "So What?"

Thinking of classes as only one way to get objects into memory is liberating:-

I had a class I wrote the other day that was part of a UAT framework based on White...

 public class CaseHelper : ScreenHelper
{
public CaseHelper(Window window)
: base(window)
{}

public string PatientId
{
get { return PatientIdBox.Text; }
set { PatientIdBox.SetValue(value); }
}

public string GivenName
{
get { return GivenNameBox.Text; }
set { GivenNameBox.SetValue(value); }
}

public string FamilyName
{
get { return FamilyNameBox.Text; }
set { FamilyNameBox.SetValue(value); }
}

public string DateOfBirth
{
get { return DateOfBirthBox.Text; }
set { DateOfBirthBox.SetValue(value); }
}

public string Gender
{
get { return GenderBox.SelectedItemChildName(); }
set { GenderBox.SelectItemByChildName(value); }
}

public void ClickSave()
{
SaveButton.Click();
}

public string BarcodeNo
{get { return BarcodeNoBox.Text; }}

private TextBox PatientIdBox
{get { return Get<TextBox>("patientId"); }}

private TextBox GivenNameBox
{get { return Get<TextBox>("givenName"); }}

private TextBox FamilyNameBox
{get { return Get<TextBox>("familyName"); }}

private TextBox DateOfBirthBox
{get { return Get<TextBox>("dateOfBirth"); }}

private ComboBox GenderBox
{get { return Get<ComboBox>("gender"); }}

private TextBox BarcodeNoBox
{get { return Get<TextBox>("barcodeNo"); }}

private Button SaveButton
{get { return Get<Button>("saveButton"); }}

}



As you can see lots of duplication that is hard to factor out further. I could turn to code generation., but what frustrates me is in Ruby I would be able to write helpers for each type of control and the code would become...


class CaseHelper < ScreenHelper
has_text "patientId"
has_text "barcodeNo"
has_button "saveButton"
has_combo "gender"
has_text "giveName"
has_text "familyName"
has_text "dataOfBirth"
end


That I can handle. This is possible because defining a class is ruby is done at execution time. All you are doing is executing code that is creating objects. (a class in an object that has a new method that makes other objects). has_text is just a method that defines methods. Easy.

Friday, February 13, 2009

NetObjectives (a focus on lean development)

NetObjectives are creating some great content. I listen to the podcast. Take some time to browse their resources.

Visual Studio... can look like TextMate

At home I'm a mac user. I love my mac (although it could stand to run faster)..

Rob Conery did an ace job of styling Visual Studio to look like TextMate.

Now less electrons need to die each second with your new black background. :)

Joking aside.. looking at a screen all day is like looking at a lightbulb. It is best if you can keep things dark but clear.

Palm Pre

Wow.. what a phone!
http://www.youtube.com/watch?v=6eUQGnqiy0g

And.. it's based on Linux.

Coverage doesn't mean anything...

... is like saying "Wii-Fit doesn't make you fit, because you can just step on and off and the game thinks you are exercising".

If you do this, you are just fooling yourself.

Coverage means nothing unless you assume you are working in an environment where developers are writing good unit test. With this assumption, suddenly it becomes a great measure of how much of the code is untested! [or in BDD lingo.. how much of your code is not required to satisfy the current set of automated requirements indicating either a requirements gap or too much code!]

100% Coverage

To my mind 100% coverage should mean all the code we as a team have chosen to test is tested.

If you decide 'generated code doesn't need tests.. as long as the generator is tested and an example is tested' .. then I say you are still 100%

If you decide 'getters and setters don't need testing' that's fine... exclude them from your coverage.

If you explicitly exclude something from your coverage statistics, then tell your tool. In NCover.. you can put attributes on the things you want to exclude.

Do that and you can get to 100%.

I'll leave the decision as to what things should be tested to the reader... for now.

Thursday, January 22, 2009

Story points for Estimation

Mike Cohn, author of Agile Estimating and Planning wrote in his comments to his "To Re-estimate or not; that is the question" article ...

"... When I do iteration (sprint) planning I don’t even consider the story point estimates. We grab one item from the product backlog, break it into tasks and hours, discuss whether we can commit and then repeat until full. The story points–as I use them–are for long-term planning. When we plan an iteration and take a lot more time to do so we do it by discussing tasks, hours and commitment."

check out "Why I Don’t Use Story Points for Sprint Planning" for more of his thoughts on this.

Monday, January 19, 2009

What makes a group into a team?

The key difference is that in a team everyone is values equally, so no decision can be made that is not unanimous.

The question then is how do you get unanimous decisions?
My ex-Coworker, Rob Smyth, taught me "the decider protocol". This is very formal and does the job well, but it's the values behind it that are key.


  • Never allow 'no resistors' decision making.

  • Never allow group decision if any one person is not aligned.

  • Give the power to any individual to block any decision but ask them first 'what will it take to bring you in'?



It's all about valuing every individual in the team.

Thank Rob.

Wednesday, January 07, 2009

How to get TDD to stick

I found this an excellent summary of points on how to help TDD adoption.

Quick Summary :

  • Training

  • Patience

  • Measure Coverage

  • Instill Pride in clean code

  • Management's Understanding & Support

  • Pair Programming

  • Sharing Community

  • Coding Dojo

  • Reading Workshops

  • Periodic visits from a Coach

GitHub Projects