The Three Laws of TDD by Uncle Bob

[Liutauras Vilda]

If you find some time in between your busy times, I recommend to watch this.
Many of you probably have heard about the TDD and probably quite a big portion of people still thinking what that is.

No more, no less - enjoy this inspiring talk and try to get better understanding about the TDD, and might coming Monday will be the day you started...!

[Liutauras Vilda]

Now that I just finished watching this completely, I'd say Bob just scratched the surface with this, but I'd put emphasis on the very first 25 minutes where Uncle Bob explains importance of tests, more importantly, about desired code coverage which is being tested. He's clearly reasoning, why writing tests at first is rather important comparing to writing them afterwards.

And then, what's after very first 25 minutes, I'd say are basics, which should be sufficient for the TDD beginner to start with.

Q&A session might be too advance for starters, so you can skip if that's the case.

After all, TDD isn't only about the writing tests and passing them, it is much more than that. In case somebody wants to expand on this - please join me.

[Junilu Lacar]

I don't know if this is the one I've seen before but on this particular subject, Uncle Bob usually concedes that these aren't really "laws" as they are guidelines.

This goes back to the three stages of learning, Shu-Ha-Ri. When you're a beginner learning TDD, it's best to try to stick to the form and sequence, Red then Green then Refactor. This helps you develop the proper perspective and rhythm for doing TDD. In reality, even experts like Kent Beck will not strictly adhere to that sequence. The important things are:

1. THINK about your design. Design thinking is really what you're driving when you TDD.

2. Focus on simplicity when you refactor. The three techniques you'll use the most: Rename, Extract, Compose Method. These can get you at least 80% of the way to clear, clean, and expressive code.

3. Use the Four Rules of Simple Design as guidelines for achieving simplicity in your design and code.

4. Be conscious of any deviations from the Red-Green-Refactor sequence, especially if you're doing Green before Red. Beginners and people not used to TDD usually have a strong tendency to revert back to GREEN before RED. It's almost an uncontrollable thing so you have to be very conscious of it and correct yourself when it happens.

[Campbell Ritchie]

Junilu Lacar wrote:. . . When you're a beginner learning TDD, it's best to try to stick to the form and sequence . . .

Surely that should read, “When you're a beginner learning anything…”

When we have the plumber, Simon, round in a week or two, I shall ask whether plumbers' apprentices are still taught to use a blowlamp and rolls of solder … and when they have their C&G they use compression fittings and a spanner. Shouldn't all trainees stick to form and sequence and when they are experienced they will know how much they can deviate.

[Campbell Ritchie]

Junilu Lacar wrote:. . . This goes back to the three stages of learning, Shu-Ha-Ri . . .

This link about ShuHaRi from Martin Fowler suggests the last stage is the fighter learning from themselves not others. But surely you shou‍ld keep on learning from others for ever?

[Junilu Lacar]

TDD involves a lot of learning.

In one sense, TDD helps you learn about your API and what your software wants to be. That may sound odd, "what your software wants to be," but that's how I like to see how TDD helps me in discovering and evolving a good design. You let your tests act as guides in discovering the kind of code you'd like clients to be able to write. You experiment with different names and interactions between classes to see which "conversations" make the most sense.

In another sense, you the programmer have to learn a lot of things outside of Red-Green-Refactor. You have to learn about design principles, how to apply them, how to detect violations of principles, how to detect code smells, what the different code smells are, what do good, clear tests look like, how to make your tests simpler and clearer, how to make tests reveal their intent, how to tell if a unit test wants to be an integration test or some other type of test, and many more.

You have to learn the ins and outs of your tools, your testing framework, and the language you're using and the different features and idioms for using it to its full potential.

All these things influence how well you can do TDD. If your programming practice is weak in some of these areas, those weaknesses will also affect your ability to do TDD well. So the more you work to strengthen those parts of your programming practice and prowess, the more you increase your ability to do TDD well.

You might even say that just as "Agile doesn't fix your problems, it reveals them," TDD won't fix all your programming problems but it will reveal them.

[Campbell Ritchie]

Isn't revealing a problem a large part of correcting it?

[Junilu Lacar]

Campbell Ritchie wrote:

Junilu Lacar wrote:. . . This goes back to the three stages of learning, Shu-Ha-Ri . . .

This link about ShuHaRi from Martin Fowler suggests the last stage is the fighter learning from themselves not others. But surely you shou‍ld keep on learning from others for ever?

I'm not sure I'd characterize it that way but I kind of get what Fowler was trying to say. I don't think he meant so much to exclude other sources of learning because you're right, you're constantly learning from others. I've often said that when I'm training in the dojo, I like working with beginners and students who are not as experienced as I am because they react to techniques differently from how other black belts react. Same thing when I'm pairing to do TDD with people who have less experience than I do.

I think by saying that at Ri, "the student isn't learning from other people, but from his own practice," Fowler wants to emphasize the importance of self-awareness and introspection. You have to learn from your own mistakes. In Shu and Ha, you didn't know better so you need someone to tell you what mistakes you made and how you can do better. In the Ri stage, you should be self-aware enough to correct yourself and be able to find ways to make your practice better. Obviously, you also have to put in the time and effort to be able to do that.

It might help to contrast how Fowler explains Shu Ha Ri with how traditional martial arts instruction views it. ShuHaRi is traditionally summarized as "Follow the form, Break the form, Be the form." Alternatively, Ri can be thought of as "Lose the form" or "no form" or "empty form" and is related to what Bruce Lee famously said about being like water.

[Liutauras Vilda]

Junilu Lacar wrote:All these things influence how well you can do TDD. If your programming practice is weak in some of these areas, those weaknesses will also affect your ability to do TDD well. So the more you work to strengthen those parts of your programming practice and prowess, the more you increase your ability to do TDD well.

Is TDD something you'd recommend for the starter in programming in general to start with it early on?

Most Universities probably 2 or 3 years teaching solely plain programming. Do you guys think that TDD even though it wouldn't be anywhere near optimal could be a preferred approach or just would add extra complexity without much of a benefit?

When student supposed to start introducing himself to such approach to tackle problems?

[Liutauras Vilda]

Liutauras Vilda wrote:When student supposed to start introducing himself to such approach to tackle problems?

I guess many of people still thinking about it as about a technique which derived from some secret cult, and that isn't something you need to consider for sure as there are possibly many other similar or not so approaches.

Taking in account a various listened talks, read articles - to me makes a perfect sense a suggestion to start with a test and let it drive your design that way, as a bonus you have written tests as you'll need to write them anyway.

But why TDD is so niche area, at least I'd think how it looks to most of the programmers. Everybody knows, every says it is good, but rare one does that.

[Liutauras Vilda]

Earlier, I wrote:Is TDD something you'd recommend for the starter

Earlier, I wrote:Everybody knows, every says it is good, but rare one does that.

Isn't it something you need to build into as a habit during early days? Uncle Bob in one of his other talks call having an early test suite a green button, about which he later mentions, that if you ever get that button, you'll never want to lose it or work other way round so you wouldn't have it. Now that gives clues, that it is a preferred approach almost always.

[Junilu Lacar]

Aikido founder, Morihei Ueshiba, who is referred to as O'Sensei by Aikido practitioners, was said to have been asked by a student one day, "Sensei, out of all the techniques in Aikido, which one is the most important?" O'Sensei reportedly answered, "Ikkyo is the most important technique."

Ikkyo (literally, "first technique") is naturally the first technique Aikido students learn. It teaches timing, balance, centeredness, entering, getting off the line of attack, and other things that are foundational to all other Aikido techniques. It isn't as flashy or as potentially devastating (in appearance) as other techniques like Irimi Nage (one form of which is what Steven Seagal does in his movies, otherwise known as the "clothesline" technique) or Kotegaeshi (wrist turn throw).

Compare how Seagal does Iriminage: https://www.youtube.com/watch?v=dJm8yDnYoRQ to how other Aikido masters, like Christian Tissier, do it: https://www.youtube.com/watch?v=1UjYxpDcMsA -- Tissier's iriminage is much softer than Seagal's usual way of doing it, which is very hard. Tissier has a much more refined iriminage. Their kotegaeshi look about the same though but I'd really have to feel each one to be able to tell the difference. Tissier: https://www.youtube.com/watch?v=TvkMWCS50i8 vs. Seagal: https://www.youtube.com/watch?v=rljlUNHgoLk

Here's what Ikkyo looks like (C Tissier): https://www.youtube.com/watch?v=xNEO64tjjuk

Anyway, when O'Sensei said Ikkyo was the most important technique, he was probably alluding to its foundational nature and the fact that even though it's the first technique taught to beginners and therefore seen by many as a "beginner's" technique, all good students find themselves going back to it and finding more and more nuance in it as they learn "advanced" techniques. Going back to basics and learning more of the nuances in them feeds improvements of your entire repertoire of techniques.

This is why I like the Four Rules of Simple Design so much. This is the "Ikkyo" of design and software development. This is what you can always go back to and find nuance that will help improve your entire repertoire of software development skills.

[Junilu Lacar]

Liutauras Vilda wrote:
Is TDD something you'd recommend for the starter in programming in general to start with it early on?

Aikido and other martial arts can be and are taught to very young children, some as young as 5 yrs old. Obviously, their level of instruction is not to the level it would be for adults. I think it would be good to introduce students to the mechanics of TDD when they have a basic understanding of problem solving as it pertains to programming. I think having them learn how to write unit tests will be a good way to prepare them to tackle the challenges of learning TDD.

One thing I would be interested to see is a study that compares students' progress when you introduce TDD-related skills and practices early on in the curriculum versus if you introduce them later versus not bothering with anything related to TDD at all. I would hypothesize that students who were taught with a strong leaning towards TDD mindsets and practices would progress farther and faster than others.

Yes, I think things like refactoring and the Four Rules of Simple Design should be taught earlier than they are now and I think that can eventually lead to teaching students how to do TDD earlier than it is currently, which is either never or very late when students have already established the kind of mindset and a set of habits that actually impede learning TDD effectively.

[Junilu Lacar]

Campbell Ritchie wrote:Isn't revealing a problem a large part of correcting it?

I don't see those kind of sayings as absolutes. They're really trying to make a point by focusing on a certain perspective. Of course in reality, people try to do Agile or do TDD to address/fix a problem they're having. The point of saying that "it reveals problems" is that if you practice TDD and find that it's not very effective for you, then the problem may not be in TDD itself but rather that you might not know when and how to refactor, or you don't know enough about code smells, or you're not very familiar with design principles and patterns. So you have to consider the possibility that you need to learn more about the basics rather than dismissing TDD as an ineffective technique.  

Put in another way, it's similar to the point being made with "Aikido works, your Aikido doesn't." Replace "Aikido" with "Agile" or "TDD".

[Junilu Lacar]

Here is a longer video of Tissier Sensei teaching differences and nuances of how ikkyo can be performed -- https://www.youtube.com/watch?v=RX3Oru_CbKY

To advanced students, there's a lot that you can pick up from this. Beginners may be able to pick up a few things and feed it back to their learning. If they come back to this video after a year or two of practice, I'm sure they will be able to pick up more from what Tissier is teaching here because they will have (hopefully) gained more experience to help them put the information into context. That's another thing that's important: the contexts that experience allows you to match with new information and absorb it as learning. Experience provides the contexts in which to absorb information and turn it into learning and knowledge.

Learning TDD is like that and so is learning how to program. The more you study the basics and feed that knowledge back and relate it to new experiences and challenges you encounter, the more you can put them into different contexts and learn new nuances and applications of the principles.

[Junilu Lacar]

Campbell Ritchie wrote:

Junilu Lacar wrote:. . . When you're a beginner learning TDD, it's best to try to stick to the form and sequence . . .

Surely that should read, “When you're a beginner learning anything…”

Sure, but we were talking mainly about TDD. Yes, ShuHaRi does apply to many different disciplines, from learning how to play music to learning how to ride a unicycle. Practically anything that involves skill, technique, and practice, so replace "TDD" with any other skill that you can think of and the statement will probably still hold true.

[Junilu Lacar]

Liutauras Vilda wrote:

Earlier, I wrote:Is TDD something you'd recommend for the starter

Earlier, I wrote:Everybody knows, every says it is good, but rare one does that.

Isn't it something you need to build into as a habit during early days?

The human brain is a wonderful thing. I learned TDD when I had almost 12 years of previous programming practice. It took me almost two years to overcome my old ingrained habits and modes of thinking and retrain my brain to think in a way that is compatible with the TDD style and rhythm. Yes, doing it from an early age will probably make learning easier because you're starting with a clean slate but erasing that slate and reversing contrarian habits can be done at practically any age, given the right amount of desire and dedication.

[Junilu Lacar]

Liutauras Vilda wrote:...having an early test suite a green button, about which he later mentions, that if you ever get that button, you'll never want to lose it or work other way round so you wouldn't have it. Now that gives clues, that it is a preferred approach almost always.

I think what Uncle Bob is referring to there is how many people find TDD to be addictive. Seeing that green bar supposedly makes your body produce endorphins that give you a sense of well-being, satisfaction, and accomplishment. That can be addictive to the point where people who do TDD enjoy it so much that they can't think of programming any other way. It's just way more fun compared to finding and fixing problems with a debugger and having to weed through messy code to do it.

[Junilu Lacar]

Let's talk about nuance a little bit.

Uncle Bob's first law of TDD is "You can't write any production code until you have first written a failing unit test."

Let's take "first write a failing unit test." The nuance here that you write a failing unit test. Singular, not plural. Many people make the mistake of interpreting "write unit tests before production code' to mean "write all unit tests first," which of course defeats the goal of incremental development. It also goes against the principle of keeping things small. Small changes lead to small mistakes that you can correct easily. How many things can you mess up in one or two lines of code that you spent two minutes writing? How hard will it be to correct those mistakes? How attached do you become to those one or two lines of code? Compare that to how attached you become to many lines of code that you have spent hours or days writing. Which is easier to throw away?

Also, you train yourself to react positively to a failure: "Oh good, now I get to write some production code to fix it!" and that sets you up for a small kick of endorphins that you get when you see a green bar again.

Those are just a few nuances that come from that simple phrase "a failing unit test".

[Junilu Lacar]

Liutauras Vilda wrote:
But why TDD is so niche area, at least I'd think how it looks to most of the programmers. Everybody knows, every says it is good, but rare one does that.

I have a theory that I've been working into a talk about TDD. It has to do with the Backwards Brain Bicycle. Watch that video (only about 7-8 minutes).

When I saw this video, I thought it was the best description of how people react to TDD. "It's bass ackwards!" said one project manager when I showed her that technique back in 2000. People describe it as "counterintuitive" or "feels weird" and I think few realize that it has to do with how their brain is wired to think. Many people dismiss it or give up on it because "it doesn't fit my style of working."  That's the backwards brain talking.

In that video, Destin starts by saying "I can't ride a bike like you can anymore."  Sounds a lot like how people who do TDD say they can't program any other way any more.

[Junilu Lacar]

I have also found that the more experience someone has, the more likely they are to not like TDD, or at least be very uncomfortable with it at first. Of the engineers who have attended the TDD workshops that I have done in the past at work, the ones that seem to be most open to TDD are those who have fewer years of experience or are really eager to learn new ways of doing things. Those who have more experience seem to have a harder time adapting to the kind of thinking and rhythm you need to do TDD well. Many programmers can't handle writing small increments of code. They want to solve the whole problem all at once. They don't see the value in writing a stub method like this:

public boolean isEmpty() { 
    return false;
}

just to see a Red bar. They want to go to directly to a Green bar and write this instead:

private int size = 0;

public boolean isEmpty() {
    return size == 0;
}

public void add(Object e) {
    ...
    size++;
    ...
}

By doing so, they miss out on all the other things that come with doing TDD: discussions about design options, thoughtful consideration of those various options, exploring the API, etc.

This example may not put those things you might miss into context very well because the problem is fairly well-known and most experienced programmers have enough context to be able to make those bigger steps. However, when it comes to problems that are less common, whose solutions you have to figure out and discover, going slower and considering all options as they present themselves with each small step forward that you take proves to be very effective.

[Junilu Lacar]

Continuing the discussion about nuance. In that presentation, Uncle Bob makes a passing mention of the cycle length, the time it takes to complete a Red-Green-Refactor cycle, At one point he mentions "5 seconds". I haven't listened to the entire presentation yet but I imagine that at some point he may mention something in the order of "1 or 2 minutes" as the cycle length.

In practice, I have have found that beginners can take up to fifteen minutes to complete ONE Red-Green-Refactor cycle. Now, this can be quite discouraging, especially if you've been told by an expert that it should take only 5 seconds or 1 or 2 minutes. Even 5 minutes will seem long in comparison. This is another reason that many experienced developers see TDD as a waste of time, something that any developer has little of to squander away writing code that you're going to change almost immediately anyway.

I think this goes back to something I often say here as well: You need to SEE the code to really understand what's wrong with it. I don't know if it's just a psychological thing or what but when I get to see or even hear the code by reading it out loud, I seem to be able to discern more about what's wrong with it than I would be able to otherwise, from just imagining what the code might look like. The human brain is really good at filling in the detail to create a complete picture and I think just imagining what the code would look like gives the brain too much freedom to fill in the details that are actually missing. Even when we see the code in front of our eyes, we can still miss obvious things, like in that one thread about a stack implementation where it took a comment from Campbell for me to realize that I had missed writing code that avoided a memory leak in a stack pop() implementation.

So, for TDD beginner's, expect to take anywhere from 3 minutes to 15 minutes to complete a Red-Green-Refactor cycle.

The same kind of thing goes for method size. You may hear experts say "Limit your methods to less than 5 lines of code."  Well, that's very difficult to do, especially if you don't even blink when you routinely bang out 300-line methods every day and say "That's nothing. You should see the one I wrote this one time, it was thousands of lines long!" as if that was something to be proud of.

[Junilu Lacar]

Just one comment about Uncle Bob's demo before I head out for a few hours: the speed and dexterity that Uncle Bob shows in refactoring and arriving at the code and algorithm to factor any given number is a bit deceptive at best and disingenuous at worst (not that I'm saying Uncle Bob is intentionally trying to mislead his audience but it would be nice if he could at least warn them that they may not find it as easy as he makes it seem in the demo, because it's not).

Uncle Bob has the advantage of foreknowledge of what he needs to do to complete the demo quickly. When someone learning how to do TDD tries this themselves, it will most likely be difficult to impossible to figure out some of the intermediate steps that Uncle Bob made and arrive at the same final solution.

This is another one of those things that frustrates people with prior programming experience much more than it does beginners or people with less experience. Demos like this make it look like it should be so easy. Actual practice proves otherwise. Experienced programmers don't like that because they'll probably think they could have arrived at the same solution faster and easier without doing TDD. TDD makes experienced programmers feel kind of stupid and inept, and that's not something that they are willing to put up with for very long. They'd much rather do things the way that has worked for them all these many years.

Sometimes trying to mimic each step that Uncle Bob makes helps you understand what he did. You have to listen carefully to his explanation though and understand how to detect the smells and figure out the solutions without Uncle Bob talking in your ear. That's a much harder thing to master.

[Liutauras Vilda]

Heads up, not ignoring posts. Just came back home, it will take some time to read all your thoughts, absorb them and watch videos you suggested.
Will do so and then will come back - most likely tomorrow. In the meantime, thank you so much for your passion about that and for invested time in posts, I'm sure there are more folks who are very interested in these topics, not just me.

[Junilu Lacar]

Caveat re my Aikido analogies: You may not be able to relate with the Aikido videos and the analogies I make with Agile/TDD. I've been told as much by at least two of my colleagues in the past. If the Aikido analogies are too esoteric for you, try plugging in your favorite professional sport and athlete. Or your favorite kind of music and musician. Or book and author. I hope you get the idea.

[Junilu Lacar]

Here's a challenge: Try to replicate what Uncle Bob did in his demo by TDD'ing a class that returns the prime factors of a given number N as an array of int.

1. If you want, watch the demo again before your try to replicate it yourself.
2. Time yourself to see how long it takes you.
3. Try to strictly follow the Red-Green-Refactor sequence
4. Time to see how long it takes Red-Green-Refactor cycle.

Suggestion: Create a GitHub repo and commit/push your changes to it on every step of the TDD cycle. Start each commit message with [RED] / [GREEN] / [REFACTOR] followed by a short description of the change that you made. For example,

$ git commit -m "[RED] Created failing test for factor(2)"

[Liutauras Vilda]

Junilu Lacar wrote:Aikido founder, Morihei Ueshiba, who is referred to as O'Sensei by Aikido practitioners, was said to have been asked by a student one day, "Sensei, out of all the techniques in Aikido, which one is the most important?" O'Sensei reportedly answered, "Ikkyo is the most important technique."

Ikkyo (literally, "first technique")...

I think I do understand well what is being meant by that thought. Unfortunately in universities we don't learn that. Maybe I should say anymore. For the last few years I was thinking that main problem of that are students, so we don't put enough effort in learning. But now I think that we being taught some other techniques, not sure what these are in Aikido terms. Maybe these don't even exist. I don't recall seeing any module about the software design in its simplest approach using 4 rules of simple design. I bought the book you recommended some time ago, it is called - Understanding the Four Rules of Simple Design by Corey Haines (disclaimer: it isn't an andvert, we don't get paid for that), and I found it also as a good starter guide for TDD. I need to admit I'm practicing it mostly for my own projects as of now.

Junilu Lacar wrote:I think it would be good to introduce students to the mechanics of TDD when they have a basic understanding of problem solving as it pertains to programming.

Reading what you wrote, I more and more start thinking, that "basic understanding of problem solving" is tightly related with TDD. I think introduce it earlier is better than later. That essentially helps you to understand and make right decisions decomposing the problem in its smaller pieces. If you can manage to write such small tests, you'd never write methods 200 lines long what we often see. They are hard to test, so they just go untested at all. And that is rotted in industry.

Junilu Lacar wrote:One thing I would be interested to see is a study that compares students' progress when you introduce TDD-related skills and practices early on in the curriculum versus if you introduce them later versus not bothering with anything related to TDD at all.

For example I've been introduced to JUnit (in practice) at second year and TDD was mentioned I think at the same year. Mentioned. So to reach the stage for such studies I think something needs to change dramatically. I don't know who drives universities modules, who creates them? Would you expect to see in universtities modules list a mandatory module of TDD, ok, at least optional? I think such module could be easily spread across one semester, which is about 12 weeks long.

Junilu Lacar wrote:I have a theory that I've been working into a talk about TDD. It has to do with the Backwards Brain Bicycle.

I did try actually that one. About 20 years ago. It was a one of many entertainments you could try near seaside in Palanga. And yeah, of course I didn't manage. And that's spot on - it seems you can compare how much effort of yours it requires to shape the way you think when you write code in TDD way. Feels like you know it, you did it before, ok, slightly differently, but essentially the same - and you still can't do it, unless you practice a lot! Probably the difference is, that once you learn to ride bicycle you'll know how to do it always without practicing anymore. I'm not sure that holds for TDD. For me it seems you need to keep your brains hot and stretched always.

[Junilu Lacar]

I believe that many universities already include TDD in their CS/IT curricula in some form or fashion. While that is a step in the right direction, the degree to which they emphasize the practice varies both in depth and breadth. The whole thing about introducing newer industry practices into academic instruction is tricky and there are many things academics need to consider.

Even though TDD has been practiced in the industry for many years now and there is plenty of information about it floating around, it's still not widely understood, even by people in the industry. Based on my experience, I would give a SWAG (scientific wild assed guess) that at best, only 40% of the entire developer population know enough about TDD to be dangerous, less than half of that know it enough to be effective, and even fewer do it on a regular basis.

Another problem is that effective TDD is difficult to learn and it's even more difficult to teach. You have to know how to do it to be able to guide people through anything other than the simplest exercise. I learned a lot from Corey Haines' book and I still re-read it to learn more, kind of like going back to ikkyo as I explained earlier. The more I study the "moves" Corey makes in his book, the more nuance I can pick up on. This requires many hours of practice, repetition, and introspection. Teachers and students don't have the luxury of that kind of time. Heck, most professional developers don't have (or are willing to give up) that kind of time which for me was a few months worth of late nights and weekends.

[Liutauras Vilda]

Thankful Junilu for valuable conversation, insights. Don't know how others, but I'll take maximum I can chew now from this thread.
I'm studying once again Understanding the Four Rules of Simple Design, but this time with more thought.

Not sure which of your posts are cow worthy, probably all, but I'm going to assign on few I liked most.

As a side note: 18 November (in less than 2 weeks time), in most countries and cities there going to be a Global Day of Coderetreat workshop, which is mentioned in Corey's book, so if you are interested in pursuing to master techniques Junilu explained across the thread, you can go and register and hope there are still available slots in your city area.

[Junilu Lacar]

Thanks, Liutauras. I'm happy to see you take so much interest in this. We need more developers who do.

I facilitated a local event for GDCR last year and here are a few tips that might help you get the best out of the day:

1. Be sure to try to switch partners on every round. There is a tendency to want to finish what you started from the previous round but you just have to let go. Always start over as though it was the first round of the day. In the morning briefing, the facilitator should tell you that the point is not to finish but to write code that is as perfect as you can write it, even if it's just one line.

2. There was one guy in the group I had last year who always went straight to the input part of the problem. He spent every single round coming up with code that would read from the command line and set up the initial population of the board. He never got around to actually writing anything that would calculate the next generation of the simulation. Watch for guys like this during the mini retrospective at the end of each round. Pair with them once if you're interested in learning about things like the Scanner class, otherwise I would try to avoid them. If you can't avoid them, try to tactfully steer the direction to a different part of the problem.

3. I can't emphasize this enough: don't get hung up on figuring out how to initialize the board. Try just hard coding initial configurations for your tests. If you're using arrays to represent your board, use smaller ones. Realize that a 5x5 board can take as much as 75% less effort to hand-configure than a 10x10 board. Try to go to the event with some common small patterns whose progression is well-known already prepared. The wikipedia page on Conway's Game of Life has a number of them.

Edit: I have created a document that contains a number of interesting GoL patterns. You can copy the text for a pattern and use it to initialize your board. This should save you some time.

4. See if you can represent the board using something other than arrays. Read the part in Corey's book about reification of a cell's location and try that in one of the later rounds.

5. Try to stick to the Red-Green-Refactor cycle but don't get hung up doing some refactoring on every iteration either. Sometimes there's just nothing to refactor.

6. Some people want to go back through what they did in each round later on, thinking that it will be like how athletes watch film of their own games to look for ways they can improve their performance. I don't think this is such a bad idea, actually. However, it does run a bit counter to the GDCR rule of deleting everything you did at the end of each round. Make sure your round partner(s) are ok with using version control. You might also want to check with your facilitator.

7. If you decide to use a version control system so you can review what you did later, I suggest you create a main line (master) that only has an empty project in it. Then create a new branch off of that for each round. Try not to eat up a lot of time writing commit comments either. Keep it simple, like maybe just one of "Red" or "Green" or "Refactor". The initial branch comment might include the constraints you're going to work under for that round.

8. Remember, good unit tests are self-verifying. This means that you should avoid spending time writing code to display the board configuration so you can verify that your code is correct. Getting hung up on displaying your board is about as poor use of the little time you have in each round as getting hung up on reading in and initializing the board's starting configuration. Again, a little preparation here can pay off. If you come to the event with a few generations of a known initial configuration already listed out, you can save some time. The wikipedia page has a number of examples of oscillators and space ship configurations with periods of varying lengths. Still life configurations obviously don't change from one generation to the next.

The most important thing to remember when participating in GDCR is that it's not about solving the problem but rather the process of solving that matters. Make sure you and your partner talk to each other and discuss design, refactoring, and testing ideas. Pair Programming is a big part of these exercises and a pair or group that is not talking throughout the exercise is not an effective TDD team.

[Tom Joe]

Also see my post on TDD - https://coderanch.com/t/729560/Test-Driven-Development-money-maker
Please share your thoughts here. Thanks.