New Headless Chrome With Selenium WebDriver

Lego made with a detached chrome logo for a head!

So if you hadn't heard, Google has implemented a headless option for Chrome. This will be included from version 59, however you can download it now and a play using the Canary install.

So I did just that. I downloaded the latest ChromeDriver, wasn't sure if a new version was required or not, digging a little bit deeper after the event, I realised it wasn't, but seems like a good practice when trying out new things. Then I downloaded and installed the Canary Chrome, nice thing about Canary Chrome is it remains a seperate app, so doesn't interfere with your existing chrome.

Then from a quick google, I discovered the argument for headless, is well '--headless', easy!

So I know from existing use cases that you can pass arguments to ChromeDriver using ChromeOptions, so I created a ChromeOptions in my code and passed in the argument '--headless'.
Now as mentioned above, Canary Chrome installs a seperate app, so this reminds me, that I have to instruct ChromeDriver on where to find this binary.

So again, we can do this using ChromeOptions, and specifically the setBinary method. Now the first time I did this, I set the path to be "/Applications/Google Chrome", this didn't work. So I dug a little bit deeper into the content of the package and discovered that I needed to go all the way to the executable, which turns out to be "/Applications/Google Chrome Chrome Canary", and boom it worked!

I then thought I'd instruct WebDriver to take a ScreenShot so I could indeed see if it was working, alas this functionality isn't available on a Mac yet, but I read here, that it does indeed work on Linux.

So here is plain pretty dull Java code, but it does the trick and runs successfully using Chrome headlessly!

Now, historically I'm not a fan of headless browsers. If I'm going to go the expense of automating on the UI, I want those to execute on a browser that my users actually use, non of my users use a headless browser!

This may change with headless chrome though, may. I say this because, in the past, most of the headless options were standalone tools, seperate from the common browsers, such as HTMLUnit or PhantomJS. Also if you hadn't seen it looks like PhantomJS will no longer be supported as the project lead stepped down.  So I think once it's more stable and available in standard Chrome, I'll do some experiments against it to see what the gains are, or aren't as the case may be. Plus I'll see if I can find some information on the internals to see how much it differs from how Chrome with a head works.

Few useful links I found since writing.


You Say Test I Say Check. On We Go.

This discussion has been going on for a very long time, and it won’t ever end, it won’t end. I repeat that because it’s reality, such a discussion will never end. But that’s OK.

I consider myself a student of testing, over the last ten plus years I’ve formulated a mass of thoughts on testing. One of those happens to be the believe that there is a huge difference between what a human can do and what a computer can do, in the context of testing. One of those distinctions is labelled by some as checking and testing. The distinction being that when we automate a check, it’s a fixed algorithm, unable to observe anything other than what’s it’s instructed to. Unable to change its behaviour or flow other than the flows that have been coded. Therefore, it’s checking the flow of the steps and some outcome/behaviour at the end. However, when we test, due to the fact we’re humans and have the best tool out there, the brain, we can observe all, we can change our focus hundreds of times a minute. We can observe in real time and adapt accordingly. Now sure, for the AI/ML fans, sure computers are showing some signs of this now, but they won’t be in the regular development teams office any time soon. But that’s not the point of this post.

I believe this distinction is universally agreed by any student of software development, and especially testing students. So, we end up at our choice of words and their importance. They do carry some importance. Others have written far better pieces on that topic then I can, so we won't go in to this.

So, let’s look at this from my angle:

I don’t care what words you use.
I actually don’t. I do not care. I’ll never correct you. I’ll never reply to your blog post going ‘I think you mean checking’, ‘excellent piece, but by the way, automation cannot test, that’s checking!’. I won’t do that.

What I will do, is frame my responses to match my own views of testing, because in my testing world there is testing and checking. Those words are congruent with my view of testing. Therefore, when I write or talk about testing, I use those words, they fit my current beliefs of testing. They fit my models of testing. My models. They may not be in your beliefs or models of testing, and that is OK. In fact, it’s more than OK, it’s awesome, it’s awesome that you’re aware of your own models and sharing those with a wider audience.

You will hear me say ‘automated checking, you will hear me say ‘automation in testing’ and you will hear me say ‘automated check. You will also hear me say, ‘I’m going to use my language for testing during this talk, so if you hear me say the word check and you’re unsure what I mean, replace it with test and say it back to yourself’. I make a similar statement when I say tester these days, ‘if I say tester during this talk, I mean anyone who does some testing, not the role’, but I digress. You will also hear me say the words above without making such a statement, but hey-ho, on we go.

You will hear and read people saying automated testing, you will hear and read people saying automated checking, but allow yourself to process them against your models, let you brain change checking to testing, or check to test, or vice versa and continue the conversation, continue the learning.

Now I do tailor my language for who I’m talking to. If I’m talking to a fellow student and I know their models are similar to mine, I’ll choose my words accordingly. This allows us to get straight to the heart of the discussion. If I’m talking to a client, I’ll use their language, as this will make them more comfortable and allow me to truly understand their problem and needs. Overtime I may introduce some of the words more congruent with me, but only if it brings value and helps us solve the problem(s).

So on we go, I say check, you say test, I’ll say test sometimes, you’ll say check sometime. Be congruent with your own beliefs and models, but at the same time, bend a little bit, flex here and there, I believe such an approach will improve all of us, and in turn, testing and software development.