Should SDETs Write Unit Tests?

Recently I was asked if SDETs should be expected to write unit test, and I feel the answer I gave at the time wasn’t sufficient, so I wanted to write a quick post to provide a better answer.

Sometimes other engineers don’t write the best tests. Your job is not to write tests for them. Writing valid, and effective tests at the levels they’re responsible for is part of their job. They should be capable of doing that on their own.

As an SDET, or QA Automation Engineer, you’re job is to make sure there’s sufficient and effective automated tests at every level (be it unit, integration, end-to-end, or any other level) to build enough evidence in the quality of the code to feel confident in pushing it out to production, or to prevent it from going out because there’s too many problems.

Your job is to think about how the desired behaviors of the product play out as a whole, and to think about what level a test can be performed at. Your job is to consider how these behaviors will play out when an actual user uses the product. Your job is to consider the big picture.

You’re there to make sure the other engineers don’t lose sight of the forest for the trees.

Should you be writing API and end-to-end tests? Yes. You are the owner of those tests, and they’re your responsibility.

Should other engineers be writing API and end-to-end tests? Yes. Quality is their responsibility too, and if they identify a test that you don’t have written, or you don’t have the time to write all the necessary tests, they are more than welcome to help add those tests.

Should you be writing unit tests? Yes. For the same reason a developer would write an API or end-to-end test, you should be equally as welcome and comfortable writing unit tests in the code that they own.

It’s all about collaboration.

You’re a software engineer, and should be comfortable working with someone else’s code. You don’t have to start off being able to write a backend server or a frontend, though.

If you find it difficult to understand or work with the code other engineers have written, then it’s a perfect opportunity to pair program with them. You’ll get more exposure to other kinds of code logic and structures, and they’ll potentially find out about a test case they may not have considered, and also get some feedback on how to improve their code.

The goal is to speed things up and improve not just the quality of the product, but also the quality of the code itself. Having more eyes on the code means more feedback, and more opportunities to make the code more usable, readable, maintainable, and extensible. This goes for their code and yours.

If we work together, everyone wins.


The Importance of Words: Waterfall vs Agile

17 minute read

Waterfall methodologies are often seen as the antithesis of Agile, and therefore ‘bad’. But what does it really mean for something to be ‘waterfall’? Are you...

The Importance of Words: Quality

5 minute read

We care a lot about the word ‘quality’ in the software industry. But what actually is quality? How do we use the word in our day to day life?

The Importance of Words

2 minute read

It’s natural (and inevitable) for words and phrases to change in meaning over time. But what if they were chosen for a purpose, but their meaning changes eno...

Back to Top ↑


“What would QA do all day?”

26 minute read

If the developer wrote the tests for their tickets, what would QA do all day? More importantly, what are the implications of that question being asked in the...

The Harmful Obsession With DRY

7 minute read

The intent of DRY is to help us find potential opportunities for abstraction. Many take it to mean we should never repeat a block of code. However, this inte...

Grey Box Testing: Less Is More

8 minute read

What is grey box testing? How can it benefit us? How is it different from white or black box testing? Are they all required? Do they dictate how we design ou...

1 Assert Per Test

13 minute read

You’ve heard it before, and probably many times. But why exactly is it the rule that should only have 1 assert per test?

Let’s Talk About Cypress

20 minute read

There’s some fundamental issues with the claims that Cypress makes of themselves that need to be acknowledged. Let’s take a look at their claims and see if t...

Is Selenium Actually Flaky?

12 minute read

We’ve all gotten frustrated dealing with flakiness once we start involving Selenium in our tests. But is Selenium really the problem? What can we do to solve...

Scientific Testing Part 2: Validity

21 minute read

The validity of tests helps build our confidence in them and determines the value they add to our test suites. But what does it mean for a test to be ‘valid’?

Back to Top ↑


Building Good Tests

22 minute read

A collection of testing maxims, tips, and gotchas, with a few pytest-specific notes. Things to do and not to do when it comes to writing automated tests.

Back to Top ↑