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