All right, time to really get into web Driver EO.
I know you guys are super interested in this.
Oh yeah, definitely. This is like the framework everyone's talking.
About right now, and for a good reason, right, totally totally.
Yeah. So, you know, maybe you're starting a new project, or maybe you just want to be in the no whatever it is. You sent in a really cool excerpt to kick things off, practical web Driver EO. Nice choice.
Yeah, that's a great book, and we have.
Our expert here to break it all down, you know, especially all the technical stuff.
So absolutely happy to help make sense of it all perfect.
So web DRIVERYO. It's not just another framework, right. It's built on no JS, right, which basically means like it s beaks JavaScript like.
A native Yeah, it's perfect if your application is already using a lot of javascripts exactly.
Okay, But like the big question, why would someone choose web Driver EO over say, Selenium or even Cyprus.
Oh that's a great question, and that's where the practical in your source really comes in. You know, Webdriver YO is known for being super flexible. Sometimes Selenium it can feel a little bit rigid, Okay, yeah, especially if you're working with like elements on a web page that change a lot, or you need to do some really complex stuff right right, webdriver Yo gives you a lot more control.
I see, I see. And in the source they talk about the package dot Jason file pretty early on. Yeah, which you know, any no JS developer knows that file like the back of their hand for sure. But the cool thing is the book doesn't like dwell on the basics. It jumps right into the stuff that can be a real headache, you know, like managing all those dependencies, Oh absolutely, and especially making sure all the versions play nice with each other, which oh boy.
Yeah version mismatches a node.
I mean, don't even get me started.
It's a whole thing.
The author definitely seems to know where people will get tripped up.
It's like it's like they've been there.
Yeah, exactly, like they've seen it all. So the source it suggests like some proactive stuff you can do, like using a lock file to basically freeze those dependencies. Yeah, and also just like updating regularly so you don't fall too.
Far back for sure, keep things fresh, you know.
Yeah. Absolutely. Have you ever had like a full on dependency nightmare?
Oh? Yeah, absolutely? I mean who hasn't spent hours and hours debugging just to realize, oh it's.
Some tiny little version contact. Yeah it's the worst. But okay, enough about setup woes. What really caught my eye in this source was like this amazing section on locator strategies. Oh yeah, it's like a masterclass in how to find exactly what you need on a web page.
Locators. That's the foundation of any good automation framework. And the source it goes into like all these different types, is it the ton I, DCSs, selectors, X path, even just planelink text.
It's pretty impressive.
But it's not just knowing they exist, right, it's about choosing the right one.
Oh, that's where the strategy comes in. Yes, The source talks about finding the most reliable locator, you know, like if you have a logo and it has a unique ID.
Yeah, Like, if it's a static ID, go for it, use that exactly.
That's probably your best bet. But if you have stuff on the page that's always changing.
Oh, dynamically generated concept.
Yeah, that's when things get a little bit tricky. Totally.
The source it says like IDs should be your go to whenever you can, because they tend to be the most stable. Okay, makes sense, But when you're dealing with more complex stuff CSS selectors they can give you a lot more flexibility. XPath can be super powerful. But it's also like if the structure of the web page changes, it can break your.
Tests right right, it's more fragile exactly. It's almost like you need to be a detective, you know, looking at the web page's HTML, like searching for clues. That's a great analogy, trying to find that perfect locator.
It's and the source it even gives you tips on using your browsers, developer tools, you know, to inspect elements and test out different locators. Yeah, it encourages you to experiment, get your hands dirty, which I really like.
Yeah totally. So, okay, we've got our elements, they're all locked down, Now what can we actually de with them?
That's where the fun begins, right.
This source goes deep, deep into this amazing world of browser commands.
Oh yeah, it's like having superpowers.
It really is. Like switching between windows, no problem, piece of cake, Taking screenshots of the entire page, like the whole layout, easy psy and get this. You can even inject JavaScript for those moments when you'd need ultimate control.
That's where things get really interesting.
For example, you know, you imagine you have a website and you have users all over the world.
Oh yeah, international users.
The source it gives an example of how to simulate geolocation. Oh wow, so you can see how the site behaves if you were in like I don't know the rebuta triangle.
That's pretty cool.
Maybe not the best place for vacation, but you get the idea.
Yeah, I get it. So that's what makes webdriver yos so awesome.
It really is powerful.
It's not just about like clicking buttons or filling in forms. It's about recreating real world scenarios like location based services.
And stuff exactly. And the source it doesn't just tell you like, hey, here's this cool feature, right, it tells you why it matters.
Yeah the way.
So like simulating geolocation, it's not just a neat trick. It's actually super important for testing features. You know, like if you have location based search, targeted content, even stuff like delivery services.
You know makes sense.
It adds a whole new dimension to how you think about testing.
It's about thinking outside the box.
Yeah, totally, okay, so we can find elements we can interact with them, but what about making sure they actually work the way they're supposed to go.
Oh, that's where assertions come in, right, exactly.
And this source goes deep into the world of web drive reo assertions.
They're like checkpoints for your application.
Yeah, exactly. So it's not enough to just like poke around and see if things kind of work right. You got to be specific, like this element must do this.
Yeah, and then you check if that's actually true.
Yeah. And this source it goes way beyond the basics, Like there are all these specialized assertions that webdriver Yo give you.
Oh it's awesome, right, it's like going from a basic checkup to a full blown medical scam.
Love that analogy. So the source it starts with this assertion is existing. Oh yeah, I no, it checks if an element is actually there, you know, in the dom. But here's the thing, and the source points this out. Yeah, it's subtle, is existing. It won't actually fail your test if the element's missing.
Right. It's more about gathering information.
So it's like a scalp.
Yeah, like a little spy.
Hey this element there, Yep, it's there, or Nope, can't find it.
And then you decide what to do with that.
Information exactly exactly. Maybe you want to wait for it to show up, or maybe you want to handle it gracefully if it's not there.
Right, It's all about flexibility and being in control, you know.
Totally totally, And if you do want an assertion that's like, hey, this element better be here or we have a problem.
Yeah, like a hard stop.
Yeah, the source recommends to exist or to be present.
Those are your go to for sure.
Okay, what about elements that are there but they're like hiding.
Oh you mean visible? Yeah?
Yeah, visibility. As users we take it for granted totally, but an automation, huge.
Deal huge, So that's where you use is displayed. It's like saying, hey, not only should this element be there, but it should be visible too, like a user could actually see it makes sense, And just like before, you've got a stronger version to be displayed or too visible.
Oh I like that.
Yeah, if you need to be absolutely sure.
Yeah totally. Oh and the source even talks about this cool assertion to be visible in viewport.
Oh yeah that's a good one.
This one's like next level thing.
He checks if the element's not just visible, but if it's actually in the part of the page the user can see without scrawling right.
Right, because you could have a super long web page.
Yeah, and technically an element could be visible, but if you've got to scroll down a mile to find it, is it really visible exactly?
It's like you got to think like a user, you know, how are they actually experiencing thisally? Totally? Okay, So we've got presence, we've got visibility. What about elements that are visible but you can't like interact with them, like a button that's disabled or something.
Yeah, that's a good one. So the source it goes into that too. You can check if an element is enabled or disabled using like to be enabled and to be disabled.
Ah okay, so you're making sure those interactive elements are actually like working exactly.
And checkboxes, Oh, don't get me started on checkboxes.
It can be a real pain to test.
The source it highlights is selected and to be selected. Use those to check if a checkboxes you know, checked or not. Right might seem small, but it's important. Like think about accepting terms and conditions on a website.
Yeah, if that checkbox isn't checked, you might not be able to do anything exactly.
It's those little things that can make or break the whole user experience, and.
Web Driver EO gives you the power to test all of it.
It does, yeah, and you know it's cool the source. It goes beyond just listing assertions. It actually gives you a whole example of like a real world test case. Oh nice, yeah, for a user loginflow, so.
You can see everything in action exactly.
You see how web driver EYO can do like end to end testing, not just little isolated checks.
I love that. And it uses like the Page Object Model POM to keep everything organized, right m h.
POMM is the way to go.
So it starts by like making sure all the important elements are there, like the logo, the input fields, you know, all that good stuff, and then it makes sure they're visible and enabled.
Yeah, got to make sure they're ready for action exactly.
Then it's like, okay, let's simulate a user typing in their username and password. And here's what I really like about it. It doesn't just assume everything's going to work perfectly.
Oh yeah, that's key.
It uses those conditional statements if and else right, so it can handle like if an element is missing or if it's disabled. It and like log a warning or something.
Yeah, instead of just crashing the whole test exactly.
So it's like built in resilience. Yeah, you know, not every cast needs to be a straight up pass or fail.
Sometimes you just want to know, like, hey, what could go wrong here?
Exactly. It's about finding that sweet spot between being thorough and also being realistic, you know.
And the source does a great job of showing you how to do that.
Yeah, it really does. So all this talk about assertions, it brings up another super important part of web Drive REO testing.
Waits.
Oh yeah, waits essential. The source dedicates a good Yeah. Basically, you just pause the test for a certain amount of time.
You have the application a chance to catch up.
It's like saying, okay, everyone, take a deep breath, count to ten and then we'll continue. I like that, but for more dynamic situations, you need something a little smarter, right.
Yeah, Like wait for display.
Oh yeah, that one's super useful.
It waits for an element to actually become visible on the page.
So you're not just waiting for an arbitrary amount of time, right, You're waiting for a special thing to happen.
That's where you see web Driver EOS flexibility and action.
And the cool thing is you can customize the time out period so you can control how long you're willing to wait, you know, and the polling interval, like how often it checks to see if the condition's been met.
It's like fine tuning your patience level exactly exactly.
And then you've got weight for enabled that waits for an element to become enabled so you can actually interact with it.
Yeah, like a button that's initially grayed out.
Yeah know, at wait for exist. No one waits for an element to like actually exist in the dom.
Web driver eyo gives you all the tools to handle those tricky asynchronous operations.
It does, but the real star of the show when it comes to waits is wait until.
Oh yeah, wait until. That's the big one.
This one's like ultimate flexibility. It's like a magic wand you can define your own custom condition.
The source it gives a great example of using it to wait for an element to have specific tech content. Oh super powerful.
So like you're not limited to just the pre defined conditions, right, you can get as creative as you need to be.
It's all about tailoring your weights to your specific.
Needs totally, and you still have control, like you can set a time out, you can set a custom message if it times out. You can even control how often it checks for the condition.
Super customizable.
Okay, so weights, they're absolutely crucial, and this source does a fantastic job of explaining like all the ins and outs it does. Now, let's talk frameworks. We touched on them briefly before, but this source it really gets into the specifics of Cucumber and Typescript.
Yeah, frameworks they bring structure to your test code, you know, they help you organize everything right, and the source it highlights the benefits of each one.
Yeah, it does a great job of that.
So Cucumber it's all about that behavior driven development approach, you know BDD. It's perfect for teams that really want to collaborate and they want to make sure their tests are understandable to like everyone involved, not just the developers.
Yeah, it's like bridging that gap between the technical folks and the you know, the non technical folks exactly. And then you've got Typescript, which brings that like lovely type safety to the JavaScript world.
Oh yeah, Typescript is a life savers, especially when you're working on a big, complex project.
It can really help catch errors early on. Absolutely, so it really comes down to like what does your team need, what are your preferences.
It's all about finding the right tools for the job totally.
And the source it even walks you through how to set up both frameworks with webdriveryo like step by step.
Yeah, it's super helpful.
Okay, before we move on to the really fun stuff. Yeah, actually writing the test scripts.
I know I'm excited for that, me too.
But first let's talk about the configuration file wato dot com dot js.
Oh yeah, the control center.
It's like mission control for your webdriver real project.
And the source. It gives a great overview of all the different configuration options there, from logging levels and services to reporters and capabilities. It's all there.
It's pretty impressive. And the source it really emphasizes like you got to understand what each option does you know, like, how does it actually affect your tests?
Yeah, it's about making informed choices exactly.
Don't just copy and paste stuff without knowing what it's doing exactly.
Got to understand the why behind the what.
And the source it does a great job of explaining all those whys.
It's like having a personalized setup guide.
You know, totally, totally. So we've covered installation, locators, commands, assertions, frameworks, configuration. Wow, that's a lot, I know, right, Yeah, it's incredible how much this source manages to pack into like a short excerpt. It's a good foundation though, it is, and I think it sets us up perfectly to actually start writing those test scripts.
Yeah, which is what we'll be diving into next time exactly.
But before we jump into all that practical stuff, let's just pause for a minute and let everything we've talked about today sink in.
You know, yeah, take a breath there.
It's a lot, but it's exciting it is.
And with this found foundation, I mean, you guys are well on your way to becoming web driver EO masters. That's the goal, and building super robust and reliable tests for your applications, whatever those applications might be.
That's the dream, right, all right, welcome back to our web driver Yo, deep dive.
I'm excited for this part, me too.
Last time we laid down all the groundwork, like installation locators, commands, all the essential there's like getting a sneak peek into the frameworks toolkit, right, but now it's time to see how those tools actually work in practice.
Let's get hands on.
Exactly and this source practical web Driver. Yo, it's a perfect guide for this part of the journey. It doesn't just tell you what to do, it shows you how to do it right the right way. Yeah, like how to write test scripts that are clean, easy to maintain, and super reliable. That's what we want exactly. So the source it starts off with this design pattern that's like super popular in the testing world, the Page Object model or POM.
Oh yeah, POM got love.
I've heard people talk about it, but honestly, this source finally made it click for me.
Yeah. POM can be a game changer for sure.
It's all about bringing order to the chaos, right, Like thinking of your application is a collection of pages, and each page has its own like unique elements and interactions.
Right And instead of having your test code all over the place, you create separate classes for each page. Ah, so you can keep everything organized and easy to find.
It's like creating a blueprint for each page exactly. So, Like, if you have a log in page, you'd have a log in page class. Yeah, and that class would have all the locators for like the username field, the password field, the log in button.
And the methods for actually interacting with those elements too.
Ah okay, okay, so instead of having like this cryptic code all over your test scripts, you'd have these nice, clean method calls right exactly.
It makes your code so much more readable.
It's like writing a story, yeah, about how your tests are interacting with the application.
And if the layout of the page changes, you only need to update the page object class. Oh, you don't have to touch all your test scripts.
That makes updating so much easier.
Exactly, makes your code less fragile, less likely to break when things change, and.
The source it actually walks you through an example of implementing.
POM, Yeah, step by step surprisingly straightforward. It is. Yeah, you create a folder for your page objects, and then you define a class for each page okay, with all your locators and your methods nice and organized.
I love it. It's like building a library of reusable components for your tests.
Exactly, And as your application grows, your library grows with it.
Awesome. Okay, so POM is definitely a game changer. What other like golden nuggets of wisdom does this source have about writing really good test scripts?
Well, it talks a lot about helper functions.
Oh, helper functions are the best, like your little helpers, like.
Your sidekicks, exactly. They handle those repetitive tasks that pop up all the time and testing.
Yeah, the stuff you don't want to write over and.
Over again, exactly. So the source gives some good examples, like a take screenshot function.
Oh, that's a good one.
Yeah. It captures a snapshot of the current page, so you can see exactly what's happening exactly. Super useful for debugging, you know, or.
If you need to document something, or even if you want to make those cool time laps videos of your tests running.
Yeah, helper functions can be as simple or as complex as you need them to be.
The key is to find those tasks that you're doing over and over again and then just like encapsulate them into a reusable function.
Yeah, keep your code dry, you know, don't repeat yourself.
Exactly. It makes everything cleaner and easier to read, and you're less likely to make mistakes.
Absolutely. So we've talked about POM for structure, we've talked about helper functions for reusability. What about the data that we actually use in our tests?
Yeah, that's a good point. You can't just use any old data right right.
It needs to be meaningful relevant to the scenarios you're testing.
So like, if you're testing a log in form, you wouldn't just use like test user and password as the credentials.
Right, No way, you'd want to test with valid email addresses, different password links, special characters, all that good stuff.
So you're testing how the app actually behaves in the real world exactly, And the source suggests storing all that test data in separate files.
Oh yeah, that's a good practice.
So instead of hard coding values directly in your test scripts, you'd put them in like JSON or CSV files.
It makes things so much easier to manage.
Yeah, if you need to update something, you only have to change in one place exactly.
And you can even use different test data files for different environments like development, staging, production.
It's all about organization, right, making your code easy to maintain. Oh and the source it also talks about code readability.
Yeah that's important.
It might seem obvious, but when you're deep in the code, it's easy to forget that other people might need to read it someday.
Yeah, got to make sure your code makes sense to others, not just to you.
It's like writing a novel that only you can understand exactly.
So the source reminds us to use clear variable names, function names, to follow coding conventions, and to add comments.
Yeah, comments are key.
They explain why you're doing something.
So your code is like a pleasure to read, not a nightmare.
Exactly. So we've got POM forra structure, helper functions for reusability, meaningful test data, and readable code. It's like we built a toolkit for writing amazing web drivery o tests. It feels that way, and the source it leaves us with this reminder that web driver eyo is always evolving, right, New features come out, best practices change, The community is constantly finding new and better ways to do things.
That's like any craft, right, you never stop learning.
That's what makes it so exciting. So keep exploring, keep experimenting, and don't be afraid to push the limits of what web drivery o can do.
I love that this deep dive has been incredible. It has I feel like I can tackle any web driver EO challenge.
Now I feel that way too, and don't forget the commune is there to support you.
Yeah, that's a good point.
So ask questions, share your experiences, and contribute back to the project if you can. Happy testing, all right, welcome back for round three of our web driver Yo, deep dive.
I'm ready to get my hands dirty and actually write some test scripts.
That's what we're here for, right, to put all that theory into practice exactly.
And our source Practical web Driver eyo, it's like the perfect coding buddy for this part.
It really is. It goes beyond just the concepts and gets into the nitty gritty of like writing good code right, like best practices and stuff exactly.
So the source jumps right in with this design pattern that's like a staple in the testing order page object model. Oh yeah, po eom, I've heard of it, but this source it finally made it click for.
Me, Pom. It's all about bringing order to your test code, you know.
Okay, yeah, I can see that.
Instead of having codes scattered everywhere, you create these separate classes for each page of your application.
Ah, that makes sense.
So each class it holds all the location for the elements on that page and all the methods for interacting with them.
So like if you have a log in page, you'd have a log in page class, and it would have the locator for the username field, the password field, the log in button, all.
That exactly, and it would also have the methods for like entering the username, entering the password, clicking the button.
Ah okay, So instead of having like lines of code define those elements and interact with them scattered throughout your test scripts, you have these nice clean method calls in your page.
Object class exactly. So your test scripts become much more readable. You know, they're almost like telling a story.
I like that. Yeah. So if the design of the log in page changes, you only have to update the login page class exactly.
You don't have to go hunting through all your pest scripts and update them individually.
That would be a nightmare, especially if you have a lot of tests.
POM makes your code way more maintainable, way less likely to break when things change, and you can.
Reuse those page object classes too.
Right. Oh, absolutely, If multiple tests need to interact with the login page, you just use the same login page class.
You're not duplicating code, right.
Which means less chance of introducing errors.
Love it and this source it walks you through like a step by step example of how to actually implement POM in a web driver yo project.
Yeah, it's surprisingly straightforward once you get the hang of it.
Okay, so POM huge win. What other like pro tips does this source have for writing really good test scripts?
Well, it talks a lot about helper functions.
Oh yeah, helper functions. Those are life savers.
They're like your little helpers ready to tackle those repetitive tasks that pop up and testing.
I'm all about saving time and effort, so I'm definitely a fan of helper functions.
The source gives a bunch of great examples, like what, well, like a take screenshot fuck?
Oh yeah, that would be super useful, so you don't have to manually take screenshots all the time.
Exactly. It can automatically capture a screenshot of the current page and save it to a specific location.
Perfect for debugging or for documentation or even and like if you want to make a cool time lapse video of your tests running.
Exactly, And it gives an example of a weight for pitch to load function.
Okay, and what does that one do?
It waits for a specific condition to be met before the test continues.
Ah, so make sure the page is actually ready before the test tries to do anything right.
That's super important for handling those asynchronous operations, you know, like when things happen out of order.
Yeah, those can be tricky. So basically, helper functions can be anything you need them to be, as long as they're helping you avoid writing the same code over.
And over exactly. If you find yourself doing something repeatedly, turn it into a helper function.
Makes sense. Okay, So we've got structure with POM, we've got reusability with helper functions. What about the data we use in our tests? Is that important? Oh?
The data you use is super important. You can't just use random.
Stuff, right, It needs to be relevant to what.
You're testing exactly. So if you're testing a log in form, you wouldn't just use like test user and password as the credentials.
Right, No, you'd want to use a variety of data like valid email addresses, different password lengths, maybe some special characters to.
See how the application handles different inputs exactly.
And the source recommends keeping your test data separate.
Yeah, put it in external files like JSON or CSV files.
Ah. Okay, so instead of hard coding it in your test scripts, you keep it organized in these.
Separate files exactly. That way, if you need to update the data, you only have to change it in one place.
That's much easier than searching through all your test scripts.
And you can even use different test data files for different environments like development, staging, production.
So you can tailor your tests to each environment exactly.
And speaking of tailoring, the source also talks about the importance of code readability.
Oh, readability, that's a good one. Sometimes I get so focused on making the code work I forget that other people might need to read it.
Yeah, it's easy to get tunnel vision, but it's super important to write code that's easy for others to understand.
It's like if you wrote a novel that own you could understand, no one else could enjoy it exactly.
So the source it gives some good tips like using clear and descriptive variable names, following coding conventions, adding comments to explain why you're doing something.
Yeah, comments are super helpful, especially when you're coming back to code you haven't looked at in a while.
They're like little notes to your future self.
Okay, so we've covered a lot in this deep dive into web drive yo. From the basics of setup and locators.
To those powerful commands and assertions, to.
The art of writing clean and maintainable test scripts using pom Helper functions and meaningful.
Test data, and always remembering that code readability is key.
It's been a journey. I feel like I have a solid foundation in web drive Yo now me too.
And the best part is this is just the beginning. Web drive Rio is constantly evolving.
That's exciting it is.
So keep learning, keep experimenting, and don't be afraid to push the boundaries of what's possible with this awesome framework.
I'm ready for the challenge. And you know, one thing that's been really cool throughout this whole deep dive is the sense of community around webdriver io.
Oh yeah, the community is amazing.
Everyone's so helpful and supportive, always willing to share their knowledge and experience.
It's one of the best parts of working with open source software.
Absolutely so to everyone listening. If you're interested in learning more about webdriver io, don't be afraid to reach out to the community, ask questions, get.
Involved, and most importantly, have fun with it. Testing can be a lot of fun, especially with a tool as powerful as webdriver Io.
I couldn't agree more so until next time, happy testing everyone,