When Clean Code Gets Messy: Surviving Over-Engineered Test Automation - by Bruno Figueiredo

In this talk, Bruno Figo explores the complexities of test automation and the potential pitfalls of overengineering. He discusses his experiences in different projects, focusing on how excessive complexity can arise from a lack of understanding and knowledge within teams. Figo questions the common practice of applying principles like SOLID in ways that can lead to unnecessary complexity, arguing instead for simpler, more effective approaches. He emphasizes the importance of context in choosing automation strategies and tools, advocating for practical solutions that prioritize maintainability and efficiency in software testing. The session prompts attendees to reflect on their testing practices and consider whether they may be complicating solutions without genuine necessity.

Challenge accepted. [music] Challenge accepted. Challenge accepted. P2 [music] is always challenge accepted. Our next speaker is a passionate QA engineer and teacher with over 10 years of experience helping teams in Brazil and Europe build better frameworks and smarter testing strategies. >> He's also the creator of M3QA YouTube channel where he shares practical knowledge, career advice, and plenty of real talk with the community. and one of his

proudest achievements growing up in some small town in Brazil, studying hard and pushing himself all the way to Europe to become a Q8 engineer and teacher. That persistence is inspiring. >> Please welcome the guy who forgot to say yes at his own wedding, but said BTS to QA challenge accepted, Bruno Figo. [screaming] >> [music] >> Hey, I understand you. I would like to to continue with drinking

a beer. [laughter] [gasps] So, let's it speak about complexity and look a little bit. This is my intention and by the way explain a bit to you. I won't provide any solution to you. I probably will provide a lot of question. This is my goal here to provoke you. who from you already is working with automation or has worked? Who? Who? Good. Good. By the way, I

answer the question and I will ask the questions. But let's go. Me too. And how long? Think about that. How long usually you take to understand the projects. When I say understand the project, if for example you got hired for a company, then you need to provide the solution to create new test cases to for example if you are working with seleno with playright how long you

get the code and say okay I'm 100% uh I have the 100% of the knowledge to be to continue building the solution. Have you stopped to thinking about that? Okay, think then I will give my answer and in this kind of context how was the experience and how was the experience to continue it's failing to continue a project instead of in this case to start a project

from the scratch I'm asking this to give you some context next because I had some issues and I was trying to investigate and try to found some solutions for some problems that I had or that I have been uh answering these uh usually if I start if in this case if I start on a new company that there are a lot of project ongoing usually I take

for example one month two months depending on the case maybe until six months to control in this case the but the problem it's not because I'm bad or not because I don't want to build the solution, but because we had a a lot of unnecessary complexity on the projects on the solutions of automation and because of uh we have a bad experience with software automation in general.

And so this is AI. Okay. And you are seeing that I'm not good with AI because I'm a bit different. But uh it's just to refresh the idea that I'm here to uh to provoke you to put in your mind to start to thinking a lot of things that I want to bring to you and I will tell some histories that I had and this is the

idea is to speak with you about complexity in testing automation and as I said more questions than answers unfortunately. So let's speak about overgineering test automation. We had um we had a uh talk here about engineering but it was not the opposite of that talk. it was on the same way because the problem it's not engineering it's when some cases we had overengineer then I will speak

about that so speaking about the problem of complexity in projects of of test automation I was trying to identif identify and I found at least three issues And these three issues are connected. Usually it's lack of knowledgement. When I say lack of knowledge, it's a huge bubble. I can say because could be lack of of knowledgement in for example in code could be lack of knowledge in

in the project that you are working from. Could be lack of knowledge inclusive in process. For example, we are developing a solution from software automation and we even had for example a pH question view. It's a lack of knowledgement and it's a lack of process. They are connected and of course we have a lack of time that yeah it's a issue that we have then we we

could start increasing the complexity of the project because of these issues. And who is key leader here? Just you. Unfortunately, I won't explore more this idea, but sometimes could be intentional. Um, intentional why? Because for example some QAS could uh increase the complexity of the solution to say okay uh I can do this task because just I know how can I do this this test but uh

I want explore this theory my theory remember it's a theory probably I'm not right this is a theory that I want to share with you and my It's that some QAS are using principles like solid. solid it's just an example but could be another framework another solution could be for example pio objects could be a lot of patterns that we have in industry but I guess solid

is one of the most famous then I will explore this theory and the QA are using this it's highlighted an excuse use to create excessive complex project. This is my theory. Let's speak about this theory. But I will just give a quick review about solid because okay I will explore this idea then I don't know if you heard about or if if you know I want just

to to give a quick explanation just to review solid it's a set of five principle created by aka uncle bomb and solid is good remember I'm not criticizing solid I'm criticizing using wrong solid this is the problem and this principle was created to to increase in this case um the escalabable of the system to organize better and to increase the manut of the system. This is good.

This is not the problem. I will just refresh um these five principle. Then I tried to connect this with our area with QA area. I will just focus on the example and on the benefit. For example, instead of having a re general report class, we can split into report classes. For example, one single class for the hippot generation and other tooth printer. The benefit it will be

to to have a easy maintenance and reduce the impact of code changes. Okay, the open close principle. The idea is for example, okay, I need to test a new payment uh new payment test type instead of add this test on the class that we already have. Okay, create a new class and split this to avoid the risk of breaking change. Okay, the list of substitution principle for

example instead of I have just a single class for example like I login page we can create three that we can for example have some general methods and for the web login page and for the mobile login page we can have another then we can swap between each others and we increase the flexibility and reuse of the And we also have the interface of segregation principle. Instead

of for example have a big generic class we can split for example in test from the registration test from the product. This is very used on the page objects approach. The idea is to improve system comprehension and maintenance. And finally the D it's the dependence of inversion principle. for example is very used on selenium because instead of we have uh in direct instantiation for example for the

chrome web driver we can create an interface that we can choose on the execution for example okay then I can swap between chrome edge and the other browsers given this context I will try to represent the problem of complexity have you ever worked with Cyprus who from you do you agree this are you explain of course do you agree this code it's a easy code to understand

and to use no one okay yeah I will try to force this code to be harder to understand and harder to maintain giving you some context but for example this is a simple test Imagine I just have a single API with save this context on your head. Okay, I maximum four endpoints. One of them is this. This is a get from users that that I'm just checking

if the status is 200. If we have an array on the body and we are checking three parameters. Okay, this is easy. Let's assume this. the problem about overg engineer always start when someone say and if something happens. Have you heard about it? if trying to to to provide a future if we uh we don't have any plans we don't have any any plans it's just that

single API but only have someone to try to and if and if and if you decided to increase the quantity of property what I should recommend do add two lines add two lines that's it the end of presentation >> [gasps and laughter] >> But usually or what happens if you don't adapt for your context normally you can create a raw boost application just to avoid two lines

for example I will force this scenario and try to explain to you for example and if okay now I will create a new class a new user ed class to save the parameters. I will create an API request because you said and if I decided to have a post request a after okay I will prepare but I won't have this is a problem I won't have okay

two classes the third class and if I decided to validate better because I need to check for example why are you logging and if you decided to validate name, email and detail. Okay, third class. And finally, of course, we need to test this into a single class I could create another test class just to save the user endpoint. That is correct. Okay, but I will skip that.

And so now instead of have one class, we have four class to do the same task. But you can ask Bruno okay but in in this in the case that I will have this situation that I need okay this approach it's correct but what I'm saying that it's for simple situation you need to use simple code or simple approach this is what I'm trying to put your

y on your as a result Instead of have a code simple, we have now a code harder and understand to maintain. Of course, this is just for classes. But and if if you're starting to create more classes, more classes, more classes. And the problem it's the forced solid. It's not the solid. Okay. Forced solid. Example, create a robust and unnecessary extra tour for simple tests. [snorts] This

is the problem. If we decided to test just direct on Cyprus, we will solve our problem. We going to test, we will have more time to drink some beer. And it was more simpler. And this is uh the the the idea that I want to put your to reflect. And we have another more issues. For we could using always this approach without any criteria. This is the

problem without any criteria because I just decided that I want to overengineering my code. We could had a misalignment with the proposal of tests because instead of to be concerned with bugs with quality with another things I will spend time giving maintenance to that code that I'm not taking any advantage but remember on that situation and we are creating this is my theory it's a cognitive overload

I don't know if you have heard about that but it's like if I just needed to create a new test for that class I will there add two lines okay I will back to my work but if I need to load on my head one classes five classes 10 classes end of the day I will be with my brain uh tired and this is a problem because

we are not 100% to do our things and I need to to search about what the specialist said. I was looking on this on this application and we have a sentence there on the course that they said that test code should be simple and easy to maintain. I will explain why and do an analogy. And the first I guess it's not the first but another reflection are

we forgetting about this sentence when we are trying to apply these patterns I won't give you a answer but thinking about that but remember without any criteria just applying because I need to apply or I want to apply I want to to show to my boss that I know solid that I know the principles then the code now aids It's hard to understand and yeah and I

don't know if you have heard about this analogy for example a mechanic understanded the technical details of the car the driver only needs to know how to drive and inside the car the QA that focuses just focuses on the code may forgot to simulate the user role and some stories about complexity during a PR view. Okay, I was doing my test code and usually I like to

send my push requests to the devs team. This is excellent by the way not for just uh usually I was able to to submit my PRs just to QA team but I like to to put to get the inputs from the dev team. Then a dev just requested me a single to in a class that I would need to factor all of my code and the point

is in terms of the theory it was a good suggestion. It was a really good suggestion. I was you I I had to refactor my code. Okay. But in terms of advantage, I was taking anything. I just will would factor my code. But the passes will run on the same way. I won't get any advantage and it's like okay I don't need to do it then I

justify it with it. I justify so this is too much complex. I don't have any advantage then because of that I won't do it. But the history that inspired me to be here it was this history believe on me to do a simple get. It was just a get. Oh my god. I don't want to to be nothing special. I just wanted to do a test. It

was three repository. three three not just one neither two three repositories to do a simple test. It was like a repository to save the details. It was repository to save the logic and was repository to do the tests. Back again on the theory that code was beautiful. It was beautiful but in practical terms it was at least a half of hour just to create a test because

for example if I need to create a get I will need to on the first repository put the DTO and after align with the logic and after align with the tests and get and pull and a lot of issues that the result it was it took a a hours to do a sample test. And um just another reflection, we are on the AI area. It's a reflection.

I'm not saying that this is correct, but for uh sorry uh it will sometimes we are just trying to avoid the repetition of two lines because we don't like to repeat lines. But for example, if this is easier to maintain, why not ask this for yourself instead of create a robust solution just to avoid repeat two lines. Thinking about that, I'm not saying that okay, let's repeat

Ctrl Ctrl V in all code. I'm not saying this, but analyze your the context of your project. And just to finalize, for example, some questions that some people ask me. For example, page objects it's good or not selenium I guess it's mandatory for example I I cannot imagine of course you have another approach but for me it's good but for example for playright and cypus in my

opinion it's not necessary you are adding more complexity then use directly the framework and including the frameworks that don't suggest use pio object approach but the point to reflect if depend of your project needs. If you are using it to work with pure objects, yeah, could be a good option if you have for example junior junior keyways that are not used with the control of pure objects.

consider to use this is the question always check the project your the necessity of your projects and for example cucumber I don't know if it's a polymic but for example we have positive points integrates very well with selenium it's really good for beginners including the beginners on the projects that wanted to read and to understand the project many companies is still request on the job. I'm I'm

checking the time and we have but we have some negative points that it's almost impossible to avoid the repetition of the code because for example I want to click in a button then I don't know even that I created already or my colleague already created it's hard to to keep this control and sometimes it's hard to to maintain this project in lac project and my final thoughts

Simplify automation is essential remembering the best practice are important but think they should not over complicate the code each project has its specific needs think about that and automation is a computer sizes and size we don't have absolute truth That's it. Thank you for your time. [applause] Thank you. Thank you, Bruno. Do you have any questions? Questions? Questions? Questions? Questions. >> Reflections. Maybe >> there is one,

isn't it? >> Do you have question? >> No. >> Sorry. >> I cannot I cannot listen. Why? What? >> Microphone >> please on the mic. >> That guy who was fighting. >> Oh, okay. >> The guy who created because I joined it then I got squared and but it was I was just a QA. I was not a QA leader but after some time the guy was

fired. Not just because of it uh but because it was a bad decision. Yeah. But we we override that. [laughter] >> Thank you. Do you have there's another >> Do you have another approach better than cucumber? Was that the question? Okay. >> I guess cucumber it's approach. I guess it's like the paint of the project. Sometimes could be better not to use the cucumber. >> Thank you.

[laughter] >> Are there any questions for vegetables or something like that? Okay, you can find Bruno in the speaker corner. Please bring him a beer there because he needs one. And let's send him off off the stage with round of applause. BRUNO >> [screaming] >> OH.