Coding dojo: Test Driven Development

Notas sobre el curso Coding dojo: Test Driven Development de Emily Bache publicado en Pluralsight.

El curso trata sobre los Coding Dojos. Los Coding Dojos son una gran herramienta para aprender y enseñar a programar, así como para aprender y enseñar TDD.

Así que, ¿qué tal si te animas a ser el anfitrión de un Global Day of Code Retreat?

Reseña del curso

El curso comienza con conceptos básicos (parece ser que es la norma en los cursos de Pluralsight) sobre TDD, tests, diferentes juegos para programar,…

Emily explica los diferentes juegos o técnicas existentes para practicar mientras uno programa, para aprender a programar o para aprender a resolver problemas.

La parte más interesante es cuando la autora muestra cómo ser el organizador de 5 Coding Dojos o más, con sus objetivos, herramientas, katas, juegos,…

¿Qué he aprendido?

Emily añade una nueva fase a TDD, fase adicional a las ya típicas 3: rojo, verde, refactor (azul). Ella le llama revisión. En esta fase uno piensa sobre una lista de tests (para hacer desarrollo incremental), decide qué test se podría escribir después,…

Randori en parejas: que es cómo funcionan casi todos los Code Retreats y Coding Dojos

Notes (English)

Sample series of Coding Dojos

Component skills for TDD:

  1. Designing test cases
  2. Designing clean code
  3. Driving development with tests
  4. Refactoring safely

All of them are interrelated to each other. Coding dojos are designed to practice one of them, to focus on one of them. Is better to focus on just one of them than to practice all of them at the same time.

TDD phases

Emiliy adds a new phase to TDD, the overview phase:

  1. Overview
    • Analyse problem
    • Test list
    • Guiding test
  2. Red
    • Declare & name
    • Arrange-Act-Assert
    • Satisfy compiler
  3. Green
    • Implement solution
    • Fake it
    • Start over
  4. Refactor
    • Remove fake
    • Remove code smell
    • (no new functionality)
    • Note new test cases

First coding dojo

Meeting outline:

You’ll practice Driving development with tests skill

Refactoring dojo


Writing good tests


Clean and SOLID code


Incremental development


Course transcript

What is a Coding Dojo and why would I want to hold one?

What is a Coding Dojo?

Hello, this is Emily Bache for Pluralsight. This course is designed to be a practical guide to creating a space where good programmers can become great programmers. I imagine that you are already an experienced programmer. Perhaps even a team lead. You want to improve your practical coding skills, and the skills of the people around you. And thinking of things like writing clean code, following design principles, writing tests and refactoring. Perhaps not everyone in your team understands how important these things are, and you’d like to encourage some change. Starting a coding dojo could be just what you need. I’ve been leading these kinds of meetings for several years now. Generally, I’ve found that participants come away with fresh ideas, improved coding skills, and they enjoy the experience. Have you learnt a practical skill recently? Perhaps outside of work. And musical instrument? How to paint, speak a foreign or martial artist. With all of those things, I expect you would have joined some kind of group where you practice together with others. If you wanted to learn karate, you go along to the local dojo, meet with others who also want to learn and practice. So that’s why this is called the coding dojo. Because coding is a practical skill that you can practice in a group. So you get together, a bunch of coders in a meeting room, for a couple of hours or so and work on a coding exercise together. The exercise is designed to be fun and stretch your skills just the right amount. It’s a concrete piece of code that allows you to discuss with your group, issues around design, coding tools, refactoring, how to write tests. All these kinds practical coding skills and test room development in particular. The idea is, that just like with a karate dojo, you’ll want to meet and hold your coding dojo regularly. Perhaps every iteration, or every month. During the meeting you practice skills that you can use in your production code later, and then after the meeting, the coding dojo becomes a forum where you and your team can discuss ideas and problems and improve your coding skills. Now of course it’s great fun to get together any group of programmers and just hack on something. That’s great. But for it to be a coding dojo, you need a little bit more structure than that. You need to hold an introduction. Decide what topic it is you’re trying to learn about, and your retrospective where you discuss where you learned and where to go with the next meeting. In a dojo you always write tests as well as code, and you show your working. Of course we’re interested in your solution to the coding exercise. But not only that we want to see how you solved it. Then also needs to be someone there with a moderator or facilitator role, keeping the discussions on track, and encouraging learning to happen. So that’s what this course is about. It’s how you as a programmer can get a group together and start a dojo. It’s a fun and rewarding way to learn.

Course and Module Overview

This course is divided into modules, and I’d like to give you an overview. What you’re watching now is the first module. And I’ve already talked a little about what a coding dojo is, and the rest of the module goes into more detail about what you do and why. So the next module is more specifically about test driven development and how you can go about become an expert at it. Then I have a module on collaborative games for programmers. These are fun activities that you can do in your dojo as part of your practice and improving your skills together. To get you started with your dojo, the fourth module outlines a series of meetings that you could hold with concrete suggestions for code katas to tackle. The last two modules are specifically for the dojo organizer. Practical advice about what to do to prepare in advance of a dojo meeting. And what you can do during the meeting to make it the best possible learning environment. In the last module, I’ll demonstrate the tool cyber dojo, which can support you with feedback when you’re learning to test your own development. And it also has a lot of useful functionality for when you’re facilitating a meeting. So as I said, you’re currently watching the first module and I’ve already talked a little bit about what coding dojo is. In the rest of this module, I’ll be talking about some theory about how you learn things to do with practice and conditions for learning. And then I’ll go through some of the dojo principles. Now principles are like values, it’s what informs the way you behave and I can tell you now, we value code with tests and we value a collaborative learning environment. So I’ve got some slides about that too.

Practical Coding Skills

If you were learning karate in a dojo, it would be an interactive, collaborative, fun learning experience. And that’s what we’re aiming for in the coding dojo too. Where it will differ though, is the kind of skills you’re learning. Think for a moment about practical programming skills. Here’s a list of some that you could potentially improve out in the dojo. It’s quite a long list. I do encourage you to pause the video and think about maybe two or three of these skills that you personally, particularly like to be better at. So what do you think? Is there anything on this list that you’d like to be better at? Well, I picked out test driven development. Because I think it’s a crucial skill for the modern programmer. I see it as essential for producing quality work in a timely manner that will be possible to maintain by others as well as myself. It’s a practical skill where it’s easy to learn the basic syntax and tools, but much harder to become proficient. That’s because test driven development is actually quite a complex skill with several components. I think it encompasses all these other skills, too. In order to do TDD, you really need to know how to do these other things, too. So in this course, I’ll be talking about all of these skills. So I hope I have picked out some of the skills that you personally would like to learn. Of course, there are great Pluralsight courses on many of these skills and test your own development in particular. I do recommend the course on test first development. They’ll help you to become familiar with the basic concepts and some more advanced topics. The thing is test-driven development is a practical coding skill. And you do have to practice it in order to become really good. As David Starr says in the opening module of that course, it’s extremely easy to understand and extremely difficult to master. Taking part in a coding dojo could be a good chance for you to follow up with a Pluralsight course, and consolidate your skills, taking them to the next level. You could also plan to do all your learning and practice on the job. If you’re pair programming that will give you constant feedback and a certain amount of mentoring at the same time as you’re getting good work done. Code reviews can give you opportunities to reflect and make changes. However, I think during all you practice in production code might not be the best use of your time. For a start, a normal part of practice is testing the limits of what you’re capable of, in other words, making mistakes. And that might not be the best thing for your production code, or your relationship with your teammates. The challenges you face in daily work are not really designed to help you learn. They don’t give you incrementally harder problems to solve that stretch you just the right amount. So I think it’s very useful to have another forum that’s just for practice.

Learning to Ski and Learning TDD

I’d like to talk a little bit about practice, and I’d like to tell you a story about an experience I had recently. When I actually learnt downhill skiing, the thing is, for many years I’ve been doing cross country skiing, which is similar but different. With cross country skiing, you’re generally going along quite a flat trail through the mountains. It’s rather like hiking. Downhill skiing on the other hand, is all about going very fast, down a very steep slope. And it’s great fun too, but in a different way. So when I wanted to learn downhill skiing, I hired a new pair of skis, downhill skis and I went up to the top of a beginner slope. The first thing I tried was the same technique that I was already familiar with from my cross country skis. I put the skis in a V shape in front of me, called the snow plow, and tried to go down the slope like that. I found this to be quite straightforward. It was very similar to cross-country skiing, and getting down that easy slope was no trouble. The problem was, that technique doesn’t scale for, for downhill skiing, you need to learn a different technique, which is called parallel turns. This is where you put the skis next to each other like the person in this picture. So I went back up to the top of the beginner slope and this time I tried to go down it with my skis parallel to one another. That proved to be much more difficult. I found myself falling over every few meters, experiencing quite a lot of head and snow drift instance. This was not a comfortable experience. And I had to force myself to get back up and go to the top of the slope again and practice some more. After a few runs like this, I found that actually it was getting easier. It took quite a bit of perseverance. But eventually I found I could use this new parallel turns technique to get all the way from the top of the beginners’ slope to the bottom. So I decided to tackle a bigger slope. At first again, there was lots of falling over, but eventually I got the hang of it, and I could attempt an even bigger slope. At some point, I could actually manage a much steeper slope than I would ever have been able to do with the snowplow technique that I knew from my cross country skiing. And I could actually experience the fun of downhill skiing where you’re swishing down the slope with the wind in your hair. So that was a story about learning to ski. But I think if you were trying to learn test-driven development, you might have a similar story to tell. If I gave you a small coding problem to solve, you could probably do it without any tests using your normal coding practices, without any difficulties at all. Just like I could get down a beginner slope using the skiing technique I already knew. If I asked you to go back and do the same coding problem again, only writing the tests first, I think you might find things quite a lot more difficult. Just like I did when I was trying out parallel turns technique. You might not experience banged knees and head in snowdrift quite as often, but the experience of doing TDD the first time probably wouldn’t be all that comfortable.

Incidental and Deliberate Practice

So, when I was learning to ski I did a great deal of practice before I really became competent with it, and actually there’s a whole theory of practice and how it works. Several researchers, including Anders Erikson, a professor of psychology, do research on how people become experts. And in a nutshell, the difference is practice, but not just any kind of practice. Dr. Erikson talks about deliberate practice and incidental practice. Now, incidental practice is probably what you’re already familiar with. If you do the same thing repeatedly you get better at it. And eventually you can do it without very much active mental effort at all. It becomes kind of habit. Deliberate practice, on the other hand, is doing something that you find hard. It’s not comfortable to do. But it’s just the right amount of hard. You’re always pushing yourself just enough that you’re improving and taking on gradually, greater and greater challenges. Another part of deliberate practice is taking a complex skill and breaking it down into components that you can practice separately until you can do the whole task or skill. You can do both these kinds of practice in the coding dojo, but deliberate practice, particularly. The thing with this is because it feels uncomfortable, you need to feel safe before you’ll even try it. If the cost of failure is too high, like in your production code, you won’t take the risk. The other thing about the coding dojo is it can help you to feel motivated to actually want to learn something new when you’re in the group and everyone’s encouraging you. It might not be quite as scary as stepping onto a high wire to learn test-driven development. But maybe nearly as scary. Incidental practice is also important. This is picture of Kent Beck arguably he invented test your own development. He’s also written a number of books on programming. He said, I am not a great programmer, I’m just a good programmer with great habits. Now of course, Kent is being a little bit modest here. He clearly is a great programmer. But I think he puts his finger on something important here. Your habits are what you do when you’re not really thinking. They’re what you continue to do when you’re feeling stressed, when there’s a deadline, when you’re tired. If you have good habits, you’ll continue to write tests, make design improvements, continue to write great code. Incidental practice is about forming these good habits. And you can do that in the coding dojo as well.

Code Katas

So what do you practice on in the coding dojo? Well of course you practice on Kata exercises. In a martial arts dojo, a Kata comprises a sequence of moves that you practice over and over again until they become part of your muscle memory, and then when you come to spar or fight, the moves just come naturally without you having to think about it. Dave Thomas proposed that programmers should do practice too, and that we can do practice on code katas. In his blog, he proposed several Code Katas that you can work on. And since then many other people have designed other Code Katas. They’re small exercises that you use to practice programming techniques. Rather like a martial arts Kata you also repeat the exercise in order to improve your technique. And you can learn a variety of different Katas to stretch yourself in different areas. So this is an example of a Code Kata, called the Leap Years Kata. It say’s write a function that returns true or false depending on whether the input integer is a leap year or not. And then it goes on to explain the rules and have some examples for which years are leap years and which aren’t. This code is not that difficult to write. It’s actually one of the easier Code Kata. The point is that you can practice the way you solve it and you should use test your own development. The idea is that the moves of the Code Kata and of test your own development, go from being at awkward at first to feeling natural like a habit. And you’ll start working in the same way in your production code. I’m going to show you a fully worked example solution for this Kata later in this course.

Dojo Principles

I’d like to talk some more about the way you’re expected to act in the coding dojo. There are some coding dojo principles to guide your behavior, and these were first documented by the Frenchman who started the first coding dojo in Paris, and published in Lauren Bosiveda’s blog. URL is on this slide. The first rule of the dojo says, you can’t discuss a technique without code, and you can’t show code without tests. Because code without tests simply doesn’t exist. Now maybe you write production code today, that doesn’t always have tests. And that may be okay. But in the Coding Dojo, we always write tests. Another part of the Coding Dojo philosophy is to do with mastery. In a Dojo for karate, you’ll find people of all abilities, but usually the most experienced and best practitioner is known as the master or sensi. In the cording dojo, I don’t think it’s necessary to point out a particular person as the master, or expect one person to be teaching and everyone else to be learning. Instead, I think we must acknowledge that coding is a diverse multi fast skill. And everyone has different strengths, things to teach, and things to learn. So if you’re in the dojo, and something seems hard, you should be able to find someone who can explain it. On the other hand, if things seem easy to you, you can hopefully explain to those who are finding it hard. Not everyone will be a master in all areas. We expect in the Coding Dojo everyone will both teach and learn at different times. So just to summarize this first module about the Coding Dojo. We’re interested in starting or joining a Coding Dojo in order to improve our coding skills. We’re going to teach and learn together in a group. Do both incidental and deliberate practice on Code Katas, usually. And we’re going to have fun doing it.

Teaching and Learning Test Driven Development

Introduction to Test Driven Development

In this module we’ll be taking a closer look at the practical coding skill of test driven development, and how you can go about learning it in the Coding Dojo. First, we’ll be going through a worked example of test driven development on a simple Code Kata. And then we’ll discuss how you can learn the skills of test driven development through Code Katas. This is the classic diagram that’s usually used to explain test driven development. You start by writing a fading test that runs red. And then you make it pass run green. And once you’ve done that, you can refactor and the code, and prove the design. And then write a new failing test and go round the loop again. I think this picture may be a little bit too simplistic, and I usually introduce a fourth stage to this diagram. The overview stage. I won’t explain exactly what I mean by that now. I’d like to show you through a worked example of doing a whole Code Kata, and showing you the steps that I go thorough to move between these states.

Demo: Leap Years Kata

So the first state that I talk about in test driven development is the overview state. This is where you take a little step back from the immediate code that you are going to write and try and analyze the problem, and define it, what is that we are trying to achieve with this current test driven development session. You might try to define a goal in terms of a guiding test, that’s a test which you can’t make past straight away in one step, probably, but that by the end of your coding session, it should be passing. Each kind of demonstrates the whole function working. You might also write a list of other test cases that you’ll want to get passing along the way. We know we’re done with the Overview state when we have a good idea of what we’re doing, and we’ve chosen the first test. So let’s have a look at this problem. So this is the description of the Code Kata. It’s a Kata that’s called Leap Years, and it’s one of the more simple Code Katas. It says, write a function that returns true or false depending on whether its input integer is a leap year or not. And then, here are the description of the rules how you know that. A leap year is divisible by four, but is not otherwise divisible by 100 unless it is also divisible by 400. So that’s a reasonably complex rule for deciding whether a year is leap year or not. But helpfully it gives us four examples. 1996 is a leap year, but 2001 isn’t. 2000 is a leap year and 1900 isn’t. So with these examples and this description of the general rule, I think I have a fairly good understanding of what kind of piece of code it’s I need to write. It’s just one function taking one argument an integer and returning true or false. And looking at this, I’m not sure that I really need a guiding test. I think it’s probably sufficient just to work with these four examples and turn them into test cases. So my test list is already given to me here in the Kata description actually. Not all Kata’s are defined like this quite so simply, but this one will do very well for getting us started. The next stage in test driven development is to declare, I name that test. Most tests follow this format, arrange, act, assert, and I’ll show you that in a minute. And you have to make the code you write compile so that you can actually run the test. In my case, I am going to be using python, so there is no compiler to worry about. I’ll know when I am done with the red state of TDD, when I can run the test and see it fail. So here’s I’ve got myself into New folder for my new project. And I’m going to create a file to put my source code in, test leap year. Because at the moment I plan to put both my tests and my production code into the same file. Normally I would separate them, but just for this simple example, I think it’s easier if you can see all the code on the screen at once. So the first thing I was going to do is declare a name, a new test case, and it was going to be

  1. So just as we discussed in the overview step, I decided I needed a, a function, that would take an integer as an argument and return a Boolean. And I decided here to name it is_leap. So here I’ve made a design decision already. I’ve also named this test case, test_normal_leap_year, because that is the, general rule that I’m trying to make work. 1996 is a normal leap year. So the test name tells you the general rule, and the data in the test case is a specific example that you’re using to illustrate the general rule. So now I’ve defined my test case. I haven’t got a compiler to worry about, the arrange act assert, in this case is very simple, there’s no arranging to do. The acting is calling is_leap with the argument 1996, and the assertion is in the same line. So it’s a very compact test case, but it’s got the parts it needs to be able to run. So now I can flip to my terminal and run the test. This test framework is called pytest and I do find it very useful for writing test in, in python. So as you can see, pytest has helpfully told me that my test is failing, and the reason for that is because is_leap is not defined. Great. So let’s just go back to the theory of test driven development and check what the state we’re working on is. So now I’ve completed the red state and I know I’m ready to move on because I’ve been able to run the test and it fails. And I’ve looked at the error message, and it is the error message that I was expecting. So now I am ready to do the green state. This is where I am going to implement production code to make the test pass. In this state, there’s a strategy you can use, which is called fake it, which is just write the very simplest thing that will make the test pass. Even though you know it’s not complete general solution, it’s probably just a hard coded value. And that’s the strategy you use in order to get the test passing quickly. Another thing that might happen when you’re in the green state is you discover that the test you’ve written is too difficult, and you want to start over. That might happen if you’ve bitten off more than you can chew, basically. And you just go back, comment out the test that you can’t make pass straight away, and write an easier one, and continue from the red state from there. In this case, I think I’m fairly confident I can implement a solution that will make this test pass. And I think I will use the fake it strategy. So here I need to implement the function to make the test pass. So there, is an implementation that I hope will make this test pass. It’s very simple. it’s a fake result hard-coding a return value. It’s not the final production code, but it should be just enough to get this test to pass. So let’s run it. So now you can see that pytest has shown me that this test is passing. So now I’m ready to move onto the next state in testing and development. My tests are all passing, or one of them. And so now the next step is to do refactoring. This is our chance to improve the design, clean up code smells. We might have taken shortcuts in order to get the test passing quickly. And in this case, we’ve actually used a fake implementation, and we’ll need to generalize that. A valid move here would normally be to just go and write the general implementation, but actually in this case I prefer to add a new test case to force me to do that. It’s important in the refactoring step not to add new functionality. Ideally we want all the functionality to be driven by test cases, and that way we can ensure it works. So here it’s quite straightforward to choose the next test so I go straight back to the red step. And here I have to decide what to name these tests straight away. I think a year that is not a leap year should be called a common year. But just looking back at this description, you can see that 2001 is the example given and that would be a good common year to do. So I shall add a test case for that. And now I can run this test, and it fails. So, just going back to my states and moves, you can see now I’ve completed the red step again for the second time round the loop, and I’m ready for the next green step. So if the year is divisible by four, then it is a leap year, and I think that will make both my tests pass. Yes, pytest is telling me two tests passed. So now, I need to think a little bit more. Is there any refactoring needed? I can’t see any refactoring needed right now, so I need to go back to my problem description and try and work out what the next test case is. It’s not completely obvious to me. So I’m actually stepping back into the overview state now, looking at the code more strategically, and I’ve decided that I’ve handled the normal case of a normal leap year and a normal common year. But now I need to start handling these special cases of the atypical leap year and the atypical common year. So let’s start with the atypical common year, because the code as it stands, if you gave it 1900, it would say that, that was a leap year. But it’s not, it’s actually atypical common year. So I think that’s probably my next test case at this point. So just to reiterate where I was on this map, I decided I couldn’t choose the next test straightway after the refactor step. So it wasn’t very clear to me. So I went back to the overview and look to the problem description, thought about it a little and decided that the next test should be for any typical common year. So there I’ve declared and named my test, I can run it and see it fail. So there, my new test has failed, and the other ones are still passing. So now I can move on to the next stage of TDD, which is to make the test pass. So here, my implementation isn’t sufficient. So I need to start handling these atypical common years. If year divisible by 100, then it’s not a leap year. That was the simplest thing I could think of to make the test pass, which it does. So now I’m in the green state, my tests are all passing, and I can think about refactoring. And I probably can collapse these Boolean expressions into one, but I think it might be a bit premature to do that right now. So I am going to defer that refactoring and come back to it the next time I am on the TDD loop. My tests are all currently passing, I have got three of them, and I was in the re-factoring step, looking to the other code whether there were any smells or fakes. And I did identify that the code could be made simpler. But instead of doing that refactoring straight away, I decided to go to the red state and define the next task which was the final example on the list. And then I’ll come back to the refactoring. So the final example is for the atypical leap-year. The year 2000 is a leap year because it’s divisible by 400 even though it’s also divisible by 100. So this test is going to fail. So I need to go back here and change the implementation so that it supports this case as well. See if that implementation works. It does. So now I have four passing tests, I’m in the green state, and now I have to decide what refractoring is needed. And I think this could be made simpler and clearer, just by extracting a method here. So here I’m doing the extract method refactoring. And the first step in that is to copy the code that you want to extract into the new method. Declare the new method, paste the code into that method. Get the new method working. I’m just going to run the test again just to check that I haven’t made any syntax errors. So my new method is there and not being called. So the next step is to replace the code with the call to the new method. So that I think makes the code a little bit more readable. The tests are all passing, so I’ve done the refactoring successfully. But I think I could even do better than this. Instead of having this as two if statements, I think I could probably make it into one Boolean expression that might be a little simpler to understand. So here I’m just switching around the Boolean logical a little, let’s try and make it more readable. And that was a successful refactoring. So I think we’re nearly there. I can just see that now I’ve got this method is a typical common year, I might like to also name this piece of code here. So I’m just going to do that. Again, declare the method, paste in the extracted contents. Make sure that everything is working still, even while you’re not calling the new method, introduce the new call. And when you’ve made the substitution, run the tests again. So that was a couple of extract method refactorings. A little bit of rechecking the Boolean expressions. And I quite like that solution. I think it’s very succinct, quite readable, and does the job. So that was an example of test driven development. All the steps, just to recap. We started in the overview stage, analyzing the problem, making a list of test cases we thought we were going to need. In the end, we didn’t actually need to add to that list., the four test cases seemed to be sufficient. You might write a guiding test, which is a kind of a larger scale test that shows you when you’re going to be done. In this case we didn’t really need one. It was sufficient just with the four tests on the list. We chose the first test. We’ve declared it. We made it run. We saw that it failed. We checked the error message. We wrote a very simple implementation. We actually had a fake. We just returned true. The tests passed so we could, had the opportunity to refactor. We didn’t actually refactor at that point, we went straight back towards the next test. Declared it. Make it run. See it fail. Implement the correct solution this time rather than a fake. Did the refactoring, and we went round this loop four times with four different tests. We did hop out to the Overview step in-between at one point, just to make sure that we were choosing a, a good next test. And in the end, now I’m happy that all the tests are passing. The solution is clean code, it’s readable, and I’m done with this TDD session, I’m ready to check in my code and go on to the next problem.

Component Skills of TDD

Now you’ve seen a demonstration of test driven development on a simple Code Kata. I hope you’ll agree with me that it’s not a straight forward skill to learn. One of the strategies of deliberate practice is to take a complex skill and to break it down into components which you can practice separately. And I think it’s easier to learn test driven development if you can do this. For a start, you need to be able to design test cases. It’s almost the first you do. But more than that, you need to be able to design code that is clean and testable. In TDD, you work incrementally, driving development forward step by step. You also refactor regularly, and you have to be able to do this without introducing errors. So all these skills are closely related and support one another. And when you’re doing test driven development, you use all of these skills. But when you’re practicing TDD in the Coding Dojo, you can just home in on one or maybe two of these skills and practice them in particular. For example, if you choose a refactoring Kata, it might allow you to do only the refactoring part of TDD. In a later module of this course, I’ll be going into more detail about which Katas could be suitable practicing which component skills. To summarize this module, Test Driven Development is like a series of moves going from one state to another; red, green, refactor and over view. And you can demonstrate test driven development on a simple Code Kata and that might be a good thing to do in your Coding Dojo. Test driven development can be broken down into component skills that you can practice separately, and again I’ll talk more about that in a later module.

Collaborative Games for Programmers

Introduction to Collaborative Games for Programmers

This module, is about Collaborative Games for Programmers. We’ll be talking about prepared Kata, Randori, Randori in pairs and various constraint games. So what is a collaborative game? Well, it’s a game, where you aim to beat the game itself, not the other players. All the players in the game are helping one another, collaborating to beat the game. There are rules and activities and goals which you’re trying to achieve, just like in any other game. As an example, you may have played a card game called solitaire. In that game, you have to skillfully move cards around, in order to get them into a particular order. Normally, you’d play that game by yourself, but there are other, similar games where you’d have several players collaborating, each contributing their individual skills to help the whole group to win. So, why wouldn’t we play a competitive game in the coding dojo? It can be fun to play competitive games too. Well, I showed this picture before when I talked about deliberate practice. For you to do that kind of practice, you need to feel safe. Able to make mistakes. Learning just happens more easily, when you are feeling safe and relaxed. If you are in a competition of some kind, you could feel that making a mistake would let the whole team down. Of course a small element of competition could be fun but just keep the emphasis. On collaboration, learning together. People should feel valued and respected, encouraged to be in the dojo. Not like they’re about to lose.

Prepared Kata

A prepared kata is a kind of collaborative game. Where you are going to show your best solution to a Code Kata. You project your Code onto a big screen so everyone can see it. And then you show all the steps, that have to solve the Kata right foot empty editor until you have a working solution. While you are coding you explain what you are doing and why, and people in the audience can ask questions and give you feedback on what they think about the code you’ve written. The idea is that everyone in the room should be learning something. Both you as a presenter, getting feedback, and the audience seeing your practice solution. After the presentation, the hope is that everyone in the room should be able to go away and do the class again by themselves. And preferably they do it better than you did during the meeting. In the last module I showed you a demonstration of this Code Kata for determining whether a year is a leap or not. I showed you what test driven development looks like, and I explained all the steps in some detail. That was a kind of prepared Kata and if you look around on the Internet you’ll find many people have recorded screen casts of themselves do coding Katas. You can watch some of them to get some inspiration. I do think it makes a big difference though, if you can get the person actually sitting in front of you coding in your coding dojo. It makes it a much more interesting and interactive experience, not least because the person doing the performance will learn a lot more than in a screencast. So, if you look at my solution to that Code Kata, this is the code I ended up with. I haven’t shown the tests, because they’re just the same for the four examples as are in the Kata description. Looking at this, I’m pretty pleased with the final design of my code, and I showed all my workings for how to get there. So now the question is, as an audience member, could you re-create it? Well, I don’t know. You may not have ever done any Python, or any test-driven development before. But I’d guess that you’d be able to have a good try at this one, even if you had to look up some of the syntax and maybe use a different testing tool. If you’re going to perform a Code Kata at your coding dojo. You should expect to have to practice it many times before you do the performance, and that’s really where you get a great deal of a benefit doing this. You are able to form habits and make test driven development feel natural, at least for this Code Kata. You should make some notes, that you can refer to if you get stuck. When everyone’s watching. Perhaps a list of test cases in the order you want to implement them in, a listing of the final code that you’re aiming for. You should prepare a Code Kata to be quite short when you perform it. The one I did for you was less than 15 minutes, and you could take up to 30 minutes or maybe even an hour. If you’re doing a larger Kata. It’s hard for an audience to concentrate for much longer than that. If you can, find someone to pair with you, preferably someone who will practice with you beforehand. But even if you can’t do that, just asking somebody at the meeting to come and sit with you is a great help. Somebody who’s there with a special responsibility to point out small errors as you code, and keep the solution moving forward. As your coding you’re going to want to be talking to the audience, explaining what you’re doing and why. You’d like to explain why this is the best solution you know to solve this problem. Although you should expect that there do exist other and better solutions to the Code Kata, even expert programmers wouldn’t do a prepared Kata exactly the same way every time. The audience should be there giving you feedback and ideas for how you could improve. Although, you don’t have to follow their advice at the time. It can be a bit of a distraction if they’re suggesting something wildly different from what you are doing. But do note down what people say and you can discuss it in the retrospective. The idea is, that everyone should be able to go away afterwards and have learned something from your performance and be able to repeat it. And maybe at a subsequent meeting, someone else would like to do a new performance of the same Kata, and show you how they would solve it.

Randori and Ping Pong Programming

A Randori is another kind of collaborative game, that you can play in your coding Dojo. The name comes from Karate, it’s a kind of free form interaction or sparring. The analogy with Karate is not perfect but in the coding dojo, the general idea is that everyone should be contributing some code, and nobody here’s particularly prepared something in advance. As with a prepared Kata, the code is projected onto a screen where everyone can see it. And everyone takes a turn at writing some code. You’ll probably spend 60-90 minutes on a Randori. Longer than that, it gets harder to concentrate. So, you take it in turns at the keyboard to write some code. And there are a couple of different ways that you can use to switch who has the keyboard. I think the best ones are using a time limit or Ping Pong. With a time limit, you just set a timer for each person, five or seven minutes, and that’s how long you get at the keyboard. When the timer pings, the next person steps up and takes it from you. Ping-pong is slightly different, it’s where you use your TDD state to decide when it is time to swap. Now you can do Ping-Pong Programming just when your pairing, maybe in your normal work, and the way it works is like this. Each person in the pair is like a player. So the first player, who writes a failing test, and then you push the keyboard over to the other player, and they have to make the test pass. The next step is for them to write a new failing test, pass the keyboard back for the first player to make the test pass. So, it’s like a game of Ping Pong. You’re swapping the keyboard, each making a move and passing it back for the other player to make a different move. Of course, I haven’t mentioned re-factoring here, but you have an opportunity to re-factor every time the tests pass, and usually you can collaborate on that. Ping Pong programming in a Randori, is fairly similar, except you have more than two players. Here I’m just throw, showing three players, but you could have a whole room full. I think it works fine, up to about ten people. Beyond that, it starts to get too infrequent, that each person gets the keyboard. So, to do a Ping Pong Randori. You start with two players, sitting with the keyboard. And the third player, and the other players sitting in the audience. So, the first player will write the failing test and when they run it can see that it fails. They pass the keyboard to the second player who has to make it pass. At this point, the first player will sit down in the audience and the new player will step up. And it’s for that person, that the second player writes the next failing test. So when that’s failing, they can pass the keyboard along to the other player, who’s going to make it pass. Once the test is passing. The person who wrote the test, sits down and a new player will set, step up. And again you write a failing test. Whenever you get the keyboard, the first thing you do is make a test pass. And then the next thing you do is write a failing test for the next player. And the pattern just continues until everyone has had a turn. And then you go back to the first layer. Again I haven’t mentioned re-factoring on this diagram, but every time the test pass you have an opportunity to do that, and usually the person who does the re-factoring is the person who made the test pass. When you’re playing this game, you’ll probably find that people have a lot to say to each other. It’s quite fun to write the failing test and then hand over the keyboard, and see if someone else can make it pass. There can be a lot of discussion going on. And I like to setup some rules in advance, for how that discussion can be the most helpful. I like to tell people, if you have the keyboard. You decide what to type. It’s your decision. Everyone else might have opinions, but it’s your opinion that counts. Of course, you might not know what to type. You might have got a bit confused or not be following what’s going on, and you need some help. Everyone in the room in the room, should be able to help you. So, if someone asks you for help, respond kindly. Give them the help they’re asking for, but don’t swamp them with conflicting advice. If you’re sitting there, and nobody’s asked you for help, but you can see an opportunity to improve the code that’s being written, it’s your responsibility to choose a wise moment to speak, not just blurt it out straight away. It’s not usually a wise moment to speak, when somebody’s in the middle of trying to make some tests pass. The best opportunity for re-factoring and improving the design is when all the tests are passing. So try and save your comments until then. You might also find that that’s not even the wise moment to speak, it might be best to just save your comments until the retrospective after the Randori is over. And this is where a facilitator, will help you to judge when a wise moment to speak is.

Randori in Pairs, and Code Retreat

An alternative to a whole group Randori. Its a Randori in Pairs, and this is one of the most common ways I like to work in a coding dojo. You split the group into pairs, and perhaps one trio if the group is an odd number and each pair will work on the same code Kata. Somebody acts as a facilitator, going around between each pair. Reviewing their code, and helping them. I’ll talk more about what the facilitator is supposed to do, in a subsequent module of this course. And then, in the retrospective, you share code and discuss how you wrote it. One of the dojo principles says, that you should show your working, and not just the final code. Which is why it might be a good idea. To actually swap the pairs. And when you do that, you should start over and repeat the Code Kata from the beginning. This means that you get to share all your working with a new person, and they’ll be able to give you different feedback from the other person. And you’ll spread knowledge around the group. I find that about 45 minutes is about right for pairing with one person before you swap. So, you might need a slightly longer coding dojo to do this. In fact, there’s a whole day event called Code Retreat that uses this format. And there’s a website with lots more information about it. I’ve led several Code Retreats. And my experience is, it is a very enjoyable day, where you can learn a lot. Over the course of the day, you fit in five or six coding sessions, each with a different pairing partner. It’s a bit like a Coding Dojo, really. The basic philosophy and aims are very similar. You have all the elements of a Coding Dojo; the introduction, the retrospective, you show all your working to each pairing partner, and you write lots of tests. The main difference really is that it’s longer, a whole day, and that you’re focusing on repeating the same Code Kata over and over. The Code Kata that’s normally used is the Game of Life Kata, and you can find more information about that on the Code retreat website. The Game of Life Kata is a good one for practicing test-driven development. As you repeat it over the day, the actual problem just starts to fade into the background and you can concentrate your brain on how you’re coding. What tests you’re writing, if the code smells, the steps of test driven development? Having said all that, my experience is also that if you have a room full of beginners, people who have never done test-driven development before, the Game of Life Kata is quite a hard one to start with. And I think you’d benefit from doing some other simpler exercises first. In a subsequent module of this course. I’ll suggest an initial series of Coding Dojo’s you can use to get started, when you’re concentrating on learning each component skill of test-driven development separately. And I think that would be a good thing to do before you attempt your first Code Retreat.

Constraint Games

Another kind of game that you can play when coding is a constraint game. The idea is that once you’ve got to know a Code Kata, your brain is no longer occupied with just solving the problem, and you can start to concentrate more on how you’re coding. By introducing a constraint, you force yourself to change the way you code. You can see what happens when you stretch yourself, whether you can still do test-driven development in artificially difficult situations. The hope is, that this practice will help you when you face tricky situations in your production code. It’s also quite fun. I think constraint games come in three main types: tool constraints, design constraints, and social constraints. And I’d like to go through examples of each one now. With a tool constraint, you deliberately restrict the way you use your tools. For example, use only the keyboard, disconnect your mouse and your track pad. It’s actually faster to edit code and get stuff done, when you don’t move your hands away from the keyboard, but it takes time to train your fingers to remember the key combinations. Once you’ve slowed down and practiced it for a while though, you get faster and more productive. Another constraint that you can try is if you’re used to using an integrated development environment, an IDE, is that you go back to using just the plain text editor where you have to do everything by hand. It really forces you to remember how your programming language actually works. How to invoke the compiler, how to run the tests? I find this is a good constraint to introduce when I’m in a mixed group, where people are used to all different IDE’s. By forcing everyone to use a plain text editor, you bring everyone down to the lowest common denominator and that can really help with the pair programming. People are more willing to pass the keyboard backwards and forwards, when everyone is equally unused to the tools. Another kind of constraint game, is where you can strain the design of your code. Now we all know, that long methods, is a code smell. So what happens, if we artificially restrict ourselves, to really, really small methods. Perhaps only two lines in each method body. Actually that’s really quite hard. Try it first with four lines in a method body. And when you can do that, decrease it further. This game really makes you think about names and abstractions, since you’ll probably have a lot more methods than you’re used to and all those methods will need names. Another game you can play, is to ban conditionals. Take away all if and else statements. And to do that, you have to find other ways to control the flow of execution in your program. For example, with polymorphism where you use subclasses and overriding methods. Similarly, you can band loops. Without constructs like for, and while, and for each, you have to turn to maybe more functional style constructs, like map, reduce, filter, and use recursion. All these games do interesting things to the way you design your code. A third kind of constraint game, has to do with how you work together in your group or your pair. If you have a whole group working on a Randorian paths to facilitate can announce in the middle, right, you have two minutes. I want to see all the tests passing in all the paths simultaneously. Your collective green deadline is in two minutes, and I set the timer. At this point, anyone who’s tests are currently failing, will find out if they’ve made a lot of changes since their last green line and how hard it is to get back to everything working and the tests being green. They may need to revert the code. Even people who currently have all the tests passing can be caught out, though. It can be very tempting to think, well, I could just make this small re-factoring. And still be in time for the deadline. And then be really embarrassed when the timer goes off, the two minutes is up and you’re still in the middle of the re-factoring and you’ve made a mistake and your tests are failing. This game can lead to quite good discussion, about the size of steps you should take when doing test-drive development. Earlier in this module, I explained a game you can play when pairing, called Ping-Pong Programming, where you kind of take it in turns to write a test for the other person. One way to introduce a constraint in this game, is to do it without talking. Only allow yourselves to communicate via typing source code, and tests into editor. You can also take this even further, by introducing a constraint that you must do the absolute minimum to get the test passing. So if your pair writes the failing test, you write as little code as possible. Perhaps even deliberately misinterpret what they mean. And have code something just to get the test to pass. And then you force the next test to make write a more general implementation. It really makes you think about how writing a test communicates the intent of what the code should do. So, in this module, we been talking about collaborative games for programmers. I’ve talked about prepared Kata, Randori, Randori in pairs, Code Retreat, and Constraint Games, generally. In the next module, I’ll be putting this all together into how you organize whole dojo meetings. With suggestions of specific Code Katas to do with specific games.

Sample Series of Coding Dojos

Introduction to my Suggested Series of Coding Dojos

In this module I’d like to talk you through the first five or so Coding Dojos that you might want to hold with your team. I’ll tell you about some activities and Code Katas that I found to work well, and give you some suggestions of how to tailor the content to your group. So, in this module I’ll outline what your first Coding Dojo could be like. And then some other sessions focusing on each of the component skills in ‘test room development. I talked about the component skills for ‘test room development before. And I said one of the strategies you ‘could use when learning a complex skill like’ test room development, is to break it up and practice the parts separately. So I break it down like this. You need to be able to design test cases, design clean code, drive development forward incrementally with tests and re-factor safely. When you’re doing testing and development you’ll be flipping between each of these skills. But, in the Dojo, we can zoom in on one or more of them. What I suggest you do is book a series of meetings, invite a group of five to 15 programmers, people you work with maybe, and initially book a series of two hour meetings, about five of them. Choose, perhaps, the end of iteration or the same day each week. In this module, I’ll go through in some detail what you can do at each of those sessions with some ideas about how to follow it up with further meetings.

A First Coding Dojo

For your very first Coding Dojo, I suggest you have quite modest aims as to what skills you’re going to learn. Mostly, the point should be to experience Test Driven Development and the Coding Dojo. I suggest you take a whole-group Randori, and choose a very easy Code Kata. So, as with every Coding Dojo meeting, you start with an introduction. And for the first meeting, I suggest you talk about what Coding Dojo is. Summarize what you think are the most important points from the first module of this course. I’d suggest that you do explain the idea of deliberate practice, because that’s really what we’re after in the Coding Dojo, at least in my opinion. When you come to the agree activities that you’re going to do in this specific meeting, you might want to go into more detail about what testing and development is. The stakes in the moves depending on what people already know about test-driven development. I already suggested you might want to work together in a Randori so it could be a good idea to go through the Randori Rules so people know what’s expected of them. You’ll also want to agree how you’re going to swap the keyboard, whether you’re going to use Ping-Pong or Time Limit. I think a time limit is simplest to start with. Of course, the main parts to the meeting, you should be writing some code. I suggest you choose a very easy calculator. Such as string calculator or Fizz-Buzz. String Calculator is a kata designed by Roy Osherove, and you can find a description of it on his website, The instructions are quite detailed and you might want to print out a copy for each of the participants. The basic idea is to implement a method that does basic arithmetic operations. Using an input string. Fizz-Buzz is similarly a straight forward cutter. This time you are turning a number into a string. The precise description of this Kata varies depending on who you ask, but I like this definition. Write a program that prints the numbers from one to 100. For multiples of three print Fizz and for multiples of five print Buzz. And for numbers that are multiples of both, print Fizz-Buzz. And then there’s the sample output that your program should produce. So both of these are really quite easy Code Katas. And the idea of them, is to help you to practice testing your own development and make it very straight forward to be successful with it. It’s always reasonably obvious what the next test case should be. So, you learn to drive development forward incrementally with the tests. And that’s really one of the aims of this first meeting. Get people to experience test-driven development working. Even if the problem being solved is extremely simple. You’re still experiencing incremental development. Writing code can be really fun. But it is important to reserve ten or 15 minutes at the end of the meeting for the retrospective. The kind of questions that you can discuss here, are things like, well are we pleased with this code and these tests? Have we achieved a clean design? And then more widely, could we work like this in our production code? Is incremental development something for us? Hopefully, people will have enjoyed your Coding Dojo, and they will be willing to come to the next meeting.

Refactoring Dojo - Introduction and Agree Activities

For your second Dojo meeting, I suggest you focus on the skill of refactoring. It’s one of the component skills in test driven development, as well as being a useful skill to have in other situations. In this meeting, I’d expect you to talk about Code Smells. And how identifying and naming a Code Smell can help you to identify a named refactoring to reply to address it. I hoped you experience that small refactoring steps can add up to significant improvements in your design. The code katas I’m suggesting all come with a comprehensive suite of automated tests so you can experience what it’s like to work in that situation. It could be very encouraging for your team to want to have such a suite of tests for your production code. So, I’d like to show you an outline of how the meeting could progress again you should start with an introduction of your Dojo and talk about why your there. Most people would have hopefully been to the previous meetings so you won’t need to go through everything again. You should probably quickly move on to talking about what you’re going to do at this meeting and what’s happened since the last meeting. Maybe people have been trying to work more incrementally in the production code. Maybe they’ve been trying to do some refactoring already. You can talk about, well what is refactoring in our codes now and make sure that everyone has the common understanding of that. A little activity that I would like to do with the group, is where you actually go through and actually try to recreate all of the atomic steps in Extract Method. So, what I mean by that is gather everyone around a, a whiteboard or a flip chart and try to brain storm what are the smallest steps that you take when you do extract method. And get everyone to contribute so that you have to really think about it. So, the first step is identifying the chunk of code that you want to extract and then you need to copy it and. Write the new method and all these steps are written down in some detail in Martin Fowler’s classic text Refactoring Improving the Design of Existing Code. And you might want to refer to that afterwards and see how your description of extract method compares with that. Now I know that all modern development tools have an automatic operation. it’s just a couple of clicks of the mouse to do an extract method for you, and it’s of course, much faster to use that than to do all these steps by hand, and I do think it’s a good idea to learn to use your tools. But the reason for doing this exercise of trying to define extract method like this is so that you really understand what your tool is doing for you underneath. You may find your tool doesn’t actually support every single refactoring you want to do. And if you can design your own version of extract method, with small, safe steps, you’ll be much better equipped to design other refactorings for yourself when you need them, and your tool doesn’t have them.

Refactoring Dojo - Tennis and Yahtzee Code Katas

So, all that introduction shouldn’t have taken more than 20 minutes, maybe half an hour. The main part of the meeting should be Coding. In this meeting I suggest you work in pairs, and take a simple refactoring Kata like tennis or Yahtzee. The tennis refactoring Kata is about improving some code that’s doing the job of working out the score in a tennis game given the number of points that each player has scored so far. Now, tennis scoring is really quite quirky. They don’t say nil. They say love all. And then they proceed to count in 15s’ or actually not. But, as I said it’s a fairly quirky way to score a game. So, for this Kata, the refactoring version of it, you get given some ugly looking code. And a directive to well tidy it up a bit. If you’ve used Git before, you should find it fairly straight forward to get the starting code for this Kata from MyGithub page. I have a public proposal tree that you can clone. If you’re not familiar with Git or Github, you might find it useful just to press on this button and get a Zip with all the source code in it. You could also download the code. From this Pluralsight module. When you’ve got the code, you should find it looks like this. There are versions for many popular programming languages, and a readme file that explains the rules of tennis and how you should do this Kata. If you look in the code you should identify some code that could do with a bit of refactoring. I think you might be able to see a long method. You should also notice that there are three versions of the tennis game. Tennis game one, tennis game two, and tennis game three. I suggest the first time you do the kata you start with tennis game one. Maybe in a future Dojo meeting you could try out one of the others. You’ll also find a comprehensive set of unit tests for this code. So, this Code Kata, is all about practicing refactoring safely. And to a lesser extent, how to design clean code. Doing this exercise, you should find that whenever you make any kind of refactoring mistake, you’re alerted to that by a failing test. This gives you really good feedback on how well you’re doing at refactoring. So, cleaning up this code is really quite fun. But you should always try and make sure that you reserve some time at the end of the session, for your retrospective so you can talk about how things have gone. How did it feel to work with comprehensive tests? Could we work like this in our production code? Could we write some more tests so it would be like this? Hopefully, going away from this Dojo, people will feel more confident doing refactoring, and more encouraged to write some tests. So once you’ve done one Dojo on refactoring, you might want to plan the next meeting to take up a different topic. One of the other component skills and test your development. Or you might feel like you want to do some more refactoring Katas. As I mentioned before, there are actually two other tennis games in the same repository that you could try refactoring. There’s also another Kata called Yahtzee, which is really very similar. It’s also a game with some rather quirky rules. You can find the starting code for this Kata also on MyGithub page, or you can download it from this Pluralsight module.

Writing Good Tests Dojo - Gilded Rose Kata

Another good topic for a Coding Dojo, is how to write good tests. You should have some good discussions about what makes a good test, and you can practice writing tests with a clear arrange act assert format. That to very readable. You can also have some discussions about how to handle Legacy Code. So meeting our client might look like this. Again, introduce the Dojo, and the purpose, why people are there. Maybe talk about the idea of component skills and Test Room Development, and how writing good tests is one of the essential things you need to learn. When you come to the part of the meeting where you agree the activities for today’s Dojo. You should talk a little bit about good test case design. The parts of the test arrange, act, assert and why readability is important. You’ve probably seen this description of the three parts of a test before, but I’ll summarize it briefly. The arranged parts of the test is where you set up the objects that you’re going to test, and the collaborators it needs. In the ‘Act part, you actually do something that you want to make sure that’s going to work. And then in the Assert part of the test, you make some claims some assertions, about what should have happened to the object now and it’s collaborators. One of the reasons for structuring your test case like this, is because it helps with readability. The test cases help to document the system at the lowest level of detail, so readability’s important. But more than that, when the test fails, you want to quickly and easily understand what has gone wrong so you can fix it. For more information about test case design and test room development in general, I recommend Mark Siemans’ Pluralsight course: Outside In, Test Driven Development. He talks about Arrange, Act, Assert there. So, again, the main part of your Coding Dojo is to write some code. And again, I do suggest Randori in pairs. Everyone is involved and active, and you can have some good discussions in the pairs. The Kata I suggest for learning how to write good tests is called Gilded Rose. Again, you can download the starting code from by GitHub page. Or from this Pluralsight module. When you’ve downloaded the code, this is what it looks like. Again, there are versions for many popular programming languages, and you can pick the language you prefer. The exercise is just the same. Here you can see the C# version of the code you’ll be working with. Again, there’s this long method that could do with some refactoring. The difference with the last Kata is, that you are not provided with comprehensive tests. Just one test to help you get started. What you do get though, is some instructions. A requirements document, if you like. And this document explains, that you’ve been hired to add a new feature to this system. Support for conjured items. But looking at the source code, you can quickly see you’re going to need to refactor it, before it will be possible to add this feature. So, before you can refactor, you’re going to need better tests. So, the first part of this Code Kata is to write test cases. And you can practice writing some really good ones. You will find, though, that it’s not completely straight forward, to translate what it says in the requirements document directly into test cases. Pros is naturally slightly ambiguous and you will have to make some judgment calls, about what it is the customer wants just like in real life. If you have time you should also get onto doing some refactoring and improving the code, and then ultimately adding the new feature. But don’t worry if you don’t have too much time for that. The focus of this Dojo should be on designing test cases. So when you’ve written some tests for the Gilded Rose Kata, and maybe done some refactoring too, you should make sure to reserve some time for a retrospective. You can discuss how well you’ve done at writing readable tests, and following the arrange, act, assert pattern. You can talk about whether these tests would be sufficient to support the refactoring you need to do to this code. And then, of course, it’s always good to bring the discussion back to how things are in your daily life with your production code. Would writing tests like this be a good thing to do in your production code? After this meeting focusing on writing tests. You might want to have another session where you do the Guilded rose, but focus on the refactoring part. Perhaps take the tests that you’ve written in this meeting and use them in the next meeting while you do the refactoring. Another thing you could do, is to repeat the exercise, but with a different testing too, maybe one you’re less familiar with, and find out how that affects the test cases that you write. For example, you could choose a tool like cucumber or Spec Flow. Do some BDD or an approval testing tool like Approval Tests or Text Test. There are also other legacy code exercises that you could look at for example J.B. Rainsberger has. An exercise on his Github page called Trivia.

Clean and SOLID code - Dependency Inversion Principle

Another good topic, for you Coding Dojo, would be clean and SOLID code. You could discuss why it’s important to write clean code. Understand about the SOLID design principles and why they’re closely related to testability. So here’s a sample meeting you could do with this topic. Again, introduce the Coding Dojo and the purpose for why you’re there, and maybe talk about the component skills of tester and development. But then, when you’re looking at the activities for today’s Dojo, you should probably talk about what the solid principles of object oriented design are all about. Now, there is a Pluralsight Course by Steve Smith in the library that will explain all of these principles. And a book by Robert C Martin that explains them as well. I do suggest you go look at those, but I would like to just explain quickly the dependency inversion principle. Because I think this is the most important principle when it comes to making your code testable. It says, high-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. So, to summarize, the dependency inversion principle says you should always depend on abstractions. Well actually, as much as possible depend on abstractions. You can’t write a whole system where nothing has any concrete dependency. It might be useful to illustrate this with an example. Here you’ve got a button class that can turn on and off, a lamp class, and in this design, the button can only be used with particularly lamp objects. Here you have a dependency on a concrete class. If we change this code little and introduce a new interface, Switchable, now the Button class has a dependency on this abstraction, the interface, the Switchable. And the Lamp is just one example of a concrete implementation of this interface. And now suddenly you’re obeying the dependency inversion principle and this also makes the button class much more testable. In our test we don’t have to use the lamp concrete class, we can substitute another interpretation of the switchable interface that might be much easier to test. So, that’s why the dependency inversion principle is so important for testability. It enables your test to substitute other concrete implementations.

Clean and SOLID code - Racing Car Katas

Once you’ve gone over the theory of the solid principles, it’s a good idea to apply what you’ve learned to some actual code. Again, you can work in pairs, Randori pairs. And the Katas I suggest. Are the Racing Car Katas. And in particular the Tyre Pressure Kata. The code for all these Katas is available from MyGithub page and you can download it from this plural site course. And when you look at the code, you get lots of different programming languages. Including Java script C# Java. This is the Java script. And you can see that the tire pressure exercise is there together with three other exercises. But what you need to do for this particular exercise, is write a test for this alarm class here. And this function here, check. There’s also in this project a README file, which explains all about the different Katas and how you should proceed, and gives you some background information about them. Hopefully, when you’re doing this exercise, you should discover one or more violations of SOLID principles, which makes this code hard to test, and you’ll have to fix it in order to get things working. So, in your retrospective, you can have a good discussion about the relationship between SOLID Code and Testable Code. And also, talk about your production code. Do you see SOLID violations there? And could that be a reason why it’s difficult to test? If you’d like to hold some more Coding Dojos on a similar theme, talking about SOLID principles, you could try the other three racing car exercises. You could also do the same exercises again, only with more focus on test case design. Perhaps using an isolation framework. Something like Moquito, Moque, Rinomox, or Typomoxiliator. Something like that that will allow you to automatically create stubs and mocks. And of course once you start talking about stubs and mocks, you should also discuss Gerard Meszaros’ definitions of the various kinds of Test Double. And what the difference between a mock, a stub, a fake, and a dummy is?

Incremental Development - A Code Kata from Scratch

In the very first Coding Dojo suggestion. I said you should try a really easy Kata, like string calculator, or Fizz-Buzz, which will make it fairly easy to break down the problem, and work on it incrementally. Now you’ve done some other Dojos, focusing on the other component skills in Test-Driven Development. You should feel confident to come back to this skill with a slightly more difficult Kata. While it might be more challenging to build up the functionality incrementally. So, in this Coding Dojo, I want you to have a focus on writing a list of test cases and then taking baby steps as you implement and work through the list. So, your meeting might look like this. We introduce the Dojo. Summarize the purpose and then maybe you could talk a little bit more about the way you can use Code Katas for practice. Once you get to know a Kata, when you repeat it your brain is no longer busy trying to just solve the problem. Then you can focus on how you’re doing testing and development, how you’re breaking it down into increments. So, when you talk about the specific activities for this Dojo, you should talk about a test list. If you remember, I showed you this picture of Test Driven Development, when we talked about the steps and the states of moves of Test Driven Development. In the overview state, one of the things you might do is make a test list. A list of all the test cases you think you’re going to need before you’re done with this piece of Code. It helps you to break the problem down into manageable pieces. And, of course, you’ll update this list as you proceed around the red green re-factor loop. So in this Dojo you might want to gather everyone around, a white board or flip chart and have people suggest test cases. Collaborate on your list. You could also collaborate on writing a guiding test this way, all together. So, once you’ve agreed some kind of test list, you could talk about baby steps and what that means. Working on really, really, small increments of code has actually been quite an effective, safe way to work. But the main part of the meeting, as ever, should be Coding, and working in pairs works well for these Katas too. I do suggest you take a Kata that you’ve already done and you know a little bit. For example, the Gilded Rose, Tennis or Yahtzee, but this time start with a completely empty editor. Begin by writing and failing test. See how much better a design you can come up with this time. You’ll be practicing all of test driven development and using all of the component skills. I think it’s quite difficult to isolate driving development with test from the other skills, but since you’re already familiar with the Code Kata it should be a little bit easier. When you come to the retrospective. You can talk about the way the tests are driving development and whether you were tempted at any point to write production code you didn’t have any test coverage for. And then, of course, you should always relate this back to your real situation at work. Could you use test driven development in your production code? Could you work incrementally like this with baby steps? Well, we nearly at the end of my suggestions, for more Coding Dojos. But of course, you can follow up this one by doing a Code Kata that you haven’t done before. It will be more challenging if you had to make up the list of tests for some, a problem you’ve never solved. For example, Minesweeper, Game of Life, Roman Numerals. All those Code Katas are out there on the Internet. Try searching for them and I’m sure you’ll find a good description. Another thing you could do is repeat one of the Katas you already know, but this time using a constraint game. I explain more about constraint games in the previous module, and that can be a way to help you to practice your skills, and learn more about test room and development. So, that’s the end of this module. We’ve gone through how you could set up five different Coding Dojo meetings and ways to follow them up with further meetings on the same kinds of topics. I hope you’ll find this information useful enough. That you’ll be able to start your own Coding Dojo with your colleagues. In the next module, I’ll have a little bit more information for you, the person who’s facilitating these meetings. What you should be thinking about when you’re planning the meeting, and what you should be doing during the meeting.

Organizing and Facilitating a Coding Dojo

Introduction to Facilitating and Organizing Coding Dojo Meetings

This module is all about organizing and facilitating a Coding Dojo. You may not have done much facilitation before, and as a programmer, you’re a member of a group that’s not renowned for having great social skills. I don’t think facilitating a Coding Dojo is fundamentally harder than performing a code review, conducting a retrospective or interviewing a perspective team member. And, well, if you’re a team lead, you’ve probably already done some of those things. This module will give you some more specific pointers about what to do in a Coding Dojo. We’ll talk about how to organize your Dojo, how to set up the Room in advance. And then during the meeting, what the structure of the meeting is and the activities that you’ll do, and how you can handle difficult questions that might come up, and then what to do after the Coding Dojo to follow it up. In the last module, I showed you this slide and recommended that you begin by booking a series of five meetings for a group of 5 to 15 programmers and that you choose the end of the iteration or the same day each week, so it’s a regular time. That module also went through detailed meeting outlines for these five meetings, and lots of suggestions for how to follow up meetings on each of those topics. So I hope that will be enough to get you started. But when you’ve booked those meetings in your calendar, what next? So who should you invite to your Coding Dojo? Well, obviously, people who want to learn practical coding skills. I think it’s quite counterproductive to force people to be there against their will. I mentioned a figure 5-15 people because I think that’s a good number if you’re going to have discussions where everyone will feel comfortable to say something. If you have less than that, the discussion is just less interesting. You should try and invite a group of people who are going to feel safe with one another. When you’re learning something, you’re going to be vulnerable, you have to admit that you don’t know things. That can be difficult if there’s someone in the room who’s your superior, maybe the person who’s responsible for deciding your salary. You should use your judgment about whether to welcome high up bosses to your Dojo. At least make it clear that everyone who comes is expected to write code. Then you need to decide whether to invite colleagues, people you work with every day or whether to find a group of friends to do a coding dojo with. Well, if you can find colleagues to do it with, you’ll probably may be doing the dojo on work time and you’ll be able to discuss your production code. You might be able to make a real difference to your daily life and how you work together. On the other hand, I have personally run lots of public dojos and it’s a very fun activity to do as a conference or a user group. You should do what’s best for you in your situation.

Preparing the Meeting Room for Your Coding Dojo

First I would like to talk about the way you prepare the room where you’ll hold your dojo. The idea is to make a space where collaboration and discussion feels natural. My preference is for a conference room where you’re all sitting around one table, where you can see the projector screen and have access to a separate white board. If you haven’t got a white board on the wall at the side, you can just have a free standing flip chart, at the front next to the projector. If you don’t have a big enough table for everyone to sit around, you could arrange smaller tables into a horseshoe shape sitting around the outside. You want people to be able to see each other and the screen. If you’re working in pairs, you’ll need laptops. And power outlets. There should be enough room for you to move around the outside of the chairs, as you go between the pairs and review their code. I recommend that you ask people to bring not only a laptop, but a mouse. A mouse is much easier to use than a laptop track pad. If possible, also, get people to bring a separate keyboard. It’s easier to pass a separate keyboard between the pair. If you’re doing a Randori altogether, you’ll only need one laptop. If the projector cable is long enough, you can actually move the laptop around the table as you swap pairs. Alternatively, you can have everyone stand up and move one chair around the table. Some groups prefer to make a bigger distinction between the pair who have the keyboard and the audience. So you could place them a little bit separately on a table by themselves called the hotspot. It can help the pair to be less distracted, especially if they are facing a little bit away from the rest of the group. Another variant is to have the navigator stand up. The navigator is the half of the pair that doesn’t currently have the keyboard. If they stand up, it forces them to talk loudly so everyone in the room can hear. And they can point at the big screen, when they’re making suggestions to their pair about what to type.

Meeting Structure and Introduction

As I mentioned before, a coding Dojo meeting has four main elements. First, you introduce the Dojo and welcome people in. You agree the activities. Talk about the theory of the skills you’re going to be practicing. Then you write some code, do some concrete practice. And towards the end, you hold a retrospective, where you discuss what you’ve learned, and how you’re going to apply it. I’d like to go through each of these elements in more detail now, talk about what you’ll do at the meeting, and how you as a facilitator could prepare in advance. When you introduce the coding Dojo, you’re not only introducing yourself, you’re also introducing people to each other. You’re setting a collaborative learning environment where people feel safe to learn together. You should also talk about the theory of how the coding dojo is supposed to work. The different kinds of practice, the fact that you’re expected to voice your opinions and ask questions. Explain that you’re the facilitator and not the teacher. Everyone in the dojo has something to learn and something to teach. No one is expected to be an expert at absolutely everything, including you. The dojo should be a fun environment. Your job is to establish a good atmosphere, where people are going to have fun and learn something. The latest research actually shows people learn far better in a relaxed, informal environment. So to prepare for this part of the meeting, you need to prepare something to say about the Coding Dojo Theory. Review the first module of this course, you can even show some of that plural site video to the group. Try to establish an atmosphere where people don’t hold back from saying something, because they think their question is stupid or their comment is naive. That’s probably not the case.

Agree Activities

In the Agree Activities part of the meeting, you maybe want to talk a little bit about what happened at the previous meeting. How does today’s topic relate to what we did then? Is everyone okay with moving to a new topic? By topic, I mean something like refactoring or test case design. The thing you’re really trying to learn about at today’s dojo. You should probably talk a little bit about the theory of the topic. And find out what people already know about it. Then you’ll need to find a Code Kata that you can work on and agree a format, a collaborative game, to work on. So as the facilitator, you should come to the meeting prepared to explain some theory about the topic you’re going to work on, and maybe you’ll have tried out A Code Kata or maybe a couple of different ones to find one that will fit for the topic. In the meeting, you’ll be needing to help people to get started with the topic, and to be able to explain the point of the code Kata. You should also suggest a collaborative game, or ask people what they’d prefer to do. Perhaps somebody would like to perform a prepared Kata, and hopefully they talked to you about that in advance in the meeting. I called this part of the meeting agree activities because I think it’s important for people to feel they have a say. As a facilitator, you trying to create this environment where everyone can learn. And people learn better when they feel they’re in control of their learning and they can contribute what they already know. So do try to be flexible. If people come with suggestions of particular activities, or if they want to jump in and teach some theory about particular topic, or do a different Code Kata that they have been working on, you should welcome all of that.

Facilitating the Coding Part of The Meeting

The part of the meeting where you write code is the longest section, and it’s where most of the learning actually takes place. Coding should be really fun. You’re working on a simple problem, bounded domain, there’s no customer breathing down your neck with a deadline. And you can just really enjoy writing some really good code. As a facilitator, your role changes a bit according to what activities you’ve chosen to do. There’s a whole module in this course about the kinds of collaborative games that you can play. So, if you’re working altogether as a group on a Randori or a g/ Prepared Kata, your role is really moderating the discussions. Keeping things on topic. You could also make notes of issues you don’t want to raise straight away but you want to discuss in the retrospective. On the other hand, if people are working in pairs, your role is more to go around from pair to pair, spending a few minutes with each. When you come to a pair, you read the code and give them some feedback on it. Ask some questions. Make some observations. Be friendly. I find that if you praise people as well as criticize them, it makes it much easier for them to accept the criticism. Of course it’s not wrong to just praise people anyway. The way you talk to people is very important too. You’re really trying to maintain this safe, helpful atmosphere where people are being friendly and learning together. I really recommend when you go to a pair that you try and phrase your comments as questions or observations. So, for example say, do you think it would be more readable with a SetUp method here, instead of saying, I think you need a SetUp method. Can you see that by asking the question, you’re inviting for collaboration and discussion. Whereas by issuing a command, you’re making people feel defensive. Another example, where instead of a question, you just phrase your comment as an observation. That test has two assert statements. Rather than, tests should only have one asset statement. Again, you’re trying to say it in a neutral way that will invite people to talk to you, and consider your point of view. Not just get defensive and, and not change what they’re doing. Praise is also very important. You can say to people, oh that was a really good refactoring. I liked the way you used really small steps. Or, I like the way that test reads, it has a very clear arrange, act, assert structure. Saying things like that can really encourage somebody and they’ll better remember what they’ve learned.


The retrospective is the part of the meeting where you stop coding and reflect on what’s happened, review the code you’ve written, and discuss how you wrote it. If you’ve worked in pairs, you might want to share some of the code you’ve written with the whole group. If you’ve used a tool like Cyber Dojo, You might have some logs that show how well you’ve been doing at taking small steps. And running the tests often. I’ll talk more about tools for that in the next module. In general you’re trying to relate What’s happened in this meeting to what is going on in your everyday situation with your production code maybe so that you can take some learnings away from the dojo back into your daily life. So as the facilitator of the retrospective Your first job is to make sure it happens. Keep time and stop people coding when there’s ten or 15 minutes left. Then you need to make sure there’s a discussion that gets going. Ask some questions. Ask somebody to share some code. Point at it. Get people to comment. When you’re discussing what you’re going to take away from the meeting, you might ask people to write that down themselves, or you could take notes somewhere visible to everyone, on a flip chart or a whiteboard. So, one of the things you might do is get some code up on the big screen, and then ask for comments or make comments yourself. Now you have to be a bit careful when you do this it’s a little bit different in the retrospective when everyone is looking at the code compared to with if you’re just going to a pair and it reviewing it with them kind of in private. The situation actually reminds me quite a lot of my daughters violin group, most weeks the teacher will ask 2 or 3 children to perform a piece for the group. And afterwards she asks everyone for comments but she has a strict rule. You are only allowed to say nice things. The teacher knows it’s very difficult to accept criticism. Especially when there’s an audience and you want that person to be willing to stand up the next week and do a new performance. So anytime you got code up on the projector, everyone is looking at it. I think the violin teacher’s rule is a good one, only say nice things. You want people to feel good about sharing their code. And it has to be something nice you can say about it. In the violin group, sometimes they have to resort to comments like You hold the bow very well. Your feet were well placed. You remembered the pause in the middle of the piece. Now I do hope you won’t often be reduced to equivalent comments for code. Good use of white space though. I liked your curly bracket placement.

Handling Difficult Questions

So now I’ve gone through all the parts of the Dojo meeting in turn. And I hope it’s given you a better understanding of the facilitator role. What can happen at any part of the meeting, is that someone starts to object to what’s going on. Maybe they asked some awkward questions, challenge what’s going on, start getting angry or aggressive. And that’s not good. It can destroy a safe atmosphere and it’s not very easy to handle for you as a facilitator. I’d like to mention some of the most common objections I’ve heard and suggest how you might handle them. So, what if somebody says, Code Katas are just toy code, they don’t teach you anything. Well, you could remind people that actually, a code kata is to help you focus on practicing a specific skill. And by working on an easy problem, it means you can be successful at applying that skill. And that’s helpful when you’re learning. The other thing about a Code Kata is it’s so easy. You can experience test driven development working well, and that might be very encouraging for you to want to learn how to do test driven development on a harder piece of code. Another thing someone might say would be, well test driven development is all very well But I have better ways to produce good code, basically saying, I’m too good to do TDE. Well, you might not think they are, but it probably isn’t very politic to say so. You could point out that test-driven development is maybe a skill worth learning. It could be a tool in your toolbox even if you don’t choose to use it all the time. You can also point out that there are very good developers who use Test Driven Development all the time. people like Kent Beck, Robert Martin, also known as Uncle Bob. Of course there might be something in what they say. They might generally have better technique for writing such good code and in that case perhaps they could demonstrate it for you. And the whole group could learn something. Another objection could be well I can do test driven development in the Coding Dojo, but I find it too hard in my production code. I think you probably want to reassure that person that test driven development is a complex skill and it will take time and effort to master. And if you can do TDD in the Coding Dojo. On easy problems, that’s a really good start. A lot of the code out there does have a poor design. And that makes it hard to test. And part of the reasons you’re getting people into the Coding Dojo, learning TDD, is so that you can improve that situation. Somebody might come and say. Well it’s ridiculous to work in such small steps all the time. It’s far too slow. Well, perhaps you should see this as a tradeoff. It might be slower, but it could also be less risky. You might introduce fewer defects if you take small steps. Then there’s a question. Well, is it really slower? There’s story about the tortoise and the hare. If a really difficult question comes up in the middle of a Dojo, people might start to get angry. People might not want to stop talking about it. It could distract from everything else that’s going on. One technique that you as the facilitator can use, is to create a parking space on a flip chart or white board. And there you can write up a summary of the issue. Make it clear that you’ve heard the question. You think the issue does need discussion. But you want to park it, postpone the discussion for now, and write it on the wall so that it’s a visual reminder that you want to take it up again at a later time. Maybe in the retrospective, or if people are really angry, it might be wise to wait a bit longer, maybe until the next meeting, when everyone has had a chance to think a bit more and calm down.

Following Up and Moving Forward

After the dojo, hopefully people will be feeling encouraged that they’ve improved their coding skills. Perhaps they didn’t quite finish what they were working on, so they want to actually do the same kata again, by themselves. Or maybe somebody will find a screencast of another programmer doing the kata, and email everyone a link. Perhaps somebody will be reading about a new kata that they want to try out. We’ll maybe find a Pluralsite course that takes up the topics you’ve been discussing in your dojo. If any of that kind of thing happens I think you should feel really encouraged. People are taking control of their learning. It could also happen that when you are working in your production code. We’ll be trying out some of these TDD techniques perhaps you run into difficulties but that could be an opportunity to help you choose the topic of your next dojo. Or may be even designing a new code kata based on your production code. In the sample series of five dojos that I outlined in the previous module, each dojo was on a different topic and that can be a good strategy to start with. In general, though, you might want to follow up a dojo meeting with another one on the same topic, perhaps, doing the same kata. If you’re going to do the same Kata again you might want to change something. Like introduce a different constraint game that you haven’t done, or a different programming language, or maybe ask someone to give a prepared Kata demonstration of it. Of course it would, it might be more fun to find a new Kata Perhaps in the same topic area or of course you can’t move on to a new area, perhaps take the same kata with you or find a different one that you’ve done before. You need to do what you think will keep everyone interested. Balancing repetition becoming expert with a particular kata and without getting bored. So, in this module, we’ve talked a lot about the practicalities of organizing a coding dojo and your role as a facilitator during the meeting, planning before the meeting, handling difficult questions and then following up after the coding dojo. In all this work, planning and facilitating Coding Dojos, try to keep in mind the reason you’re doing it. You’re hoping to take your team with you, further along this road to becoming a great programmer. Expert in test driven development.

A Tool for the Coding Dojo: Cyber-Dojo

Why might you want to use a tool in your Coding Dojo?

This module, we’ll be looking at tools for the coding dojo. We’ll talk about what a tool could contribute to your coding dojo and then I’ll give you a demo of Cyber-Dojo, which is a tool that I’ve used quite a lot in my coding dojos. Normally, it’s good to practice with your usual tools so you get more proficient at using them. It becomes more fluent. It can be useful to augmentable your toolset with some tools that are specific for the Coding Dojo. As a participant, you can use a tool to give you extra feedback on how well you’re doing a test dojo development. For the facilitator, it can make the whole experience managing a Coding Dojo a lot easier. A tool can help you to set up a Code Kata. And then, during the session, direct your help to the pairs that really need it. And, then, during the retrospective, they can help you to share the code with a group. So a Coding Dojo Tool is most often useful when you’re doing Randorian pairs, actually.

Analysing a Test Run Log

On this slide, you can see two examples of test run logging. The first is created by a tool that you can download from and the second is from Cyber-Dojo which we’ll be looking at in some detail in this module. What this is, is that every time you run the tests the tool records when the tests have passed, green. Or if they failed, red. Yellow indicates a compiler error. So in the first graph, the height of the bar indicates how long it was since you last run the tests. Now this graph might be quite hard to read if you’re color blind, although it does display all the information in quite a compact format. The Cyber-Dojo, it uses this traffic light format where red is at the top and green is at the bottom and it leaves gaps between each traffic light to show long it was since you last run the tests. So the format isn’t so compact, but it works well even if you’re color blind. So either of these tools could be a helpful source of feedback on how well your doing test driven development, are you running the test frequently when you run them do they pass? Are you seeing a consistent TDD cycle with regular switching between red and green? Well actually both V sessions but for when the person was doing a re-factoring carter and for that you might expect that all the test runs should be green. But actually people make re-factoring mistakes and sometimes the tests fail if there’s a compiler error. And in these graphs you can see whether the component error or the test failure is being corrected quickly. In the top graph you can see that mostly, the re-factoring is successful. Although there was a period in the middle of the session where there were about seven or eight failing test runs, where clearly there was something going on. But eventually they got back on track and were back at mostly green. In the second output from Cyber-Dojo, you can see much less of the session, but you can still see that the refactoring is generally successful. And even when the tests start failing. They get them passing again quite soon. So here’s another example of a cyber-dojo test run log, this time when you’re doing normal TDD cycles. And you can use this to analyze how well you’re doing TDD. So you can see that this person started by writing a failing test made it pass, and then you can see they must have been doing some re-factoring there’s a few compiler areas but then your back at a green bar again. And then of course their writing a new failing test it takes a little while to compose a test and see it run and fail and then quite quickly they can make this test pass there’s another green run quite rapidly. But then you can see they go straight on to write a new failing test with a compiler error in between. And then this time, it takes a little bit longer before they can make the test pass. There’s some, another failing test run and some compiler errors in between. So hopefully you can see from this analysis for a whole session you can start to draw conclusions about how well you are doing to TDD. Whether you are managing small cycles. Whether you are remembering to refactor. Whether you are remembering to do the simplest thing Possible to make the, pa, test pass quickly. You can also start comparing your output, your test run log with somebody else who’s maybe more experienced with TDD than you, and you can have a good conversation with them about what it is you need to do to improve the way you’re doing TDD.

Revert To Last Green - Practicing Refactorings

Another feature that some tools have is to help you when you’re practicing refactoring. They can make it easier for you to abandon a failed refactoring and practice it again. So here’s another test run log from Cyber-Dojo. This time its compressed so you can’t see how long each step took but you can see more steps. This is also a refactoring carter. Occasionally you can see a red traffic light followed by a green one with small dots in the middle. Now that means that there was a failing test run. And then in the next green run what they’ve done is reverted the code to previous state in order to make it go green straight away. So what this person has done is abandoned a failed re-factoring, so that they can practice it again. You can of course achieve a similar effect if you just make a local commit every time the tests pass. And then, when you find yourself with an unexpected failing test run, you can just roll back your changes. And a tool of course just makes this process much smoother, by making sure you don’t forget to do that commit every time your tests pass. There is an added benefit though. CyberDojo can help you to analyze your entire test log, how often you were needing to repeat a refactoring. And of course, you might also identify if there were times when perhaps you should have done a revert so you could practice it again.

Setting-Up A New Code Kata in Cyber-Dojo - Demo

I’d like to show you how to use the tool cyber-dojo. As a facilitator, I’ve found this a very useful tool, so I’d like to take you through some of its main features First I’d like to show you how you can setup a new code kata for a group so that they can all get going quickly and easily. You point your browser at, and then you press this button Setup. And you’re taken to a screen where there’s a list of programming languages and you choose one you’d think your group would like to work with. And then an exercise, and there’s a long list of code Katas here, you can see there’s Leap Years which I’ve already shown you, and Fizz Buzz, which is another easy Kata, so you can select a carter and there’s a description of it that you can read to check that it’s suitable for your group. And then you click okay, and it will create you a new cyber-dojo instance, for your group to use, for this, particular cording dojo. So what you do is you take this practice ID, that it’s assigned you for your dojo, and you write this up on the whiteboard or the, flip chart, and you say to all the participants in your coding dojo, go to, enter this practice ID, and then you should press, start. You’ll be assigned an animal. Each pair that goes into the cyber-dojo gets assigned a different animal, and it’s a good idea for them to take a note of which animal it is. You can always get back, into, the same coding environment, if you’ve lost your, network connection or your, net, laptop crashers or something, you can always get it back by knowing the practice ID and the, the animal. So, in this case ,I, I’ve got elephant and I come into a coding environment, here. And the first thing it does is run the tests. And as you can see, you start out with a failing test. It’s just a really boring empty test that says I expected 54, but it was 42. And that’s is a signal to the a person who’s come into the cyber dojo. Now you have some work to do. You have to make that test pass. And when you’ve made that test pass, it shows you’ve understood how the tool works. So what you can do here is you can look and you can find, here, we’ve got a Java Source code file and a J Unit test. And it’s this J unit test which is failing. You’ve also got the instructions for the code Kada. The test run output, which we saw earlier, and that’s being produced by this shell script, which just shows you how it’s compiling. The code with J units and then running J unit on the, all the tests files it can find. You wouldn’t normally need to actually edit this file, it’s just there for your information so you can see how cyber-dojo works. So when the pair comes into this side of the dojo, the first thing to do is to work out why the test is failing and fix it. And I’ll just show you that. So here, this test is multiplying 6 by 9 and saying that’s the expected result. And then it’s calling this untitled class, and asking for it an answer, and the actual answer that we’re getting doesn’t match. We can see in the output that we’re expecting 54, but we’re actually getting, 42. So the easiest way to get this test to pass, is to change the expected to match the actual. So, we’ll say that we’ll expect 42. And then, we can run the tests again. And see that this time, the tests pass. And we’ve got, a green traffic lights down here, to show that the most recent run was a passing test run. And these are the previous failing test runs. So then I can go, and proceed with this code cutter. I can go and read the instruction, work out. Actually I need to rename these untitled classes and tests and write a new suitable test for PhysBuzz. The point of arriving in cyber-dojo with a failing test that you need to fix, is so that you have to understand immediately how to use the tool. And very quickly as a facilitator, you can also see if people are managing to get this test to pass and getting up, and getting running.

Facilitator Overview - the Cyber-Dojo Dashboard

Another way that cyber-dojo is very helpful is the way it gives you as a facilitator an overview of what’s going on. So here I’ve got the same elephant environment that we had before, but I’ve also added another participant in this dojo deer. And if I go back to the home page, I can actually see an over view of everything that’s going on by pressing this review button. So it gives me a bit of information about this. But here I can the two animals that are participating in this dojo at the moment, the elephant and the deer. And you can see that the elephant currently has passing tests. And the deer also has passing tests and has had a few more test runs. And here this page is actually being updated in real time. See if I go back here and break this test, and run it again. I should be able to quite soon see a new traffic light appear on this dashboard. There it is, showing that another test run has been done by the elephant pair. So, as a facilitator, what you can do is, to put this up on the projector, where you can see it, while you’re going round all the different pairs and talking to them. And from this you want to be able to spot if one of the pairs is having a problem. Maybe they haven’t had a test run for a very long time or they’ve been having a long series of red test runs. And then you know, I better go talk to the pair who’s using that animal. So this is a very useful tool during the dojo, for you to direct your efforts.

Using The Cyber-Dojo Dashboard in The Retrospective

So when you get towards the end of your coding session, you should end up with a cyber-dojo dashboard that looks a bit like this. You have a test run log for each pair, and you can see whether the tests are currently passing or not. By the most recent traffic light here, by each animal, and then when you stop the group for the retrospective you can have a discussion. You have this up on the projector and you can look at it, and there is a couple of things you can do to make it stop moving, because it is automatically updated. If you press disable auto-refresh then it will stop, putting new test runs on. And you can also increase the number of columns you can see and decrease the amount of space it’s putting between them. And that means you can see more of the test log at once on the screen. So this, gives you perhaps a better overview of what the group was doing. And you can have a discussion about whether there’s any obvious patterns in the test run logs. And also, you can ask people if they want to share their code with the group. So for example, Raccoon might say oh, we’re very pleased with our final design, would you like to look at it? And then you just click on the raccoon, and you can go in and see the current state of their code. And here you can see they’ve been doing the gilded rose carter, and they’ve come up with an inventory class, and a default item, an AgedBrie. And they are all inheriting from the static abstract class item and you can have a discussion about whether this is a good design and whether anyone else has a similar design. You can also have a look at what they were doing during the session, for example, here there is quite a long gap. And suddenly, the tests are failing. We could have a look and see what they were doing at that point, and obviously, they were designing a new test case. So you can have a look here at the diff between, when it was green and when it was red in this run, and there were 12 changes to this file, and it was adding this test. So that was obviously a TDD step: “Write a failing test” and you can analyze “why haven’t they got it to pass yet”? I don’t know. Well you can see there is a long gap here (green bar to green bar) that should have been a refracturing. May be we can see what that refracturing was. Well look here they were introducing this Sulfuras class. And there are also some changes in the test code to do with that. So that’s just some of the things you can do in cyber-dojo in your retrospective, to quickly share with the whole group some of the things that people have been doing, and have a look at the code. It’s a lot faster and more convenient than having to pass the projector cable to each laptop and show each code in turn.

Setting-Up A Custom Starting Position in Cyber-Dojo

I’ve already showed you how to set up a new cyber-dojo instance for your coding dojo meeting, and all the different Code kata that it supports. But sometimes you might be wanting to do a different kata that’s not on this list. So, I’d just like to show you how to set that up. Again, you need to choose your programming language. And then instead of choosing one of these katas off the list, you can choose Verbal, which means the instructions just say Listen to the instructor, you’ll tell them at the time what it is they are supposed to work on. And then you can hand out the practice ID straight away or you might want to a little bit more set up and set up a test to be failing at the start. Or you might want to work altogether on the first test and then one needs splits up into paths. So if you make a note of this practice id, it will be opposition that you can set up for this particular dojo. So just start as before in the standard starting position. Only this time, of course, the instructions are largely empty. If you’re going to set this up in advance and then share it with a group, you might actually want to write something here. So in this case actually, I am going to write something. I’m going to set up the first test for the string calculator cutter, so I’m going to put the instructions here. I’m just going to get those off Roya Shrubs website. Then I might want to do a little bit of formatting, some of these lines are a little long. So there now I’m happy with the instructions. Now I’d like to just set up the starting position with a different first test. There, so now I think I’ve set up a suitable starting position. Where you have a failing test for the at in this string collector, and I’ve got an appropriate method here for people to start working on. So now I want to share this with the group and I can do this very easily just be pressing this button fork. Gives me a little explanation of what this will do and then it will give me completely new instance of cyber-dojo with the new practice ID. And this is the one that I should then share with the group and as each person comes and enters his practice ID and press this start, they could assign their animal. And they are set up with this position to start with. As if it was the first thing that had ever happened in this particular instance, and they can start working on this as they wish. So for you as a facilitator you can set up this in advance and come to your coding dojo with a practice ID that you hand out, and know exactly the starting position that everyone is going to have.

Summary - what a tool like Cyber-Dojo is useful for.

So now I’ve showed you a bit about how to use cyber-dojo in your coding dojo. And actually, it’s the best tool I know of for this purpose. It’s free and open source invented by a friend of mine, John Jagger. And he’s responsible for this public server. Actually I think the tool does have disadvantages too. One of the things it does is it always enforces this constraint that you’re coding in a plain text editor. Now that’s a constraint game, and it can be interesting to play it because it makes you get back to the basics of coding and how your language and tools actually work. On the other hand, when you’re doing practice, you might prefer to be practicing in the coding environment you know your integrated development environment. Now there are, of course, some plug ins for your IDE that would provide some of this functionality, for example test run logging. But actually I haven’t found anything with all these tools for the facilitator. Future tools, of course, might be better. And this module is likely to be out of date quite quickly. But anyway, I think we’ve gone through some of the reasons why you might want to use a dojo tool. Test run logging is really useful for feedback on how well you’re doing test driven development. Bering able to easily revert the code to the last green run means that you can revert and practice refactorings again and this time hopefully not make refactoring mistakes. This overview that you get as a facilitator helps you to see what pairs are up to and which pairs might need your help during the meeting. Then, at the end, it can help to just be able to easily put up code and diffs on the screen, so everyone can see and discuss it. It’s much simpler than actually passing a cable around to each laptop. And now that I’ve just shown you how to set up a starting position so that you can work on a different Code Kata with your group, and have everyone start from the same code. So that was the last module in this course about the coding dojo. I hope you have all the information you need now for a very successful coding dojo where you’ll learn loads and become a better programmer.