Last year, I’ve tried automating a Windows 7 desktop calculator using a Java library called Winium. A year later, someone from the comments told me that the example didn’t work on Windows 10. I ignored the comment for a while because I didn’t have a Windows 10 machine to perform a test back then, but now that I’ve recently upgraded my home PC I decided to try it out.
What I found:
Running a Windows 7 desktop calculator automation example (using Winium) on a Windows 10 machine
The Windows 10 calculator opened up but the tests didn’t run properly. The error log told me that the program was unable to find the calculator elements it was supposed to click. Bummer. Maybe the names of the calculator elements were different, Windows 10 versus Windows 7? It wasn’t; the element names were still the same according to UI Spy. Perhaps there’s something from Winium that can point me to a clue? Oh, it seems that the library has not been updated in recent years.
If I can’t use Winium, how then can I automate the Windows 10 calculator? A Google search pointed me to PyAutoGui. Instead of Java, it says that I’ll need Python (and Pip) for this tool to work. And yes, being Windows, I also need to properly set the environment variables so I can use the Python and Pip commands on a terminal.
Let’s install PyAutoGui:
And after writing some code, let’s see if we can automate the Windows 10 calculator with it:
Automating the Windows 10 desktop calculator with PyAutoGui. Click the image to view the GIF full-size on another browser tab 🙂
But here are some catches:
- I had to rely on PyAutoGui’s keyboard control functions for performing the calculator actions, instead of finding elements via the user interface. Well, from what I’ve seen so far from the docs is that the only way to locate a UI element is by locating elements using screenshots. I tried that the first time and it was very flaky, so I opted for using the keyboard control functions instead.
- The code introduces a time variable to wait for the calculator to appear on screen. The code also introduces a time variable to pause a portion of a second in-between each keyboard action so the actions don’t happen too fast for a person’s eye.
- There are no assertions in the example code, because I couldn’t find any assertion functions I could use from the PyAutoGui docs. It is not a tool built for testing, only for automating desktop apps.
Source code for this experiment can be found on: Win-Calculator-PyAutoGui.
This is probably old news, but I only recently found out that there is a way for Cucumber tests running in Ruby to automatically retry when they fail.
Here’s a sample failing test:
Apparently we can just add a
--retry command to set the test to retry if it fails. And we can set how many times we want the test to retry. If we retry the failing test above to retry two times, with a
--retry 2 command, we’ll get the following output:
It did retry the test twice, after the initial failure. Neat! 🙂
But what happens if we run the test, with the same retry command, and the test passes? Does the test run three times? Let’s see:
Good, the retry command gets ignored when the test passes.
A week ago I was working on a quick automation project which asks for an HTML report of the test results to go along with the scripts. It was a straightforward request, but it was something that I don’t usually generate. Personally I find test results being displayed in a terminal to be enough, but for the said task I needed a report generator. I had already decided to use Cypress for the job so I needed something that plays well with it. In their docs I found a custom reporter called Mochawesome.
To install it, I updated the
package.json file inside the project directory to include the reporter:
The Cypress documentation on Reporters also said that for Mochawesome to properly work I should also install mocha as a dev dependency, so that’s what I did.
And then run
npm install on the terminal to actually install the reporter.
Before running tests, there’s a tiny change we need to write on the
cypress.json file inside the project directory, which tells Cypress which reporter do we want to use for generating test reports.
And we’re all set after all that. 🙂
Run Cypress tests by running
cypress run --reporter mochawesome. Or if you specified a script in the package.json file the same way I did in the first photo above, just run
After running tests, we’re going to find out that a mochawesome-report directory has been added to our project directory which houses both HTML and JSON reports of the tests.
A sample HTML test report looks something like this:
Looks nice and simple and ready for archiving.
I was browsing my Feedly news feed recently, as I routinely do once a week, and saw this particular bit of cheery bulletin:
Click to redirect to the official announcement from Selenium HQ
Long live Selenium IDE! 🙂
Nostalgia hits. I remember the days when the only automation I knew was Selenium IDE’s record-and-playback. It’s easy to install, is relatively fast, and isn’t difficult to pick up as the Selenese commands are straightforward. It was possible to run a test individually as well as to run tests as a suite. There was a way to manually change test steps, and, of course, save tests, as needed. It only worked on Firefox at the time, but that for me back then was good enough. At least until I eventually craved for the re-usability, maintenance, and customization advantages that programming has over record-and-playback.
This is what it looks like now:
And some delightful things about it (that I don’t remember – or perhaps forgot – having seen in the Legacy IDE):
- Command dropdown options in English
- Control flow commands baked in
- An execute async script command
- A run command to run tests headlessly! 😮
- Google Chrome extension and Firefox add-on versions out of the box
Although I don’t see myself going back to record-and-playback tools for my automation needs, I’m still glad Selenium IDE is back for everyone to try. It’s still a great tool for recording quick automated browser scripts, for demo purposes or otherwise, as well as for learning automation in general.
Looking at the screenshot above, it’s ironic that there’s a mismatch between the commit message and the actual pipeline result from the tests after pushing the said commit. 😛 What happened was that after making the unit tests pass on my local machine, I fetched the latest changes from the remote repository, made a commit of my changes, and then pushed the commit. Standard procedure, right? After receiving the failure email I realized that I forgot to re-run the tests locally to double-check, which I should have done since there were changes from remote. Those pulled changes broke some of the tests. Honest mistake, lesson learned.
I frequently make errors like this on all sorts of things, not just code, and I welcome them. They bewilder me in a good way, and remind me of how fallible I can be. They show me that it’s alright to make mistakes, and tell me that it’s all part of the journey to becoming better.
And yes, testers can also test on the unit level! 🙂
Knowing how to automate things and building scheduled tests to monitor known application behavior does not guarantee bug free apps.
They do help boost confidence in what we’ve built, and that makes us more comfortable releasing changes into the wild, because it means we’ve explored a fair amount of feature breadth. It’s not the only strategy I’m sure to use given some software to test, but it’s something I’ll practice every after thoughtful exploration.
But, even with that tool to augment my testing, I have to keep my guard up. Every time, I should keep asking myself about the more valuable matter of the unknowns. What sort of things have I not considered yet? What scenarios might I still be missing? Have I really tested enough or am I merely being overconfident, just because I can automate?
When integrating a PHP application connecting to a PostgreSQL database, both services running as Docker containers using the official PHP and Postgre images, you might encounter (as I have) an error that looks something like this:
Uncaught Error: Call to undefined function pg_connect() in ...
It’s actually a simple error, which means that there’s something wrong with the connection between the app and the PostgreSQL database, but when I first stumbled on it I had a hard time finding out what I needed to do to fix it. There was definitely something missing from the Docker setup, but I did not know what it was until I sought help from a teammate.
Apparently the official PHP docker image does not contain the PDO and PGSQL drivers necessary for the successful connection. Silly me for assuming it does.
The fix is simple. We have to create a Dockerfile that updates our PHP image with the required drivers, which contains the following code:
RUN apt-get update
# Install PDO and PGSQL Drivers
RUN apt-get install -y libpq-dev \
&& docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql \
&& docker-php-ext-install pdo pdo_pgsql pgsql
Easy peasy. And to run this Dockerfile from a docker-compose.yml file, we’ll need the build, context, and dockerfile commands, replacing the single image command that does not use a Dockerfile:
# All your other settings follow ...
And that should be all that you need to do! 🙂