Phillip Trelford's Array

POKE 36879,255

TickSpec: One Year On

It’s coming up to the first anniversary for TickSpec, a library and framework designed to support Behaviour Driven Development (BDD).

The first check-in was on the 30th August 2010:

Barebones BDD framework that supports a subset of the Gherkin language (Given,When,Then).

Since then the original aims of the project have been met, i.e create a lightweight parser library and invocation framework with first class support for F#, C# and integration with the major unit testing frameworks.

At the start of the project the focus was on core features, e.g.:

Added dynamic code generation so that you can step through feature files with the debugger

Added table support

Added Tags support

After the core features came a set of project examples for major unit testing frameworks including NUnit, xUnit, MbUnit and the Silverlight Unit Testing Framework.

TickSpecSLUT

Then with a number of projects using TickSpec in production, it was time to get out and about to talk with people about BDD and demonstrate how Acceptance Tests can be automated with TickSpec. Most recently a Live Meeting in June for the F# Community:


 

Over the last year I’ve been fortunate to attend and speak at quite a few related conferences and community events:

And there’s more on the horizon:

    OSJCukeyFSharp

And there are plenty more related articles here on this blog:

Thanks to recent user feedback on TickSpec there is also now a New Release with:

  • 100x Performance Increase (thanks Jon Harrop)
  • Improved error messages (thanks Martin Trojer)
  • A better C# debug experience (thanks James Banton)

In summary, a year on TickSpec has become a mature open source library and framework for automating acceptance tests on the .Net framework.


Disclaimer

Please bare in mind that a BDD framework is a means to an end and not the end in itself.

In the words of Gojko Adzic from his excellent new book Specification By Example (chapter 4, pages 46-47):

Don’t make test automation the end goal

this approach often leads to tests that are too technical

Don’t focus on a tool

this approach often ends up with programmers using a non-technical tool, intended for executable specifications, to manage technical, developer-orientated tests. This is a waste of time.

And Liz Keogh’s wise words in the article Step Away from the Tools:

BDD isn’t about the tools.

You don’t need BDD tools to do BDD.

Start by having conversations, engaging both testers and business stakeholders

If you can’t have those conversations, stop. You can’t do BDD

BuyerUser Beware!

Progressive F# Tutorials November 2011

At first glance it sounds a little like a set of rock music tutorials, based on a genre from the late 60s and early 70s performed and in a specific key. However on closer inspection the Progressive F# Tutorials seem to have a lot more to do with learning F#, an exciting new multi-paradigm programming language that’s part of Visual Studio 2010.

progfsharpbanner

Could there still be a tenuous link with Progressive Rock?

Jon Covach, once described in Contemporary Music Review, Progressive Rock as:

"a mostly British attempt to elevate rock music to new levels of artistic credibility."

Phil Trelford described in this very article, the Progressive F# Tutorials as:

“a mostly British attempt to elevate F# to new levels of developer understanding.”

Here’s How!

First, assemble of some of the big names in the F# world:

Second, mix in 2 tracks of F# goodness:

  • Track 1: Practical F# from the beginning
    suitable for programmers with C# or VB.Net experience
  • Track 2: F# in the Enterprise
    suitable those with F# experience or advanced C# and VB.Net developers
  • Each tutorial will be approximately 3 hours long and will have a very practical focus (i.e. bring your laptop or netbook). The aim of the conference is to have you programming F# confidently by the time you leave.

Third, help you shift into a Functional mind set with a Programming with the Stars session, where developers explain how they solve problems, featuring:

Finally, kick the whole event of with a look at what’s new in F# vNext!

Hope to see you on November 3rd..4th.

C# Light Syntax

Java and C# have somewhat reduced the ceremony over C++ by not requiring header files, but they are still both quite verbose. What would it look like if C# went one step further and adopted a light syntax like Python, where white space is significant?

Let’s start with an immutable Person class implemented in idiomatic C#:

namespace MyCompany.MyProduct
{
    public class Person
    {
        public Person(string name, int age)
        {
            _name = name;
            _age = age;
        }

        private readonly string _name;
        private readonly int _age;

        /// <summary>
        /// Full name
        /// </summary>
        public string Name
        {
            get { return _name; }
        }

        /// <summary>
        /// Age in years
        /// </summary>
        public int Age
        {
            get { return _age; }
        }
    }
}

Now lets extract the namespace, public modifiers, return statements and curly braces:

class Person

    Person(string name, int age)    
        _name = name;
        _age = age;    

    private readonly string _name;
    private readonly int _age;

    /// <summary>
    /// Full name
    /// </summary>
    string Name 
        get _name;    

    /// <summary>
    /// Age in years
    /// </summary>
    int Age 
        get _age;

Not too bad 30+ lines reduced to 20! But we could do more, what if triple slash comments were assumed to be summary text by default:

class Person

    Person(string name, int age)    
        _name = name;
        _age = age;    

    private readonly string _name;
    private readonly int _age;

    /// Full name
    string Name 
        get _name;    

    /// Age in years   
    int Age 
        get _age;

16 lines and dare I say it, no less readable!

Perhaps we could merge the class declaration and constructor to define a closure over the class members?

class Person(string name, int age)           

    /// Full name
    string Name 
        get name;    

    /// Age in years   
    int Age 
        get age;

9 lines and some might say the intent is actually clearer now!

Which incidentally isn’t a million miles away from what we can do with an F# class today:

type Person(name:string,age:int) =

    /// Full name
    member person.Name = name

    /// Age in years
    member person.Age = age
 

Or we could go one step further and take it down to just 1 line with an F# record:

type Person = { Name:string; Age:int }

It’s probably worth mentioning that both the F# class and record types can be consumed as classes from C# in exactly the same way as the original C# example.

So, if like me you’re a little bored of reading and writing verbose C# class declarations then F# might just be your thing!