The JSCodeRetreat is always a lot of fun, a day free of stress, just practicing and honing our craft. But sometimes people come up to us and ask if we could do an introduction to TDD before, so it is easier to understand what the red-green-refactor cycle means or how baby-steps shall be understood. Well, we listened. And we set up this workshop: TDD for beginners. The first one is going to take place on the 4th of December, two days before the JSCR #4.

This little itch

It was many years ago, that I was working in a company that was certified ISO nine-thousand-something. And it felt like quality was written everywhere, but rather on the walls and on paper. And quality meant to do paper work and that does ensure quality. I guess I had a wrong impression of quality. It felt way less fun to produce quality than to buy a quality product (you know, when it’s expensive it must be of high-quality, so it’s a pleasure spending that money). Something was wrong with my perception of quality.
During that time I was working with Daniel, a very skilled programmer, and we enjoyed working together so much. When he wrote code I would have written it exactly the way he did. That was fun, pure fun! That is what work should feel like and programming even more so, since in my opinion programming is not work, it’s a part of me. And that part I want to do as good as possible, I want to get better at it and I get excited the better I get, because it shapes so much more of what I actually want to achieve I just can’t describe how it feels. But there was always this little itch which was there, that when I change a thing in my code I might break something or just have to (manually) test if all is as it was before, plus the new feature or fix. And that feedback always was the not-so-fun part.

Scratching it

Many times I got told that TDD is when you write a test first and then you write the production code that makes this test pass. Lot’s of times, I just overheard them. Then I maybe tried it a couple of times but it wasn’t for me. Until we in uxebu worked on a product which was just so big, that (manually) testing and ensuring all the features still work the same way as before the last change was just too complex. It was clear that we needed automated tests here. So we set up a test environment and pushed testing forward and so on. But it still felt like a heavy process which we didn’t know how to do. I remember from my ISO-times, that there must be something like a test plan. Feels, good. And sucked fast. A colleague of mine Stephan suggested that we invite J.B. Rainsberger for a workshop, which we did. After the initial skepticism was gone and we got some things done with TDD it felt like a good path. The valley that came was deep for me. Man did I screw up. But afterwards it was going uphill, steep!
TDD is nothing else but doing in code what I had been doing before in my head. I sketch the problem, I solve it and verify that it works. Only that now I do less guessing about the assumptions, but I really do, as a programmer just needs to do it, write down the requirement in a test. That is, if I tell `I` to convert to `1` then I write that down in a test and next time I run the test again I am still sure that it still is that way.
TDD is no more than a brain dump into structured code and the relief of having to scan the code’s results manually. Just let the stupid computer do that work, not me anymore. Thank you!
I could pull out reports, statistics, research papers and Gardner reports to convince you. I don’t need to. Try it. You will be convinced or not. Just like programming, either you are a programmer or not, there is nothing in-between. And give it time to estimate the value of TDD well, it’s not learned in a week.

Step by Step

I recall my first programming steps. It took quite a while for me to understand the parts of `10 PRINT “Hello world”`. Why the hell does it have to have a `10` in front. And just like my daughter asked me a couple days ago: What are those quote-signs for?
Learning was so slow in the beginning. As it is with many things, I guess. But with programming, I quickly gained the knowledge of how to do things. I stored it and recalled it every time I needed that knowledge. I modified the patterns a little bit and I applied them again. I became really secure in using them. Back when I wrote C code all day long, I remember that I was proud to compile only twice a day and have been “working” the rest of the time. There was one time, when I used to have a small PSION mobile computer with just a text editor and I hacked out a program of about 200 lines of code on it, without syntax checking, no compile run and no test run of the program. For about six hours I was coding. And when I got back to real computer to run the program it had only one syntax error and it ran. Boy, was I proud. All that just assured me more and more that I am becoming a skilled programmer. How wrong was I!
I lost sight of the big thing, I had one way of doing things hammered in my brain, it was not in my comfort zone to change that. And if the program needed additional features that didn’t match the initial plan the code started to rot. Architectural changes applied to the code had been close to impossible. I hardly refactored back then. When I did refactor, I checked the result manually. As usual.

Thinking and Working Step by Step

In the last years I unlearned going in big steps. I practiced really hard and am a happy baby-step user now. I feel uncomfortable when I have to make big steps, when I have to write out more than just the last thought. My good feeling fades quickly when I fall back into the old let-me-fix-this-and-that-quickly habit. In those moments I just praise `Undo`, it has become one of my biggest friends. And a good reminder of how often I still move forward way too fast.
Especially when refactoring a quick test run and a tiny change are so valuable. I just can’t thing of how to properly do defactoring without baby-steps. I got trapped so often by just another step that I had skipped, just because of the `I know that` feeling. The false sense of security really robs my time.
In a CodeRetreat one participant said after the paper-only session: “It is amazing to write code on paper and realizing how often we do already change things while writing the code.”. The times are those where we don’t even remember that we hit backspace or changed a piece of code again before we are actually happy or ready to run the tests. It’s just like this “Where did I put the car keys again?” thingy. It becomes a habit which eliminates consciousness and I just hack it out like a trained stupid robot, even though I might know much better. I am getting better at doing things more consciously.
It takes some practice to go in smaller steps but it really is worth the time and consciousness you gain. TDD taught me that again.

Re-think Requirements and Dependecies

Another thing that TDD taught me is the re-evaluation of requirements and dependencies before implementing them. First it’s the test that I have to write, where I have to formulate an explicit expectation. If I do already have a problem doing that, how can I assume to have understood the problem?
Once I got through to the real requirement I have to dump it into code. When this gets difficult or when lot’s of setting up of environment is going on, I smell another problem. The dependency problem. Nowadays I start writing out a complex test in order to find out how deep I have to dive. It is like prototyping the problem, I try out things until I have learned enough about the problem to really write a better test. Explore, Stabilize, Commoditize (Dan North). Once I stabilized my knowledge about the problem I start refactoring my tests.

Finally – How to workshop?

TDD is not hard, it just takes a bit of practice. The first kick-off and the inspiration to do it more often I will try to give you during that day. We are going to switch between me showing some stuff for ten to twenty minutes and to practicing it. I will be there to actively support you, answer all your questions and give you guidance around applying TDD.
You will pair with different people which adds most value to the learning, since you can discuss the things with your pair and push each other forward. From time to time I will sneak in, listen to you and ask questions that make you think harder.

I am looking forward to seeing you at the workshop and also love to discuss things in more detail.
So why this workshop? Because TDD brings back and increases the fun in programming!

All the best

Wolfram