An SDET is a developer and not a tester
--
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.
