I need your help.

At the Better Software Agile Development Practices conference in November I will present my tutorial entitled Avoid Integration Defects Without Integration Tests. I will describe and demonstrate the design benefits of reducing your reliance on integration tests (specifically end-to-end tests) to gain confidence in the basic correctness of code. I’d like to take sample integration or end-to-end tests from the audience and turn them into good, focused object tests, but at a busy conference, few audience members prepare such material in advance.

Enter you.

If you have some end-to-end or integration tests that you’d like to turn into good, focused object tests that help improve your design while offering the same or better confidence in the correctness of your code, then please contact me to receive instructions on how to send me your sample. I will, of course, give you whatever credit you want, or promise not to identify you if you’d rather remain anonymous. Whether I use the sample in the tutorial, I will work with you to show you how to improve your design through focused, object tests, rather than relying on integration tests.

Thanks.

Discuss

I remember Alistair Cockburn presenting a keynote address at XP/Agile Universe 2002 in Chicago. I remember most vividly his comments on microtechniques, a phrase that struck me and has stayed with me since that time. He described how microtechniques enable higher-level improvements by speeding up the rote parts of one’s work. Put another way, quicker typing buys slack, and since slack compounds, higher-level improvements are significant and inevitable. To write code, we type, and we learn to type by rote. While programming involves much more than typing, programming includes typing, so one can argue convincingly that typing well helps people develop as programmers. I contend that typing combines with knowing your text editor or IDE well to drastically amplify a programmer’s skill, which explains the typing test badge attached to this entry. I believe my typing speed helps make me a better programmer.

At times, though, fast typing gets me into trouble. I do manage to spend too much time typing quickly and not enough time typing thoughtfully. Does this mean, then, that typing quickly really slows me down? I haven’t measured it closely, so no-one knows the answer; however, I have become conscious of this, which explains why I so easily get up and walk away from the keyboard when things don’t go well. I know that I need to walk away from the keyboard to avoid letting my quick typing lead me down a rathole and, perhaps more importantly, I know when I come back to the keyboard with better ideas that typing won’t pose a bottleneck to completing the task. In a sense, I treat typing time as free and feel comfortable taking all the time I need to think. More than anything else, this helps make me a better programmer.

Would you do well to take a typing class? Perhaps. I suppose if you can afford to spend an hour per day for three months to practise typing and if you plan to type for more than about 10 more years, then you ought to at least consider it.

Suppose a full-time programmer sits at the keyboard prepared to type about four hours per day, half of that time actively typing. If you increase your speed from 30 to 40 words per minute, then you’d reduce typing time from two hours to 90 minutes. An investment of 65 hours (1 hour per day for three months, meaning 250 / 4 < 65 working days) would return 0.5 hours per day * 250 working days per year * 10 years = 1250 hours of saved typing. I count more than 1920% return over 10 years, or 35% return per year compounded annually for 10 years. (1250 / 65 > 19.23 and (1 + 19.23) ^ (1/10) – 1 > 0.35) The payback period for the 65 hours of investment is approximately 130 days (65 working days * 0.5 hours saved per day) or 7 working months (12 * 130 / 250 < 7). In other words, if you took a three-month typing course for one hour per day that improved your typing speed from 30 to 40 wpm, the decrease in typing effort would return you the investment in 4-10 months (7 +/- 50%). This ignores your increase in effectiveness from spending more time thinking about what you type before you type it! It sounds like a win to me.

102 words

Typing Test

Discuss

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

Proceed at your own risk.

Discuss