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!
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.
Top comments (5)
I've been a professional developer for almost 30 years and have VERY rarely used any form of automated testing.
I've always thought (and seen plenty of evidence) that automated testing very much encourages a siloisation of code knowledge, and really isn't good overall for teams working on a project. To my mind, if you are working on some code - you should UNDERSTAND that code and the ramifications of modifying it. Automated testing encourages a hands off approach and a reliance on the assumption that the tests are 'correct' and up to date - keeping the code being tested very much as a black box, with no real understanding being gained.
Do you expect every developer, no matter the maturity, to know every single line of code in a project with hundreds of thousands or millions of lines of code?
No, but it's a great idea to have them actually understand the particular code they're working with, and its relationship to the project. Automated testing works against this
It's actually illegal.
What is the "it" that is actually illegal?