In an ongoing software development project we are using Makefile tasks to make running long and repetitive commands as easy and as fun as possible to run. They’re like bash aliases, shortcuts to performing recurrent jobs we frequently have to do while writing new code or testing applications. For example, we could define a task that runs unit tests and code standard checks on an application running in a Docker container like so:
echo "Checking application code with PSR2 standards ..."
docker-compose exec -T php phpcs -v --standard=phpcs.xml ./app/src
echo "Running unit tests ..."
docker-compose exec -T php phpunit --colors=always --configuration ./app
and we would run the task with only the following command:
Cool, right? I don’t have to remember all the exact commands to do what I need to do. And even if I forget the right task name (in this case,
make test) I can just run the
make command in the CLI and I’ll be provided a list of the tasks that I can use for the project.
Now Makefile tasks will run on Unix terminals out of the box. For Windows however, we still have to do some setup before Makefile tasks can run. For my machine at work, I did the following:
- Download and install GnuWin32
- Go to the install folder
C:\Program Files (x86)\GnuWin32\bin
- Copy all files inside the bin folder to the root project directory (
- Add the installation bin directory to the system environment variables
There are other tools that we can use to configure Makefile to run on Windows but this is a quick and easy way to do it. After that we can run
make.exe test on the default cmd CLI but on some Unix-like terminals like the Docker Quickstart Terminal we can definitely use
It’s amazing that the recently concluded Selenium Conference over at Austin Texas continues to live up to expectations, building up on the previous conferences and keeps delivering quality talks on automation and testing. And what’s more interesting is to know how they’ve been keeping up with everything with help from the Software Freedom Conservancy and the testing community. There’s even a European Selenium Conference happening on October 9-10, which I’m very much looking forward to.
Meanwhile, here are some of my favorite talks from the Austin conference:
- Automate Windows and Mac Apps with the WebDriver Protocol (by Dan Cuellar, Yosef Durr, and Stuart Russell, about easily automating Windows and Mac apps using Appium)
- Automating Restaurant POS with Selenium – A Case Study (by Jeffrey Payne, about automating a point-of-sale system for testing, including credit card readers, printers, cash drawers, and caller IDs)
- Selenium State of the Union (by Simon Stewart, on an overview of the W3C spec process and about naming things in the Selenium project, how APIs should be correct and how people won’t write their own, how not everyone is a sophisticated developer, and how testing is under resourced)
- Leverage your Load Tests with JMeter and Selenium Grid (by Christina Thalayasingam, on adding load tests for your system using JMeter and Selenium Grid in combination)
- Selenium and the Software Freedom Conservancy (by Karen Sandler, on the safety and efficacy of proprietary medical devices and how often open-source software are more likely to be safer and better over time, and about what kind of organization the Software Freedom Conservancy is and how it helps open-source projects like Selenium continue to live on for the long-term)
- Stop Inspecting, Start Glancing (by Dan Gilkerson, on automating web apps without looking at the DOM structure)
- Transformative Culture (by Ashley Hunsberger, about moving from QA to Engineering Productivity and the culture changes necessary for getting better at testing)
Ever since I learned how to use Selenium to automate browsers and web applications a few years back, I’ve wondered from time to time whether I can use the same process or technology to automate Windows desktop applications via its user interface. There’s no particular use case at work considering our apps are all in the web, but I challenged myself to find an answer only for curiosity’s sake. It didn’t turn out to be a thought-provoking experiment but at least it was somehow amusing.
Here’s what I got from the quick study:
Click the image to view the GIF full-size on another browser tab 🙂
And a few notes:
- We can’t use Selenium to automate Windows desktop applications.
- A quick search about automating Windows apps tells us that there’s actually a number of tools we can use for such purpose, some paid, others free. Other than Winium, I found out that we can also use Sikuli (or its successor SikuliX), WinTask, autoIT, TestStack.White, Automa, MacroScheduler, Cobra, or Pywinauto. There’s probably more tools out there. I just chose to use Winium because writing tests and automating the app with it is similar to how Selenium works, which means very little learning curve for me.
- Source code for this short experiment can be found here: Win-Calculator. It uses Maven for handling installation of project dependencies while the test code is written in Java. The tests run locally, I’m not sure whether there’s a way to manipulate a Windows app on another machine using Winium. I have not researched that far.
- Winium will actually take control of the machine’s mouse to move to the element locations set in the tests. This means that interrupting the position of the mouse while the tests are running would likely fail the test. This is annoying, and I’m not sure whether the other Windows app automation tools behave otherwise or the same.
There’s a lot of stuff going on in the software testing community at the moment, specifically in the field of automation, because of how software is now being deployed into various other platforms besides personal computers. Google needs to worry about testing their eyeglasses, virtual reality headsets, and cars. Others care about testing robots and televisions. This is why it is fun to watch talks from conferences, like the Selenium Conference or the recently concluded Google Test Automation Conference: I get to find out what problems they’re facing and see how they try to solve them, and maybe learn a thing or two. Sometimes I get to pick up a new tool to try for my own testing too, a great bonus.
Some favorite talks from the conference are:
- Automating Telepresence Robot Driving (by Tanya Jenkins, on the challenges she faced building and running automated checks for telepresence robots)
- ‘Can you hear me?’ – Surviving Audio Quality Testing (by Alexander Brauckman and Dan Hislop, on how testers can leverage automation for testing audio)
- Developer Experience, FTW! (by Niranjan Tulpule, about Firebase and how Google build tools which help mobile developers create high-quality apps for their users)
- ClusterRunner – Making Fast Test-feedback Easy Through Horizontal Scaling (by Joseph Harrington and Taejun Lee, on how horizontal-scaling can help run tests faster)
- Need for Speed – Accelerate Automation Tests From 3 Hours to 3 Minutes (by Emanuil Slavov, about continuous improvement and how incremental changes to tests dependency contribute to improving the overall test suite speed)
- Selenium-based Test Automation for Windows and Windows Phone (by Nikolai Abalov, on automating applications for the Windows desktop and mobile platforms)
- Flaky Tests in Continuous Integration: Current Practice at Google and Future Directions (by John Micco & Atif Memon, about Google’s battle with flaky tests and how data analysis helps find out the trends for finding out what makes a test flaky)
- OpenHTF – The Open-Source Hardware Testing Framework (Joe Ethier & John Hawley, about testing various types of hardware and helping hardware test engineers focus on the test logic for phones, cars, eyeglasses, daydream, among others)