An SDET is a developer and not a tester

Image for post
Image for post
Photo by Markus Spiske on Unsplash

More and more companies require that both the application code and the test automation code (for UI, API, etc) are written in the same language. This can be Java, C#, JavaScript, Python or Ruby.

The reason is simple.

They want the developers to contribute to the test automation code, read it and maintain it (if needed).

Sometimes, these requirements remain unfulfilled (as application developers do not have time for other things than the application they build) but in many cases they happen.

Moreover, not only the programming language should be the same but the repository as well. The test automation code should live in the same repository as the application code. This may be very useful as the automation project may need and use many classes that the application project has for product or general purpose functionality.

So, you have in the same repository two types of code:

  • the application code
  • the test automation code

The code is written in the same language, for different purposes and , at least initially, by different teams.

Should the code follow the same rules?

Should the test automation code be at the same standard as the application code?

Is this a normal requirement? Or we should be ok with the test automation code following different rules than the application code?

In many projects, the test automation code is written in ways that may make developers have a bad reaction while reading it.

It may have long variable and methods names.

It may rely on utility classes that have lots of different and , in many cases, totally disconnected reasons to exist.

It may have classes with setter methods which lead to having mutable objects.

Or classes with 50 or more methods.

Or public static methods and variables that are accessible everywhere in the project.

Or Null used as default value of variables or return value of methods.

Or methods with multiple purposes and sometimes with hundreds of lines of code.

Or Manager and Controller classes that are inherited by all other classes.

Or obscure code commented heavily.

Or custom libraries instead of using known 3rd party libraries.

These things are so common in test automation projects that you may start looking at them as normal.

But the question is, what would a developer think when he sees them in the test automation code?

Would he be pleased?

Would he agree to this style of development?

Or consider it not good?

All above “test automation patterns” are in fact development and OOP anti-patterns. They are patterns that should not be used in test automation project and avoided as much as possible.

Using them leads to code that is not OOP oriented (static methods and variables, utility classes), is difficult to maintain (large classes and methods), may lead to unpredictable results (mutable objects, null values).

Good developers do not do these kind of things so you should not see them either in application or test automation projects.

An SDET is a software development engineer in test.

In short, a developer.

Being a developer that works in a test automation project does not mean that different development rules and patterns should be used. Development is the same regardless of the type of the project.

But, let’s say that you find some anti-patterns in your test automation code.

How do you fix them?

In some cases, you may find solutions on Google, or on development blogs and books.

But there is another way, far better and faster.

Ask a developer to do a code review of your code.

He should review your test automation code in the same way he reviews his peers code.

You do not want or need any special treatment because all code should have in the end the same quality.

Written by

Blogs about Selenium and Java at

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store