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.
Top comments (14)
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.
Knowledge siloization is bad, but I think the amount of time required to test a software product without automated testing is also bad.
Without any automated tests, people have to ensure an app works. I've seen different people have different thresholds for how much manual testing they consider to be easy. Some people see no issue with complicated and convoluted manual testing setups, like creating 500 line JSON payloads by hand to submit to REST endpoints. In fact, this also can lead to siloization because the knowledge for the test needs to be passed to the next person. If it's not written down and the person leaves, the knowledge gets lost.
One of the benefits of automated tests is the ability to focus on very small pieces of code. I think that at a certain point, the amount of time spent on regression testing can get to be completely unreasonable when everything is done by manual testing.
In fact, I've seen entire teams dedicated to manual testing struggle with keeping track of their tests. Eventually they got to the point where they HAD to come up with an automated solution because they were wasting so much time testing the same things over and over for regression.
Perhaps you can get by without automated testing on some projects, but for massive projects with hundreds of contributors and mission critical operations it's just not possible. At least, that has been my experience.
@code42cate commented about how failure to understand code before changing is a cultural problem. I agree because regardless of manual testing or automated, if people are blindly changing things that's a project management failure rooted in a dysfunctional culture.
Good take
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
I don't see how that is working against it to be honest. If you are blindly changing code just because tests pass, thats not the tests fault but an engineering culture fault imo.
I agree. You change the code knowing full well how it works and the implications. Unit testing is in place for regression testing of the things you may not have considered. Often it's something small and overlooked, but you didn't need a full time team to catch the issue after you've merged
By automated testing, do you mean like any of unit, integration, e2e tests? If so, isn't automated testing's main value is to replace manual testing, which takes hours of man power and probably does not covering all scenarios such as regression testing? How can you make an argument against automation of manual testing? Unless you're saying that manual testing is also optional.
This is a great take and very succinctly put! The tradeoff between writing tests and productivity is not as important as making sure your devs know how to test. Furthermore, knowing how to test will actually improve how you design your components for better maintainability. Your three examples of dependencies making it hard to test is a great example.of this. Lastly, what to test for is probably the most important question and has been discussed a lot.
My thoughts exactly! I would advise the said developer to leave their employer for one who does not allow a merge until tests have passed, if they care about advancing their career in finite time that is.
It's actually illegal.
What is the "it" that is actually illegal?
As a full stack developer I agree, BUT the better approach in my opinion is to move the responsibility of creating Unit Tests to the testers as they have the Test Cases and that is their primary responsibility. This ensures the tests are more accurate and not built to have a passing result.
I disagree, if your developers can't take a TDD approach then they don't know what there expected acceptance criteria is. Integration and end to end testing is the responsibility of the testers to ensure regression issues outside of the changed code are identified.