Sustainable Test-Driven Development

New Little Book

I've been posting more on LinkedIn these days.  Short little nuggets about TDD that people really seem to respond to.  It's all out there if you want to read it, just look for my name on LinkedIn. Anyway, I did so many of these that I realized I could make a sort of lightweight handbook out of them, for the the practitioner why just wants to sharpen his or her TDD skills.  So I

Test-Driven Development in the Larger Context: Pt 4. Synergy

Having established the differences between ATDD and UTDD, how are they the same? Why are they both called “TDD” collectively? Tests ensure a detailed and specific, shared understanding of behavior. If properly trained, those who create these tests will subject their knowledge to a rigorous and unforgiving standard; it is hard if not impossible to create a high-quality test about something

TDD Mark 3, part 2

I realized recently that this had been written, but never published.  Part 1 was, but never this second part.  Not sure how that happened.  Maybe I needed a test. :) Anyway, here it is.  Part three is still pending. -Scott-  Expanding the thesis Our central thesis thus far has centered on the notion that TDD is not really about testing, it is really about

Test-Driven Development in the Larger Context: Pt 3. Automation

Both ATDD and UTDD are automatable. The difference has to do with the role of such automation, how critical and valuable it is, and when the organization should put resources into creating it. AUTOMATION ATDD ATDD’s value comes primarily from the deep collaboration it engenders, and the shared understanding that comes from this effort.  The health of the organization in general, and

Test-Driven Development in the Larger Context: Pt 2. Cadence

Test-Driven Development in the Larger Context: Pt 1. Audience

Test-Driven Development in the Larger Context: TDD & ATDD (Introduction)

Introduction A question that often arises in our consulting and training practices concerns the relationship between Test-Driven Development (TDD) and Acceptance-Test-Driven Development (ATDD).  Which is “really” TDD, and which should an organization focus on in terms of which comes first, and which should achieve the most attention and resources? It’s not uncommon for someone to refer to

TDD: Testing Behavior in Abstract Classes

Magic Buttons and Code Coverage

This will be a quickie.  But sometimes good things come in small packages. This idea came to us from Amir's good friend Eran Pe'er, when he was visiting Net Objectives from his home in Israel. I'd like you to imagine something, then I'm going to ask you a question.  Once I ask the question you'll see a horizontal line of dashes.  Stop reading at that point and really try to

TDD and Design: Frameworks

Increasingly, in modern software development, we create software using components that are provided as part of a language, framework, or other element of an overall development ecosystem.  In test-driven development this can potentially cause difficulties because our code becomes dependent on components that we did not create, that may not be amenable to our testing approaches, and that the

TDD and the "6 Do's and 8 Skills" of Software Development: Pt. 1

This post is not about TDD per se, but rather a context in which TDD can demonstrate its place in and contribution to the value stream.  This context has to do with the 6 things that we must accomplish (do) and the 8 skills that the team must have in order to accomplish them.  We'll describe each "do", noting where and if TDD has an impact, and then do the same thing with the skills. 6

Specifying The Negative in TDD

One of the issues that frequently comes up is "how do I write a test about a behavior that the system is specified not to have?"  It's an interesting question given the nature of unit tests.  Let's examine it. The Decision Tree of Negatives When it comes to behaviors that the system should not have, there are different ways that this can be specified and ensured for the future:

The 6 Do's and 8 Skills of Development

This post is not about TDD per se, but rather a context in which TDD can demonstrate its place in and contribution to the value stream.  This context has to do with the 5 things that we must accomplish (do) and the 8 skills that the team must have in order to accomplish them.  We'll describe each "do", noting where and if TDD has an impact, and then do the same thing with the skills. 6

Structure of Tests-As-Specifications

A big part of our thesis is that TDD is not really a testing activity, but rather a specifying activity that generates tests as a very useful side effect.  For TDD to be a sustainable process, it is important to understand the various implications of this distinction. [1] Here, we will discuss the way our tests are structured when we seek to use

TDD: Specifying the Negative

One of the issues that frequently comes up is "how do I write a test about a behavior that the system is specified not to have?"  It's an interesting question given the nature of unit tests.  Let's examine it. The things that you cannot do Sometimes part of the specification of a system is to disallow certain actions to be taken on it. The simplest example of this is an immutable

TDD and Its (at least) 5 Benefits

Many developers have concerns about adopting test-driven development, specifically regarding: It's more work.  I'm already over-burdened and now you're giving me a new job to do. I'm not a tester.  We have testers for testing, and they have more expertise than I do.  It will take me a long time to learn how to write tests as well as they do. If I write the code, and then test it,

TDD and Defects

We've said all along that TDD is not really about "testing" but rather about creating an executable form of specification that drives development forward.  This is true, and important, but it does not mean that TDD does not have a relationship to testing.  One interesting issue where there is significant synergy is in our relationship to defects. Two important issues we'll focus on are

Welcome Max Guernsey

Max has joined Net Objectives, as some of you may know, as a trainer, coach, and mentor.  We've been friends with Max for a long while, and he has been a contributor to this blog and to the progress of our thinking in general. So, we're adding him to the official authorship here and when (if ever :)) we get this thing written, he will be co-author with Amir and I. I know this has been

TDD and Asychronous Behavior: Part 2

TDD and Asychronous Behavior: Part 1

In TDD we write tests as specifications where each of them is focused on a single behavior of the system.  A “good” test in TDD makes a single, unique distinction about the system.   But this means when the TDD process is complete our spec also serves as a suite of tests against regression.  This is a hugely valuable side-effect

TDD Mark 3 Introduced

First of all, sorry for the long absence.  Our training schedule has been wall-to-wall, and when one of us had a brief gap the other has always been busy. It has given us time to think, however.  Long airplane rides and such. :) We're been playing around with an idea we're calling (for the moment) TDD Mark 3 (the notion that TDD is not about testing but rather about specification

Hiatus

We just wanted to make clear to our readers that this blog, and the book we are working on through it, are not dead.  Amir and I have just been in very high demand for training since the holidays, but we will be back!  Stay tuned..... -Scott-

Testing Through API's

Download the Podcast We recently got a question from Tomas Vykruta, a colleague of ours, and we felt it turned out to be such a good, fruitful question that we wanted to pass it, and our answers, along in this blog. Here is Tomas' question: Do you prefer to have unit tests written against the public API, or to test individual functions inside the API? I've seen both approaches at my company,

Testing the Chain of Responsibility, Part 2

Download the podcast Chain Composition Behaviors We always design services for multiple clients.  Even if a service (like the Processor service in our example) has only a single client today, we want to allow for multiple clients in the future.  In fact, we want to promote this; any effort expended to create a service will return increasing value when multiple clients end up using

Testing the Chain of Responsibility, Part 1 (redux)

Download the podcast Testing the Chain of Responsibility The Chain of Responsibility pattern (hereafter CoR) is one of the original “Gang of Four” patterns.  We’re assuming you know this pattern already, but if not you might want to read about it first at the Net Objectives Pattern Repository. The basic idea is this: you have a series of rules (or algorithms) that are conceptually