WebDriverIo v8 Must Know Features with Christian Bromann

Foreign.

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast. Today we were talking with christian all about webdriver io8 being released. Really excited about this. I think it's a major release that we've been waiting for for a while. If you don't know, Christian is a full stack engineer, passionate about open source and open standards, a driven individual with the ability to adapt to any situation and a proven potential to grow himself and others. Christian is a quality focused engineer with a background in automation technologies and test driven development and he's a leader in this space, especially with webdriver IO that everyone raves about. So really excited to learn more about these new features and the latest version of WebDriver IE and why you need to be checking this out as well. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment. For Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey Christian, welcome back to the Guild.

Hey Joe, thanks for having me.

It's been a while. I think last I spoke to you was 2019. So is there anything you've been up to since then that you want the Guild to know more about that I may have missed out on your bio?

I mean no, everything was perfect. Great bio. Yeah. I've been running the open source program office at Sauce Labs for a while which was a lot of fun and doing some test automation there, obviously working on Web Devio. And now my career changed a little bit. I joined some friends working at a company called Stateful where we are building developer tooling and trying to make developers happy by building productive toolings there.

Nice. So since you are working with developing tooling, does that help inform you of how you're going to what kind of features you think would be really helpful for webdriver IO?

Yeah, I mean I haven't been able to that much to like like put my ideas into action because there's a lot of stuff that we're currently working on at Stateful itself. But I'm definitely like the whole idea about creating this ephemeral workspace for web IO that allows anyone to just, you know, create a workspace and start contributing to webdro. That came from a lot of research that I've done over at Stateful where we're looking at, you know, the IDE space and how that is developing over the next years.

Nice. I guess before we get into it, if folks missed the episode from 2019, they hit webdriver, they may automatically think selenium. So which webdriver IO it's different than selenium webdriver?

That is correct. Yeah. People still get this wrong and that's totally fine. Yeah. Webdriver as itself is the web standard that helps you to automate Browser. Selenium and WebDiver are both projects that implement that protocol. Both independent, both like great open source project in my opinion. So yeah, there are differences and yeah, it's not all the same.

What are the main differences though that you would say?

Yeah, I've been talking to the folks at the Selenium project a lot and I think Tai just mentioned it really well. I think Selenium enables you to automate the browser and webdriver comes more with like the test framework aspect where like if you want to test your application and you don't want to build your framework itself, you can use webdriver. There are similar tools for Selenium like Nightwatch is now built on Selenium 4. You know, that comes with a lot of, you know, built in capabilities where if you don't want to, you know, build a whole framework yourself, so it.

Includes all the plumbing, basically it's built on top of Selenium where the foundation's already in place though, and you have the scaffolding, everything's ready for you to start adding your own touches. But you don't need to start from the beginning with the contract or with designs to create the house basically.

And WebDriver is the same like WebDriver itself has, you know, the protocol drivers, the WebDriver npm package and the WebDriver IO as an npm package that help you to build your own automation framework or your own automation tool even. I've seen like projects like Spectron who was built to test Electron application was built on WebDrive IO and you know, it comes the same way with a test runner that has this testing stack for you that, you know, removes all the work of plumbing, has like a more, you know, opinionated way. You know, it suggests you how you think, how you should run your test.

Absolutely. And I know a lot of people, like you said, they want to start from the just out of the box with something that's going to work for them. A lot of people find webdriver IO very helpful that way as well. Easy install, ready to go. So cool stuff. So, you know, I know you work on this a lot and I'm always curious to know when do you know to go to a new version like this is version 8, I think you've been releasing, you know, 7.1, 7.2. Like when does it become like, wow, this is version 8. What does that usually represent?

In the past I've always been, you know, look like the reason reason why I work on WebDev because it just allows me to learn so many things around different kind of aspects, mostly around Node JS because Webdev is built on Node JS and a big. Now with version 8, one of the biggest topics that I've been tackling was the common JS to ESM transition. Right? Like the node JS, I think version 12 or 1314 has introduced ESM as like a new model system, which is a standardized way to import JavaScript files into other files and the whole import functionality and now the whole ecosystem basically in Node JS transitions to esm. And that was something that piqued my interest and something I wasn't really, I didn't know much about. And so I was like, okay, at some point the project has to move to ESM anyway. So I just get ahead of myself, look into what ESM is about and transform the whole project, which has cost me to transition to basically touch every file. The same happened, I think with version 7, where I transformed the whole code base from JavaScript to TypeScript and all the previous version had like a simple, like the same, you know, story behind where it's like this technical thing that I wanted to learn and you know, the project enables me to do that.

Nice. So I'm just looking at the notes, the release notes, and it does mention comma JS to ESM transition. One thing that popped out is Jest. I know Jest is a pretty popular unit type of framework. Why would you move from Jest to VI test? Is that part of the EMS transition? In order to take advantage of esm, it needs to. You needed to move that library.

Correct. Jest currently has not a good support for esm. The team is working on that and at some point it will have support for it. But at the point where I started the transition, VITest was just much further along with that effort. And since the transition from Jest to vitest was very easy because basically vitest took a lot of, like, the design goals from Jest and put it into their framework. It was like, okay, if I want to continue and, you know, be fast with the ASM transition, the vitest transition as well, like, was one of the things that had to be done as well.

So I've actually never heard of Vitess, so this is something I love having this podcast I'm learning. It's just, what is Vitess then? Does it have better, more, different benefits? I'm not comparing tools, one's better than the other, but does VITest give you anything else that maybe Jest didn't give you?

I couldn't actually pinpoint, like, a specific feature that VITest is better than Jest. It's almost the same interface. It almost does the same thing, like unit testing, including snapshots and all that fun stuff. The only reason why it moved over is that, you know, the ESM support that has been lacking in just a little bit, but other than that, both frameworks are same. I've been using both projects a lot in the past.

So this is something basically behind the scenes. Right? If someone takes version 8, they don't need to worry about going from common JS importing or changing any libraries in their code, do they?

No, the transition only happened within the web developer code base. WebDriver will still support your common JS code base because it is possible to import common JS files in an ESM environment or run them there. So there's ways to execute both types in an environment. And so actually V8 is one of the first releases where there's actually not really major breaking changes. People should just be able to upgrade their version and go with it.

Nice. So let's talk about some new features. I believe the first one you have listed is a new browser version of the Runner or a new browser runner. Can you talk a little bit more? Why you think that's one of the most exciting features that were actually pointed out in the readme log as one of the highlighted areas?

Yeah, I'm very excited about that one. I've been working on a lot of web components as I'm working on VS code extensions and use web components in there. And I've always found that there's not really any testing framework that will allow me to run these, to test these web components in an actual browser. A lot of these frameworks, testing frameworks, they use js, DOM which is a, you know, an implementation of the HTML specification and it's been supposed to be used for testing. But I'm, you know, I'm this extremist who wants to test the his components, his, you know, React, view, whatever. You have components in an actual browser because that's space, you know, that's where they actually be useful from my users. So there's not really, there hasn't been really any framework that would allow me to do that. And so I took this as a challenge and with all these great tools that we have these days with the Byte Server, it has been actually not that difficult to build a runner that basically would take your test, would put it into the browser and would allow me to use an actual browser environment to test front end code that are running in a browser as well, like Vue, React, Svelte components or if I want to run, you know, JavaScript code that are supposed to run in a browser that use for instance the canvas web APIs. I can do that now with WebDAV very easily.

Nice. I guess it also points to the type of DOM you're using. A GS DOM rather than an actual browser. Something that helps you with component testing. I can talk a little bit about. I guess it points out some disadvantages compared to running tests in the browser compared to jsdom.

Exactly. Since yeah, since jsdom basically just runs within Node js, you don't have like a UI really that is being rendered. There's a good guess how the UI looks like. But you cannot do things for instance to interact with Soido elements. Like if you have an hover in a component, it's not really possible to test that with jsdom. And again, the Canvas API, there's some, you know, workarounds how you get this working with JS Storm as well. But it's not real, not the real Canvas API that you interact with. And so you always end up with the, you know, with testing it in environment at the end, don't deliver that at the end are not used by your users. And you know, we are at the point where we have the technology to run this in an actual browser and I feel like why shouldn't we do so.

Very cool. And another thing it points out is it allows you to use different frameworks like a testing library and I guess it allows you to use APIs interchangeably. Is that something you think is going to be a big feature?

Yeah, I wanted to have testing library as like a first, you know, first class support. It is basically it's A popular framework that helps you to stage your component test basically to render it into the browser and to find elements in there and assert elements to be in a certain state. And I've been using it quite a lot and I like the structure and you know, the community behind the testing project, testing library. So I wanted, you know, have users do the ability to use just that to for the little plumbing that is needed to render the component in the dom. But basically at the end of the day the user can do everything that they want, you know, in the browser, with the browser environment that they have.

Nice. So I haven't used spoken to a lot of people that use Karma lately, but it was more popular library back in the day or Runner. This actually replaces the need to use something like Karma, is that correct?

Absolutely. Yeah. Karma has been very popular when Angular came around as people wanted to test the Angular application Angular components in the browser. However, Karma has been not really seen a lot of development recently and WebDriver can be an ideal replacement because it does actually the same thing. It allows you also to run browser tests on Source Apps or BrowserStack or other cloud vendors if you need Safari or browsers that you don't have to your disposal. You know, it comes with almost the same features, has better integration and you know, webdev more maintained as Karma. So yeah, it would be a replacement for that project.

Awesome. Also you had some new action. New action interface and what really caught my attention was the ability to chain almost different commands together to do different events in the browser. So back in the day I used to have to test like a mainframe app that was rendered in a browser and the only way that logic would be generated is if you tabbed out of fields, which was really difficult. But with the windrunner you would be able to do the different like keyboard combinations to get it happening. This almost looks like it when I'm looking in the send keys documentation here. I guess I'm rambling. So she just tell us a little bit more about the new Action interface and especially the ability to use a kind of chain these type of commands together.

Yeah, this is kind of like a little bit overdue feature. WebDriver hasn't been really doing great in supporting the W3C WebDriver Action API that well, because you know you can send in a JSON object and it would do that. But now with the new Action API you have some type safety. The code is better readable because you have these commands that you can chain with each other. And it makes just creating these Action calls much easier. And that's important basically now with the browser runner. Now it's also important to help you test Canvas application where you have to interact with the Action API to do, you know, to have to create user events. And so basically the new Action interface comes with, you know, the browser runner to, you know, help you to do those kind of things and simplify just creating and help and you know, suggest users to use more this Action API because it's very powerful.

So I know I spoke to Simon Stewart a few times in the past and he always mentioned WebDriver bidi support. One, what is it? And two, is this part of the new version 8 of WebDriver IO?

Correct? Yeah. The WebDriver web standard for automating browser has been developed during the phase as all the new front end frameworks came out, like React, Angular Vue. And it was always developed with the idea in mind that you can do what the user is doing. Basically you click on a button, you see an element and so on. But all these new browser frameworks have created the demand for more introspection on the application. And so we've seen other tools like Cypress and Playwright, you know, becoming very popular because they would allow those kind of things. Now since 2019, the W3C working group has been working on a new version for webdriver which has the name Biday because it allows you a bidirectional communication and kind of like enables the introspection part for browser automation. So we will see features like, you know, listening to lock events or to events that happen in the browser, like dome events, lock events, network events. We will be able to see the ability to mock network capabilities because that's a big part of introspecting the browser. And all these features will now be available in the new BIDI stack. And with V8 we will ship the first primitives for Webdava by to send commands and listen to events. And we will, moving forward, we will kind of like Secretly replace the WebDriver commands with bidi commands without having the user to see it. So we will be running the commands more effectively basically on the new protocol and also allow the user to give the user an interface to work with the protocol if they feel like it. But at the end we will try to build abstraction around it. Like for instance, now RepDeiver already supports mocking network requests, but it uses the DevTools interface for that. So we will moving forward, once we have network capabilities in the Bidac protocol, we were kind of like have like broaden out the support above DevTools and you know, allow whenever, you know, browsers support it, allow it on other browsers as well.

Very cool. I know a lot of people used to use no, they went to Cypress because of the ability to kind of interact with the network and sniff it by seems to replace kind of give that feature to Selenium in webdriver I o that may have been lacking maybe a few years ago, but now webdriver and webdriver IO seems to have that exact ability, I think. Am I understanding that correctly?

That is correct. I mean that's with many things that happen also like in the past. It's like there are tools out there that provide you a certain capability to do things. And the people that work on standards, they think, okay, this is a signal for us to kind of like create a standardization around it to make it really available in all browsers and to give it, make it more accessible to people. And so that's the same way happened here. We've seen tools like Cypress Puppeteer, Playwright, that provided a lot of great functionalities. And that was the signal to the working group being like, yeah, we have to provide and we have to work on adding introspection capabilities. And that is now what's happening. And we see this, you know, being implemented in browsers, like across all browsers. And so we have it, you know, available and we can do now actual browser testing and fill out the gaps that we've seen before.

So you just mentioned a bunch of different tools. There's so many automation tools out there nowadays. How do you know what to. How to select one for you? Maybe not one's better than the other, but maybe might be better for your situation. So how would someone know webdriver IO for my particular needs would be the perfect fit?

That's a good question. I mean there's so many factors that play into it and again, there's nothing really a better or worse because it's like comparing apples with oranges, right? So in my opinion, you know, Web IO might not have the best, you know, devex capabilities because there's not like a team behind like a company that sponsors a whole team working on this project. However, it comes with the advantage that it's based on web standards and it allows you to do cross browser automation in real browsers and not like a browser engine, you know, and it has mobile support. If, you know, running on actual browsers and mobile support is important for you, then webdavu might be a choice. If you however run, if you build an application and you want to have some test quick testing cycles and have something like a somewhat good clarification whether or not your application works from end to end and you're not interested in a lot of cross browser nor mobile, then playwright and other tools might be working for you as well. Maybe better dev experience but you know, that's it's always like the factors of what you're looking for and you know, that should decide. And also I always recommend people, you know, take a tool and take it for a test ride. You know, there's a lot of stuff that is, you know, set in blog posts which is always not really true at the end. I've been reading a lot of stuff and we're like, that is not factual correct at all. So it's always good to take it on a test ride and see how the tool behaves and if it feels good to use it, then, you know, make a clear decision on that.

Yeah, I highly recommend you try it for yourself. You make your own decision. I had a, I shouldn't say this. I had someone contact me from a different tooling saying, hey, this other person is talking about another tool and they're going to compare them and it's not correct, but I guess it's up to you to do the proof of concept and test it out. Like you said, don't believe the hype. Try it yourself and see if it actually does what you need it to do. So, you know, I think it's interesting you mentioned like you don't have a company backing this project but, and so it's usually not mentioned in a top tier of tools. But the people I talk to that use webdriver IO tend to be kind of fanatic about it. So I guess that's kudos to you for doing that. So why do you think people, when they do use it, they tend to really evangelize it?

I guess, I don't know, maybe it's me that is like this extremist when it comes to these tools. Like, you know, if I would have someone who gives me millions of dollars to work on reptar Veo, you know, that's great at the end I would make myself dependent on it and I rather work on a project that is, you know, driven by interest of people that are, you know, has no, you know, commercial aspect or as less commercial aspect as possible. Which is why I moved webdavo to the OpenJS foundation in the first place because there I get like a neutral foundation to build a project with sustainability in mind. So we don't see things like what happened to Protector where you know, it has been developed by a corporate identity and at some point there was no commercial interest running the Steam anymore. Then you know, it disappears and then the project, you know, will not continue to be maintained anymore. You know, if that is like unique example, maybe, but you know, there's a lot of others. There's similar things happened in the past and that's what I feel like working on WebDrive IE is such a great fun because there's just a neutral ground, everyone can join in. There's like not me who you know, steers the roadmap of the project. It's like once someone has put in the effort and energy to contribute to the project goals, then you know, there's a democratic decision where things should head. And I think that's a fine ground for working on technologies these days.

Absolutely. And I also like how you said this follows standards. So standards should be important to companies and to people using tools. So if you look at a tool that should be one of the factors, does it follow industry standards? I think that's a big indicator of where you think the tooling is going to go or how it's going to help you.

Absolutely.

Cool. So I know you have some other things in here like miscellaneous and optional globals. So anything sexy about either of those you think that people should know about?

Not very particular. I mean the global thing is important because you see this in other test framework as well where you know it used to be cool to just attach things on the global scope and then use it from there. You don't need to set up things, you don't need to have this import. But at the end having this implicit import is important or very good. When you use things like TypeScript where these types can be mixed with other test frameworks like they expect function to do assertion. If you have jests in your project as well, it can interfere with that. And so having these imports is I think a nice way. Especially now with the browser runner when webdriver becomes more like a unit test framework for a lot of people unit testing their web components and maybe have a different unit test framework for other stuff. So I think that's important. And yeah, at the end of the day, yeah, there's not like a big end to end automation feature. I've been asking the community, hey, what do you like to see like API testing or better IDE experience? And their like API testing was up a lot and you know all these features are great and we will look into Them, but with the ESM transition was basically the biggest chunk of that now will allow us to do a lot of cool things like running WebW in the browser, which is possible with the new browser runner. And we can now look into, you know, building an IE experience, which some of the community already start doing. So there's a lot of exciting stuff coming up in that area as well.

Nice. So it sounds like. I know it's Selenium. They put in a lot of years building the latest release and it got to the point now where because they did that, they opened up a whole new avenue of different things they could do now because they put in all that hard work behind the scenes. It sounds like this is something similar that you did with Webdriver IO. So what's on the roadmap then that you think. I know you said you could. Now that you have these things in place, you could start doing other things that you've probably been wanting to do. Is anything on your roadmap or will you see that down the road is definitely going to be something that could probably be a feature in a newer version of WebDriver?

I o I'm currently like putting a better roadmap together for the community so that everyone knows what they can, where they could contribute to. I think there are a lot of exciting areas for me Personally after the V8 release, I would like to put my time and effort into building an IDE experience. I started already doing that, and then folks over at SAP have built an IDE extension as well, and I found that very interesting. So we joined forces to do some cool stuff there and then we'll see. You know, there might be a new technical challenge or a technical thing that I would like to explore, and then it will end in Raptor IO because, you know, I'm just one of many contributors that tries to, you know, work in open source.

Absolutely. And actually I'll have a link to the roadmap as well. You know, some listed here for upcoming projects, better debugging capabilities, where I think would be awesome. Paralyzed test on, test block level versus file level. Whole bunch of cool things that people should definitely check out. So, you know, you mentioned interesting thing. How can people contribute? Is it all you, Christian? I mean, when people are looking for a tool, they're looking for a community. They're looking for one that's maintained not just by one person, but there's a group of folks doing it. So how's the health of WebDrive IO for maintainers? And are you looking for help and if people want to help, what can they do?

Yeah, so I have to do a little bit better job in like posting out a roadmap for people to see, you know, where which are the parts that they can contribute to ultimately. Like they can look into, you know, the issue list or look into the roadmap and get in contact with maintainers and we can work with you all to find a place where you like to explore technologies. The project has a one on one happy hour, so there's twice or four times a week people can have a one on one session with one of the maintainers working on a particular ticket or issue. And I've been doing this a lot in the past and it has been great fun to just meet all the contributors to WebDav IO and work with them on concrete things that they're interested about.

Awesome. Okay Christian, before we go, is there one piece of actual advice you can give to someone to help them with their automation testing efforts? And what's the best way to find or contact her or learn more about WebDriver IO?

The best advice is like not use just the tool that you see in the blog post, but you know, take every tool for a spin and see what's good for you. You can find the webdriver release and all about that in the probably in the description below or on webdriver IO in the blog post that we put published. And yeah, you can reach us contributors on the Gatorade support channel or on Twitter wherever you like.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a426 and while you're there, make sure to click on the Try for Free Today link under the exclusive Sponsor section to learn all about Sauce Labs awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the guild community. I'd love to hear from you. Head ON over to testguild.info and let's make it happen.