Hi everyone, I’ve been giving this some thought lately and would love to hear your opinions. Should testers also write unit tests, or is that strictly the developers’ domain? I tried to share my own thoughts in my article, but I’m genuinely curious to hear your thoughts, especially from those who’ve worked in both testing and development roles.
5 Likes
I believe it depends on the team structure and project needs. It makes sense for testers to contribute to unit tests, or at least review them, it builds stronger understanding of code base and helps identify early gaps. A collaborative approach where both QAs & Devs discuss coverage, edge cases and test strategy always lead to better outcomes.
10 Likes
I’m 100% with @ansha_batra .
In my organisation, its a dev responsibility as the goal of unit tests is to ensure the software builds, integrates and is operationally sound. QA have different eyes, we’re checking if its “fit for purpose”. Throughout my experience, devs are better at unit tests and QA Engineers are better at checking if software is fit for purpose. Thats why its a different skill.
However, going back to what Ansha said both areas need better awareness of each others test responsibilities. There is undoubtedly cross over at some points and testing could be far more efficient and collaborative if QA understood the coverage of unit tests and vice versa. This is definitely an area for my engineering team that we need to tackle.
4 Likes
I also agree with @ansha_batra that “it depends” but in most cases here in Belgium, it’s not part of the job description.
What I tend to do is introduce Mutation Testing for Unit tests though! 
Because developers will often come to you with “we have 85% code coverage” but code coverage is bullsh*t and that’s why Mutation Testing exists <3
5 Likes
Well, In Automotive I do mostly unit test. And when testing the complete thing (the car),I am primary focussed on how the Unit I am testing responds in the context of a complete system.
But in Automotive this is normal as you have one unit (ECU) in charge of some feature (for instance infotainment). So the way to develop it is to create a framework that simulates the rest of modules that are involved. Basically your testcase simulate inputs to your unit and observe the outputs. We speak here about black box testing. Well, in Automotive this is normal and clients hire different companies for test different units. And also different companies for write the unit internal code. I must admit that in my six years of experience most companies test one Unit or subsystem. Just look at the job offers in Automtive for testers. You will find somithicg like “Software Tester needed for Powertrain, or ADAS, or Battery Management, or Infotainment, or suspension,…”
3 Likes
It also depends on the tester, I would say. Some testers are quite programming/automation focused while other thrive in the external interfaces, likes systems rather that details. A popular manager assumption is that one kind automatically have the other preferences but its not what I have learned, starting testing 1989 and returning to whats fun after a long career in management.
Unit tests gets very codey and well, it should not be stuffed down anyone’s throat.
3 Likes
I think testers should help create the test cases to be unit tested but I wouldn’t have testers be the sole creator of them(of course they can help when needed). Devs should write the code in a testable way and if we remove the devs from the testing process it just turns into “I wrote my code and testing isn’t my problem.”.
Here we let testers help create the test cases and give the devs the work to do, and then validate it. That way they know what to test for, but also the devs know the code the best. It’s just easier for them to write it. We also use Mutation Testing to highlight problematic areas and if a service for some reason is below 80% Quality Engineers may step in to backfill the missing test cases.
Removing Devs from testing is a big “Pitfall” identified from DORA it should be collaborative. As a dev, I want unit tests to document my code does what it says it should do. As a tester, I want tests to validate the end-users experience is what we expect it to be. 2 different domains, but both working in quality. Testing from different perspectives.
2 Likes
As simple as that for better Role clarity, in my company testers avoid writing Unit Tests… As these tests are usually considered part of the developer’s responsibilities since they directly interact with the codebase. Overloading testers with unit testing duties can distract them from focusing on higher level testing aspects… And we testers usually are short on time anyways
3 Likes
Totally agree. In my experience, unit tests shouldn’t be done in total isolation by developers. They’ll write the tests, but they should still be reviewed by all concerned.
2 Likes
Testers should be exposed to unit tests and know how to write them and their purpose so that they can review the unit test cases of developers if necessary and avoid writing the same test cases in their own test cases to avoid redundancy and save time.
2 Likes
Not directly related to the question posed, but the question made me think about something I posted sometime back relating to unit testing and UI test automation:
2 Likes
I found it interesting that the discussion made a reference to UI tests and it’s a big tangent but you need to ask should testers write UI tests or even more outlier consideration should testers write tests?
Lets skip the latter and consider the UI automation coverage. This is the one that has caused a lot of problems because often it hits that inefficient layer to get the coverage and its often because there is no lower level tests never mind the consideration to cover at that level.
When those things are evident then testers writing UI layer tests is problematic and the work around can be to also empower them to write lower in the stack tests so at least you get optimal layer coverage.
Now if developers did the UI layer tests, that correct layer issue would be much less likely to exist so in theory it seems a better option for developers to write UI tests rather than testers write unit tests based on that correct layer goal.
Then you have the efficiency question, and again it leans strongly to developers writing these tests as they build the software.
Then there is the correct skill set argument, I think testers are very capable of this but good chance they’d be bored and start thinking if I’m taking this pain then I might as well become a developer who can cover all layers in stack. So is this the better solution?
Combining these it seems to be a general no on unit tests unless its a progression to that developer role.
Testers doing UI coverage is less straight forward and even when it makes sense for developers to cover this there will be pushback and less clear arguments for this.
I tend to view higher value in testers when they are doing something different or more than developers, often that is a different bias towards the unknowns, sometimes its better test design skill but offering something more at unit level is in my view harder and if testers are doing unit tests they are very likely just replacing developer coverage of the same thing but slightly less efficiently.
I am bias though as I fit into that its not fun for me category.
2 Likes
Thanks for sharing the article, very interesting read! As you mentioned, it’s important that POs are designed in a way that they don’t require major refactoring when new scenarios come up and I wonder if this is where the QA mindset plays a bigger role than we sometimes credit it for?
I completely agree that technical skills are key, but I tend to think that the QA mentality, understanding the product and anticipating future scenarios, is just as important when it comes to designing scalable framework architecture and Page Objects.
I think all the major points have been hit and I agree with the general sentiment that its good for testers to be able to read, and review unit tests, but writing is good practice for devs. Some of my devs are TDD style devs, so unit tests are a natural byproduct of their process. Often when they discuss code they talk about what tests to write to solve the issue.
I encourage my qa team mates to do MR review to get an idea about what the devs chose to do to implement a fix or feature to spot any obvious risks or missed requirements and learn a bit more about the logic that powers the system. Where they excel though is putting the big pieces together and seeing across service boundaries and integrations. In many ways this is the hand off, the devs test the code and smoke briefly while the QAs review MRs for quick checks and test/verify deeply. But of course, different organizations and code bases could benefit from different involvement of the teams.
Small aside though, all the testers who were really good at unit test reading ended up becoming devs, so its a good skill to have no matter what.
1 Like
That maybe be true as well, it makes sense. Sadly in my time working within QA, I rarely came across colleagues with that level of understanding and planning to design highly flexible page objects for tests. May be just my luck I guess. I think those with this kind of QA mentality, especially that also have the technical skills are some of the rockstar QAs you might encounter.
1 Like
This is really great!