Test-first software development helps us build testable behaviors and support refactoring.
Summary of Seven Strategies Series
I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. These posts are filled with practical advice for implementing the nine core practices from Scrum, Extreme Programming, and …
Continue reading “Summary of Seven Strategies Series”
Read MoreMake Each Test Unique
I want to conclude this series of Seven Strategies for Great Acceptance Tests with the advice to make each test unique. I know this is easier said than done but it does get to the very core of what quality software development it’s all about. When our unit tests test units of behavior, then every …
Continue reading “Make Each Test Unique”
Read MoreSplit Behaviors on Acceptance Criteria
We think about what we build at different layers of abstraction. At the highest level, we have the minimum marketable feature set or MMF, which is composed of a list of features. A feature is some value that someone gets from using the system. This may involve the fulfillment of several things in the system, …
Continue reading “Split Behaviors on Acceptance Criteria”
Read MoreUse Examples
One of my favorite books on acceptance test-driven development is by Gojko Adzic called Specification by Example. This book talks about how you can specify the features of a system through examples cleanly and clearly so that they are straightforward to work through. Examples allow us to quickly flesh out details and drive out inconsistencies …
Continue reading “Use Examples”
Read MoreSpecify Edge Cases
Another huge benefit of Acceptance Test-Driven Development or ATDD is that it helps us flesh out edge cases, exceptions, and alternate paths for a story to follow. I far prefer to specify edge cases and exceptional paths through acceptance tests rather than with use cases because acceptance tests are more articulate and they are executable. …
Continue reading “Specify Edge Cases”
Read MoreAutomate Acceptance Criteria
You can do acceptance test-driven development (ATDD) manually without the aid of a tool by just keeping track of the acceptance criteria for a story and noting when it meets the criteria. Automating the process is helpful but the real value comes in articulating the acceptance criteria ahead of time. It is estimated that more …
Continue reading “Automate Acceptance Criteria”
Read MoreKnow Who it’s for and Why They Want it
Another huge benefit of acceptance test-driven development or ATDD is that it helps us get clear on defining features for a specific type of user. And it also helps us get clear on why they want that future. Why is really the key question. Why do we want to implement or build a feature in …
Continue reading “Know Who it’s for and Why They Want it”
Read MoreGet Clear on the Benefits of What You are Building
I have heard it said from a number of sources that the largest source of defects and the ones that are the most expensive to fix are our misunderstandings of requirements. Requirements are essential. If we build the wrong stuff, something the customer doesn’t want or need, then it doesn’t matter how beautiful our code …
Continue reading “Get Clear on the Benefits of What You are Building”
Read MoreWhy Practice 6: Write the Test First
I wrote Beyond Legacy Code to talk about the value of technical practices in software development. One of the most valuable technical practices for me has been test-first development and I really wanted to discuss it in ways that I hadn’t seen it discussed before that I found to be productive. Having exposed thousands of …
Continue reading “Why Practice 6: Write the Test First”
Read MoreMore on Test-Driven Development
One of the most valuable development practice that has become popular recently is test-driven development. When done correctly, unit tests can dramatically drop the cost of maintaining software while increasing its value. All the things that management wants and needs from the processes that are built around software development are embodied in this simple practice …
Continue reading “More on Test-Driven Development”
Read MoreMake Your Test Fail First
The test-first development cycle means that first we write a failing test and prove that it fails by running it and seeing the red bar. Then we implement the test so that it passes and we see the green bar. Finally, we refactor the code and the test for quality and maintainability. That’s the test …
Continue reading “Make Your Test Fail First”
Read MoreDon’t Write All Your Tests Upfront
I find that different people have different ideas about what test-driven development really means. Some people think that test-driven development is about writing all of your tests after you write your code. To me, that is not test driven development. I call that test-after development and when we do TDD we write our tests before …
Continue reading “Don’t Write All Your Tests Upfront”
Read MoreIt’s Not a Test of You Write it First
Although I am an advocate of test-first development, I also acknowledge that there’s a bit of a conundrum in the name test-first development. How can you write a test for something before you write the something? There’s nothing yet to test so how can it be a test? The answer to that question is that …
Continue reading “It’s Not a Test of You Write it First”
Read MoreWhy Write the Test First
As you can probably tell by reading my blog, I am a proponent of TDD. But my enthusiasm for test-first development took a long time coming. It took me a long time to convince myself that TDD had great value and was worth the effort. Software developers already have too much to do and not …
Continue reading “Why Write the Test First”
Read MoreDoing More of What We Love
Developers love writing code. It’s what we’re good at. It’s what we do. But all sorts of things get in our way: Meetings. Reading and interpreting specifications. And the worst time-sink of all—debugging. Most of us would rather do anything other than debugging, but that’s where we end up spending a lot of our time. …
Continue reading “Doing More of What We Love”
Read MoreFlying Blind
The way most software is developed—designing entire programs on paper and then typing them into a computer in their entirety before they run—is like flying blind. Software is virtual. We can’t see it or touch it. The only feedback we get is when we compile and run our program. But on a Waterfall project that …
Continue reading “Flying Blind”
Read MoreWriting Good Tests
As Misko Hevery, the author of AngularJS, says in his outstanding Google Tech Talk series “Clean Code Talks,” most developers assume they know how to write a good test but they don’t. Knowing how to write a good test is paramount to being successful with TDD. Tests must be unique, expressive, and independent—easier said than …
Continue reading “Writing Good Tests”
Read MoreSeven Strategies for Solving Problems Test-First
Using tests to drive development in TDD concertizes abstract requirements making them easier to understand and work with. This is a very powerful way of solving software problems while at the same time creating maintainable code. Here are seven strategies for solving problems test-first: 1. Think outside-in Before solving a problem we must first understand …
Continue reading “Seven Strategies for Solving Problems Test-First”
Read MoreThe TDD Zealot
On December 22, 2010 Mark Seemann published a blog post The TDD Apostate. Since then several friends and associates have sent me links to his post as if to say, “See, TDD is not all it is cracked up to be.” It is an excellent post and I agree with much of what the author …
Continue reading “The TDD Zealot”
Read MoreReflections on the Three Steps of Test First Development
Decide what to do, figure out how to do it and then do it well. These are the three essential steps we perform over and over again in TDD. Each step is different and requires us to focus on different things. Separating out these steps helps us focus on each one at the right time, …
Continue reading “Reflections on the Three Steps of Test First Development”
Read MoreTriangulation
If I get stuck and I don’t know how a complex algorithm should work I’ll write a test for an error case. Then I’ll write a test for the simplest non-error case I can think of and return a hard coded value. Then I’ll write another test case and see if I can figure out …
Continue reading “Triangulation”
Read MoreIt’s Not Easy Being Green
Kermit the Frog used to say that it’s not easy being green and he was right. In TDD we want to stay in the green as much as we can. When our tests are green life is good. Turning the red bar green can be easy at first but keeping it green can be very …
Continue reading “It’s Not Easy Being Green”
Read More