First – realize what constitutes good tests.
The answer: little (ideally: zero) false positives. Feel free to read my previous article that elaborates on this topic.
But how exactly? Here is my answer:
Continue readingPersonal blog
First – realize what constitutes good tests.
The answer: little (ideally: zero) false positives. Feel free to read my previous article that elaborates on this topic.
But how exactly? Here is my answer:
Continue readingThis is the most important, yet the most unspoken trait of good tests. Tests should be the oracle.
If all tests are green – the app will work on prod. If at least one test is red – the app won’t work.
Think Continuous Delivery. Every step in the process has to be automated. When tests are green, there is no room for extra human checks before going prod. The decision (deploy – no deploy) is handed over to your tests.
Do you trust your tests this much? Is this even possible to be this confident about tests?
Continue readingConsider a method that calculates some ETA:
class Calendar {
add3WorkingDays(): Date {
const result = new Date();
let daysAdded = 0;
while (daysAdded < 3) {
result.setDate(result.getDate() + 1);
if (this.isWorkingDay(result)) {
daysAdded++;
}
}
return result;
}
isWorkingDay(date: Date): boolean {
const day = date.getDay();
return day !== 0 && day !== 6;
}
}
Notice how add3WorkingDays
depends on the time when it’s called (result
is initially now). Because of that, you’d have trouble writing reliable unit tests for this.
My recommendation: change the implicit dependency of now
to explicit one and inject it:
add3WorkingDays(date: Date): Date {
const result = new Date(date);
// no changes from here
It takes only so much to implement dependency injection, the most overcomplicated technique in the history of programming. You don’t need frameworks, containers, service locators, interfaces, or decorators. You only need to know how to parameterize a method.
Oh, by the way, we changed the interface of the method too. We have to change all the callers: calendar.add3WorkingDays()
-> calendar.add3WorkingDays(new Date())
Does this mean you don’t want to introduce dependency injection later in the project, to avoid risky refactors? No. You can still have DI without changing the interface using the default parameter:
add3WorkingDays(date: Date = new Date())
We often design our code so that one procedure comprises many classes, often grouped by layers. For example, in web dev, that could be controllers, models, repositories, etc:
Layers are good. Often at least two layers are desirable for maintainability: domain and low-level. If you’re like me, you like 2-5 layers but not too many.
Now how do you test such code? It comes naturally to want to test each component separately and mock out the collaborators from other layers. I believe it’s because unit tests are said to be run “in isolation”:
My advice – don’t automatically do this. Aim for this instead:
© 2024 Bartosz Krajka
Theme by Anders Noren — Up ↑
Recent Comments