Cyber-Dojo

/Cyber-Dojo

Reduce, Reuse, Recycle

From http://kids.niehs.nih.gov/explore/reduce/:
Three great ways YOU can eliminate waste and protect your environment!

Waste, and how we choose to handle it, affects our world’s environment—that’s YOUR environment. The environment is everything around you including the air, water, land, plants, and man-made things. And since by now you probably know that you need a healthy environment for your own health and happiness, you can understand why effective waste management is so important to YOU and everyone else. The waste we create has to be carefully controlled to be sure that it does not harm your environment and your health.
What exactly is “waste?”
Here’s a list (not exhaustive, by any means):

Code that doesn’t get used
Log entries that give no information
Comments that echo the code
Tests that you don’t understand
Continuous integration builds that aren’t consistently green
Estimates that you aren’t confident in

How can you help?
You can help by learning about and practicing the three R’s of waste management: Reduce, reuse, and recycle!

Reduce – do less. Don’t do something because that’s what you’ve always done. Do it because it adds value; because it helps you or a colleague or a customer; because it’s worth it.
Reuse – repetition kills. Maybe not today or tomorrow, but eventually. Death by a thousand cuts. Eliminate pointless repetition,  and go DRY (Don’t Repeat Yourself) for January. You’ll enjoy it so much, you’ll never go back.
Recycle – is there nothing to salvage? Really? When you find yourself building that same widget from scratch again, ask yourself “why didn’t I recycle the last version?” Was it too many implicit dependencies? Or was the granularity of your components not fine enough? Try building cohesive, decoupled components. Practice doing it – it gets easier.

By |January 12th, 2015|Agile, Cyber-Dojo, Musings, Practices|0 Comments

Diamond recycling (and painting yourself into a corner)

The post I wrote recently on recycling tests in TDD got quite a few responses. I’m going to take this opportunity to respond to some of the points that got raised.
Do we really need to use the term “recycling”?
The TDD cycle as popularly taught includes the instruction to “write a failing test”. The point of my article was to observe that there are two ways to do that:

write a new test that fails
change an existing, passing test to make it fail

It’s this second approach that I’m calling “recycling”. Alistair Cockburn says that “it’s a mystery this should need a name” and it probably doesn’t. However, I’ve regularly seen novice TDD-ers get into a mess when making the current test pass causes other test(s) to fail. Their safety net is compromised and they have a few options, none of which seem very appealing:

Roll back to last green
Comment out the failing test(s)
Modify the failing test(s) to make them pass again

Whichever way you go to get out, you’ll want to try to avoid painting yourself into a similar corner in future.
Why do tests that used to pass start failing?
Ron Jeffries suggests that this will only happen if the tests don’t “say something universally true about the problem and solution.” Several people (including George Dinwiddie and Sandro Mancuso) demonstrated that this problem can be solved by writing a series of tests that each say something “universally true.” However, to me, this seems like a similar approach to that recommended by Alistair Cockburn in his “Thinking Before Programming” post.

I’m a big fan of thinking before programming. In the courses that I deliver, I routinely prevent students from touching the keyboard until they’ve thought their way around the problem. But, it’s just not realistic to expect that […]

By |December 9th, 2014|Agile, BDD, Cyber-Dojo, TDD, Uncategorized|3 Comments

Recycling tests in TDD

The standard way that TDD is described is as Red-Green-Refactor:

Red: write a failing test
Green: get it to pass as quickly as possible
Refactor: improve the design, using the tests as a safety net
Repeat

TL;DR; I’ve found that step 1) might be better expressed as:

Red: write a failing test, or make an existing test fail

Print Diamond
One of the katas that I use in my TDD training is “Print Diamond”. The problem statement is quite simple:
Given a letter, print a diamond starting with ‘A’ with the supplied letter at the widest point.

For example: print-diamond ‘C’ prints

  A
 B B
C   C
 B B
  A
I’ve used Cyber-Dojo to demonstrate two different approaches so you can follow along with my example, but I recommend you try this kata on your own before reading further. .
Gorilla
The usual approach is to start with a test for the simple case where the diamond consists of just a single ‘A’:
> PrintDiamond(‘A’) 

A
The next test is usually for a proper diamond consisting of ‘A’ and ‘B’:
> PrintDiamond(‘B’)

 A
B B
 A
It’s easy enough to get this to pass by hardcoding the result. Then we move on to the letter ‘C’:
> PrintDiamond(‘C’)

  A
 B B
C   C
 B B
  A
 

The code is now screaming for us to refactor it, but to keep all the tests passing most people try to solve the entire problem at once. That’s hard, because we’ll need to cope with multiple lines, varying indentation, and repeated characters with a varying number of spaces between them.
Moose
The approach that I’ve been playing with is to start as usual, with the simplest case:
> PrintDiamond(‘A’) 

A
 

For the second test, however, we start by decomposing the diamond problem into […]

By |November 23rd, 2014|BDD, Cyber-Dojo, Practices, TDD|12 Comments

Using SpecFlow on Mono from the command line

SpecFlow is the open source port of Cucumber for folk developing under .NET. It has been compatible with Mono (the open source, cross platform implementation of the .NET framework) for several years, but most of the documentation talks about using it from within the MonoDevelop IDE. I wanted to offer SpecFlow as one of the options in Cyber-Dojo and, since the Cyber-Dojo IDE is your browser, I was looking for a way to make it all happen from the command line.

Cyber-Dojo already offers C#/NUnit as an option, so I used this as my starting point for making SpecFlow available. I came up with a list of tasks:

Install SpecFlow
Generate ‘code-behind’ each feature file
Include generated code in compilation

Install SpecFlow
I found an interesting website that had detailed instructions for installing SpecFlow on Mono. There don’t seem to be any handy ‘apt-get’ packages, so it is basically a process of downloading the binaries and installing them in the GAC, for example:

  gacutil -i TechTalk.SpecFlow.dll
Generate ‘code-behind’ each feature file
SpecFlow ships with a command line utility, specflow.exe. I tried following the instructions from the article that had helped me with the installation, but they didn’t work for me. I ended up invoking the utility directly:

  mono ./specflow.exe

Running specflow.exe like this lists the operations that the utility provides, from which I chose ‘generateall’, because (according to the documentation) it should do exactly what I want:
re-generate all outdated unit test classes based on the feature file.
Unfortunately it needs a Visual Studio project file (csproj) as input, and since we’re not using Visual Studio we don’t have one. This led me to insert a fourth item in my task list: “Create csproj file”
Create csproj file
I started with an MSDN article that describes creating a minimal […]

By |October 5th, 2014|BDD, Cyber-Dojo, Practices, TDD, Unit testing|1 Comment