8 Mistakes to Avoid in Cypress Test Automation with Filip Hric

yeah, well, let's send you an emoji, yeah, yeah, hopefully always because hey here we go, it's from me, it's from me, yeah guys, let's check our connection because I want to see that you're here, the chat is not working, okay, Maria. Uh, can you check it? I will see it and not only did I write that the chat does not work, the chat is disabled, but in any case you can hear me, you probably agree with the sound, yes, we received confirmation from Yulia, okay, so I think. Maria will check what's going on with the red chat, but in any case Julia can listen to us guys, who else can listen to us and see, yes, I listen, okay, thanks, great, okay guys, and then I see what happened Two minutes and maybe we can. start, yes, Philip, are you ready? uh yeah, cool, I'm ready, cool, so guys, welcome to the Symphony Solutions Tech talk.

My name is Vitality Maskov. I'm a solutions architect and head of QA practice at Symphony Solutions and I'm a negative member of our internal QA community we call it QA band, it's like a marching band because we write code like music but we don't just code, we also

test

and music. Symphony Solutions is a Dutch jail-driven company that offers a full cycle of digital development services in many different domains such as a play in healthcare e-commerce and many others, and we are a remote first company and our talents can work from anywhere in the world, by the way, try, yes, margin, okay, I'll clean up the dadaization, but I'll do it.

Please continue, at Symphony we have many vacancies which you can find on our website and you can find the link in our description of this event. And these vacancies are not only for QA Automation and QA but for many other different specializations. I see that is becoming clearer today we are pleased to welcome our guest Philip grids, a well-known

test

automation

expert, he is an ambassador for Cyprus, he is an independent educator and cons consultant who teaches testers about web development and developers about evidence. Hi Philip, hi. Nice to meet everyone, yes, yes, and today Philip will talk about a very hot and summery topic, how to

avoid

the eight most common

mistakes

in Cyprus test

automation

.

We have streaming on YouTube so you can watch us here on zoom or there and please welcome to ask your questions so write them in the Questions section and we will try to answer as many as possible at the end of our event and this session will be recorded so that I can review it later and the total duration is about an hour, so Philip now on to the main part, the stage is yours thank you, thank you very much. I started sharing my screen, I hope there are no problems there, but I guess Zoom is pretty reliable so we can, hopefully, we can do this without problems, so thank you.

Thank you very much for the warm welcome. I am very happy to be here. Thank you for inviting me to this event and thank you for having the opportunity to be a part of it. So my name is Philip. Nice to meet you. As in your case, as stated, I am an independent educator at this time. Everything I do can usually be found on my Hopi homepage philippines.com. Also, in the bottom right corner of the presentation, you can see my ad handle so you can follow me on Twitter if you're interested in connecting, but you can also find me under my name on LinkedIn and I'll be happy to connect there.

What you can find on my home page are usually workshops, presentations, webinars. like these courses, consultations and everything I do, I do it as an ambassador for Cyprus, which I guess I should say now is something unpaid. Cyprus does not pay me but I am just a Cyprus enthusiast and when I enter the world of technology seven years ago I came across this technology and started to become a big fan of it, so today I want to talk to you about how to

avoid

common

mistakes

when writing Cyprus tests so those of you who have been using Cyprus, you may remember that you were promised tests that don't fail, finally a solution where our tests will never fail and you will test your code and not your patience, so keep going Go ahead, try this new tool and history may have been like this, right?

You're writing furiously, um, and when you start writing your tests, you soon realize that your expectations haven't exactly been met, your tests become unstable, your pipeline fails, and suddenly it's a nightmare, so what do you do? Obviously, you need help, then. I will reach out to the community and ask for help. I actually run a Discord server where people can join and it's called learn Cyprus, so if you need help there's a Need Help channel which is probably the most active of all. The entire Discord channel, uh, and there are a couple of cloning issues that appear, yeah, repeatedly and these are some of the common bugs that hurt the stability or effectiveness of testing, so these bugs are sometimes due to adopting habits from other tools and I'm trying to apply them to Cyprus and sometimes they just arise because we don't really understand how the tool works internally, which is important if you want to write stable tests because it doesn't magically happen.

We have been taught, we have heard about the playwright. as a solution more and more often, but the same instabilities that you get in Cyprus you will also get from the playwright because the way you use your two tools really matters, the design of the test will matter no matter which tool you are going to use, so let's take a look at some of the common errors that appear on my Discord server that I've been seeing as the most common, so the first one, the most obvious one, is the explicit wait and I know this one is kind.

It's obvious because no one likes explicit waiting, it's just that your test does nothing for x number of seconds, so here's an example of how it might look good. We want to render an element so we visit our page and then this element loads very slowly. so we wait 10 seconds and then that element finally appears and we have a test that passes, so the problem with this is that while this is happening our test does nothing, it's just sitting there waiting for the page to finally load, but what ends up happening? is that your test is burning money on Pipeline and then maybe the 10 second limit is not enough, so your limit will increase and seconds will become minutes, minutes will become hours and as they add up, you are just wasting your money, you are wasting your time and there is a better way to approach this and that is to use timeouts, so here is an example of how a timeout can be used.

Timeouts are a central concept in Cyprus and in fact you can specify timeouts not just in commands but for all of them. testing or maybe you were aware of the full default timeout in Cypress settings, but this might be new so what it does is it actually sets an upper limit on how long we want to wait for that button to actually be visible . Cyprus will query this for 10 seconds and only after 10 seconds, if it does not appear the test will fail, but it will not wait 10 seconds, if the button appears within two seconds or one second we will continue immediately.

We don't actually spend, so this test is actually faster, we don't spend time waiting on the test, uh, uh, and of course, as I mentioned, you can set different wait times for different things in Cyprus. There's a default command timeout which usually means if you want to get an item or something and it's set to four seconds, but we have a task execution timeout, we have request and response or page load, these are basically the default values ​​you can set to anything. you want, that's the number one mistake, oh actually, I forgot to mention one thing: you can actually set it globally, but what you can do is set these different options per test correctly, so if we have a test that is particularly slow.

So maybe we can change the timeout just for this test because we are testing a part of the application that is particularly slow, so it can be very useful to play with the timeouts instead of waiting, so let's move on to the error now common. number one and now they are unreadable selectors, sometimes if you are looking for a selector you may find yourself in a situation where it is very hard to reach and you end up creating something like this, you have a div that has a final child and then the last child nearby is again div, there is this inflected and is this?

I couldn't tell you well just by reading that it is quite unreadable, so my advice would be to write your selectors in a readable way as it generates a lot of There is a difference if you are debugging your tests correctly because eventually we are writing code not only for for the computer to run it but also so we can debug it and take a look at it and really know what we're testing correctly. Cyprus has a full set of recommendations on how you should approach selectors. This is actually a screenshot taken from the documentation and they would say that using a generic button, clicking whatever is not very good because it is too general if we rely on classes that are also not very general. is the best approach because it is combined with the right style, so if we have our entire page in red and he uses red buttons and elements and then one day we decide to rebrand and everything turns green, then all those red classes are they will convert to green classes and it will probably ruin your functional test, although it shouldn't ruin the functionality because the functionality stays the same, so we have IDs and attributes and things like that and that can be used, that's a little better, but what Cyprus allows you to, uh , sure, it doesn't allow you, what it recommends is to use dedicated selectors and having written thousands of tests, I would say this is a really good approach, so I try to rely on classes and just from my experience, having a selector dedicated for your end-to-end testing makes a difference, it's just easier to maintain, it works very well, so I would follow this recommendation, but sometimes we find ourselves in a situation where you can't add your attributes because you don't really you got it. access to the source code, which again I would say is not the best situation, but sometimes we can't choose this well, what sometimes happens happens, uh, and what we could contact are expats, so expats are supported in Cyprus you need to install a plugin but it is an official Cyprus plugin and you can use it but honestly I don't think you need it so here is a comparison of using pretty much the same thing with selecting the same item but on the left we have an expat and on the right we have Cypress Way, so Cypress has all these different commands that can help you find a selector, so here we're trying to do that in the first example.

When trying to select an element by index, then we want to select an element that contains a specific child element. In another, the third example shows a text that we want to select element by text on the right and then we also have an element that is right after a specific element and like You can see that these expats can become quite complex and really difficult to read in Cyprus . What you can do is take a two step approach so that you first get the item you are jumping from and then specify your selection, so if we have several of these dashboard items then we can select the first one by index to start indexing by zero and that's it, if we want to select an element that contains a specific child element, we can take a look at the parent so we can Traverse and move up, we can select an element by text very easily using the contains command and if we want to be very specific and we want to select as the next item, we can also do it using the following command so we can traverse up and down, left and right with uh with Cypress commands and they're all built in so you don't even have to install a complement, not that it is a bad thing.

I think plugins are awesome and you should use them, uh, but yeah, make sure your selectors are readable, it will make a big difference, moving on to mistake number three, selecting elements incorrectly, so finding selectors is only half the story, In this example we are making a simple assertion and we have two elements and If you take a look at the code, it might be pretty easy to read. We're selecting a card that will find two elements correctly, so we'll filter with the EQ command that will take the first element of those two and then we say it must contain a text box, so we have a statement and we look at just this test and this application where we have two elements and both actually have text errors.

Can you tell which element we are on in this test? let's select the answer can be quite easy, it seems that we should select the first elementbecause that's the one we're filtering here with eq1, but the answer is actually a little more complicated because we'll select whichever element renders first, this is the demo, so if we have two cards and we have this load while the card is rendered while in each of the list, then we will select the first one, but if the situation is different and the first list is being loaded and we are going to select the one that may lead us to some unexpected results, so the list that will be loaded first will be the one that It will be tested and here we have a good statement. that's going to happen anyway, but we're not deterministic in terms of what we are, what we're testing, the thing is that the way Cyprus works is that every time a Cyprus command completes its action, it will go directly to the next Cyprus .

It's optimized for speed, so as soon as a command finishes doing something, it'll move on to the next, next command, and that's a good thing to keep in mind when you're writing your tests, because when you interact with the application, you can come up with a situation where that will give you unexpected results because the test is just moving too fast, so in this test. There are actually several ways around this is just one of the ways to mitigate it, so instead of filtering out the item we want to have, we can use a contains command and select the card. which actually contains the text we want and that way even though the second car will load first Cyprus would try again and eventually find the element that has this text so just a tip for you to select elements correctly, moving on to error number four by ignoring requests in your application, so modern applications that we are testing today usually communicate with the server with either Graphql or Rest API and what that usually means is that we get some data from the server. and that data will then be processed or reprocessed by our application, so if we don't take this into account, we could have some problems, so look at the example here, so here we want to make sure that the board has no lists, so we visit the dashboard details page, take a look at the list and say it shouldn't exist, but our test is actually passing, so this is a screenshot of this test running, but if you check a glance actually look at the list so this is the gray card that we see here we're asserting that this doesn't exist so we're getting a false positive which is a nightmare if you're a uh if you're a tester , that's not it.

What you want first of all, the complicated thing is that we are doing negative tests and my advice, my personal advice, would be to try to avoid negative tests, but if you have to do it, there are ways to do it and use requests. and actually seeing the communication that your application makes can make that difference, so when we look at the test and we look at the timeline that we have in Cyprus that allows us to look at the application in each state, we will see that our get command in is actually running before our API calls are made, what this means is that while we were using the get command, the data was still being loaded and we are certain that it should not exist, so the test actually Passed , uh, which is not a good situation to be in and also, but it's also like I'm repeating the same point as in the previous chapter and that is that as soon as a commando in Cyprus finishes doing its thing, it will move .

Continue with the next command, so optimizing Cyprus for speed can sometimes lead to some unexpected results. Okay, so what we need to do is take a look at this lists API endpoint which will actually load all the lists that are in our application into our database and we'll essentially make this loading animation zoom out and render our list the way we can do it. Yes I have one main point I forgot to say, yes we are getting a false positive so if you are doing a negative test try to make sure the test is written correctly, in other words never trust a test you haven't seen fail if it's not, uh, if it's testing, uh, the thing, uh, if it shows the right thing, you should also do I'm sure you'll catch the bad thing, so what we can do in this situation, like we did here, is to use the intercept command, so this intercept command is pretty good.

What it will do, we will take a look at everything. network communication and it will look for a get request that has the word lists in the URL, we're basically telling Cyprus, hey, be careful with this request. I'm interested in that one and I want to see when it happens, so what am I? What I do here is that I am visiting the dashboard details and after opening the dashboard I wait for that intercepted request to be made as Cyprus will always move to the next command only if the previous command has finished. What this will cause is that after visiting and waiting for the request, we will move to the get command only after receiving the response from the server in this API call, so this will ensure that our test succeeds. we fail when we are in a situation and when we are testing that the list should not exist, so this will eventually fail, we don't get false positives and we can be sure that we are testing what we intend to test, um, okay, moving on.

Let's move on to another error and that is bypassing Dom rendering, so in this situation I have a test where I'm testing this search bar, so what I'm doing here let me quickly show you what I'm visiting. an application, I'm activating the search bar by clicking the K command and then I look at the search import entry and type the four letters so you can see we have the sort box found and we're looking for critical errors. eventually we will end up with a single element when we finish typing, what we want to do is get a result element, filter the first one and make sure that the text in it will have the text search. critical errors, so as we write this we are looking for this last element and when we finish writing this we should only have one element in the list.

Now the way our app works is that as we type each key in our search bar, we go to get three API calls then we go to search for the letter A F then we go to search for the letters f o and finally we go to search for the letter f or r so what's going to happen while it's in uh so what's going to happen is the first request is going to make our app render like this, the second one is going to make our app render like this, and the third one is going to make our app render like this , so we'll end up with just one element, what is that?

I mean again I mention this for the third time today is that as soon as the element like the command finishes doing its job, it will go straight to the next command, so what could end up happening is that when we don't. waiting for these API calls to finish is that we are going to select a result element but we are not going to select the first one because we are going to select the one we are going to select at that moment while we still have two results. One solution is to wait for the third to finish, but also this is the bug that this approach could uh, I'm struggling to find it worse, but.

This is the type of error that can happen to you when you approach things like this, so you may have seen this in the past, that the element has been separated from Dom. Now the good news is that with Cypress version 12 this problem. is a lot harder to reach because it's actually Cyprus, it's actually going to retry the item query, so you should see this a lot less, but this was a model situation for when something like this should happen, so here If you're not looking at how the Dom re-renders how things are happening, you might find yourself in a situation where you're not getting the right result, the way to fix it, especially in older versions. 12 is to add a protection assertion, so keeping in mind that Cyprus will move on to the next command as soon as possible, we can add a command that maybe slows down the test a little, so we move on to the next one at the point that we want, so in this case we first assert that we only get the correct result, that is what we see, that is what we want to render and only after that we will make sure that the result actually contains the text that we want, so this would be another tip on how you can mitigate that.

The next common mistake is inefficient command chains, so Cyprus has this chaining command syntax, which works very well, it's like a scenario. I really like this syntax because it kind of forces you to go linearly to go from A. a B to Z right um yeah uh what this means is that you create these strings of commands that are going to set the stage for your Now trying a string like this isn't really best practice, it's hard to read and it also ignores how they work the Cyprus commands, so there are actually a couple of types of commands in Cyprus, there are primary and secondary commands and I have highlighted them here. so get, get and location are examples of parent commands and this type of click and shoot are examples of child commands, child commands usually need to be chained from a previous command, parent commands don't have to be now, this code will still work, but it will continue.

It can be confusing when you read it because you may feel that this new board entry is actually somewhere inside this crafting board, which may not always be the case, yes, although this seems like a huge chain of commands, in reality There are multiple strings here so each parent command starts a new string and this can be shown very well if we take a look at the console where Cypress prints information if you are writing your tests and not using the console. You're doing something wrong and I. I'm here to tell you that you should use your console because there is so much vital information there that you should have it open at all times, so if we take a look at the test code that I just showed you, you might see that the get command will select this board and that will be shown in this generated parameter right here we have the get command and here we have the data obtained from the console, if we take a look at the click command we can see that it has been applied to the create com create board element that we have selected in the previous element .

If we move on to the next command, you'll see that this produces something else, so we're actually changing the context here and each command produces something. So in other words, each command passes some information to its other command and you can see this in the documentation, in the performance part, which can be shown below each command, but also looking at the console will give you a very good understanding. of what's going on there, so I highly encourage you to take a look, that will increase your understanding of command chains and as a result you will start creating these chains that make a lot more sense and as a bonus are a lot easier.

To read, this example on the right is pretty much the same commands that we have on the left, but now it breaks this test down into logical parts where we get an element, we click on it, then we get an input type, and then we're. assert some part name, while here it's a little difficult to know what we're trying to do or at least we're increasing a cognitive load to figure out what's going on here, well, mistake number seven is overusing the UI , now this might be a bit surprising because when we talk, we are talking about UI testing here, so why should we skip UI?

This is an example I want to give you. We want to check all links within a navigation bar to have a navigation bar. it has a blog page about a page and a contact page, so the way we traditionally decide to do it is to take that block element, click on it and then check if it has redirected us to the correct path and then we go back to the page. home page do the same for the about page and do the same for the contact page we go back and forth from left to right but there is a problem with this, we are not actually checking if it is active because if the blog about our contact page would give us 404 Cyprus wouldn't tell us right and we might not even see if the page content is actually displaying correctly, so although it will show you 200, it won't tell us anything about whether the page is up, so , another The approach could be OK, click the link and check if there is content on the page, but this will make our tests slow.

Maybe the content will be displayed if we redirect it to like and generate. 404, but even if we check the element, we may not be so sure, so if the goal is to make sure all the links in the navigation bar are active, we can choose a different approach, we can choosejust trigger a request that would be pretty much the same thing we would do if we visited page after page, so here I take all the links from the navigation bar and then repeat them to trigger a request. this will trigger a get request for all href elements and that way we will check if the page under that link is actually giving us a 200 error or a status code of 200 or a 404 error.

Um, error number four that Now I'm getting into repeating the same set of actions. Now we all know the dry principle, don't repeat yourself. However, when it comes to testing, we often walk the same path to get where we want, so for example, when we want to log in to a page, we always type the credentials, type the email, enter the password, we log in and then we continue with our test, and since Cyprus deletes all cookies and session storage between tests, we might find ourselves in a situation where we want to uh when we log in again and again um usually the tests contain three parts uh These are some of the most common design patterns when it comes to testing in general, but especially for end-to-end testing where we organize, then act, and then make a statement now, especially this organized part is something we tend to do for. use the user interface and this is what I am advocating against Cyprus including these powerful tools that can help you prepare for your exam. in an effective way and for example if you want to login to a test this would be our range part and in this example what we are doing by creating a custom command so we try to login to our page so what we do is to visit the login and then type our email then type the password and then submit the login click on the submit button and it should login so what I am doing here is asserting that the user element blocked appears as your name in the top right corner or something, here in this test that we have here, we are using this custom command, this login Cy that we have created before each test, so we are actually doing a good job by not repeating ourselves, but what happens here is that when we have four tests like the ones we have here, test number one, number two, number three and number four, is that one.

We repeat this same set of steps every time and before each test, so we spend a lot of time in the UI and repeat ourselves in the test execution, which ends up being quite slow now that Cyprus has come up with a solution actually good. Because one way to try to make this login faster is to log in programmatically, you've probably already heard of don't use the UI, just log in programmatically, which is easier to say than to do because if you want to find out your login. especially if you're using a third party login or you're using all authentication, that's going to be very, very complicated now with this session command that you actually have.

Things can get pretty easy, so what this will do is here. I'm still using the custom command I created myself. Here are the same steps we have to log in, send the email password and verify that you're logged in correctly, but what I'm doing here in addition is adding this Cy session and naming that login. I know why I have a lot of logins here, which can be confusing, but this is a session, so what this will do for us is that every time we use this login command, Cypress will find this session command and to do one of two things, the first time the test is run it will follow the same steps so no changes there, but the second time I'll take a look.

Hey, this is a session I've already been through if I should repeat it and the answer is no. Cyprus is not going to repeat that, but it will take all the cookies, local storage and session storage and all the things that happen in the browser so that you can log in, cache them and save them so that they can be used later, so when I run this command a second time, I won't actually follow these login steps, I'll just grab the cache, apply it to the browser, and then open my browser as if I'm logged in. because I'm logged in, you can go even one step further and combine these Cy sessions with the Cy source with the version.

I don't remember if it was version 10 or version 11. Cyprus has released a Cy origin command and paired it with the Cy session, what that means is that when you have a third party server that you are visiting to log in, you could You might find yourself in a situation if you try to log in before each test, you might get into a situation where you will be speed limited because that third party server is trying to prevent you from logging in too fast or too often or too many times, right? What will this Cy session do for all your tests? and you can have hundreds of tests, you'll just log in once and then use that cached session to include in whatever tests you're using and that way you won't access your identity provider repeatedly and reduce risk. than being rate limited and ending up having much cleaner code because you're not going to do the same thing over and over again through the UI, okay, so maybe to conclude, here my advice for writing stable tests is the following: Of course, read the documentation.

Cyprus has done a stellar job with their documentation, each command is full of examples full of different parts and I pointed out that one thing today is the performance part, what does this command return? What's happening? to another command, be sure to do research that will make your test readable not only for you in the future but also for your colleagues. You can use things like typescript and document JS to make your code self-documenting and readable to any new members you meet. You have to onboard your new member for six months, probably not the best, but if you make your test readable and descriptive, that will save you a lot of money and a lot of time.

Examine your application. Dom, your network calls your cookies, as I mentioned at the beginning, I teach developers about web development and developers about testing and testers about web development. I think it's time for us testers to be more interested in what actually happens in the apps we test. Don't do black box testing. Try creating an app on your own. You will learn a lot about it and it will help you write more effective tests and give you insight into how your application works. It's great. that would be my number one tip if you are a tester, try to immerse yourself in the world of development and also make use of the recoverability that is used which is one of the similar basic concepts in Cyprus, all commands can be retried . make that play against you, but it can make that play for you, so make sure you review it, make sure you understand it, and use it for your test, also strings in the browser console, as I mentioned. that open thing all the time think of a range act and assert if you haven't used this pattern try to review your evidence and try to see which part of your evidence is arranging which is asserting which is acting and make sure it lines up right and you're not going so mindlessly all over the place and your tests actually have a direction join the community, feel free to join my Discord where we talk about Cyprus and we are, but not just Cyprus, we talk about all kinds. of things, read the documents.

I know I have this twice, but it is actually very important to also experiment and learn, and if you feel like it, you can visit my workshop. I'll announce one soon so you can sign up for a newsletter on my page. and I will definitely let you know. I also connect with me on Twitter on LinkedIn. I also have a YouTube channel and like a couple minutes before this talk, I announced that I'm doing a stream tomorrow and I'll be watching. in different playback tools, so the playwright has a tracking viewer. Cyprus has announced a test play feature for its cloud service.

There is a Currents solution. There is also repetition. Tomorrow I will compare this time travel and debugging tools live on my YouTube channel. Come and join, it will be fun, so thank you very much and we will be attentive to your questions. uh, yeah, thank you, thank you Philip. I completely agree that reading the dogs should be said twice because it is so important and Piper. the documentation is really amazing and your presentation is amazing, thank you very much, I enjoyed it by the way, I remember you typing like Jim Carrey on the first slide and then dealing with shaky tests, sure it's a nightmare yes, but no one likes it deal with it.

Yes, yes, so I am sure that if our participants implement their tips in real life, it will help them avoid many difficult and complex situations. That would be great, if that's the goal we address today, that's awesome, yeah, yeah. I agree and we have a couple of questions. Do you see them or can I read them? Yes, yes, I can see them, so maybe I can go through them one by one. So the first question is: I know I don't like the page object pattern approach, so what would you recommend for testing? To make the test files clear and easy to read even for non-technical people, but without the bdd approach.

Bdd is evil. I agree with you on that. I just have to do it. uh, to be clear, I've written how to set up Cyprus with cucumber just so I can have a blog that I can send to people who ask about this. I haven't used this approach because I don't find it particularly effective, um, uh, about the page object model or the page object pattern, uh, there has been a blog post on the early stages of uh, from Cyprus, no use page objects, use application actions, which I think you somehow managed. it confuses a lot of people because application actions aren't really one-to-one, uh, something you can change instead of using the page object model.

The problem I have with the page object model is that there is actually quite a bit of boilerplate code. that you need to configure to write your test, so it may depend on your situations, sometimes the page object model can be good for you, especially if you are dealing with very, very complex situations, especially if you are dealing with You can't uh don't use your AI uh AI UI for everything uh if you basically have to log in over and over again if you don't have control over your data if there's a lot of uncertainty that you want to address with a sort of automation robot approach, then the object pattern Page Objects can be beneficial the more control you have over the code you are testing, the less need there will be for a Page Object Pattern, or whatever with Page Objects is that they might be good for creating abstractions, but sometimes, like I see it applied, the abstraction gets too crazy, you go through seven files and in the final file you will find a function that will only get you an A.

Button I don't think this is an effective use of abstraction. I would recommend avoiding abstracting everything and trying not to write a single line twice because I don't think this is the effective way, especially if you are debugging. Your test fails and you need to go through seven different files to find out why the test failed. I think that will make your debugging process slower and yesterday I asked you on LinkedIn how much time you spend writing your tests, whether that's the biggest part. of your testing is writing your tests or debugging tests last time I looked 60 people wrote that most of their day is debugging tests so this is something to keep in mind if your tests are too abstract and not very descriptive, then that will slow you down and debugging will take up more of your day if your tests are easy to read, so maybe just use simple commands, you have the organization part, you have the action part. have the assertion part you see with very concise cyber syntax, what you get, what you click, if you have great selectors, and that will make your life very easy when you want to debug something, you know where your test failed.

What happens to screenshot and video information? You're fine, you don't need page objects as soon as you add abstraction, you also add complexity to your test, so I'm not saying I'm against a page object model, but it's very easy to not use that pattern effectively, so be careful with that and I mean use your own judgment. I don't know with your application, so you probably know what you're doing if you decide that page objects are good. so they are good because you know better, I hope that answers the first question. I should probably be briefer with that right now, we have nine minutes, so yeah, let's move on to the second one, implicit weights, for an element, appear on the page while explicit weights wait for specific conditions, like thepresence of an element in the press or clickable element, is it vice versa in Cyprus? uh uh no.

I don't think it's bytes verse, at least I don't know if I understand the um. ask correctly what timeout points to is the upper limit for which you want to test what you want to wait for a certain item or certain action to complete, so that's what timeout is, it's not a timeout of the test, it is not the waiting time as The waiting time is just the upper limit. So I have a suspicion that there might be some similar terminology pointing to a different principle in some other framework, but that's what Cyprus means. That's what waiting time means in Cyprus.

Okay, let's move on to the next question, if we configure the e2e project to pipe where to install Cyprus plugins in dependencies or development dependencies, it will depend on how your project works, so I've seen it especially in mono repositories. you should install things that are connected to the code to the development dependencies and things that actually created the application to the dependencies, so generally I would leave a look at the development dependencies here for both Cyprus and plugins as well, okay , another question, which approach do you prefer? A test with multiple statements or multiple tests with a single statement.

Finally, I would lean towards the link for the first one. A test with multiple statements. I know this might seem like it. Like, it seems like it violates the principle I stated, organize, act, assert with end-to-end evidence, you can actually be more liberal with that, you can organize and then act and assert multiple times, to the point I was trying to Lo What I do is that the organization part is not part of the test and maybe it should not be Part B, it should not be part of your interaction with the UI in the test, okay, yes, sorry, I heard someone shout.

I was afraid that my kids might be yeah, yeah, I heard that too, yeah, it's uh, it's my baby, it's okay, it's okay, we're okay, nothing, no one is going to be killed, and one last question, thank you for the great talk, ah, thank you very much, glad you enjoyed it. aboutuh, ask about your thoughts on the future of Cyprus and how it compares to the playwright and his potential, that's a great question so you may have noticed it's been debated in recent weeks, someone said that Cyprus will it's sinking it has no future and you should migrate your test is not true at all so there was this reddit post that was really strange because it was kind of an opinion but a lot of people took it seriously it was my opinion based on uh, based essentially on lies because it is also claimed that Cyprus pays Cyprus ambassadors, no, so that is one thing and then there was also some information that this person could not obtain, so it was all speculation and fortunately it was amplified by Some people don't think it was the best thing to do, but I don't fear for the future of Cyprus.

I think the company is doing very well. We had an internal meeting, like an ambassadors meeting. I think that was the last time we knew. I think so. It was actually two weeks ago and they told us how they were doing. They have more than three and a half thousand clients worldwide, so the panel is working well. They're doing this big update with test repeats maybe. You've heard about it, if not tomorrow on my stream I'll show you that it's cool, so they're updating and while the open source Runner may have only been getting smaller updates, they're actually doing a lot of work. on the board, which keeps the company alive, so the company is doing well, the open source tool is also doing well, so I think betting on Cyprus is not going to come to bite you in a couple of years, of course, we are talking about software, so I don't think anything has been given, but yes, so far, the way things look, I think Cyprus is doing well compared to the playwright who is backed by Microsoft.

I heard someone claim that being backed by Microsoft is some kind of guarantee. that the tool will be there, I don't think that's guaranteed. We've seen Microsoft and other big companies cut projects left and right when it comes to budget cuts, so I don't think they can close the project as such. easily like any other project, I don't think that will happen as well, but I don't think being backed by Mary Cross is a guarantee of future existence, as we have seen several times in the past. I think the comparison with the playwright is definitely interesting, it's still growing, it has a fraction of the users that Cyprus has, it's an interesting and interesting project that I'm personally working with, I don't currently find it particularly fun, I enjoy Cyprus. much more, but that's a personal preference, some people have a personal preference to go for playwright.

I think they are making a good choice. I think in today's era it makes a lot more sense to write your tests in JavaScript or typescript than to go with uh with Java and try to automate your react web app or angular app with uh with a framework like selenium. I'm not a big fan, but that's a personal preference, so I'm not trying to criticize anyone who is working on selenium, be it the tool. or they use it for work simply to publish it. I think it will be interesting in the coming years how Cyprus will grow and how playwrights will grow.

I don't think they are a big competition yet but it could be getting there in a couple of years so far Cyprus has a big advantage so I hope it stays that way we'll see okay yeah the last question was quite tricky because everyone is Aware of this challenge, but if we continue with this question, if you are asked to join a playwright as an ambassador, will you go there or not? If they asked me, yeah, I think I'd have a problem with that. I mean, we are the Golden Age of testing Solutions. Think that what we have in both Playwright and Cyprus is really cool, like Playwright, it's super fast, it's super easy to try different browsers, it has a very good vs code integration, it doesn't have one that good, since the syntax is not so good.

It's nice like in Cyprus, what I see, what I would like to see happen is for these two tools to merge and we actually saw some of that in the past, when Cyprus finally implemented the webkit to, to test, they have used the playwrights . solution like the playwrights browser, uh, that, uh, that the playwrights team built on top of webkit and connected it to Cyprus, which I thought was really interesting. Some people said haha, they can't even create their own solution. I said no, this is great. This is actually the power of open source and the power of coming together and providing the best solutions we can, so honestly I would like to see more of that, if that were to come true it would be amazing, so I have no problem with it. playwright.

I'm still learning that tool, maybe that's the part I'm not enjoying yet. It's a little difficult, but I will make it and yes, join the ambassador program. In fact, I was thinking about it a couple of days ago. ago so we'll see, we'll see, okay, okay and yes, I like this webkit plugin that has the experimental plugin Mark, yes, yes, everything is experimental because Cyprus is being cautious in releasing its features. I'm trying because they have quite a few similar to Enterprise. customers and obviously there's a lot at stake with these types of customers who are marketed as experimental, so that they don't have something like that, um uh, like companies aren't too hard on them, like fixing a bug or whatever, because they need to balance their priorities for everyone, not just one company, so I think it will remain experimental for some time, but as we will see Cyprus rice and user growth, I think that will emerge from the experimental feature to As long as uh, very soon we will see yes, yes, I completely agree by the way, we have one more question from Juan Torres and do you see it?

Oh, how do you become an ambassador? In fact, you can go to Cypress IO and deep down I think there's a part about ambassadors, let me see and if you go to the ambassador page, there's a link on how to become an Ambassador. Yes, at the top is the application to become an Ambassador, so we click on that link. I'll take you to a forum, you'll get an interview, and hopefully you'll get into something as simple as that. Yes, I had it a little simpler because I joined very, very, very early, when not many people knew Cyprus.

So I became an Ambassador instantly, but now it's in the interview process, so okay, okay, anyway, I hope we try it one day, so thank you Philip, thank you participants, slowly but surely We are running out of time, yes, if there are no more questions, I don't see any questions. Yes, it doesn't seem like it. If you have any questions, feel free to reach out to me on Twitter or LinkedIn. I will be happy to respond. I'm sometimes slow to respond, but I'll get back to you eventually. so please be patient, yes, yes, so I can also post questions in our QA community.

We will be happy to answer them or direct you to Philip directly and follow Symphony solutions for more events and visit our vacancies page on our website, so thank you, thank you. Goodbye everyone, thank you for joining, thank you, goodbye.