Posts filed under ‘People’

Cucumber And SpecFlow Aren’t Test Tools

…. although it’s certainly possible to use them that way. But why would one such a thing, de-tuning what is really a rather nice way of getting product owners and developers to talk to each other?

At least that’s what I think at the current state of my exploration of the world of Given-When-Then.

It comes down to trust and boredom:

Feature: Our new application

Scenario: Users use the system
Given that we want this application to work well
And that there are requirements
When you build it
Then it should meet the requirements
And delight users.

This is the ultimate trust: The spec is short and sweet. It lacks specifics, but there is hope that the CEO will not get bored when reading it: The buck stops with her if requirements are not met and users are not delighted. Technical detail for which she has no time is omitted. Actionable success criteria are at least outlined (“Ask Larry if we’re delighting users yet. Have Malcolm’s folks see if we are meeting requirements.”)

Unfortunately, it’s not very helpful. So let’s look at paranoia instead:

Feature: Create Bus Stop
    We need to be able to enter bus stops into the
    system     so we can have busses arriving at them. 
    There must be no duplicate bus stop numbers and 
    no two stops must be in the same place.

Scenario: Bus stop creation succeeds
    Given there are the following existing bus stops:

        | Bus Stop     | Latitude   | Longitude   |
        | 12111 | 49 20' 0'' | 122 1' 23'' |

    And I enter bus stop no. 44444, lat. 50 1' 12'', long. 122 23' 02'' into the 'Create Stop' form
    When I click 'Create'
    Then the stop with no. 44444, lat. 50 1' 12'', long. 122 23' 02'' is in the list of bus stops. 

Scenario: Cannot create a stop if the stop number already exists
    Given there are the following existing bus stops:

        | Bus Stop     | Latitude   | Longitude   |
        | 12111 | 49 20' 0'' | 122 1' 23'' |

    And I enter bus stop no. 12111, lat. 50 1' 12'', long. 122 23' 02'' into the 'Create Stop' form
    When I click 'Create'
    Then the error message "A stop with this number already exists." appears.
    And the stop with no. 12111, lat. 50 1' 12'', long. 122 23' 02'' is not in the list of bus stops.

Scenario: Cannot create a stop if the stop is in the same location as an existing stop
    Given there are the following existing bus stops:

        | Bus Stop     | Latitude   | Longitude   |
        | 12111 | 49 20' 0'' | 122 1' 23'' |

    And I enter bus stop no. 10000, lat. 49 20' 0'', long. 122 1' 23'' into the 'Create Stop' form
    When I click 'Create'
    Then the error message "A stop already exists in this location." appears.
    And the stop with no. 12111, lat. 50 1' 12'', long. 122 23' 02'' is not in the list of bus stops.

This is great for testers:

  • It’s easy to add new tests which re-use existing step definitions. For example, setting up test data for new scenarios with “Given there are the following bus stops” is straightforward.
  • Lots of parameters are available to write edge test cases. What happens if I enter bus stop no.  –9999999999999999999, lat.  5000 –12’ 0;;, long. 0 0’ 0’’? We can find out – plenty of opportunity to add scenarios without the need for a whole lot of step definition coding.

Unfortunately, it’s boring and obscure:

  • Too much detail. Who has the time? Come to the point.
  • How can I tell how this fits into the big picture? Are we missing something?
  • It’s repetitive and makes your eyes glaze over.
  • Ze Inglisch kann be bat.  “Given there are the following existing bus stops”, followed by a table of only one?

Alternatively, one might tell a story:

Feature: Bus stop creation
    We need to be able to enter bus stops into the
    system so we can have busses arriving at them. 
    There must be no duplicate bus stop numbers and 
    no two stops must be in the same place.

Scenario: Successful bus stop creation
    Given that I enter a bus stop number and location
    And the bus stop number doesn't exist yet
    And there is no other bus stop in the same location
    When I try to create the bus stop
    Then the bus stop should appear in the list of stops.

Scenario: Bus stop number already exists
    Given that I enter a bus stop number and location
    But the bus stop number already exists
    When I try to create the bus stop
    Then an error message appears
    And the bus stop is not created.

Scenario: A Bus stop already exists in this location
    Given that I enter a bus stop number and location
    But there is already a bus stop in this location
    When I try to create the bus stop
    Then an error message appears
    And the bus stop is not created.

Testers won’t be happy:

  • Not possible to write comprehensive tests without new step definition code.
  • Too much ambiguity. What exactly is a “location”?

But it’s less boring:

  • It’s possible to read it like a story about what the system can do and what rules it has, without excessive repetition which obscures the big picture requirements and business value.

So what is the point of the story if it doesn’t give us decent tests? From “The Cucumber Book”:

“Cucumber might just seem like a testing tool, but at its heart it’s really a collaboration tool.”

For example:

“Looks like we’ve got the the requirement of no two bus stops  in the same location covered. I just thought of it – what if somebody enters a stop which is very close to an existing one?”

“Hmm. Let me have a look how we implemented that. Here it is – We check for an exact match in latitude and longitude:”

[Given(@"there is already a bus stop in this location")]
public void GivenThereIsAlreadyABusStopInThisLocation()
{
    CreateBusStopInSameLocationAs(BusStopDataEnteredByUser());            
}

private void CreateBusStopInSameLocationAs(BusStop busStop)
{
    const string stopNumberWhichDoesntExistYet = "99999";
    var existingStop = new BusStop()
        {
            StopNumber = stopNumberWhichDoesntExistYet,
            LatDegrees = busStop.LatDegrees,
            LatMinutes = busStop.LatMinutes,
            LongDegrees = busStop.LongDegrees,
            LongMinutes = busStop.LongMinutes
        };
    _busStopController.Create(existingStop);
}

“Could we change that so that  we can’t have a second bus stop within 30 meters of an existing one?”

“OK…”

Arguably, this conversation might not have happened without the story. We are collaborating more because the story is told in a way that’s accessible to all participants:

The Given-When-Then story is executable documentation, accessible to non-technical stakeholders as a means of seeing what the application can and cannot do.

The tests exercise the code, telling the  “how we do it” part of the story: Click this button, fill in that field, call the method, …

The Step Definitions (… or fixtures, etc.) could be seen as a way of telling how developers interpreted the story. That’s the part I could never figure out before: They aren’t a specification. They aren’t tests. They sort of glue the specification and the tests together, but the usual reason why they need to change seems odd: They need to be modified because either the story or the underlying tests changed. Why did they change? Presumably it was because:

  • Product owners changed the story of what the system can do in the Given-When-Then specification.
  • Developers changed the way they interpreted the specification: They renamed classes/methods/variables, they changed method signatures or behaviours, etc.

In other words, the domain language evolved. New concepts were added to the ubiquitous language, existing ones were better understood or changed.

From a collaboration standpoint, “step definitions” could be seen as an interpretation layer, a  “We Thought You Meant…”

Given readable code, consistent levels of abstraction and good naming developers and product owners might look at this and get a better understanding of  what is being built.

The value compared to having requirement docs in Word and just doing TDD style tests comes from relating requirements to implementation in a way which is accessible to business stakeholders, encourages conversation and is executable at the same time:

  • Given-when-then (What)
  • Step definitions  (“… Thought you meant…”)
  • Tests (How)

Anyway, a story about stories. Given less boredom and more trust when we build the app then we’ll get better software?

April 2, 2012 at 6:31 am 2 comments

The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It

Gave this presentation at this year’s Agile Vancouver conference.   Thank you everybody who attended – much food for thought and ideas in the discussions afterwards. The slides can be found at http://www.slideshare.net/rreppel/why-theyarentbuyingyouragileandhowtomakethemloveit .

If Agile works, why isn’t everyone doing it? Or, as Agile has become fashionable of late, why all the lip service without the expected amount of real change? This talk makes the argument that it comes down to trust and presents tools and examples for building and keeping trust. The focus is on how to project plan and design applications in a way which, wherever possible, avoids putting stakeholders into situations which require trust in the first place.

In a nutshell:

  • Own your stack. If possible, use one co-located team per bounded context and architect systems in a way which allows developers to easily write end-to-end tests and do releases.
  • Make sure you and your stakeholders have a shared definition of what success looks like. Are you measuring the same things?  For example:  “Diligence in planning” vs. “Adaptability when responding to new knowledge”:  In light of the former, finding something unplanned-for is failure. For the latter, it’s learning and success is measured by how well the new knowledge is assimilated.

November 7, 2011 at 7:24 am Leave a comment

Entrepreneurs: Saving The Odd Million

OK, a disclaimer: I’m a geek. I have learned to do some business-speak and googled the odd idea about how it’s done, but my instincts are questionable: I haven’t made my first million and therefore I’m not really qualified to give advice to those who have.

My specialty is to deliver software applications. Very often, situations present themselves like this:

  • We are a team of developers. We have finite capacity and Conway’s Law rules us with an iron fist. By  Seth Godin’s   “hunters and farmers” analogy, we are farmers: We try to leave no stone unturned to make sure we build the right thing at the right time. In the face of (inevitably) changing requirements and (inevitable) learning-as-you-go about how the system should be implemented, we do our best to manage technical debt. It’s in our nature to strive for certainty, but we have a hard time getting it.
  • We build applications for hunters: What we produce is a means to an end, to exploit a market opportunity, satisfy demand, help run the business (… a hunting tool of the trade …) more effectively.  The hunter needs commitment: When is it going to be done? How much will it cost?

The hunter’s need for commitment and the farmer’s difficulty to give it in the face of (inevitable) change are a culture clash which dominates our industry. Untold millions are spent every day on experiments which prove over and over again that preventing (inevitable) change through waterfall project management and avoiding (inevitable) learning-as-you-go during project development is not the answer: It has a tendency to result in inflexible, expensive to build and dull end products. You can fairly hear the hunter’s howl of frustration:

“It’s a thinking machine, people! It’s the marvel of the age, one of the cleverest things ever! Why is it so #!!@$!! hard to make it do something smart……!”

The answer to this is a farmer’s answer which makes him howl louder still:

Building non-trivial software requires an incompletely understood balancing act between a complex set of trade-offs involving social interactions, technological factors and resource constraints. Working smarter beats working harder every time. Debate over what is meant by “smarter” is ongoing.

The current fashion for Agile and Lean delivery approaches looks promising and I remain cautiously optimistic that we’ll figure it out in the next 50 to 100 years.

In the meantime, in an extreme case of semantic diffusion, let’s see if we can hijack the concept of a balance sheet to identify a set of mutual commitments between entrepreneur-hunters and farmer-developers which, when in balance and taken with a grain of salt, might help to increase the chances of success:

Hunter-Entrepreneur Farmer-Developers
The team will not miss deadlines, but scope of what is delivered for the deadline is up to the development team. We will not miss deadlines. we will do frequent releases.
I will ensure that features are clearly prioritized. We will deliver the highest priority features first.
I will do my utmost to ensure that requirements are as clear and simple as possible. I will assist the team by minimizing scope. We will minimize cost/effort by adhering to the YAGNI principle as much as possible.
I will ensure that the team has direct contact with end users to the greatest extent possible. We will communicate clearly and skillfully, assisting management in reconciling conflicting user opinions, priorities and requirements and limiting scope.
I will not override technical decisions without clearly understanding the consequences in terms of technical debt. We make all technical decisions with business priorities and the quality of the end user experience as the most important criteria.
I will support the development team in their efforts to adhere to the principles stated in the Agile Manifesto. We will adhere to the principles stated in the Agile Manifesto.

 

It’s far from ideal, but maybe it could save the odd million?  Anything which results in less chaos and more predictability would be good …   Spoken like a true farmer?

February 27, 2010 at 3:22 pm 1 comment

Software Craftsmanship: Coding Under The Influence

Started following the software_craftsmanship group where there is a thread on vouching mechanisms and their inherent problem.  Who is an apprentice? What makes you a journeyman? A master? It seems clear that in terms of supply and demand, software development mastery is closely related to intelligence: Many of us are fairly certain that we have a lot of it. Ranking others “Ebay style” and being ranked ourselves is both highly subjective and somewhat discomfiting: What is our focus? Building great software or trying not to be voted off the island?

So what is a constructive way of telling what makes craftsmen tick? Who did they learn from? Who influenced their thinking? It seems that the question of lineage, in the Eastern tradition of acolytes and adepts, is of some significance.

In a fine display of craftsmanship, James Martin hits the nail on the head:

As an aspiring craftsman, I’d like to know who are the people that are well respected by other craftsmen because of something they’ve actually done, so I know who’s shoulders to stand on when I’m learning and honing my craft.

Fred Ballard tells us about Erdös numbers, an interesting concept.

From the Wikipedia entry:

The Erdős number (Hungarian pronunciation: [ˈɛrdøːʃ]) describes the "collaborative distance" between a person and mathematician Paul Erdős, as measured by authorship of mathematical papers.

Can we develop our own measure of “collaborative distance”? The mind boggles, recalls a long-ago beer-sodden night with Greg Young and Adam D. and does some storyboarding in commemoration:

Click to enlarge.

codingundertheinfluence

January 31, 2010 at 4:35 pm Leave a comment

Key Developer Skills: Renaissance Man And The Case For Voluntary Ignorance

Looking at resumes this weekend, trying to see good developers among the Currently Fashionable Acronyms (CFAs…?) and I can’t.  Assorted certifications can be found and new-fangled terms like “Agile” and “Scrum” have made an appearance but they seem to obscure more than they tell. It appears that we are all trapped in some kind of techno-fetish wonderland: Good evidence that he or she is a wizard with generics, dreams in lambdas and knows that a “sprint” is about spending long hours sitting on your butt instead of running trumps all else.

(more…)

January 24, 2010 at 10:12 am 1 comment

TechDays 2009 Impressions: Dialog Refactors Mind

Thank you all who attended the “Refactoring for Fun & Profit” presentation. I had fun preparing it and learned a lot from some very smart people, not all of it about technology.

To me, TechDays was a reminder that nothing in the TwitterFacebookBlogospheroVerse comes close to old-fashioned human contact. It’s as if face-to-face dialog is the ultimate in full-immersion learning by experience. Preparing presentations for the Developer Foundations track was a lot of back-and-forth of ideas, suggestions, banter. Special thanks to Justice, Adam D., Stefan, Adam C.  and Peter – you guys rock! Thanks also to John Bristowe for making the track possible.

There were really good conversations after the sessions and at ALT.NET Vancouver’s Open Space at Mooses’s Down Under on Tuesday.

Dialog as "codeless refactoring”, anyone?  Shape shared understanding well enough in advance of implementing and maybe we’ll re-write a lot less? Nah. Give me a corner with a keyboard and screen. Go away. I’m coding.

September 17, 2009 at 4:16 pm Leave a comment


Recent Posts

Twitter

   @robertreppel

Follow

Get every new post delivered to your Inbox.