We Shouldn’t Be Writing Unit Tests

By: The Reluctant Unit Test Composer

Ah, the age-old debate in the software development scene: “Should testers write unit tests?” As a seasoned software tester with a passion for finding possible issues, I’m here to share my thoughts and arguments against this trend. Spoiler alert: it’s not because we can’t write them (We can, and we do), but because some things are better left to our developer friends. Let’s dive into this discussion with a dash of humor and a sprinkle of real-world scenarios.

Imagine a bustling office where developers are the architects, designing intricate blueprints (read: code), while testers are the meticulous inspectors ensuring the buildings stand tall and bug-free. Now, what if we asked the inspectors to also design the buildings? Sure, they might do a decent job, but would it really play to their strengths?

In this sense, unit tests are like the foundation stones laid by developers. They understand the architecture — the codebase, the logic, the dependencies. Testers, on the other hand, excel at seeing the bigger picture, simulating user interactions, and identifying unexpected behaviors. Again, not a rule of thumb, just a perception.

A Developer’s Playground

When it comes to Unit Tests, developers are the maestros who orchestrate this symphony of code and tests. They have the intimate knowledge required to create precise, efficient, and meaningful unit tests that ensure each component functions as intended, mainly because they wrote these methods, functions, components …

Imagine a developer writing a complex sorting algorithm. To ensure its reliability, he/she crafts unit tests covering various scenarios — empty arrays, already sorted data, large datasets, and so on. These tests are tightly coupled with the code’s structure, something a tester might not fully grasp without deep diving into the implementation details, which takes time, specially if you are a new team member.

Guardians of the User Experience

Now, shift the spotlight to testers. Their superpower lies in thinking like end-users, exploring edge cases, and uncovering issues that automated unit tests might overlook, which by the way it’s likely the case. They create test cases based on user stories, ensuring that the software not only works but delights its stakeholders and users.

Suppose there’s a new feature allowing users to upload profile pictures. A tester might explore scenarios like uploading extremely large files, unsupported formats, or malicious content, to name a few. These are higher-level concerns that unit tests — focused on individual functions — might not capture effectively.

When testers start writing unit tests, we risk blurring the lines of responsibility. Testers might end up writing shallow or redundant tests without the necessary context. This can lead to inefficiencies and, ironically, more bugs slipping through the cracks.

Collaboration = the key

This isn’t a call for gatekeeping or siloed workflows. On the contrary, it’s a suggestion for respecting each role’s unique contributions. Developers and testers collaborate, communicate, and complement each other’s strengths. Developers write unit tests to ensure code quality at the low level, while testers perform integration, API, and system testing to validate the software holistically.

We can see this in different environments / projects where developers write unit tests for new endpoints, ensuring each function behaves correctly. Meanwhile, testers design API and integration tests to verify that the endpoint interacts seamlessly with the database, handles concurrent requests, and manages error responses gracefully.

Wrapping

Specialization leads to excellence. When each team member focuses on their core competencies, the end product benefits from a synergy of skills. It’s not about who writes what; it’s about working together to deliver quality. After all, a well-tested product is a team triumph, not an individual effort, remember this ^

I recognize that in some environments, roles may overlap. Flexibility, simplicity, and mutual respect are key to any successful team. Now, if you all excuse me, I have some unit tests to ️finish ;)