Jun 252011
 

Just write your tests, and nobody gets hurt

In his post, “The Fallacy of Premature Optimization”, Mikhail Opletayev wrote:

“Just being aware of performance while designing a product will help tremendously- just like how one of the better ways to diet is to calculate how many calories you ingest every meal.

“Writing efficient code doesn’t take much more of your time, if any. In fact, it can easily be argued that writing efficient code actually saves you a lot of time in the long run.”

Now, Mikhail may have had another direction he was heading, but as I read his writing I immediately went back to Test Driven Development.

By itself, TDD is not about optimizing performance. One of the most fundamental acknowledgments of XP is that all the practices work together to produce the greatest value. So I am thinking more about how NOT practicing TDD impacts product performance.

In this case, the relevant side effect I highlight is the length and complexity of methods and algorithms when TDD is used and when it is not. In the TDD case, it can get really hard to test a method that is 2 pages long, so we end up breaking up our code into smaller fragments “just so we can test them”.

Really? At first glance, that is definitely the behavior I see. When people follow TDD principles, their code methods are shorter… and those who really hate doing TDD are often “algorithm-writers”, using longer and more complicated logic.

One side effect of short methods is less nesting within loops and conditional statements. Another is a tendency toward functional primitives that may be mixed and matched in a more reusable way. Patterns can then emerge that suggest refactoring into more flexible structures.

And putting these benefits together, the code is cleaner, shorter and easier to understand. It is tighter, more flexible and high performing.

Metaphor: How the system works!!!

Now… there is one caveat I will mention. Many agile developers shy away from documentation, but in the case of TDD (or any form of design) it is a huge benefit to first draw a picture… whatever picture is relevant – a class diagram, a sequence diagram, a doodle on a whiteboard or a napkin.

What you are searching for in your pictures is what XP calls “Metaphor”… the shared mental model of what you are trying to tackle. Without metaphor, TDD can breakdown into endlessly finer primitives and actually INCREASE complexity.

So, let me know: do you practice TDD? What can you say about its impact on code complexity? And what do you do to set up metaphor with your teams?

  6 Responses to “The thing about TDD and pretty pictures”

  1. I recently created a working model of service layer testing for one of my clients with a tool called Fitnesse. What I found most interesting is that under this particular service layer implementation, the analytical staff finally had a chance to directly provide “Metaphor” via simple data grid (This + This SHOULD equal This) Acceptance tests for the new development effort leading up to, and even during development of iteration 1.

    As complexity increases and more code is deployed, the service layer fixtures are expanded and the Analysts are given a chance to be creative by forcing complex scenarios, real world gotchas, and even malicious scenarios against deployed code. This often uncovers bugs, and even requirements that were completely overlooked by the business.

    While this gives us Metaphor providing initial direction for an Agile / TDD project, I would like to ask Ken if he thinks it is enough to do so from the Acceptance testing level.

    More about Fitnesse: http://fitnesse.org/FitNesse.UserGuide.OneMinuteDescription.

    • OK, Daniel. If you would “like to ask Ken”, go ahead and ask! (If I were still a drinker, you would owe me a beer right now.)

      😉

      –k

    • Let me be less literal. Hmmm. I wrote a complete response for you that started looking a lot like a blog post of its own… so that will come out later next week. Meanwhile, I don’t think what I was replying answers what you asked… so you did not miss anything.

      So Metaphor is a mental model, and it can certainly describe what a user will accept in the product. (Note: it doesn’t have to.) The metaphor gives momentum to development because the team shares a conceptual understanding of what they are building. It is a communications metaphor, but may be more abstract than something like a requirements document.

      If the metaphor is proscriptive of the product requirements, then I could see where it might be used to drive acceptance tests.

      Meanwhile, a common name for a pattern (like Visitor, Pub/sub, Template Method) provides metaphor for developers… so they share a common language and vision for what is happening in the code or what needs to be built. But you would not have acceptance tests saying that Template Method was implemented correctly.

      So yes, I could see ways that the same visualization, tools or technology used to produce metaphor to drive development could ALSO drive criteria and standards for acceptance testing, it is not always the case.

      In my simplistic view (which you know I always fall back internally on even while I confuse everyone else), What the customers will accept is the best acceptance test criteria you can produce. I have a post coming soon about the 4th key attribute of the agile project manager that will talk more about that.

      (As well as the post that I nearly included in this reply.)

      It’s good to hear from you, Daniel!
      –k

  2. […] strive for teamwork, communication, quality, bullet-proof automated unit tests and high […]

  3. […] Though metaphor is usually intended to help produce shared meaning, when the metaphor itself is not shared between people and we base our language on that metaphor, we leave meanings open to each person’s interpretation of the metaphor in question. […]

Leave a Reply