My second book is out ... kinda

To many of my colleagues and friends writing a book is at the top of the dream list or life goals. I have been very fortunate to have done that, but quite honestly I never even dreamt that I would do it. Or that someone thought that what I had to say was interesting enough to read it.
Maybe should have realised that after 500.000 views on this blog but still...

Ok, something really strange have now happened. I have been published again. The book is called Architect book which is even more strange, since I don't consider myself an architect. At least not on the levels that this book is about.

Some thoughts I got after talking with Woody Zuil

Yesterday I had the good fortune to have a chat with Woody Zuill over Skype. I was a really nice hour that just flew by, where we exchanged stories, ideas and had a few laughs.

Let me, as a side note, just say that I love that; just exchanging stories with people. I **always** learn new stuff and quite often stories from my own experience pop back into my memory.
This is the best part of conferences - meeting, interacting with others. That's what I miss the most, being a little sidestepped here in Indonesia. Praise the Lord for Skype and Twitter... ah well for the Internet too (although I'm not entirely sure He had any hands-on action on either of those inventions).

I just thought I summarise some of the things that I took away with me from our conversation.

I'm telling you for the last time - Marcus style

As most of you probably know I'm on my way to leave the country and do other type of work for a while. It's been a bumpy ride and we're actually still waiting for the work permits before we can leave. Any day now...

The last couple of weeks I've ended most of my commitments and different consultant contracts with my customers, but I don't have anything else to do... so I thought I'll make something up. Two things popped into my head:

• last year when I did some free presentations during a period between employments 
• and the fact that I don't want to come back in 3 years and just continue with the same material

From IMDB

Communication and rotting specifications

Over and over again I've seen the main gain from using specification by example emerge in the conversations you have around the specifications. I've even been known to tell people to just make sure to do the specifications on a whiteboard, take a photo of it and then don't use anymore of the practices. Just doing that will help an awful lot - I promise.

But lately I've come across a situation that have got me to think about the other end and what happens when we don't automate our scenarios. It's a continuity thing and it doesn't hang together.

Context injection of driver object in SpecFlow

SpecFlow is a wonderful tool. With a lot of hidden gems inside of it. I have been using and coding on it now for about 4 years and still I often forget about features and extension points that Gaspar and the community has put in there.

For example: did you know that there's an inversion of control framework built right into SpecFlow? Now you do and in this post I wanted to show you one way that you could use that feature to make your step definitions more maintainable.

I found this feature (again, i had heard about it before) when Gaspar mentioned it too me after my presentation at CukeUp 2013 and the usage is part of "Pushing the HOW down" which I wrote at length on before.

Cucumber / SpecFlow pro tip: push HOW down

I've just attended my first ever CukeUp conference, that is given by Skillsmatter each year. It's organized by Aslak Hellesoy that created Cucumber five years ago. It attracts a nice audience and community that share a lot of interest with me. For me it was extra fun to meet some of my heros and friends that I've followed and interacted with for quite some time (Matt Wynne and Gaspar Nagy to mention a few).

As always at conferences the learning is plentiful, even though my focus and nervousness was at my talk for a few hours. I especially like Matt Wynnes talk on Cucumber Pro Tips. There's two excellent books (The Cucumber Book and Cucumber recipes) that Matt and friends has written that contains loads of tips and pragmatic hands-on descriptions for any Cucumber user. His talk was an extract from the books.

The biggest thing that stuck in my mind was: push HOW down. He has been talking about that before (very funny here) to great effect in this excellent talk called "BDD - as it was meant to be done!". That point was then something that run through almost every talk (including my in fact) on the conference. At least the once that I heard so far.

Nancy.Testing - executable specifications through the full stack, in memory

When I showed the code from the last post to a colleague (@HugoHaggmark), he remarked: Nice - but that no unit test. And he's absolutely right.

A unit test should test a unit. The tests in the last post, and the test that Nancy.Testing allows us to easily write, flexes the whole stack of our application. In memory (which is super cool) but the full stack. That's no unit test.

This can still be VERY useful and in this post I'll show you how to put one of my favorite tools, SpecFlow, in front of what we wrote in the last post, to get an executable specification. Not only that - I'll do it in a manner that let's you swap it and hit the HTML page if you wanted to.

As the tradition calls - let's look in wonder at Nancy's silhouette.
If you came here and want to read up on what we have spoken about so far, the other posts in the series can be found here:

1. Intro to testing with Nancy
2. The Configurable bootstrapper
3. The Browser and Response objects 
4. Hat and shoeless testing with Simple.Data
5. SpecFlow and Nancy(this post)

In this post I'll introduce you, short - very short, to Specification by example and SpecFlow and some practices that makes automating your application ... bearable   

Pickles - generate SpecFlow documentation from MsBuild and PowerShell

If your doing specification by example or BDD you will soon realize that the tooling still points towards developers. WIth that I mean, that Cucumber and SpecFlow allows you to write your (executable) specifications in plain text, but you still check it into the source repository. This is of course a good thing since you'd want to version the specification with your code - but it also effectively hides it and keeps the spec out of reach for any non-developing member of the team.

Make no mistake here: the .feature-file is the master and original. That's how it should be since it's versioned together with the code. But we want everyone in the team to be able to read the specifications and see the test result easily. So we generate documentation off the .feature-files.

Pickles is a nice OSS framework that helps you solve this problem by generating documentation in a variety of formats from your specifications. This can be done in build scripts to keep the site up to date.

In this blog post I'll show you two easy ways to include the generation of an HTML-site from your features with Pickles: via PowerShell and via MSBuild. Let's start with the latter since I know that the best.

If you want to skip ahead you can download my code here.

TDD for kids

I had the opportunity to do something exciting yesterday. I was invited by my good friend Tristessa to teach a class on programming for her 13-14-year olds. She teaches at the International School of the Stockholm Region and had introduced them to programming just a couple of weeks before I came.

Since the first time I learned TDD I've always thought that it's a bit like thinking like a child; challenging the code, come up with more examples, try to break/understand your code and just being curious. Also - when TDD works it feels much like doing a puzzle - the next piece just comes to you in a nice way, another kid-activity.
So I thought I'd try to teach them TDD during an hour and a half.

Specification by example and Model based testing

My current client, Spotify, is really on forefront when it comes to good, solid engineering practices. There are inventors, leaders and all around great people where ever you look. So this gig has rendered me a lot of learnings, even in the areas that I don't touch much (being hired as an agile coach that reads coding people...).

So the first week or so heard the term "Model based testing" for the first time in my life. Investigating further I realised that it had strong similarities, technology-wise, with Specification by example. And there's some fundamental differences in the thinking and reason behind each approach too.

In this post I'll take a brief look to clear out the differences and similarities  I think that you can have great use for both approaches but you should probably know why or you'll find yourself fighting the tools and process for a better fit.

Should I add bugs-scenarios in my specification?

Right now I’m very impressed with the way that two my colleagues (Hugo Häggmark and Tobias Karlsson) has introduced BDD or rather Specification by example at their client. They have in a very short time gone from people not speaking to each other (analysts and developers) to collaboration around the scenarios of their specifications and demos running from those specs. I’m officially impressed!
Another colleague even threw together a speech engine integration that speak the SpecFlow features as they are run. Silly but …Coolness!
I got a very interesting and I think common question from Hugo that I thought I’ll share here, since the answer might be useful to others.

Hugo asked me if I update my specifications with any bugs found later on. Or if not – where do I keep them?

The reason for adding bugs in the same .feature file as the specification itself is of course compelling; over time you would get a long list of every change ever made to the specification. Every bug we’ve fixed and it’s always up-to-date and automatically verified against the system. Nice…. but are there some drawbacks?

What i learned from 'From User stories to Acceptance tests' with Gojko Adzic

I've just returned back home from a course. It's the first course I've attended in over a year and I'm always amazed how much you can learn in a short time; if the course and teacher is good and if you engage yourself in the course.

This time I knew it would be great since Gojko Adzic was the teacher and the subject was something that I find really interesting and useful - Specification by example.
I would be completely impossible to write down even a fraction of all the stuff I picked up during the two days but I thought I stop at the main points and write down what stood out for me.

As I've been following the BDD and Specification by example community intensively for two years I had quite a lot of knowledge on before hand - the main points I wanted to get out of this was practical tips on how to facilitate and handle the early phases of the lifetime of a specification done in this manner. Being a developer I have focused much on the later parts up to now.

Here are the main topics we discussed, but not in this order as I remember:

• Communicating with examples
• Key process patterns of successful teams
• What makes a good specification
• Fitting into a development process
• Adoption strategies and patterns

SpecFlow.Assist.Dynamic–maxing out with Simple.Data

SpecFlow.Assist.Dynamic came about from my own need when I wrote something that used Simple.Data. I saw the power and simplicity (duh!) in Simple.Data by using dynamics. And I started to thinking on how it could be used in SpecFlow to further simplify and shorten up the code in my steps.
This is the third and final post on SpecFlow.Assist.Dynamic. Again this is not the formal documentation. It can be found here. These are just my personal preferences and thoughts on how to use it. This time with Simple.Data. And it won’t be long.

SpecFlow.Assist.Dynamic–how to use it

This is the second post about SpecFlow.Assist.Dynamic – a little tool I wrote to help you write less code in your step definitions, and focus on the actual step instead of infrastructure. You can read the first post here – it explains little about what SpecFlow.Assist.Dynamic is.
In this post I’ll show you how some ways I use the dynamic features to and some tricks that you might not know about.
Again – this is not the documentation for SpecFlow.Assist.Dynamic – that can be found here.

Executable specification - the whole stack or not

This is really an age-old BDD question that pops up from time to time. Just now I got a question from an ex-colleague about it. A bit rephrased it something like this:

Should I test through the GUI all the way down to the database? How do you handle test-data in and test executing speed in those cases?

Many of us first got exposed to BDD tests through web applications and the way that we could test through the actual web page. We use tools like Watin, Selenium and other automation tools to accomplish that. We structure our automation code with page wrappers to get manageable automation code that can be re-used in our step definitions. For some BDD even implies automation (which is not at all the case).

On the "other" side we try to go through the whole stack and go through all the of the application and hit the database as it's supposed to be used by the application.
And that's when it strikes us - this thing with test-data is really hard. And a bit slow also.

Who writes the specification, now again?

There’s been a lot of buzz around Specification by example lately. At least in my networks and close to me. I hear it almost everyday at the office. A couple of days ago I was asked to do an introduction to the subject to a group of interested people. Striking also is that most people I hear talking about it is not developers (anymore) but rather business/requirements people and testers.

One question that I often get asked and that puzzles me is:

But who writes the specifications? Business people, developers or testers?

Maybe not exactly like that but something close too that. Actually I think the underlying intent is something else and has to do with ownership…

I have also discussed the topic with a few of my Twitter contacts that are involved in a project using Specification by example. In this post I’ll give my view on this – based on experience from a project last winter and from the book by Gojko Adzic.