I’m a true believer in the power of interactive coding sessions. I’ve been really inspired by the ideas of Chris Granger’s Light Table and Bret Victor’s Learnable Programming. And I think these interactive coding techniques can be especially useful when applied to the first phase of developing a Selenium UI test.
To start, we use a technique I explained in an earlier post to load a third-party library into the Kotlin REPL:
$ ivy -dependency org.seleniumhq.selenium selenium-java 3.141.59 -cachepath classes $ kotlin -cp $(< classes)
Welcome to Kotlin version 1.3.72 (JRE 1.8.0_252-b09)
Type :help for help, :quit for quit
The REPL (read-eval-print-loop) is a feature that seems to get overlooked far too often. REPL sessions offer a quick and convenient way to try out snippets of code, and with the right start-up option, you can easily load classpaths and .jar files to explore third-party libraries too.
$ brew install ivy
With the stand-alone Apache Ivy utility installed, you can download individual third-party libraries, along with their transitive dependencies, on the fly, outside of a project, with no pom.xml file required. The library’s .jar …
To start development work on a new Android phone, the Developer Options must be turned on first. A few years ago, Google hid the Developer Options on Android to prevent non-developer users from misconfiguring their phones. Now you need to perform something like a secret video game cheat code, kind of like the Konami Code, to enable Developer Options.
Here are the steps of the secret code 🤫
Selenium provides some really useful functions for interacting with web browsers. In my own automation projects, I’ve used the browser window management methods frequently, and I’m really thankful they exist.
But the Selenium library does not cover everything in browser automation. One type of browser interaction that is still missing is the file upload, or more precisely, interactions with the file type of <Input> element.
Selenium does not offer any class or method to help with uploading a file. If you try to click the “Choose File” button on a form, the browser displays a native file chooser dialog, which is outside of the control of the browser, and therefore out of Selenium’s automation reach. …
The usual pattern of writing an automated test is to load a page in the browser, find the element you need to target on the page, and inspect the element (Right Click > Inspect or Command + Option + C on a Mac). The Elements panel of Developer Tools opens up, and from there, you can figure out a selector expression for the element. …
I’ve been arguing against using Java for test automation code for years. Java is too verbose and its edit-compile-run cycle is too slow to be effective for an automation project.
One response I get back is that someone’s team is so heavily invested in the JVM ecosystem, it’s just not realistic to leave it behind to move to a different language. And alternative JVM languages like Scala, while very interesting, are not the best fit for automation code.
Another alternative, Kotlin, gained a lot of attention last year after Google made it the new standard for Android app development. Kotlin has also developed into a really compelling choice for test automation code. …
QA Automation is a specialized, niche field in the tech world. There’s not many of us, and it’s hard to find information about the tools you should use for the role. So, here’s a sampling of what tools work for me:
You need a language for your test code, and it’s really helpful to use something with a productive environment and a light-weight syntax. On most automation projects, you need to move quickly and get test cases written before the next release. …