The dynamite double
Side effects should be isolated, kept in code that is separate from domain logic, and have no conditionals in them. They are the adapters in the “ports and adapters”-pattern.
To test code interacting with the ports, we need test doubles to use as the adapters.
As an example we have pseudo code for a system that sometimes start a siren.
The code actually starting the siren is wrapped in a simple class
implementing the port-protocol Siren.
protocol Siren {
void turnOn()
}
The code starting the siren gets it as a parameter,
together with the boolean emergency.
I really don’t want the siren to go off when there is not an emergency.
So to make sure that the function does not even try to start the siren, we use a Dynamite Double. It is a test double that fails the test if the code tries to call its functions. Touch it and it explodes.
class DynamiteDoubleSiren implements Siren {
void turnOn(){
make.test.fail.horribly
}
}
Instead of using a test double that records if, and how, it has been called, I feel safer if the “no action”-alternative is tested with a dynamite double.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about quality and testing, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.