The ABCs of Acceptance Test Design (7-Jun-2018)
In this blog post for Ranorex, I present seven design principles for the tests you’ll craft as part of practicing behavior-driven development (BDD) or acceptance test-driven development (ATDD). Stick to these principles and you’ll create a body of tests that returns many benefits while allowing you to keep your sanity.
Agile Documentation: Specification by Example (26-Aug-2009)
Published at InformIT, this article is a companion piece to Mike Cohn’s book Succeeding with Agile: Software Development Using Scrum. It takes an automated test example from the book and demonstrates how to enhance it to act as clearer documentation on the system’s capabilities.
Agile Hiring (26-Jul-2018)
Don’t create a long laundry list of technical buzzwords for hiring. There’s a better, more agile approach. In this blog post for Ranorex, I present six major points to consider when hiring someone for your agile team: three job requirements essentials, and three important aspects to consider during the hiring process.
Agile Reflections:A Dozen Years or so of Agile Development Practices (2-May-2011)
Written with Tim Ottinger for PragPub. Tim and I reflect on the various “agile development practices” (perhaps better classified as the technical practices from extreme programming).
Balancing Mobbing, Pairing, and Solo Work (21-Jun-2018)
I view modes of working as akin to tools–you want to use the right tool for the right job or situation. In this blog post for Gurock, I talk about the distinctions around appropriateness for mob programming and pair programming. I also admit to enjoying the ability to work alone from time to time.
BDD Testing Skills Q&A (15-Apr-2018)
A number of good questions about BDD arose from the Gurock webinar “BDD Testing Skills.” I felt like answering them all, though I did so rather hastily (so don’t expect a lot of clean editing for this “article”).
Building a Simple BlackBerry Application Interface (14-Aug-2008)
Written for Developer.com. Building applications for the BlackBerry involves a few interesting wrinkles. Explore some of these challenges in building a front end for a new BlackBerry unit testing framework.
But We Have These Distributed Folks (Oct-2011)
Written with Tim Ottinger for PragPub. Is “distributed agile” an oxymoron or reality? Tim and I talk about distributed teams and agile values, covering a number of do’s and don’ts for agile teams. We also provide a number of communication guidelines for working distributed.
Can Refactoring Produce Better Code? (6-Mar-2007)
A simple example of how you can refactor some of your longer methods so that they can read well as “high-level policy.” Hosted at Developer.com. (Hopefully it’s clear from this article’s title that I don’t always have the final say on things like titles and blurbs.)
Can You Have Too Many Tests? (23-Feb-2018)
Yes you can. In this blog post for Gurock, I talk about a customer who didn’t realize the pickle they were brining themselves into when they slowly but surely found their way on a path to “too many” tests.
Cohesive Software Design (Dec-2010)
Written with Tim Ottinger for PragPub. Tim and I talk about one of the four “big ideas” in software, cohesion. Cohesion–the principle that “things that belong together should be kept together”–makes code easier to understand, debug, and test.
Clarifying Scope with Scenarios in Behavior-Driven Development? (19-Jan-2018)
In this article written for the Gurock blog, I talk about the values of negotiating around scenarios when doing behavior-driven development (BDD). Rather than delve deep into the narratives (given-when-thens), this focus will help when it comes to negotiating the scope of a given story.
Connecting the Dots (8-Mar-2002)
An article published in Software Development magazine (now part of Dr. Dobbs) about using test-driven development in conjunction with GUI development. The article demonstrates an approach using Java and Swing to build a small game.
Considering Test-After Development (24-Sep-2007)
Written for Developer.com. Should you write tests first (before you write production code), or should you write tests after you build the production code?
Convincing Your Team to Adopt TDD (15-May-2018)
In this blog post for Ranorex, you’ll pick up a number of ideas about how to approach introducing TDD into your team. While TDD is a simple practice to learn (though a challenge to master), getting developers to think they might want to even consider it is not an easy task. I’ll also talk about why resistance is to be expected.
Crafting Java with Test-Driven Development, Part 1: Getting Started (13-Jan-2006)
The first installment in a new series at Informit. This 13-installment series will introduce and discuss test-driven development (TDD) concepts. The series presents the incremental development of an application to play the poker game of hold ’em. Installments will appear roughly every other week for about six months.
Crafting Java with Test-Driven Development, Part 2: Testing Equality (20-Jan-2006)
The second installment in the TDD series at Informit discusses how to drive out the development of a
.equals method using TDD.
Crafting Java with Test-Driven Development, Part 3: Testing Hash Codes (27-Jan-2006)
The third installment in the TDD series at Informit follows up on the discussion of building a
.equals method by discussing the need (or not) for test-driving a
Crafting Java with Test-Driven Development, Part 4: Shuffling and Dealing (3-Feb-2006)
The fourth installment in the TDD series at Informit ponders a number of ways to test that a deck is shuffled so that cards are dealt in a random order.
Crafting Java with Test-Driven Development, Part 5: Handling Exceptions (17-Feb-2006)
In the fifth installment in the TDD series at Informit, I show how to write tests for exceptional conditions.
Crafting Java with Test-Driven Development, Part 6: Refactoring Tests (10-Feb-2006)
In the sixth installment in the TDD series at Informit, I talk about the need to keep tests as refactored as production code, so as to better document class capabilities and keep maintenance costs low.
Crafting Java with Test-Driven Development, Part 7: Adding Some Bulk (17-Mar-2006)
In the seventh installment in the TDD series at Informit, I add support for dealing the rest of a hold ’em hand. I also discuss the practice of adding “todo” reminders in code.
Crafting Java with Test-Driven Development, Part 8: It’s Just Code (24-Mar-2006)
In the eighth installment in the TDD series at Informit, I move the application toward a better design through a series of incremental refactorings. The beautiful part about code is that it’s easily changed, especially if you have tests to be confident about it.
Crafting Java with Test-Driven Development, Part 9: Driving a User Interface (7-Apr-2006)
In the ninth installment in the TDD series at Informit, I show how it’s possible to drive development of a Swing GUI using TDD.
Crafting Java with Test-Driven Development, Part 10: Building the View (14-Apr-2006)
In the tenth installment in the TDD series at Informit, I show how test-drive building a simple view, emphasizing the need for heavy refactoring of Swing code.
Crafting Java with Test-Driven Development, Part 11: Making Things Happen (21-Apr-2006)
In the eleventh installment in the TDD series at Informit, I show how to trigger behavior on mouse clicks without cluttering the view with logic.
Crafting Java with Test-Driven Development, Part 12: TDD at Cassatt: An Interview with Jerry R. Jackson (28-Apr-2006)
In the twelfth installment in the TDD series at Informit, I ask Jerry Jackson about his experiences with test-driven development at Cassatt.
Crafting Java with Test-Driven Development, Part 13: Nine Reasons Why You Should Be Using TDD (26-May-2006)
In the final installment in the TDD series at Informit, I talk about how TDD enables more rapid development.
Does Mobbing Really Speed Us Up? (5-Nov-2018)
I keep hearing from teams who are mobbing, where everyone is in the same room with a WIP limit of one, that “we go faster.” Really! How is that possible? In this blog post for Ranorex, I talk about my use of mobbing and pairing in training environments, then segue into a discussion of the value of minimizing WIP. Finally, I present a long list of reasons why mobbing might actually allow teams to go faster.
Doing TDD Well (19-Nov-2007)
TDD is a simple discipline: “a minute to learn, a lifetime to master.” This Developer.com article offers a number of nuggets on how to improve your mastery of test-driven development.
Don’t Mock Me (22-Jun-2004)
A discussion of the forces that drive the need for mock objects, as well as the design impacts of introducing mocks. This is the peer-reviewed submission to the 2004 Agile Developers Conference. (The original article appears in Jeff’s Blog.)
Enlightened Java Style (12-Feb-2002)
A solution published in Software Development magazine (now part of Dr. Dobbs) for what I call “simple style.” Three rules, instead of an entire book, to give you a simple approach for ensuring that your code remains highly readable and maintainable.
Evolution of Test and Code via Test-First Design (Jan-2001)
An article presented at OOPSLA 2001. A simple exposition of how to build code using test-first design. The example produces a class that the author still uses for reading CSV (comma-separated values) files.
Find the Right TDD Approach for Your Testing Situation (16-Aug-2018)
No, there’s no one “right” way to practice TDD, though there are plenty of ways that technically are not TDD. In this blog post for Ranorex, I talk about some of the variant ways of approaching test-driven development (TDD). I first introduce two distinct ways of describing TDD. I then discuss “assert-first,” “one assert per test,” and how tests are best named (or not).
The Formatter Class in J2SE 5.0 (18-Mar-2004)
A very brief article written for Gamelan.com (part of Developer.com) that discusses the Formatter class in Java J2SE 5.0. The Formatter class allows for String formatting similar to printf in C; it depends on the availability of the varargs feature in J2SE 5.0.
Getting Test Doubles in Place (3-Jan-2008)
Written for Developer.com. Test doubles (aka fakes or mocks) are a great tool that allow for deeper ability to test-drive solutions. The most common way to use test doubles is to pass them via constructors or setters. But there are at least a couple other solutions.
Half of a Third of a Century in TDD (6-Jul-2016)
A reflection on why I’ve found TDD to be an indispensable practice for the past sixth of a century. Published for PragPub–get the whole issue with a pile of great articles at The Prose Garden.
Heading into Ten and Twenty Years of Pragmatism (3-Jul-2018)
With the July 2018 issue, PragPub magazine (edited by Michael Swaine) celebrates the beginning of its tenth year. This year also begins the 20th of Andy Hunt’s and Dave Thomas’s classic book The Pragmatic Programmer. In this article, I talk a bit about what it means to be pragmatic and about how both the book and magazine have helped us be pragmatic over the years.
How Virtuous Is Your Code? (Aug-2011)
Written with Tim Ottinger for PragPub. This article is based on the Agile in a Flash card “The Seven Code Virtues.” It presents yet another possible definition for letting us know when code is “good.”
Humility: The Lost Value in Agile Development (29-Aug-2018)
XP presented four values as the basis for its approach to software development. Humility is perhaps the 5th, missing value. In this blog post for Gurock, I offer some thoughts on what it means to be humble. I relate humility to the unease that many seasoned developers feel about TDD–its insistence of building only the software needed to that point in time.
Insights from the TDD Community (21-Aug-2018)
Check out We Do TDD for numerous great stories about test-driven development from people, teams, and companies that test-drive their software. In this blog post for Ranorex, I talk about Dave Schinkel’s site that features interview questions and answers from a good number of TDD practitioners. I highlight some answers to questions about interesting TDD topics:
- How did you adopt TDD?
- Why would you want to be “test infected?”
- How does TDD relate to design?
Java 5’s BlockingQueue (22-Nov-2006)
Article appearing at Gamelan.com (part of Developer.com). A code-based discussion that demonstrates use of the BlockingQueue class found in Java 5’s concurrency packages.
Java 5’s DelayQueue (18-Jan-2007)
An article appearing at Gamelan.com (part of Developer.com) that discusses the class java.util.concurrent.DelayQueue, first available as of Java J2SE 5.0. The DelayQueue provides a thread-safe blocking queue that requires objects to remain in the queue for a minimum period of time.
Just What Is DevOps? (30-Aug-2018)
There’s no such thing as a free lunch, or free-expensive-steak dinner. You might have to listen to someone ramble about DevOps for hours while not being able to tell you what it is. In this blog post for Ranorex, I get to vent a little with a story about a steak dinner dominated by blather. I present a few thoughts about what DevOps is, since I can’t seem to find a concise definition anywhere (or get one at a steak dinner).
Making the Grade (part 2 of 3) (12-Mar-2004)
The second in a series of three articles published in Software Development magazine (now part of Dr. Dobbs) about the changes in Java J2SE version 5.0. This installment digs deeper into the new generics feature.
One Thing At a Time (18-Feb-2019)
In this blog post for Ranorex, I present OTAAT: One Thing At A Time, one of the most effective habits you can adopt as a software developer. From tackling stories to designing tests to refactoring, doing more than OTAAT is a guaranteed way to waste time. I’ll talk about how OTAAT instead helps makes life easier in general.
The Only Coding Standard You’ll Ever Need (13-Sep-2018)
Yes, coding standards are often a source of discontent within a team… but if you can’t get past agreeing on a few simple things, I suspect that portends something. In this blog post for Ranorex, I talk about the value, or lack, of having coding standards. I present a set of recommendations for deriving “agile standards,” but ultimately distill all standards down to a singular concept.
Pair Programming Benefits (6-Jul-2011)
Written with Tim Ottinger for PragPub. We list over twenty benefits that you can derive from pair programming, categorized as being from the perspective of the team and system, programmers, and managers/project managers.
Pair Programming in a Flash (2-Jun-2011)
Written with Tim Ottinger for PragPub. We discuss three of our Agile in a Flash pairing cards, covering the rules of pairing, pair programming smells, and what to do when not pairing.
Pairing Across Time and Space (2-Mar-2016)
Written with Tim Ottinger for AgileConnection. Much like in pair programming, working with a partner through pair writing provides increased support and valuable immediate feedback. But there are additional obstacles when you and your partner are not collocated. Here are some tips on how you can still implement pair writing successfully when you can’t collaborate in person.
Postmodern Agile: A Story of Collaborating Beyond Buzzwords (22-Jun-2018)
This blog post for Ranorex tells the story of a day in a life where we don’t talk about a process, we just live it, with the singular goal of delivering high-quality software frequently.
Principles for Agile Metrics (7-Dec-2007)
Written for Developer.com. Deriving metrics in an agile software development process can be an integral part of managing and improving execution. As with any tool, metrics used poorly can actually damage a project. A set of guiding principles for agile metrics can keep your team on track.
Raspberry Jam Gets Thin in the Pool (16-Jul-2018)
“The more you spread it, the thinner it gets,” said the late Gerald Weinberg. In this blog post for Ranorex, I talk about the mass growth of our industry, and how as a result developers have on average less experience than ever before. I talk about some ways in which we might thicken up that jam.
Rule #1 for Distributed Teams–The 2015 Edition (Apr 2015)
Written for PragPub. revisits his own coding history and finds it necessary to revise one of his basic principles. Along the way he shares some hard-won insights on how to make distributed development teams work.
Should We Automate All of Our Feature Scenarios? (8-Feb-2018)
This post for Ranorex’s blog talks about how behavior-driven development (BDD) can help us come to consensus. I share a story about a customer who found value in BDD, even though we were unable to automate their “specs by example.”
Shu Ha Ri–Learn, Detach, Transcend: Steps to Agile Mastery (Nov-2010)
Written with Tim Ottinger for PragPub. Our well-meaning agile coach’s maturity model was based, either deliberately or subconsciously, on Shuhari, a Japanese martial arts concept involving three stages of mastery: “first learn, then detach, and finally transcend.”
Software Volatility (2-Mar-2011)
Written with Tim Ottinger for PragPub. The final in a series of four articles on the “big ideas” in software development. This article discusses what volatility is, what problems it can create, and how to begin controlling it.
Succeeding With and Sustaining TDD (Dec 2011)
Published in the Java Tech Journal, this article presents a laundry list of things you need to look for and monitor in a TDD shop. TDD is a significant investment and challenge; following these recommendations should help you more effectively sustain the practice over time.
Succeeding With Test-Driven Development at a Distributed Start-up (17-Jan-2018)
In this blog post for Gurock, I talk about my experiences doing test-driven development (TDD) at a small startup: Where did we succeed, where did we fail, and what would I change?
Sweet and Simple (part 3 of 3) (12-Apr-2004)
The final installment in a series of three articles published in Software Development magazine (now part of Dr. Dobbs) about the changes in J2SE version 5.0. This installment covers the remaining new features, including foreach, autoboxing, varargs, typesafe enum, static import, and metadata.
Test Abstraction: Eight Techniques to Improve Your Tests (2-Apr-2011)
Written with Tim Ottinger for PragPub. Using smells that identify problems with respect to abstraction in your unit tests, we whittle down an ugly test (take from open source) into a pair of highly readable, maintainable tests.
Test-Driven Development: A Guide for Non-Programmers (2-Nov-2011)
Written for PragPub. Want your manager to understand test-driven development (TDD)? This article overview what TDD is and discusses its cost and benefits. Jeff also presents some thoughts on how non-programmers might understand whether or not their team is doing TDD well.
Test-Driven Development: A Love Story? (22-May-2018)
In this blog post for Gurock, I wax rhapsodic about TDD… well, maybe not. I don’t love TDD itself; I love the things that TDD enables me to do. I talk about what those things are, along with a bit of my personal history about how I got here.
Test-Driven Development in C/C++ (15-Apr-2003)
A lead article originally published in (the now defunct) C/C++ Users Journal about how to do test-driven development when working in C. Written with Dr. Robert Koss.
Testability and Design (10-Oct-2007)
This article discusses some supporting ideas for this argument that, in most cases, a good design is also a testable design (and conversely, that an untestable design is not a good design). Hosted at Developer.com.
Tiger Stripes (part 1 of 3) (10-Feb-2004)
The first in a series of three articles published in Software Development magazine (now part of Dr. Dobbs) about the changes in Java J2SE version 5.0. This installment overviews the changes and begins a discussion on the generics feature.
Tools, Iterations, and Stories (29-Oct-2007)
A brief article written for Developer.com. Are you focusing on the wrong things? Agile promotes de-emphasizing tools, but as agile grows, tools are becoming more pervasive. Agile centers around iterations, but are you focusing too much on the iteration to the detriment of delivering stories?
A Unit Testing Framework for the BlackBerry (24-Jul-2008)
Written for Developer.com. What do you do when there’s no effective unit testing framework for your programming environment? Why, build your own, of course! Building a simple unit testing framework for the BlackBerry provides some interesting insights into the BlackBerry programming environment.
Note that this article contains a link to code that can be found at Developer.com. That code will likely not get updated. You should instead use the link http://langrsoft.com/ftp/bbtest.zip.
The Value of Failing Tests (30-Oct-2018)
“A test that passes with no change to your classes is always cause for humility and pause.” We learn red-green-refactor for a reason–it’s not just “green-refactor.” In this blog post for Ranorex, I talk about the various reasons why you might see tests pass (green) when expecting them to fail. You’ll learn why it’s important to stick to that TDD rhythm.
What Agile is Not (Oct-2010)
Written with Tim Ottinger for PragPub. Tim and I present some stories about dogmatists, cowboys, and authoritarians, demonstrating a few ways that your transition to agile can be derailed.
Why I Practice TDD: Speed and Need (2-Mar-2018)
Why do TDD at all? In this blog post for Ranorex, I explain that my primary reason to do TDD is because it allows me to go faster, particularly as a system grows. I talk about some of the reasons why, and iterate some of the high cost of defects along the way.
Why Pair?: Challenges and Rewards of Pair Programming (7-Feb-2007)
An article written for Developer.com that discusses many of the merits behind pair programming.
Why You Need at Least Three Sets of Eyes on Your Code (9-Jul-2018)
Passive review after code (PRAC) is largely a waste of time. In this blog post for Ranorex, I provide some reasons why active review is better than PRAC. I discuss pairing and mobbings as two forms of active rule, and present a core rule for review that focuses on outcome instead of mechanism.
Working With Design Patterns: Abstract Factory (4-Sep-2008)
Written for Developer.com. One of the bigger challenges with using design patterns is knowing when to use one pattern over another. The abstract factory creational pattern looks similar to the builder pattern but is used to help solve a different problem.
Working With Design Patterns: Adapter (6-Feb-2008)
Written for Developer.com. Not all design patterns are complex. The adapter pattern provides a simple mechanism for conforming an interface into one that’s more useful for a client application.
Working With Design Patterns: Bridge (5-Mar-2008)
Written for Developer.com. Separating interface from implementation is a fundamental object-oriented strategy, one that’s also the essence of the bridge design pattern. You can use the bridge pattern to help solve the more complex problem of separating tangled hierarchies.
Working With Design Patterns: Builder (21-Apr-2008)
Written for Developer.com. A common theme in design patterns is organizing things so as to separate high-level policy from low-level underlying details. The builder pattern does just that, by allowing a single construction policy to be realized by many different implementations.
Working With Design Patterns: Chain of Responsibility (7-May-2008)
Written for Developer.com. The chain of responsibility pattern allows you to emulate a real-life chain of command. In a chain of responsibility, a request moves from handler to handler until someone is able to manage and return it to the client.
Working With Design Patterns: Composite (2-Jul-2007)
Written for Developer.com. The composite pattern takes advantage of recursion to help produce elegant solutions. This example diverges from the typical examples of the composite pattern.
Working With Design Patterns: Decorator (18-Jul-2007)
Written for Developer.com. The decorator pattern gives you the flexibility to wrap special behavior around objects. Unlike inheritance, which gives you the ability to predefine specialized behavior, using the decorator pattern allows you to dynamically attach specialized behavior.
Working With Design Patterns: Facade (21-Feb-2007)
Written for Developer.com. Object-oriented languages provide great opportunities to isolate complexity in a system. A facade buries an unwieldy interface behind a simplified one.
Working With Design Patterns: Factory Method (28-Aug-2008)
Written for Developer.com. Your production code isn’t the only place you will find a use for design patterns. The factory method pattern helps you answer a question about how to organize your test classes.
Working With Design Patterns: Interpeter (22-May-2008)
Written for Developer.com. Many of the design patterns lead a double life–the structure of some patterns are exactly alike, but the intent differs. An interpreter is a composite whose purpose is to support interpretation of a simple grammar.
Working With Design Patterns: Iterator (9-Jul-2008)
Written for Developer.com. Patterns exist for virtually all common programming challenges, even one as simple as “how to traverse a collection of objects.” The iterator pattern provides a consistent solution for something that programmers do daily.
Working With Design Patterns: Mediator (5-Jun-2008)
Written for Developer.com. Objects talking to each other and no one in control? Messages going all over the place? The mediator pattern can help you control the chaos!
Working With Design Patterns: Memento (10-Jan-2008)
Written for Developer.com. The Memento design pattern presents a consistent solution for storing state, allowing you to build undo and redo support in your applications with ease.
Working With Design Patterns: Odds and Ends (18-Sep-2008)
Written for Developer.com. The design patterns book lists 23 design patterns, but that’s just the beginning! Many more patterns exist, including the specification pattern, lazy initialization, object pools, and the utility class pattern.
Working With Design Patterns: Prototype (2-Apr-2008)
Written for Developer.com. Like the abstract factory pattern, the prototype pattern helps you adhere to a clean design by moving object creation into a polymorphic hierarchy. When using the prototype pattern, you create objects by making copies of already existing instances.
Working With Design Patterns: Proxy (1-Aug-2007)
Written for Developer.com. (The original, official title is Design Patterns: Proxy) The proxy pattern provides a protection layer for your objects by exposing a stand-in to interested clients. I’ll explore one possible use for the proxy pattern in this article.
Working With Design Patterns: Singleton (20-Mar-2008)
Written for Developer.com. The singleton pattern is one of the simplest in the catalog of design patterns. Lurking beneath its simplicity is the potential for testing trouble!
Working With Design Patterns: State (19-Jun-2008)
Written for Developer.com. The state pattern can help simplify complex conditional logic by representing individual states as classes, each with its own simple behavior.
Working With Design Patterns: Template Method (27-Apr-2007)
Written for Developer.com. What can we do with duplication? The template method pattern allows us to move common portions of an algorithm to a base class, and leave “holes” to be filled in by derived classes.
Working With Design Patterns: Visitor (28-Jan-2008)
Written for Developer.com. Visitor is often viewed as a complex pattern that’s often regarded as difficult and troublesome. But the appropriate use of visitor demonstrates what’s at the heart of good object-oriented design.