Struggling to understand test automation code

As part of my ā€œcareer pathā€ I’d like to learn test automation using tools like Selenium/Cypress/Playwright and I have watched numerous full courses on Youtube.

I have practiced a little bit using demo websites and everything is ok except some hard xpath to do sometimes, but it’s fine.

Recently a friend showed me a real project using Playwright and wow I was a bit lost despite the fact that I have followed some courses about test automation :open_mouth:
In a ā€œreal life projectā€ they use a lot of keywords compared to the very basic code that I saw in the courses. It was hard to me to understand the framework.

→ I’m going to show you some parts of the code in screenshot, I’d really like to know what should I study now in order to be able to understand a framework like this. What chapter or concept ?

I have the impression that most of the online courses can give basic knowledge but it’s not enough if you need to understand a real project.

Thank you for your help !

2 Likes

At first I suggest you to learn programming and it’s concepts.
Automation like this is basically programming.

Many courses tell you the technic, e.g. what each method does, but not how to organise such a project. Which is also an important aspect.

Are your familiar with the Page Object Model?
This is one common approach.

Other than that I’m not sure what you looking for.
What do you not understand from that code?

2 Likes

From the screen that I see and the little experiments I’ve done with Playwright/typescript/automation:

  1. Object Oriented Programming concepts;
    Object-oriented programming - Learn web development | MDN
  2. Typescript/Javascript;
    https://www.typescriptlang.org/docs/handbook/2/classes.html
    Asynchronous JavaScript - Learn web development | MDN
    Promises, async/await
  3. Playwright syntax and concepts;
    https://playwright.dev/docs/
  4. Page Object Model as a way to structure together page-related functions that can be reused
    Page Object Models | Playwright

What you’ve shown is code, it’s not much ā€˜automation’ specific.
The ā€˜automation’ part is mostly happening at the execution and by using the outcome of that code.
The testing part as a concept in automation is the entire thought process that you do before and after coding/executing the automation.
SWEBOK Problems, Part 2 Ā« Cem Kaner, J.D., Ph.D. (see section ā€˜tasks done by’)

If the programming language changes - like python and not typescript, or some of the tools - like Cypress instead of Playwright you’d need to learn the particularities of those.

What’s also useful is learning how to learn: search online for all the keywords in that file that you don’t understand. And go as deep as needed until you understand the base concepts that can be used to understand more complex concepts.
Examples:
.ts extension > typescript > typescript vs javascript > strict typing
typescript programming / typescript documentation > typescript for new programmer
constructor typescript
promise typescript
await typescript
extends typescript
loginpageobjects > page object models > page object models playwright
playwright documentation

5 Likes

Hi @jean-l I think it is a bit early to jump to the code before learning basic test automation concepts that apply regarding of the tools. I wrote an article about it here: Test Automation Best Practices - testRigor Codeless Test Automation Tool
BTW, testRigor would be the easiest way to practice, it is free for personal use.
Disclaimer: I’m a co-founder of testRigor.

1 Like

First off, don’t be daunted. We’ve all struggled to get started with code.

  • Don’t try to learn and memorise everything. Go just deep enough to understand what you need to get things working. The popularity of resources like Stack Overflow shows you just how much developers investigate how to achieve things on a need to know basis.
  • Don’t assume there is only one way to achieve a result. The satisfaction of seeing something work will motivate you to learn more. You will look back at code you wrote, or copied from Stack Overflow in the months to come and will wonder why it ever confused you.
  • Don’t overcomplicate things. Sometimes simple is best. Treat your code as a work in progress, refactoring when necessary. Adopt a KISS approach. Too much abstraction can lead to bewilderment and will just slow you down, at least in the beginning.
  • Don’t try to design a framework by trying to anticipate all its future needs. Let it build organically. Then when reusability becomes necessary, it will flow naturally.
    Lastly, revel in your ignorance. Ask your colleagues for help. Many will love the opportunity to mentor, or at least influence your code.

Good luck. It’s gonna be a wild, fun ride.

2 Likes

Thank you a lot for your answers guys !

I think that you pointed out the real problem : my basic skills in programming.

I hope that this topic can help other people in the future as well, because when you go on Youtube or Udemy you have thousands of courses on automation you have the impression that you’ll be ready to be a junior automation engineer after that. Actually when you put hands on a real project from a company you discover that the reality is a bit harder :slight_smile:

2 Likes

How to put this.

There are multiple ways to write code, in school you learn one way, later in life you will do formal training and they might or might not show you other ways. People on udemy/linkedin will generally be a mix, and university courses will be more on the pure side. All of programming comes down to 2 things - well 5 actually, but S.O.L.I.D. is far too complicated to teach to someone even after a few years in the field.

  1. Write code that other people can read. this might sound crazy, you want to be able to read your own code surely? Well, a year from now you will have changed your coding by skilling up, and stuff you can read now will be unreadable a year later. Write code that others can read and understand. This does NOT mean adding comments to your code. comments are to document externalities and behaviors that the code does not reflect. Most people only get this right after a few years programming, do not write obvious comments, banners are fine, but obvious comments are a waste of space.

  2. Make sure your code is maintainable - this means your little 200 line script that suddenly grows to 1000 lines can never happen. How? Object orientation is one way, and no objects are not what you think, objects are grossly missrepresented, and not all objects are the same. give 20 programmers a complex problem and ask them to only create 5 classes to solve it and you will get 50 different classes implementing a solution. Objects only start to make sense once you have a good grounding in design patterns, and you can only learn those patterns after you have learned all of the basics of each pattern. and only then can you move onto SOLID.

So, the short of it, it’s a long road, prepare yourself, and be open to new things all of the time. Things will change. welcome to the wonder of coding that brought many of us here and we love it.

As others have mentioned, don’t get down on yourself! This is a difficult point in your journey where you need to learn how to read and understand basic coding concepts.

One simple step may be to look at one of the Javascript Koans implementations. Koans are groups of short little lessons, normally driven by tests, which help you learn keywords, idioms, flow control, etc. They are a great way to learn the fundamentals of any programming language.

One JS Koan implementation is here on Github. I’ve not run through this specific one, but I :heart: koans in general.

Also, if you’re a Pro member here you might check out the Coding for Non-Coders course I wrote. It’s in C#, but speaks to a lot of critical fundamentals that apply regardless of the language platform. (Disclaimer: I wrote that course and I get a small bit of revenue when people watch it.)