The Web App Testing Guidebook with Kevin Lamping

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Kevin Lampen. Kevin is the author of the Web App Testing Guidebook and a core contributor to Webdriver IO. He is a front end engineer and runs the YouTube channel Front End Testing with Kevin. He has a newsletter available@frontendtesting.com where he shares a weekly curated list of stories from the front end testing world.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial, visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey Kevin, welcome to the Guild.

Hey Joe. Good to be back on here.

Awesome. Great to have you back on the show. It's been a while. I think it's almost been almost three years since we talked, so.

Yeah, at least three years.

Yeah. Before we get into it, is there anything else that I missed in your bio that you want to tell the Guild about?

Can't really think of too much. I've been doing a lot of little side projects here and there, but nothing too major aside from the book that I'm finishing up right now.

So you were nice enough to me, a pre copy of it, a pre release copy. I really enjoyed this book. You have really small code examples that are really clear that I think anyone can follow. So before we get into the book itself, I think writing a book takes a lot of time and energy. So I always ask authors, why, why, why did you write the book, the web app Testing Guidebook?

So I had the idea for it based off of a course that I built three years ago on test automation with WebDriver IO and I wanted to update the course. But I also remember the course that it took a year and a half of all weekends and weeknights basically working on that course. And by the time that I had actually finished recording all the videos, some of the content at the very beginning of the course had been outdated because of updates to the WebDriver IO framework and mainly improvements to where that information it wasn't necessary anymore. So instead the idea that the problem with videos is that it's harder to edit and rework material because you spend a lot of time doing the screen recording and then the audio has to be very smooth and everything. So I wanted to go basically try out writing a book and knowing that it's going to take me a year and it's taken me at least a year to put this together again because I'm working on this kind of a side project at night and weekends and so kind of fitting it in where I can with my life. And you know, over the past year I've completely moved across the country and that was a big investment for me as far as time goes. And also I have some young kids in the house and they I don't want to take away from time with them. So that was kind of the idea of using a book in that I can more easily update it and it turns out I need to do some more updates for it because webdriver IO when I first started writing it or when I first started writing the book had been on version five and a few months ago they released version six which has. It's not as big of a change from version four to version five, but there are still some API changes that require updates. They've added new functionality including a new built in assertion library. And so I need to go in and replace some of the old assertion syntax with the new library because it's really a vast improvement over what was previous in there. So yeah, the basic idea for writing the book was I can build out the outline for what I want the videos to be, the updated videos to be, without having too much rework with that.

Cool. So it's also. It's been around three years, so you're still committed to Webdriver IO. You're a core contributor. What is it about Webdriver IO that you still enjoy after all these years?

It's the. The community is really great. The way the framework kind of lets you choose for yourself how you want to build your automation suite I really enjoy. I love that it's geared towards front end developers. The selector syntax for selecting elements on the page is very front end developer friendly because you can use just pure CSS selectors. You can also do XPath, you can do the normal selectors that you can actually do in Selenium or webdriver itself. And just to remind folks that it's there's the WebDriver which is the W3C recommend or W3C spec, and WebDriver IO which is this Node JS framework that is used for driving WebDriver. It can get a little bit confusing and I actually have a section on the book about the difference between those two, you can use all of the selectors that you can use in WebDriver, but it's just got this syntax to it that's really friendly for front end developers and that's my background, so I really enjoy it. It's also the ability to extend the library, to extend the framework. You can custom services, custom reporters, and that's one of the big selling points for me are the officially supported custom services. It ties into Sauce Labs really easily, it ties into Browser Stack really easily. And the customer reporters, they have good support for Allure, the Allure reporting framework, I think HTML Report as well. So it's just got a lot of functionality to it that really goes above and beyond what you would find in a lot of other tools out there. So webdriver IO, I wouldn't say is it's not necessarily a tool, it's a full featured framework to build out automation. And in my experience that is extremely helpful for teams trying to write test automation because writing the actual test itself is just a small, small part of building out your full automation suite. Getting it tied into your CICD process, getting it tied into services like Sauce Labs, having reports that people who aren't testers can more easily read. And then yeah, it's got a lot of customization to it. So you can choose between Cucumber, between Mo, A, Jasmine. I don't think it's officially supported, but there has been some work on tying it into jest. So yeah, you kind of pick and choose what fits really well for you and I really like that level of freedom.

Very nice. And I really like it. It looks really readable. I'm not a JavaScript guy at all, but even looking at the API for Webdriver IO, it looks very readable, very clean. So, you know, this book seems geared towards all levels, but it starts off for beginners, I think, and that's what I love about it. But for a beginner, do you think webdriver IO is also a good choice?

It's going to depend on the language that your team writes in, the coding language that your team writes in. If your team is writing Node JS for the front end, which a lot of teams are now these days, I think it's a really great choice for a beginner. One thing that I changed between my video course and this book is I introduced JavaScript concepts a little slower for people who may not be more familiar with that. That's one thing. One piece of feedback I got from the course was that people really to work with this, but they don't have a JavaScript background. And when I made the course, I went in with the assumption that people did have a JavaScript background. And I don't think that was a wrong assumption to make. I just, it was due to limited time, limited resources, but I had heard enough feedback that I really wanted to make sure that I introduced these topics. So I don't actually dive, I don't think that I dive too deep into really nitty gritty technical details and all the possible things you can do with JavaScript. But I did want to give a taste for how you can take advantage of more advanced features that JavaScript provides to write more readable code and more maintainable tests. And I think that's a big part of your automation plan in the long run, is having maintainable tests. Because I've spent a lot of years and seen a lot of tests that they just don't work after three months. And it's really unfortunate to see that. And so that's one thing that I really wanted to highlight with this. And so on the flip side, if, if your team is writing specifically in a language like Python and they have kind of a more static HTML site, then maybe WebDriver IO is not the best choice because one of the key selling points for me is that I don't have to switch between two different coding languages to write my automation. It's in the same language that I'm already speaking every day, in a way. So, yeah, I think it does depend on how your team is set up and how your project is set up. But yeah, I think it's definitely approachable to beginners and especially you had mentioned it's more readable syntax. That is one of the features of webdriver IO is they, they have what's called sync mode, S, Y, N, C, so synchronous mode. And it takes, it strips out some of the syntax necessary in order to make your test more readable. So basically instead of having to type extra code each line, basically it handles that for you. So you don't have to worry about it.

Absolutely. And I also want to stress though, even if someone's not using webdriver IO, I'm not being paid to say this, or they're not using JavaScript. The book itself is broken down into the key areas that anyone would have to focus in on for any automation framework, any technology, any language binding, they would just have to apply it to whatever they're using. Pretty much is perfect. And you know, later chapters in this book go over some topics I don't normally see in a book. So I just want to hit them really quick to give people a flavor for how much you cover in the book. One of them is testing complex inputs. Just really quick. What's that chapter about?

That's talking about form inputs and a lot more complicated things than just a value or, sorry, an input field. So one thing that I see in a lot of examples and exercises out there is let's fill out a login page. And that was actually a little project that I made. TestYourLog.in is kind of a generator for building a set of WebDriver IO tests to test your login page. It's a good start, but there are many, many more complex form fields out there than the simple username password combo. And so in that one, I cover a few complex ones, a few complex inputs, one being a markdown editor. So the site that we test, this demo application that we test is from the Real World I O yeah, Real World IO Project. The Real World IO Project and what it is, it's a set of functionality defined that defines this blog app kind of thing. And it's written in all these different frameworks, so React Vue, Angular. And then on the back end it's got a bunch of different frameworks as well. So the one that I use is Node, JS and Express, but you can also use Python or Java or php. It's. You can pick and choose from there. And the idea is to create a more advanced demo application. And the application itself allows you to write articles, post those articles to a newsfeed and comment on those articles. Favorite the articles, follow authors.

Just.

Just more advanced functionality than the basic to do app. The to do app is the most basic of. Not maybe the most basic, but it's kind of your bread and butter demo app that you see out there. This is a little bit more advanced than that. So on that site we've got a post editor page where you can create a new post or a new article, whatever you want to call it. And by default all it had was the title of the page, which is a plain text field, the description, which was another plain text field, a text area, and then a tags area. I actually went in and. And updated that text area for the actual content of the post to be a markdown editor. Because while it looks simple, a lot of times these markdown editors or these WYSIWYG editors will have an iframe correlated to them. And it starts out as a text area. If you look at the actual HTML source in the react component. It's just a text area, but after the fact, it gets replaced by JavaScript on the fly and gets replaced by an iframe and all these divs and kind of stuff. I've seen that really trip people up because they tried to set the value, the text value in the text area, but it doesn't get updated because that text area is kind of pushed off to the side and isn't important anymore. What's really important is this iframe and how do you get into the iframe and how do you get into the field inside of that? And so I wanted to show that off. Another part was the tags input area. You'll see autocomplete with tags. And I don't cover autocomplete in these examples, but in this one you type your tag and then you press enter and then it adds the tag to the list of items or the list of tags that you want to have for this post. And so I wanted to show how to hit enter, basically. And it's as simple as doing browser key browser keys. And then you enter the string enter and webdriver IO picks that up and says, oh, you don't want to type the word enter. You want to actually press the enter key. And it presses. It simulates pressing the enter key for you. So it's not too terribly complicated in my opinion, but it is something that could be trip you up and definitely something you want to know about. Keyboard keys that aren't just the letters themselves are pretty important to know about. That was definitely something that I saw and I hope to add a few more complex examples. I mentioned that autocomplete, that's another one that you see a lot across websites is autocomplete. How do we test that? The tricky part of an autocomplete is it makes a request to the database to get the list of values that match what you've typed so far. So not only do you have to type text, you have to wait for the list to pop up. You have to validate that the list has the correct values in it. You have to be able to click that list. And a lot of times these autocompletes aren't written with the most semantic HTML. And so it can be difficult to get those clicks to work. And yeah, something like testing an autocomplete is can really trip people up because they say, oh, that's going to take, I don't know, 30 minutes, I'll just set the value on it. And then they actually go to test it or to write the test and they set the value. And for some reason it's not sending the right keys because of all sorts of things. I'm speaking from personal pain here. One time I was sending the value to what I thought was the input, but actually the component had created a second input and it was typing in visually what looked like the correct field, but it was dropping letters. Every few letters it would drop. And I pulled my hair out trying to figure that out. So I'm hoping to help save some people some pain there and kind of guide them along how you would not necessarily handle that specific situation, but how you can handle situations like that.

Great. Another thing I think people don't do enough of, and I think it's one of your last chapters, is generating data for your tests using APIs. So really quick, why, why do you think that's important? Or how do you think that can.

Help people listening the main point of doing that is to have consistent data every test run. If you're going off the from the database, well, there's no guarantee that data is going to be there when you run your test. And a lot of times the effort or the time hasn't been put into creating a completely separate test or automated test site server, whatever you want to call it. A lot of times the server that you're running your test against is the same server that you're doing manual testing against that developers are pushing changes to and are doing their own validation on, that business owners are demoing different functionality on and trying out different things. And so there's a lot going on in the background there. And I think ideally you want to have your own local environment that you can run your tests against and has a set of data that never really changes. And you know what's going to be there when you go to test your page. But in reality, practically, that's a lot of times not an option, at least at the time. A lot of these servers, the more complicated web apps out there, aren't a simple node app that you can get started in 15 minutes. They take a lot of configuration, they take a lot of different services. And so with that, you kind of have to deal with the fact that the data on the page is going to change most likely by the time that you run your test again the next day or the next week. And so by using this API method, a lot of websites sites these days, not all of them, but I would say a fair number of them, especially if you're writing Your front end. In a tool like React, they interface with an API. And an API is basically an interface to the server, to the database. It's the official term is application protocol interface, I believe, and I hope I didn't get that wrong, if I did get that wrong, just edit this bit out. And what it does, it allows you to, instead of going to a website to retrieve data, you send a HTTP request and that's to either get data from the server or to send data to the server. So you can create a new post or you can create a new user, you can delete a user, you can edit a user. And by using these API calls, you can define what data you expect to have on the page. And that's really useful for doing your assertions because you don't have to hard code in data that you hope is on the site but may have been deleted by somebody else. No, the data, you just added it to the site. You go to the site, you run your tests and then at the end you delete that data. And it's all pretty clean. You can always get into conflicts with that, but it's a pretty safe bet to run that. The other really good thing about using an API is it's a lot quicker to get that data set up. You don't have to write database queries to send to create new data or delete data or anything like that. It's a lot cleaner. And so I cover how to do that. And it also replaces the method of testing where say you want to test that you can edit a post. So in order to edit a post you have to have a post to edit. So you would write UI automation that goes to the Create post page, enters all the details, hit submit, then waits for the page to load that has the new post. Then you click the Edit. Well, that bit where you're writing the new post is unnecessary in a way because one, it can break just as easily as any other bit of test that you have out there. And two, UI automation tends to be pretty slow because it does have to run a full browser, it does have to wait for the full website to load. And so by having to go through the steps of creating a new post, it can take a fair amount of time. And if you're doing that for a hundred different things, then you're adding just, you're just slowing down your test more and more and more and kind of reaching that point where anytime you want to run a test, you have to go take a 15 minute coffee break to see if your test actually completed or not, and trying to avoid that as much as possible.

Awesome. Okay Kevin, before we go, is there one piece of actual advice you can give to someone to help them with their automation WebDriver IO testing efforts and what's the best way to find contact you or get their hands on this book?

I think my advice would be keep it simple and really narrow your constraints because a lot of the difficulty with testing comes from just a bit too much complication in what you're trying to test, a bit too much complexity in what you're trying to test. So see how you can narrow the scope of what you're trying to test and divide things up as much as you can and that's going to allow you to have more maintainable tests, tests that aren't as flaky as they can be and help get a lot more value out of your tests.

Yeah, the best way to contact you and get our hands on your book.

So you can contact me on my website. I have a contact form there and it works. It wasn't working for a while and someone let me know and I fixed it now and I know it works because I get a lot of spam that actually helps me know that it's still working. If, if I ever stop getting spam from that contact form I need to investigate it. But you can also reach out to me on Twitter. My handle is klamping. The book is available on LeanPub L E A N P U B.com that is a independent publisher and it's kind of a self publisher. So you search for web app testing guidebook on there and it will be available for you there. I'll also have a link to it on my website which is.

Thank you Kevin for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com a307 and while there make sure to click on the Try for Free Today link under the exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. 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.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.