“TDD or BDD?” or “Functional Tests or Unit Tests?” Write any tests! The more clearly you understand the purpose of those tests, the more these apparent dilemmas will fade into the background.
It’s easy to give the instruction to reveal intent, but harder to provide helpful examples. I’d like to provide a tiny one that illustrates the point quite clearly—at least to me.
When you notice that you need “too many” stubs (mocks for querying data), you have at least two helpful options for refactoring. Here is an example of using the more-aggressive of the two options: replacing a stub with the stubbed value.
Let’s look at a simple example of a name. Let’s judge the name (kindly!), then imagine some likely next steps in refactoring. We can learn and do quite a lot from only a single name!
No, tests aren’t supposed to make refactoring easier; they make refactoring safer. Sometimes, by accident, they do both.
The stronger your refactoring skill, the more easily you can use architecture advice as guidelines instead of as rules to enforce. This makes it significantly more likely that you’ll invest wisely in architecture, rather than over- or under-engineer.
Just another little example of two people looking at a situation, one seeing a problem and the other seeing a solution.
What happens when I try to review code in small steps and in public? Let’s find out.
You refactor too much! We’re not refactoring enough! This is a problem that, with a light touch, resolves itself.
The most common definition of “refactoring” suffers from a common weakness that creates big problems for a very specific group of people. I’d like to help.
Refactoring means rework, which means that we didn’t “get the design right the first time”. This can indicate a problem. It can also indicate a natural process of convergence towards a suitable design. Calling it “a code smell” seems to overstate the matter.