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
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…
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.
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. …
Software Quality Engineer fighting for truth, justice, and better quality apps. Thinks a lot about Automation and CI/CD, in both practical and abstract terms.