In this article I want to write about the automation code that is impossible to read. I’ve seen around 10 automation projects in my life and 8 of them were written using a very complicated code. I want to share my opinion on the reasons why that happens.
The separation on Software Developers and Test Engineers
The problem that I see here is that Test Automation Engineers feel themselves underestimated in comparison to Developers. From my point of view both Test Engineers and Developers are Software Engineers and there is no need to prove anything to each other. I think that exactly this misunderstanding leads to a some kind of competition between Test Automation Engineers to prove whose code is better in the meaning of technical complexity.
Instead of moving towards the simplicity, they are trying to use complicated structures and a lot of levels of abstraction just because it is written in a book or a Developer would do that. I will say that these decisions should be based on the project needs and not on subjective wish to be a cool guy who produces the super complicated code that nobody can understand. To be honest I’m tired of trying to understand these tests. It is annoying when you’re trying to fix something and it takes 2-3 hours to just understand what the function does. And guess what? Yes, there is no even comments on the code that explain what is happening there.
Sometimes you can argue that some simple constructions are expensive performance-wise. Yes, maybe. But let’s take a look on how much time you can save using something different. Maybe 0.1 second? And how much time will a single interaction with your UI take? Maybe 0.3-0.5 seconds? In comparison to the time that automation tests will take, these enhancements in the code can’t even cover 5% of the test execution speed. So, why should it be so complicated? We’re not writing the production code here, we’re writing something that should be easy to maintain and the process should take as less time as possible.
Abstraction for the sake of Abstraction
There is an opinion that: “Everything in your project should be fully abstracted from the automation framework you use”. I got a lot of those while presenting the article about light-weight page objects, because this concept implies the direct interaction between the framework and your page objects.
There are some abstractions that I consider useful and some are not. The most problematic is the complete abstraction from the test framework. I understand the reason behind this one. It would be nice to isolate code from the framework and have a possibility to change frameworks without doing much. But this is an achievement that will require a lot of effort from your side. The effort that doesn’t compete with the stuff you want to achieve. I see it as a big overhead for the project. And to be objective, the chance that your project will die sooner than the automation framework that is supported by thousands of people is higher.
Moreover, I like the idea of simplicity and code readability. When you use the abstraction too often in your project, the readability of your tests is drastically decreases. I worked on the project in which I can’t even say how many levels of abstraction were implemented. It was nearly impossible to debug and understand this stuff. The thing that everyone who worked on this project did, was just implementing something new instead of fixing or improving existing implementation. As a result the project contained a lot of methods and classes that had the same functionality but worked differently. It was really hard to find or fix something there.
Simple doesn’t mean ugly
I’ve seen too much code that could have been extremely simplified without breaking the programming rules. You can write simple and understandable code and it doesn’t mean that it will be incorrect. From my experience there are no developers who would like to implement something super complex instead of just picking out the simpler solution. The best code is the simplest one and if there is a way to write something simple, why shouldn’t you do that?