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…
Once more I get into a training session on unit testing, and once more I hear “It feels wrong to change my code just for testability.” My immediate reaction was “because the design you have right now is so good, right?” (yes, I said it out loud). Let’s break it Read more…
We tend to categorize different types of tests according to what they cover. Unit tests cover small portions of code, usually a method or a class, while we mock the rest of their interaction. Integration tests cover several components in concert, and then mock the other boundaries. System tests and Read more…
This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing unit tests for legacy code, and how they make our life easier. Other posts include: In the last post, I’ve talked about Extract Class refactoring pattern, Read more…
This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing unit tests for legacy code, and how they make our life easier. Other posts include: A few years ago I got this from Erik Talboom: “A private Read more…
This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing unit tests for legacy code, and how they make our life easier. It continues the last post on accessors. Other posts include: We talked about refactoring Read more…
This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing unit tests for legacy code, and how they make our life easier. Other posts include: Adding accessors to private state data is an admission that either our Read more…
This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing unit tests for legacy code, and how they make our life easier. Other posts included: As with renaming, extracting a method helps us understand legacy code better. Read more…
This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier. Other posts include: Renaming is easy and is usually safe refactoring. Most IDEs have the refactoring Read more…
It’s a funny thing, code testability. It’s not really defined, or rather, it is defined poorly. If “testable code” is “code we can test”, that means all code is like that. We can test it through unit tests. If it’s hard we can move to functional tests. And if all Read more…