2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- May 30, 2018 ( 1 comments )
- Write the Test First
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 we write our code.
Some people think the test-driven development is about writing all of your tests upfront and then making each one pass, one at a time. I don’t consider this test-driven development either because one of the main benefits of doing TDD is the higher level perspective you get by thinking in terms of the context of your test. It’s actually the feedback of going between code and test that gives us this insight. By writing all our tests up front and then making each one pass, we often lose some of this insight that we would’ve gotten otherwise by building software iteratively.
I believe that software development in its highest form should be a discovery process, but I know that those words make some people a bit anxious. I can certainly relate. I remember times in my early career when I didn’t have enough information to start coding but I started anyway and ended up basically wasting my time and my customer’s money. My solution back then to this dilemma was to do more planning upfront, like any good Waterfall developer. But there are some things that you just cannot foresee in planning upfront can be really hard.
Building software requires deep thought and I find that I get a great deal of insight as I’m coding, as opposed to thinking about coding up front. There’s a huge difference between building a planning and executing the plan. There’s a difference between reading a map and taking a journey. Very often, what we think is on the map doesn’t fully represent the actual journey.
When I do TDD, I focus on creating a small behavior in the system by first defining a test for that behavior. When I do this, I set an expectation on what that behavior will do, as well as what parameters I need to call for the API that generates the behavior, and what return value I expect back. In other words, I get crystal clear on what it is I’m about to implement. That’s what writing a test does when you do it before you write the code. It sets your expectation and that can be very powerful.
The saying goes, “ready, aim, fire,” not “fire, aim, ready.” If we want to hit a target we have to aim for that target and writing the test before writing the implementation is the process of focusing my attention on what it is I want to create.
Many developers who have not been exposed to test-driven development properly see writing tests up front as busywork but I couldn’t disagree more. Writing a test before writing the implementation for that test is like having guardrails, they keep me focused and in the channel where I can implement the behavior that does what I wanted to do and is independently testable, and with good code quality. That’s exactly what I should be focused on when building software.
{1 Comments }
Previous Post: « It’s Not a Test of You Write it First
Next Post: Make Your Test Fail First »
I like your last paragraph!