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!

Comments are closed