Coding Is Like Cooking

Collaborative coding can be a fantastic forum for getting stuff done at the same time as learning programming techniques and getting to know other developers. I’ve been enjoying the recent Samman Society Ensemble sessions where we work on our website sammancoaching.org. Some of the participants have asked how I set up the shared ensemble machine that we use, so I thought I’d write up some instructions.

When you’re coding in an ensemble, about 4-8 people together, you’d like to frequently switch who has the typing role, to keep engagement high and get the benefit of everyone’s input. For this to work well it helps if the switching cost is a close to zero as possible. The best solution I’ve found so far is actually to use AWS AppStream. You set up a cloud machine running Windows or Linux and install an IDE on it. Everyone can access this machine from a browser, no need to install any other tool or client. Switching typist is just a case of calling out who it is, and they can begin using the machine immediately. Everyone can see what they are doing in their browser.

There are a few disadvantages though. Many developers are used to working on a Mac and don’t know the keyboard shortcuts for Windows or Linux. Some people experience a significant amount of lag especially if they are in a different part of the planet to the cloud machine server hall. It’s not free to run one of these machines, either, but the costs are a matter of a dollar or two per session. Overall, I find the experience is pretty good for everyone and a good compromise for an open ensemble with participants from around the world with different tool preferences. We all have a browser and everyone can code in an IDE on Windows even if it’s not their usual preference.

Steps To Create an Ensemble Cloud Machine

If you haven’t used AWS much before it can be a bit daunting because there are so many options. Let me take you through the steps to set up a machine for your ensemble. First a disclaimer – I’m absolutely not an expert with AWS and I don’t know if I’m actually using this tool the way the tool vendor intends. I am sharing what works for me.

Once you’ve logged into your AWS account, you will want to open the “AppStream 2.0” console, you can search for it in the top left search box:

Inside AppStream there are lots of options on the left menu, for Stacks, Fleets, Images and more:

Honestly I really don’t know what most of those things are. The part I’ve used is ‘Images’, specifically the ‘ImageBuilder’ tab:

The button you want is the orange one on the right – ‘Launch Image Builder’ – that will let you create a cloud machine for your ensemble. This brings you into a four step process to define and launch your machine:

Step 1: Choose an image

There are a huge number of images to select from. I picked the most recent Windows Server image from the most recent base image. I’ve also had success with Amazon Linux images if you prefer that.

Step 2: Configure Image Builder

First you need to choose a name for your Image Builder – this needs to be unique and help you to remember what this machine is for. It’s hard to change this name later, so choose something descriptive. Then you need to select which size of machine to have:

For a developer machine my instinct is to get the most powerful box available, although having said that I’m not sure how much difference it actually makes in practice. The lag in the network is probably more significant to how you experience the performance.

Step 3 – Configure Network

The essential step here is to check the box ‘Enable default internet access’ – without that your machine will be pretty useless for programming. You also have to select a subnet:

In my AWS region there are three subnets so I chose a random one. I honestly don’t really know what difference it makes. I also accepted the default security group, again I’m not sure what that does.

Step 4 – Review and Create

This page lists all the options you already chose, so you can check if you missed anything. Make sure you really did select “Default Internet Access Enabled” then hit the orange button to create your image.

Now it should appear in your list of Image Builders. It might be in a ‘Pending’ state for a few minutes while it gets created. Eventually you should be able to select it and press “connect” to launch it in a new browser tab.

Select ‘Administrator’ to log in with full permissions to everything and open the Windows desktop:

What you have here is access to a full windows machine through your browser. There is a extra menu along the top that you might need sometimes for accessing the machine’s clipboard for example. Honestly I’ve just found it completely intuitive and like a normal windows machine just in a browser. This is where you go ahead and install your usual development tools like an IDE, Github desktop and so on.

Once your new machine is all set up and ready to use, you can share it with the other members of your ensemble. The only gotcha here is you can’t just give them the same url as you’ve got in your browser address field. You need to go back to the AWS console and create a streaming url:

When you’ve opened a video meeting with the other people in your ensemble, put this Streaming Url in the group chat and they should be able to connect to it straight away. I’ve found that this url only works for an hour or so after you create it so if it doesn’t work, try creating a fresh one. Be careful who you share this url with – they will have full access to your cloud machine. On the other hand, they won’t be able to access your AWS console so the damage will be limited to this machine, which you can always delete and start over.

After your session when you’ve finished coding and pushed all your changes, you’ll want to shut down your machine. The costs of running these machines is relatively small, but it adds up if you leave your machine running all the time. Select “Stop” from the ImageBuilder Action menu. For your next ensemble, you can use the same ImageBuilder. Start it and create a streaming url to share when it’s ready to use.

Get Involved

I’d like to thank Llewellyn Falco for introducing me to ImageBuilder and for being a regular attendee at the Samman Ensemble. We are a community of Technical Coaches who aim to spread useful resources and support one another. If you’d like to support our work on sammancoaching.org and get involved in our ensemble, please join my Patreon which will give you access to our Discord server. The #samman-ensemble channel has all the details of when and how to join our meetings. In any case I wish you every success with your own Ensemble meetings.

If you have comments on this post – perhaps you’ve found a better way of doing this – you can find me on social media as ’emilybache’.

I’ve been favouring an Approval Testing approach for many years now, since I find it pretty useful in many situations, particularly for acceptance tests. Not many people I meet know the term though, and even fewer know how to use the technique. Recently I’ve put together some small exercises – code katas – to help people to learn about it. I’ll be going through them at a couple of upcoming conference workshops, but for all you people who won’t be there in person, I’m publishing them on github as well.

I’ve got three katas set up now, Minesweeper, Yatzy and GildedRose. If you’ve done any of these katas before, you’ll probably have been using ordinary unit testing techniques. Hopefully by doing them again, with Approval Testing, you’ll learn a little about what’s different about this technique, and how it could be useful.

Before you can do the katas, you’ll need to install an approval testing tool. I’m one of the developers of TextTest, so that’s the tool I’ve set up right now. Below are some useful commands for a debian/ubuntu machine for installing it.

I’m still developing these exercises, and would like feedback about what you think of them. For example I have Python versions for all three, but only one has a Java version as yet. Do people want more translations? Do let me know how you get on, and what you think!

Installation instructions

You will need to have Python 2, and TextTest. (Unfortunately TextTest uses a GUI library that doesn’t support Python 3). For example:

$ sudo apt-get install python-pip
$ sudo pip install texttest


For more detailed instructions, and for other platforms see the texttest installation docs. For more general documentation, see the texttest website.

You need to have an editor and a diff tool configured for texttest to use. I recommend sublime text and meld. Install them like this:

$ sudo add-apt-repository ppa:webupd8team/sublime-text-3
$ sudo apt-get update
$ sudo apt-get install sublime-text-installer
$ sudo apt-get install meld


Then you need to configure texttest to use them:

$ cd
$ mkdir .texttest
$ touch .texttest/config
$ subl .texttest/config

Enter the following in that file, and save:

[view_program]
default:subl
[end]
[diff_program]
default:meld
[end]

For convenience, I also like to create an alias ‘tt’ for starting TextTest for these exercises. Change directory to one of the exercise repositories, then a ‘tt’ command should start the TextTest GUI and show the tests for that exercise. Define such an alias like this:

alias tt='texttest -d python -c .'


Two of the exercises start with a small test suite for you to build on. There should be instructions in the README file of each respective exercise, to help you to get going. If you really can’t work out what to do, have a look at the sample solutions and see if that helps. These are also on github: Minesweeper-sample-solution, Yatzy-sample-solution, GildedRose-sample-solution

I’ve been interested for a while in the relationship between TDD and good design for a while, and the  SOLID principles of Object Oriented Design in particular. I’ve got this set of 4 “Racing Car” exercises that I originally got from Luca Minudel, that I’ve done in coding dojos with lots of different groups. If you’ve never done them, I do recommend getting your editor out and having a go, at least at the first one. I think you get a much better understanding of the SOLID principles when you both know the theory, and have experienced them in actual code.

I find it interesting that in the starting code for each of the four Katas there are design flaws that make it awkward to write unit tests for the code. You can directly point to violations of one or more of the SOLID principles. In particular for the Dependency Inversion Principle, it seems to me there is a very direct link with testability. If you have a fixed dependency to a concrete class, that is always going to be harder to isolate for a unit test, and the Tyre Pressure exercise shows this quite clearly.

What bothers me about the 4 original exercises is that there are actually 5 SOLID principles, and none of them really has a problem with the Liskov Substitution Principle. So I have designed a new exercise! It’s called “Leaderboard” and I’ve put it in the same git repository as the other four.

I tried it out last week in a coding dojo with my colleagues at Pagero, and it seemed to work pretty well. The idea is that the Liskov principle violation means you can’t propely test the Leaderboard class with test data that only uses the base class “Driver”, you have to add tests using a “SelfDrivingCar”. (Ok, I confess, I’ve taken some liberties with what’s likely in formula 1 racing!) Liskov says that your client code (ie Leaderboard) shouldn’t need to know if it has been given a base class or a subclass, they should be totally substitutable. So again, I’m finding a link between testability and good design.

Currently the exercise is only available in Scala, Python and Java, so I’m very open to pull requests for translations into other programming languages. Do add a comment here or on github if you try my new Kata.

Recently I became intrigued with something Seb Rose said on his blog about ‘recycling’ tests. He talks about first producing a test for a ‘low fidelity’ version of the solution, and refining it as you learn better what the solution should look like. In a follow-up post he deals with some criticisms that other posters had of the technique, but actually seems to agree with Alistair Cockburn, that it’s probably not important enough a technique to need a name. I disagree, it’s a technique I use a lot, although most often when using an approval testing approach. I prefer to call it simply iterative development. A low fidelity version of the output that is gradually improved until the customer/product owner says “that’s what I want” is iterative development. It’s a very natural fit with approval testing – once the output is good enough to be approved, you check it in as a regression test that checks it never changes. It’s also a very natural fit for a problem where the solution is fundamentally visual, like printing a diamond. I also find it very helpful when the customer hasn’t exactly decided what they want. In this kata, it’s not such an issue, but in general, quickly putting out a low-fidelity version of what you think they want and then having a discussion about how to proceed can save you a lot of trouble.

The other posters seemed to be advocating a TDD approach where you find ‘universal truths’ about the problem and encode them in tests, so you never have to go back and revisit tests that you made pass earlier. In order to take small steps, you have to break down the problem into small pieces. Once you have identified a piece of the problem and solved it, it should stay solved as you carry on to the next piece. That seems to be what I would call ‘incremental’ development.

There’s a classic explaination of the difference between iterative and incremental that Jeff Patton came up with a few years ago using the Mona Lisa painting. It’s a good explaination, but I find experiencing abstract concepts like this in an actual coding problem can make a world of difference to how well you can reason about and apply them. So I thought it would be interesting to look at these two approaches to TDD using the Diamond Kata.

I have a regular coding dojo with my team these days, so a few weeks ago, I explained my thinking about incremental and iterative, showed them Jeff Patton’s picture, and asked them to do the kata one way or the other so we could compare. I probably didn’t explain it very well, because the discussion afterwards was quite inconclusive, and looking at their code, I didn’t think anyone had really managed to exclusively work one way or the other. So I decided to try to force them into it, by preparing the test cases in advance.

I came up with some starting code for the exercise, available here. I have two sets of unit tests, the first with a standard incremental approach, where you never delete any test cases. The second gets you to ‘recycle’ tests, and work more iteratively towards the final solution. In both cases, you are led through the problem in small steps. The first and last tests are the same, the difference is the route you take in between.

When I tried this exercise with my team, it went a lot better. I randomly assigned half the pairs to use the ‘iterative’ tests, and the rest to use ‘incremental’ tests. Then after about 45-55 minutes, I had them start over using the other tests. After another 45 minutes or so I stopped them and we had a group discussion comparing the approaches. I asked the ‘suggested questions for the retrospective‘ I’d prepared, and it seemed to work. Having test-driven the solution both ways, people could intelligently discuss the pros and cons of each approach, and reason about which situations might suit one or the other.

As Seb said, ‘recycling tests’ is a tool in your developer toolbox, and doing this kata might help you understand how to best use that tool. I’d love to hear from you if you try this excercise in your coding dojo, do leave a comment.

I’ve been working on this Kata “Gilded Rose” at a few different coding dojos lately. There is even a video of a session I did at the “Tampere Goes Agile” conference recently. In the video, you can see me talking about my Principles of Agile Test Automation, which I have just written about, and updated in my last blog post.

I think these test automation principles are useful to think about when you’re doing the Gilded Rose kata. The basic plot of the Kata is that you’ve just been hired to look after an existing system, and the customer wants a new feature. Having a look at the code, you can see you’re going to want to refactor it a little before adding the new feature, and before you do that, you’re going to want some automated tests.

So the first part of the Kata is to add automated tests to the existing code. You’ve got a requirements document the customer has given you, and you can use it to identify test cases. You’ve also got the code which you can read and execute and work out what it does. The customer is happily using the code in production right now, so you can assume that the behaviour it has is the behaviour they want to keep, whatever it says in the requirements document. (hint!)

Warning – spoilers lie ahead! You should probably try the Gilded Rose kata for yourself before reading on!

When I’ve done this exercise with various groups, I’ve spent a lot of time discussing with people how to make their test cases really readable, and express the requirements clearly, and at the same time useful as regression protection when refactoring the code later.

When you design a test suite you have two main aims – to help you understand what the code should do, (and what it does now), and protection from regression failures when you update it. It can be a bit tricky to do both with the same test suite. If you focus solely on describing the requirements in an executable way, you tend to miss edge cases and there are gaps in the regression protection. If you focus only on regression protection, you’ll spend time analysing the edge cases, and measuring code coverage to see how well you’re doing, but the test cases can become quite hard to read and understand.

You can see for yourself by comparing this test case by Bobby Johnson with this text-based approval test. (It was written by several people at a GothPy meeting). Bobby’s test case is extremely readable and expresses the requirements clearly. He’s done pretty well on the edge cases, but I think he’s missing one or two*. With the text-based approval tests, it’s not so easy to understand what the underlying business rules are, although the regression protection is very good.

When I do this kata with a group, we spend some time discussing the various test cases we’ve come up with, and showing them on the projector. When we did this last week at the Booster Conference, people commented that showing these different test cases had given them a better understanding of “readability” and “regression protection”, and many went on to improve their test suites.

Once you’re reasonably happy with your test suite, the next task is to do the refactoring and add the new feature. How useful are your test cases for regression protection? It’s very easy to make refactoring mistakes in this kata, and you will be testing your tests! You may discover while refactoring that there are more test cases that you want to add. Version control can be pretty useful, so you can run the new test cases against the original code.

There’s also an interesting restriction on your refactoring options – the “Item” class is owned by a nasty-sounding goblin and he doesn’t want you to change his code, so if you do, you have to be prepared for some serious consequences! When comparing refactored solutions at the end of the dojo, this is often an interesting discussion point – did you change the Item class? Is your new design so great that you’re prepared to argue with the goblin for it?!

I havn’t tried this, but I would actually like to try running the text-based approval test against all the refactored solutions at the end of the coding dojo, as input to the retrospective. I think this test covers all the edge cases very well, and would reveal any refactoring mistakes that were not caught by the tests people had developed themselves. That would be interesting feedback to have!

If you havn’t tried the Gilded Rose kata yourself, I do recommend it for practicing writing good test cases. I’d be happy to get a pull request from you if you want to translate the exercise into your favourite programming language, or you can do it in the original C#, as Bobby suggests.

If you’re interested in taking part in a coding dojo with me, I’ll be at several conferences later this year: ACCU in Bristol, XP2013 in Vienna and Test Automation Day in the Netherlands.

* I believe he’s missing a check that the quality of backstage passes doesn’t increase past 50