Welcome to Episode 85 TestTalks. In this episode, we'll discuss the The Java Selenium Guidebook with author Dave Haeffner and discover how to create reliable and maintainable Selenium automation scripts using the Java language binding.
Many first time Selenium automation engineers face common issues like slow, brittle, flaky, hard-to-maintain tests. Many of these issues are due to a lack of information on how to get up to speed with Selenium the right way. Simply Googling and reading all the various information you need to piece together in order to get started is not only inefficient; it can be downright frustrating.
What would you say if I told that you can skip most of these Selenium issues right from the start? Well, you can! You can pick up Dave’s quick, jump-start guide, which is a concise “good practices” approach to learning Selenium correctly and quickly.
Check out this episode to discover more.
Listen to the Audio
In this episode, you'll discover:
- The post popular language used in creating Selenium tests.
- What growing Selenium trend you need to know
- Is there a way to create awesome HTML reports in Selenium?(Hint: There is)
- Tips to improve your Java Selenium efforts
- What The Selenium Guidebook is, and why you should buy it.
Join the Conversation
My favorite part of doing these podcasts is participating in the conversations they provoke. Each week, I pull out one question that I like to get your thoughts on.
This week, it is this:
Question: What Selenium language binding are you using to create Selenium Tests ? Share your answer in the comments below.
Want to Test Talk?
If you have a question, comment, thought or concern, you can do so by clicking here. I'd love to hear from you.
How to Get Promoted on the Show and Increase your Kama
Subscribe to the show in iTunes and give us a rating and review. Make sure you put your real name and website in the text of the review itself. We will definitely mention you on this show.
We are also on Stitcher.com so if you prefer Stitcher, please subscribe there.
Read the Full Transcript
Joe: Hey, Dave. Welcome back to TestTalks.
Dave: Hey, thanks for having me.
Joe: It's great to finally have you back on the show. You were on episode two, so it's been quite a while. What have you been up to since last time we spoke?
Dave: Oh man, a lot of stuff. I've been to a lot of countries talking about Selenium and consulting with companies to see what they've been doing with Selenium. It's really been a fascinating set of experiences. I had spent some time in Israel and got to meet with a bunch of companies and see companies at different levels of maturity, and see some ones with just really fascinating implementation of Selenium. Really robust, really mature, really dialed in, and some very non-obvious uses of Selenium. I saw one company that was using it for doing monitoring for their website. There's some really interesting use cases.
I've released a second edition of my book. I branched out from Ruby into Java. That was something I started before I started traveling oversees for Selenium stuff. It really confirmed and driven home how widespread Java is with regards to Selenium. Every company, with one exception, used Java for Selenium. Since then I've looked up all the download numbers for Selenium across all the programming languages and Java owns, this year, something like 65% of the downloads for Selenium.
Joe: Wow. Yeah, I agree with that. Everyone seems to be using Java and it's just a lot easier when you Google issues. Because most people use Java to find ways to fix whatever you may be encountering. I find that helpful in that case but I also like your point of view that you have also, where you don't necessarily need to use the same exact language as your developers. Do you still believe that or what are your thoughts now that you know that Java is one of the main language bindings that most people use?
Dave: Yeah, I think that is a real tough thing to figure out and I seen a couple companies navigate that. I don't think that they figured out a good answer yet. There was a talk at a Selenium Conference in Portland earlier this year, I think it was about having testing as a service. Almost like a rest endpoint that could receive wire protocol from WebDriver and execute tests on a infrastructure of grid nodes and how it didn't really matter what language you wrote it in it would just receive it. They added some clever stuff but it was interesting to think “What if you did have multiple languages but one way to execute them all?” As long as you can aggregate the results in the reports. The hard part, I think, is just making sure that the feature set of cross languages is consistent. Because that's always the big issue with rewrite is that you end up with things that are doing things differently and if you have someone move from one team to another it's not something that's conducive for growth ultimately.
Joe: Awesome. It seems like you were mostly working in Ruby and it sounds like you've just started implementing Java. I'm pretty sure you're going to implement every language binding for your Selenium guidebook. Have you learned anything specifically about Java though, as you were working on Java, that you didn't know about?
Dave: I don't know if there's anything specific about Java, other than, since I came to test automation not as a programmer. Like I really had very limited programming background that I spent so much time in Ruby, that I was kind of innately afraid of Java and compiled languages. It seemed very robust and had all these other requirements. You have to deal with compilers and really need IDE to use it well and then after I got into it, I was like “This is actually pretty straightforward.” Especially with an IDE because it just does so much of the hard part for you.
The thing I would say is that it was actually a nice break from spending so much time in a dynamically typed scripting language where everything is an object. To a very explicit, strongly typed language that's compiled what it's doing. Where as in Ruby, if inadvertently the type of an object gets changed, that object becomes that new type but there is no way to really know. So you could have a really pernicious bug in your test code and not realize it and finding it can be hard. In Java, it's like “Well, it just won't run.” It will tell you where it's broken and it'll probably tell you where it's broken as you type. I really appreciated that. I think it made things a fair bit easier in that you can work past the verbosity of things pretty quickly. Because you end up gaining a lot on insight into exactly what a test is supposed to be doing.
Joe: Awesome. You actually have a pretty good video on YouTube. I forget what conference it is, I think it was in Russia. Where you talk about building a maintainable, reliable framework in Selenium using Java. I thought it was really good. I'll include that in the show notes. I guess my question was, one of the things that came out of that you mentioned something about jUnit rules. What's a jUnit rule?
Dave: Oh, yeah. Okay, I'm refreshing my memory because I released updated editions in my book and I started with Java then ended with Ruby. I got Ruby on the brain. Let me give myself a refresher. There is two things that I use that I think are lessor known or just not enjoyed for use. The jUnit rules and then there were categories. JUnit rules are what I used, they're basically built-in functionality that exists within jUnit, that enables you to do extra things. Like storing the set up and tear down actions in different places.
When I end up creating this framework that I talk about in my book and I've talked about it in various talks and network shops and at conferences, was that you want to have a way to abstract your set up and tear down and have it fire before your test. But in your test still have access to the before annotation, so that if you wanted to you could create an instance of a Page Object and have it receive a Driver Object. The first obvious abstraction would be if you have a test and it has a before and after annotation you can create a base utility class for your tests, then your tests classes wouldn't hear it.
Then you would just move that before a block into your base test. What happens is that before annotation in the base test fires, but kind of stomps on what's happening in the test. Then you can't really create a Page Object and it ends up creating either a race condition or as I will call it an it just doesn't work condition. By using a jUnit rule it kind of works around everything. Where you can have a jUnit rule that handles, the external resource is jUnit rule, it has a method you can overload called Before and a method you can overload called After. What these do, these actually fire prior to the jUnit annotations for Before and After. You can end up basically creating an instance of Selenium in this base test class. Then in your test, that inherits from the base test, you can end up getting access to this Before annotation and keep you basic, your setup method and create an instance of a Page Object, receive the Driver Object that was created by this jUnit rule. Then everything just does the right thing.
Joe: Awesome. I never knew about it and I've been using Java for awhile now and my framework. That was kind of cool to find out more about. Also, you mentioned Base class, Base Object. I think most people are familiar with Page Object but what is a Base Page Object for people who don't know?
Dave: When I talked about this every time I would get a percentage of the room that would scratch their head just based on what I was calling it and even the concept a little bit. I started to add additional names, so it's like Base Page Object, a Selenium wrapper, a Base Utility Class, a Utility Class. I don't know the best way to describe it so that everyone knows what it is. When you say plaid, everyone knows “Oh, plaid, flannel.” Basically, it's the concept of taking the similar tenants that go into a Page Object. You would have your locators in the behavior of a page in an Object and you do the same thing but with your Selenium actions.
Instead of having them all throughout all of your Page Objects, you could take those Selenium actions that are common and put them into a class and then the cool thing is that there is a couple benefits. You can start adding additional functionality in this one central place, like if you have a method that's checking to see if somethings is displayed on the page and that thing isn't on the page, it's going to return an exception. You can actually do a tri catch to catch for a no such element exception and have it returned false instead. The method will say “is displayed” and if it's there it will say “true” and if it's not there it will say “false” as opposed to exception.
By doing that you start to bullet proof your Selenium usage a little bit. Then you update all your Page Objects so they are a bit more readable. If there were ever any API changes to Selenium, you just go to one place to change it. This is probably not super true of an issue for Selenium three coming at some point in the future. I don't know when because the W3C specification. It's not as big of a change as when they jumped from from Selenium one to Selenium two. Right? We went from RC to WebDriver and there was huge, huge changes.
I got this idea and this practice, I guess it's more of a pattern, from Jason [Labia 13:18] at Selenium Conference in Boston back in 2013. He gave a closing keynote talking about how Google uses this pattern to migrate from RC to WebDriver. They also did some stuff with WebDriver backed Selenium within this pattern, but it made it super easy. Because the other thing I didn't mention is, you could actually pretty easily swap out the underlying automation framework with this pattern too. If you really wanted to. You could actually just say “Oh, I'm going to plug in something else that will drive the browser.” And you just back in the actions for that framework into these methods that you create in the base class.
That's pretty much it, assuming, of course they use locators. The same way, that's basically the gist of it. I was thinking in Ruby it was like, you could use Selenium WebDriver or then you could use something like Mechanize and then that would just traverse and use locators the same way. If you could find the commands to do the same things.
Joe: Cool. What I love about this concept, I don't know if you've heard of HP's new LeanFT? The reason why I'm mentioning it is it's basically QTP but it allows you to [inaudible 14:28] and rest TK create test in [C Shop 14:31] or Java, pretty much like you do with Selenium. But allows you also, to not only automate a browser but also to automate the client applications. Like I said, I work for a big company and we actually have a modern web application that integrates with thick client applications and you can't automate with Selenium. If we use some sort of Base Object, maybe in those instances, we can just switch it over to the LeanFT to handle it. Just a thought, thinking out loud.
Dave: Yeah, that's interesting. The only real logistical hurdle I can foresee would be dealing with locators. In my book I write about how you could create constance at the top of a Page Object to store the locators. Then the thing you could do differently would be to capture those objects elsewhere, so then you could inject “Is this a webpage, use these web elements if it's a desktop, use these desktop elements”, that kind of thing. That sounds like a pretty cool setup.
Joe: Dave, you also mentioned something about the Allure framework. Once again, I've never heard of it. What is the Allure framework?
Dave: There is this company based out of Russia called Yandex. They make some awesome stuff, a lot of it is open source. They build really cool software products, then they happen to learn a lot and then they package it up and open source it. Yandex released, what's called the Allure framework, which for those of you that don't know, it's basically a really awesome HTML report generator for Selenium tests. It is platform agnostic and there are bindings for almost all, if not all by now, of the prominent testing frameworks for all prominent programming languages that are out there.
Basically, what is does is you plug it in to your test setup and you make it so you output XML from your test runs. Just like you would do for continuous migration, into a directory and then you also capture screen shots on failure. Much like you would do for your test runs for any sort of framework. Then what you do after your test run is you run this binary that they have that will take those things and convert it to this standard schema that will then generate this HTML report that is like a full blown angular app. That's just like really slick, bells and whistles, HTML5. It just looks really good and they take the screen shots and they make this really nice interactive report. It solved a real problem for Selenium space because most anyone that builds a framework realizes pretty quickly that they have to build their own HTML report generator, if they want something better than just the standard, gnarly-looking, not super helpful one that you can generate with certain test tools that exist.
They did it really well and the fact that it works for everything is mind-blowingly cool. I talked about that and that's a really good one. Then some people might be familiar with Yandex through, they wrote this Page Object helper, I think for people that use Java they're familiar with the Page Factory, which comes built into Selenium. But Yandex, also created one called HTML Elements, which is an even simpler, sleeker Page Object Wrapper. I don't use it but I've heard really good things about it.
Joe: Awesome. That's two cool thing I definitely didn't know about and I'm definitely going to check out. I'm using something called Serenity to get that reporting but it also adds extra things on top of that. I guess there's pros and cons to that, sometimes I don't know what it's doing in the background, so sometimes I'd rather just do a strip down framework I created and just add in these extra things that do something specific, like reporting rather than taking care of everything else behind the scenes.
Dave: Yeah, it's cool because you can script it out pretty easily. Then you can have it be sucked in as part of Jenkins test run for a job and as a final action and then you have a really robust report.
Joe: I know a few times we mentioned your book, The Selenium Guide Book, but I've been hearing a lot of good things about it, that you're working on some new things. Could you tell us a little bit more of what you're doing with the Selenium Guide Book?
Dave: Yeah, sure. As I mentioned I started in Ruby, then I wrote it in Java. In between those two things two things I realized that just the book along wasn't really enough, as far as, making the material approachable. I added some additional tiers that people can purchase, like the cheat sheets and then 2 1/2 hours of video walkthroughs. Designed to be as friendly for self-paced learning as possible.
Earlier this year I released the Java Edition and then I did an updated release recently, a couple weeks ago, and that was to update the Ruby Edition so it's current with the current version of RSpec. Then updated the Java Edition to make some tweaks based on feedback I got from Java developers. Where they were like “You really shouldn't be using an interface like that. You should really be using a set of class.” Like that kind of stuff and then just general bug fixes and that kind of thing.
The goal of the Selenium Guide book is really, and also for my tip newsletter, Elemental Selenium, is to offer all of this content in every supported programming language for Selenium. That's an exclusive for TestTalk, not listeners. This is the first place I think I've mentioned it this publicly.
Traditionally, I would just do some sort of pre-order to gauge demand, to make sure it's really something that's interesting to people, then do it, then launch it. Instead of that, that's like one book a year probably and it's a horrible pace. So I'm going to do a kick starter to basically put it all out there and say “I'm going to do them all.” And set a reasonable goal for the kick starter campaign and then assuming it gets funded, then I'll do all of them. I'll do them, well the goal is early next year to launch the kick starter and then the hope would be like a few months after the kick starter ends I'd be able to rock through all of them and get them out there.
It takes about somewhere between, I haven't really done the math in a while. But it's like, say I spent about two weeks figuring out the code examples and probably another week before that figuring out and understanding this programming language, that I don't understand. Then there's a peer review cycle, where I get a bunch of people to code review. Then I'll write the book, then I'll make the cheat sheets, then I'll record the videos and then I'll repeat. That's probably a six week to two month window. I'd say probably 6 months after the kick starters done to get everything out the door. Which is a tremendous feat to accomplish, I think, considering I've only done one book a year for the last two years. I think it would be awesome. I think it would be worth it. I've covered some of the need by covering Ruby and Java, but I think there's still over half of the languages that aren't covered. I've looking forward to doing that.
Joe: Awesome. I think it's a great resource. If someone wants to learn more about the Selenium Guide Book, I'll have a link to it in the show notes but is there a particular site you like people to go to to find out more information and keep up to date on where your progress is with that kick starter program?
Dave: I'm at a loss considering I wasn't planning really to make an official announcement yet. But the easiest way is to come to either of my websites. Which there's probably more than there should be and basically sign up for something of mine and then you'll get an announcement when things happen to go out for the kick starter. There will likely be kind of a lead up sequence going into it, just to tell people more about it. The best places are, if you want to receive weekly tips on Selenium go to elementalselenium.com and if you're new to Selenium and you just want to figure out how to get started you can go to elementalselenium.com/bootcamp. That's a signup form to sign up for a free five day email course on how to use Selenium.
As far as my book goes, there's a free sample available and you can find out all you want to know by going to seleniumguidebook.com, about halfway down on the page is the free sample. If you sign up for any of those things you ultimately end up getting the weekly tip emails from me. That's pretty much it. I would like to give a shout out to the fact that I recently got sponsors for those things as well, if that's all right?
Joe: Yeah, definitely.
Dave: Sauce Labs, I know is a sponsor of your show, is a sponsor of my newsletter. I'm really excited about that. I think they have a great product and I hope they continue to have a great product.
Joe: I love Sauce Labs.
Dave: Yeah. Then I signed on with Applitools as a sponsor recently.
Dave: For those of you that don't know, automated visual testing or if you really don't like the word testing for automation, automated visual checking. Basically, they are an app that makes automated visual testing easy and awesome. Just as Sauce Labs makes it turn-key to get a infrastructure for Selenium, Applitools makes it so it's turn-key to use machine learning with computer vision to do visual layout testing and a whole bunch of other things. It's fascinating. I spent the last year researching and writing about automated visual testing. The one takeaway I have is, the future is here and for a few lines of code you could be in the future too.
Joe: I totally agree. I love Applitools. I actually even love the owners of Applitools. Everyone I meant at Applitools is awesome. I think that is a great recommendation. People should definitely check out visual validation testing. It actually picks up things that even our manually testers can't find, it's that good. I'll second that recommendation.
Dave: Yeah, I'm pretty stoked about that. Those are the big things. I'm looking to offer more content around automated visual testing here soon. I might incorporate something into my book about it.