Not long after the Christmas break between 2001 and 2002 I wrote “JUnit: A Starter Guide” in response to a flurry of complaints over the lack of a decent JUnit tutorial. I didn’t know at the time that I would turn this simple tutorial, written somewhat in haste, into JUnit Recipes: Practical Methods for Programmer Testing, which I completed in 2004. It has surprised me to note that several hundred people continue to read the Starter Guide, so I thought I would include a link to it from here. In order not to deal with differences in HTML formatting, I have decided to link to the document as a PDF and keep it mostly for historical purposes. Much has changed since 2002, and I hope the Starter Guide remains a solid introduction to JUnit, test-driven development and software design.

JUnit: A Starter Guide

Discuss

I don’t want to claim that story test-driven development doesn’t work, because some of my most respected colleagues teach the practice with success; however, I do want to warn people who might find themselves seduced by STDD, especially if they think of it as an easy replacement for TDD.

Allow me to clarify the two terms, TDD and STDD. To practice TDD, the programmer begins with a small, well-defined behavior they’d like to implement. Typically, they design that behavior as a method on a class, although they could get away with doing even less, then brainstorm a list of tests they might write. With such a list in hand, they run through the TDD cycle, illustrated beautifully by Bill Wake’s stoplight analogy. When the design behaves adequately and correctly, the programmer stops.

To practice STDD, the programmer begins with a story and several story tests, which I tend to call “examples”. The programmer then selects a story test, watches it fail, then test-drives enough code to make it pass. One by one, the programmer makes each story test pass until they complete the entire story.

I have been teaching people about TDD and stories for years, and have practiced STDD most of that time, in one form or another. I find the technique helpful; however, when I have pushed STDD to its limit, I have found it to guide me in directions I don’t like, which TDD has generally never done. When I watch others attempt to practice STDD, especially novices and advanced beginners, I see how they misapply STDD and lead themselves towards a Big Ball of Mud, despite what the agile community’s marketing machine says about TDD and stories. I believe the intersection of the two creates problems for those not accustomed to the different goals of TDD and user stories.

I use examples, the term I use for story tests, to show progress towards delivering a story, or feature. Broadly, I add examples to reflect increasing levels of understanding of the system to design, and as examples pass, that reflects progress towards delivering an ever more powerful system. I use programmer tests, the term I use in place of unit tests, to test my design ideas as they come to me and to help me type code in correctly. Any time all the programmer tests pass, the system works as designed, even if it does not yet do everything the business needs. Any time all the programmer tests pass, I can freely commit changes to the main line of the project’s design repository.

More succinctly, examples help us design the right system and programmer tests help us design the system right. (I prefer “correctly” there, but then I lose the symmetry.)

I often see programmers try to use passing examples as an absolute criterion to stop designing. They underestimate, in my opinion, the role of programmer tests to put positive pressure on their design. Examples, especially when written as end-to-end or integration tests (a test whose failure does not isolate the mistake to a single method), simply do not put positive pressure on a design: their high-level nature can’t constrain a design enough to support careful refactoring. For this reason, I recommend novices and advanced beginners not practice STDD until they first see or feel for themselves the impact focused, small programmer tests have on their design.

I want to leave no room for doubt: I do not mean to say that novices should avoid STDD as an “advanced practice”; but rather that a combination of novice tendencies makes STDD harder than TDD to practice well. Specifically, the novice tends to write examples as end-to-end tests, which provide too much design freedom and exert too little positive pressure on the design to guide refactoring and prevent defects. Instead, I would counsel novices and advanced beginners to focus on TDD and run the examples every hour or so to measure their progress towards delivering the story.

Read more about how to practice STDD well.

Discuss

I am late filing my taxes for 2007, which explains why I’m awake at 5.00 this morning. I’m not entirely sure how many consecutive mornings I’ve been waking up earlier and earlier: maybe it’s six, maybe it’s seven. My fingers feel a little heavy, I’ve yawned three times since I opened my computer, and it’s too dark in here to scan paper, so I decided to write these words.

Let me tell you a little about my project: I have to file my taxes. Since I have been audited, I no longer trust myself to file my own corporate taxes, so I’m preparing paperwork for my accountant. My goal is to deliver a DVD of my data and let my accountant and her staff do a first draft of my taxes while we’re at XP 2008. When we return, I’ll be able to answer questions, then I hope to file before June 28 when we have to leave for the next trip. That is the goal, some context and a few constraints, and I think that’s enough for you to understand me.

This, dear friends, is a death march. Here is how I know: I have a pile of things to do long enough that I don’t know how much there is, I don’t know when I will finish, I don’t feel like measuring what I’ve done will help he know how much more time it will take, I have doing this essentially 12-14 hours per day, I have no system for choosing the next task, and I feel like I’m making up the tasks as I go. As a result of all this, I’m in here at 5.16 and I don’t think I’ll leave here until 22.00, and I need to do this until further notice, and until it’s done. And oh yes, I can’t really describe “done” precisely, but I’ll know it when I see it. That all sounds like a death march to me. It’s not a fun place, so how did I get here?

A big part of it is fear: I am at the tail end of an audit for the four preceding years, and I don’t think I’ve ever felt so much stress in my life. I dealt with my father’s alcoholic rages better than I’ve dealt with this audit. I have coped (if you can call it that) mostly by withdrawing from life in general and certainly avoiding anything that looks like financial record-keeping. Of course, I’ve also spent a lot of time blaming myself for being such a poor accountant, even though my last bit of real accounting training was 1991 in high school. I’ve been afraid to deal with the audit, and terrified to keep records carefully since about October 2007 or so, and my year end is October 2007. As a result of this fear I have delayed tackling my current taxes, wanting to focus my accountant and tax lawyer on the audit. Only now that the audit is mostly settled have I turned my attention back to the present.

Another part is incompetence: in 2002 I walked away from my first accountant because I started a full-time job and let my company hibernate indefinitely. On that basis I couldn’t justify the expense of an accountant. As a result, I hired myself as accountant by default, and while the job wasn’t very demanding in 2003, I left my full-time job that year to write JUnit Recipes, which led me to more of the work I’d wanted to do as an independent, then I started XP Day North America, which introduced me to my current business partner, ... you can see where that’s headed: more money, more records to keep, more taxes to pay, and more financial information to get wrong. It’s that incompetence that directly led to the audit and ignorance of a good filing system that has led to the long string of files of paperwork I need to process here. If I were any good at this, not only could I file my taxes sooner, but I probably wouldn’t have been audited in the first place, and even if I had I would have been confident enough to handle it well.

As you can see, incompetence and fear play a big role, and not that my incompetence—at least as far as it has hurt me in this context—has mostly to do with something I was never trained properly to do! It’s worth arguing that if I’d hired someone to do it, I’d be in better shape, and that that is the truly incompetent part. I grant that, but part of the reason I didn’t hire anyone is that I was too ignorant to see that I needed to do it, then once I realized I needed someone, too ashamed of the mistakes I’d made to let anyone look at them. Fear, incompetence, shame… I’m doing really well so far.

Finally, there are the tangible effects of my fear, incompetence and shame. The audit has contributed to my sinking into a fairly deep depression (and no, not just sadness, believe me), the result of which has been many days spent in bed, rather than taking care of these matters. Every day I went to bed thinking, Tomorrow I’ll get up, start working on my financial records, and within a couple of weeks, I’ll have organized everything, and every morning the first big thought in my head was, Not today! As a result of this, not only were my 2007 records remaining disorganized, but my incoming paperwork began to create a serious backlog. Even more, I wasn’t separating the 2007 material from the 2008 material, which is one of the reasons my current work is going so slowly: I first have to figure out whether I need to handle a piece of paper before I handle it. Such waste!

In addition, as you might expect, I am ignoring my other responsibilities in the name of Getting This Done, but when an urgent request comes up, it completely ruins my flow. My business partner needed me to pay him for some long-outstanding invoices. Nothing huge, but big enough to matter, and because the invoices were months old, I had to wade through old reports, old receipts, and so on, in order to help him. What should have taken 45 minutes took over 3.5 hours and knocked me completely off my rhythm. (I did manage to track down the cause of a $107 credit I had in my books, though: it turns out the credit was my mistake. Big surprise.) Yesterday, after paying him (but not for everything, because I’m just not that well organized) I had to stop working, even though it was only 17.30, because my mind simply folded up its tent and left. I couldn’t concentrate at all. I managed to go grocery shopping, but even that manifested this death march: we usually shop every 2-3 days and carry home 2-4 bags of groceries. Sometimes those bags are pretty heavy, but usually they aren’t. This time, even though we were leaving the country in 5 days, we carried 5 bags home—after buying another bag at the store—and just barely. I don’t know about Sarah’s, but my bags were heavy! I was struck by how my work problems were affecting my home life. About the only benefit of staying in my office is that I’ve mostly avoided working around the contractors finishing up the main floor in our house.

So it’s now 5.37 and the sky is brightening despite the rain. Pretty soon I’ll be able to see enough that I can’t justify not scanning papers and organizing them. I don’t know how much I’ll get done, nor how far along the project that represents, nor when it will be done, nor how to pace myself to finish it. I don’t yet know whether I’ll be late and delay my taxes an extra 1-2 weeks as a result, not to mention having this waiting for me when we return from Ireland. I don’t know much about this project, but I’m busting my ass on it, and that is what makes it a death march.

The foregoing is a true story. The names have not been changed. The events are real. I hope you feel a little compassion and even pity for me, even though this is a situation largely of my own creation. I have a question: do you think the causes of your last (or current!) death march are much different? Do you feel compassion and even pity for the people who landed you there?

Discuss

The standard, universal data processing answer is “it depends”. Specifically, it depends on the ongoing participation of your stakeholders.

If the development team is demonstrating the application at the end of the iteration to the stakeholders, then that’s an anti-pattern. If you’re not getting any constructive criticism from the stakeholders about the demonstration, then the stakeholders are likely not engaged by the demonstration, and it’s a waste of time. If your stakeholders are engaged, then they’re likely giving a sizable amount of constructive criticism, the result of which is re-working a substantial number of stories in the next iteration. Of course, you could just be that good, but I haven’t met that team yet.

The last time I worked with a team in this situation, they held demonstrations once per iteration, which for them meant every two weeks. They expressed to me that they were not getting feedback soon enough, so I asked them whether they thought weekly demonstrations would work better. They did, they asked the stakeholders to make at least two people available every Friday afternoon, and that worked. After a while, they added a Wednesday morning demonstration just before lunch. The next step would be daily demonstrations, then finally continuous stakeholder participation. The secret was to sneak up on the daily demonstrations.

Rather than ask your stakeholder to go from hands-off to daily meetings, hold demonstrations once per iteration. When they point out how much feedback causes rework, suggest having a mid-iteration demonstration to avoid so much rework. You might be able to fix a small problem or two right in front of the stakeholders, and if you can, then do. (It looks impressive.) Once you’ve established that you can fix some problems without putting the stakeholders to sleep, they’re more likely to want to work directly with you. Each time they notice a demonstration leads to substantial rework, suggest doubling the frequency of the demonstrations. Eventually you’ll arrive at the right amount of stakeholder participation for your project. The key is to let your stakeholders notice the problem of not enough feedback, because if it’s their problem, they might look for solutions, but if it’s your problem, they’re less likely to care. If they can’t see it’s their problem, then look for subtle, non-destructive ways to make it their problem.

My goal is for a key stakeholder and the development team to demonstrate the product together to any and all interested parties. This is an important step towards the whole team approach to building software that I find so incredibly effective.

Discuss

I remember being a technical lead, believing that it was my job to make sure everything was doing correctly and as quickly as possible. The result was predictable: I made myself a bottleneck because I was afraid to delegate important tasks to other people, for fear that they’d do it poorly and have to redo it, or even simply because it would take me less time to do it than to explain to someone else how to do it. I know now that letting myself be a bottleneck is a bad idea, but I wasn’t able to explain why very well until just a moment ago when a long-awaited neural connection finally happened. I almost felt the crackle in my brain at the point of impact.

Tim Ottinger wrote about Sooner, Not Faster, which I describe to people frequently in my work as a consultant. My goal in teaching test-driven development is not to help programmers write code more quickly, but rather to help them deliver solid code sooner. The time-saving techniques include being clear about what to build before trying to build it (write a failing test first), building only what you need (write just enough code to pass the test), stopping when you’ve built enough (continue until you can’t think of more failing tests to write), and keeping the code clean as you go to avoid building up inventory of uncompleted necessary work (“clean the kitchen” refactoring). Not all these techniques involve thinking or typing more quickly. Some involve thinking more to type less and knowing what’s enough then stopping. In general, I help teams by focusing on how to deliver a satisfactory result sooner, no matter how fast or slow the individual tasks are completed.

Now I wish I’d thought that way as a technical lead. If I have a backlog of 10 tasks that take a total of 4 weeks to complete, but I could delegate some of those tasks to others, then even if they take 5 times as long as I do to complete those tasks, I could delegate any task up to 3 days in length and, as a group, we could be done in 3 weeks, even if we spend more total time working. The alternative is to keep those tasks for myself, then have the others do busywork to avoid looking idle. You might think this is a false alternative, but how many people on your team are working on its top three priorities, and how many are working on other things? The other things are busywork!

Had I thought this way, I could have benefited dramatically. More important work would have been completed, I’d have learned how to delegate effectively, and I would have felt (and probably now feel) less stress.

If only.

Discuss