Manuel Artero Anguita 🟨Today i come across this tweet:
which reads
Does anyone have any written articles or anything telling what strategies they have used to introduce their colleagues to the wonderful art of testing? In cases where they say "I don't agree with tests."
this part:
"I don't agree with tests."
oh my dear, this isn't about an active stance. Considering the generation tools we have today, I'm afraid...
It's a skill issue
I've been there.
- You know the theory: tests are good for the codebase.
- They act as documentation for devs.
- They offer coverage.
- They give peace of mind.
But here's the real problem. It's not about a "stance." It's just that you don't know how to write the test.
And you've tried with the official docs, which look something like this:
function foo() { return 42; }
expect(foo()).toBe(42)
You already know how to test a simple "input-output" function.
But in the real world, things are more complicated...
- You want to test a React component, but it depends on 4 contexts, page location, and a router?
- You want to test a Node.js object, but it depends on 8 external libraries, has a messy internal state, and needs some obscure pre-fetching from Dracula’s castle?
- You want to test a Python class, but it’s tied to RabbitMQ, and getting the system ready is a nightmare?
The first step is admitting: it's a skill issue.
And that's ok
Testing is a skill. And it's different from regular coding.
Start small, break down the dependencies, and isolate the parts you can control.
Control is the key:
The moment you can test your "component" is the moment you fully control your code.
*"component" as an abstract term, your class, your module, your system...
you know when i did finally understand-understand (like really understand) React contexts ? when i was able to test them!
Another related post:
Mocking libraries exist for a reason. Master the tools available, whether it’s Jest, Playwright, Pytest...
Remember, it's a skill. And like any skill, it can be learned.
