Each stage of implementation is hard in its own way. When we start out with a new effort or process, we think of it as: Sure, it will be hard in the beginning, but it’s going to become easier as we continue. It’s true, and then after a while a new challenge Read more…
Kevlin Henney asked once: Why do cars have brakes? Imagine if cars didn’t have brakes, how fast would you go? You’ll be driving really slow to not hit anything. But by giving the capability to slow down, brakes actually give us the ability to go faster. TDD is like a Read more…
TDD is pretty simple right? Obey the red-green-refactor step-by-step and you’re on your way to glorious, non-legacy code. It’s really easy to explain. The rules are easy to follow. Why then so few people actually do it, and when they do, so few actually do it well? In my talk Read more…
Introducing TDD is a lot more psychological than you think. When we start introducing TDD we need to think about how people new will react. For example, the first question that people ask is: How am I going to write the test if I don’t know what the code does? Read more…
I know, you want to check out the rest of the series. Here are the links: Code simplification is one of the best things we can do for ourselves. If we understand the code, not only will we write simpler tests, we will make less mistakes. Problem is, we’re now Read more…
You didn’t think we’ve covered everything, did you? Here’s a short reminder of what we got through: Today we’re going to talk about the Introduce Parameter refactoring pattern. This is one of the more useful patterns to clear code from dependencies. Here’s a method we’d like to test: public int Calculate(int x, Read more…
If the 2nd D in TDD is design, then we’re talking about emergent design. The tests drive the design, which emerges from thin air, and step by step reveals itself in all its glory. Emergent design has got to be superior to upfront design, right? Well, it depends. If we’re Read more…
This is the 5th and final part of the series about analyzing what we’re coding, and therefore what to test. Last time, we actually got to writing the tests. Let’s do some cleanup. Step 8: Review Once we have the tests, it’s time to review both the code and tests. But Read more…
This is the 4th part of the series about analyzing our code and deciding what to test. Last time, we talked about design constraints. Now we’re moving towards the code itself. Almost there. Step 6: Prepare existing code This is an obvious step in test-after. We want to test the existing code, and Read more…
This is the 3rd part of the series about analyzing what we’re coding, and therefore what to test. Last time, we talked about test categorization and design considerations regarding testability. We haven’t touched or written any code yet. Nor will we before the end of this post. Patience is a virtue Read more…