duplication – Tea-Driven Development https://blog.mattwynne.net Matt Wynne taking it one tea at a time Wed, 21 Aug 2019 13:02:06 +0000 en-US hourly 1 https://wordpress.org/?v=6.2 165828820 DRY up your Cucumber Steps https://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/ https://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/#comments Fri, 14 Nov 2008 18:40:49 +0000 http://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/ Continue reading "DRY up your Cucumber Steps"

]]>
Update (13th Jume 2012): This is an old, old post that still gets a lot of hits. I don’t recommend this practice anymore. Instead, I recommend composing Ruby methods that carry out these actions. For more details, please see The Cucumber Book.

A while back, I asked the Cucumber team for the ability to call in the steps of one scenario from another.

The canonical example of this is the ‘log in’ scenario:

Scenario: User logs in
  Given there is a User whose username is "matt"
  And I follow "log in"
  And I enter "matt" in "username"
  And I enter the User's password in "password"
  And I press "Log In"
  Then I should be logged in
  And I should see the text "Hello matt"

Phew. Now obviously I don’t want all this noise in the scenario every time I specify behaviour that requires a logged in user. I want to write something like this:

Scenario: User views their dashboard
  Given I am logged in
  And I follow the "dashboard" link
  Then I should see "This is your dashboard"

Thanks to the fabulous creativity of the Cucumber community, this is now possible. It’s also highly recommended, as it’s a great way to help you keep your step files tidy and DRY of excess duplication.

Given /I am logged in/ do
  steps %{
    Given there is a User
    When I follow "log in"
    And I enter "#{User.first.username}" in "username"
    And I enter "#{User.first.password}" in "password"
    And I press "Log In"
  }
end

I’m doing this more and more now – writing simple ‘building block’ steps and assembling them to make steps that read nicely and make sense to the stakeholders.

]]>
https://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/feed/ 13 89
“Total Programming” and the XP Team https://blog.mattwynne.net/2008/11/08/total-programming-and-the-xp-team/ https://blog.mattwynne.net/2008/11/08/total-programming-and-the-xp-team/#comments Sat, 08 Nov 2008 20:13:50 +0000 http://blog.mattwynne.net/2008/11/08/total-programming-and-the-xp-team/ Continue reading "“Total Programming” and the XP Team"

]]>
Pair programming brings a great many benefits to a team that’s truly mastered it.

Those of us who are lucky enough to have experienced working on a really effective XP team know about that almost magical thing that starts to happen when the barriers between different members of the team break down, egos and code ownership are cast aside, and the team starts to evolve the codebase as one, mighty, coding machine. It’s truly a joy to be a part of, or even just to watch.

dutch-team-78

When I worked at the BBC, we tried various experiments with different styles of pairing and retrospected on them regularly to figure out what was working. We went from the extreme of the same pair working together right through a whole story, sometimes staying together for a whole iteration, to switching up pairs several times a day. In the end, of course, we found a sweet spot somewhere in the middle, and seemed to know intuitively when a pair was going stale and needed a fresh injection of energy by changing up the members.

Compare this ideal with this description of “Total Football” (that’s ‘Soccer’ for those of you speak US English!)

“Total Football” is the label for an influential theory of tactical association football in which any player can take over the role of any other player in the team. It was pioneered by Dutch football club Ajax Amsterdam.
In Total Football, a player who moves out of his position is replaced by another from his team, thus retaining the team’s intended organizational structure. In this fluid system, no player > is fixed in his nominal role; anyone can be successively an attacker, a midfielder and a defender.

Regularly rotated pairs of programmers are essential in developing this kind of fluid self-organisation within a development team. While specialisation may become important for larger teams, there’s no doubt that keeping the whole team familiar with the whole codebase for as long as possible brings huge benefits.

For me, the biggest, and often the least mentioned of these benefits is that the team develops a kind of shared consciousness about the code and how they conventionally like to work with it. Not only does this mean the team can move extremely quickly, knowing exactly where to find something and how best to hack on it, but it is a stake through duplication’s dark and twisted heart: “Didn’t we work on something a bit like this last week, Brett?”. Once a team starts to think and communicate together this effectively, code re-use goes through the roof as common problems are solved in consistent ways, patterns emerge and are factored out for re-use.

You can probably tell, I’m a massive fan of pair programming, mainly because I absolutely love being this effective in my day-to-day work. How about you, loyal reader? What are your experiences with pair programming? Have you tried it? How was it for you?

]]>
https://blog.mattwynne.net/2008/11/08/total-programming-and-the-xp-team/feed/ 3 87