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
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.
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
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.
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.
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
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.
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.
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 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.)
You could try some of the record facilities these tools provide such as Cypress Studio or Playwright CodeGen to record a user journey, the code will be generated for you then you can tinker with it to see what affects what.
I think these tools have a way to go to make them less daunting for non-technical people and to make the transition from manual to automated testing less of a steep learning curve.
I donāt think anyone mention this but learn how to use debug tool to step through the code.
I find this to be very helpful when trying to understand how a project work.
I see a danger in codeless or semi code-less as well @willyjamesfold .My first formal tester job had us using a record and playback tool. and it was very much a black box. I had to go away and read the spec docs before I could understand the data I had captured. But in the meantime I had to build tests and find bugs. Which I did. Once I understood the traffic capture it allowed me to finesse a bit.
But often you have to merely have faith and run some test code as it is generated and only worry when a test tells you a thing is failing or passing when what you can observe with your own eyes as a user experience, looks suspect. Trusting the tool and focusing on the problem is hard, I have for example used compilers for over 30 years and trust them in all of their complexity, while many people still struggle to. Trust your eyes first, you cannot do everything.
Writing code to click or writing text in a webpage is fine Iām able to do it.
The problem starts when you have to reorganize the code using POM, understanding a real and big project. When I look at tutorials on Youtube it looks easy, then IRL not really
Itās OK not to understand how a tool does what it does. I have worked in jobs where the tools we used took me ages to really understand. I continuously underestimate how lucky I have been in a lot of jobs. I have had at least 2 jobs where the tool beat me. It also did not help that I did not understand the product. And I guess, thatās my advice if you are struggling. Change something about your environment. Iām a slow learner, so if I have a job with a long commute, I miss out on time to get into the office and do some extra learning and catching up. Normally I have had to fall in love with the product first, then learn the tools afterwards.
But if something is not environmentally good for you, use it as a lesson and move job. Celebrate your failures even, I do. There is no such thing as personal failure, only failure to find your best way to learn by targeted efforts.
koans in general.