Concurrent Unit Testing Kata in Mumbai

Last week I ran a workshop for agile teams in Mumbai, which I'm so glad to visit again and again and see their progress. This time we plunged into Concurrent Unit Testing. I am lately avoiding the term TDD, not because there's anything wrong with the practice itself but sometimes I see this weird perception: "TDD is not for us", "it's too extreme" etc. Well, it is extreme, but who said extreme things aren't simple?

Four hours of kata session (see previous posts to see how "kata" format works in different cases) was quite enough to kill a couple of myths. First myth, saying that writing tests before code isn't natural... I guess teams realized quite the opposite after their first few methods implemented after we specified their behaviors as JUnit tests. Second myth, saying that pair work is too extreme. I think guys didn't even notice that they started spending 100% time with a partner in front of a notebook.

So, two people always sitting at the front table... writing tests, coding, talking out loud. What they do is on the projector. Everybody sees that and think about the next steps. Every 7-10 minutes we change one of the partners with someone from the group and move on, and then introduce another new person in the next 10 minutes and so on.

The process is very smooth, we would only halt to emphasize something important to the audience, e.g.: "now, if we have a situation when a test compiles but causes run-time exception - this very likely means that we will be adding more tests to catch the problem with this test"... and then we would move on again.

Couple more steps and our Enterprise Chat Server is now functioning and we move to its advanced features. Devs rushing to make further progress...

Oh... and the polar teddy bear that I bought in Vienna for these guys as a prize for the best performance went to two guys this time, because it was really hard to decide who of them was a better agile dev. Now each of the two will own the bear for a sprint, because guys are from different scrum teams.

It was fun... for everyone, even though it's hard work. Only Eclipse, JUnit and no Powerpoint slides.

Wednesday Night: Unit Testing Kata in the Bar

Today my old team mate on the previous projects and currently Scrum Master, Alex Ginda, joined me in Unit Testing Kata effort... in the bar :) Kata is very straightforward thing: masters of martial arts perform certain fighting "patterns" in solo (or even in pairs) but it's not a real fight.


The idea turned applicable in software development. For more detail we refer reader to CodingKata website. What we did was a bit different though. The idea was not that much about performing a coding exercise but rather coding and unit testing.

So, we came up with the exercise, relatively simple one, here it is.

The exercise: Lighthouse radio monitoring devices run Java (wishful thinking, allowed in kata's legend:) ). Two in-house (or better say, in-light-house) programmers need to code and unit test simple java method that accepts a collection of Morse signals as input and returns true if the signal is SOS; single mistake allowed though. And it returns false otherwise. Very simple. Oh, and I almost forgot to mention that SOS in Morse code looks like this: . . . _ _ _ . . .

Took us about 45 minutes pure time. Technical details are not that relevant, here's few screenshots of the process:



Good finding... eating and coding is not that bad, seriously... when both of us ate we couldn't continuously code, but we could think better - very useful for "test-first" approach. It doesn't necessarily mean though that TDD develops unhealthy team habits :) It's all more complicated...

And finally, performing kata is fun, should be fun no matter what... Having it in the bar, like we did, or even outdoors or some other funny place, really sets cool context and totally reloads your mind. It's funny and insightful...

ATDD with JUnit: No Extra Cost!

By Alex Yakyma

There's a couple of good ATDD tools already on the market and all of those are free ones but it doesn't come all free eventually. Certainly there's learning curve for each. And even more so, there's real danger that the team may not necessarily adopt them which may influence badly the adoption of ATDD itself.

There's a surprising news for teams though: if they are using JUnit (or actually almost any unit testing framework from the xUnit family) - it can be used for ATDD very efficiently.

Let me show this on an extremely simplistic example. We're building simple Calculator service, that's the brief context.

First, let's specify our examples of system behavior that will serve us also as specification of the acceptance tests.
------------------------------
Adding 2 and 3 is 5

Adding 0 and -1 is -1

Multiplying 3 by 6 is 18

Multiplying 4 by 0 is 0

Multiplying -1 by 16 is -16

Multiplying 7 by 1 is 7
------------------------------

...it's very straightforward, isn't it?

Now what we do is implement the test (using JUnit):

Notice that for all these tests there's no an important nuance that many developers would miss while working on their unit tests:

Each assertion now includes the message and the message is exactly the specification.

This basically performs one of the key roles of ATDD - sustaining a living documentation and traceability to code. Now, if something fails, you know what exactly that is:

As we can see, now JUnit tells us what exactly goes wrong with the code, or better say - what exactly it fails performing at this moment of time.

Very simple!.. And if your team already uses JUnit then there's no additional effort to master a new tool, so you can concentrate on the technique itself.

This reminds me to mention in the end that tooling really secondary to ATDD, what is first and foremost is to ensure that those examples that the team is automating and then implementing come from the the people in the company who actually know what their client wants.

My Paper on Refactoring Got Published in Overload Magazine

By Alex Yakyma

Today the article "Refactoring and Software Complexity Variability" was published in Overload magazine (issue #102, April 2011). It is available in both paper format and in electronic form.