On An Indeterminate Hiatus

I wrote my first post on this blog about six years ago. I was three years into software testing then. I’m around nine years into it now. Many things have changed over the years, in processes, in tooling, in people I work with, but some things remain the same. The core of my abilities in making a living as a tester is still rooted in a strong relationship with the software development team, and how strong that relationship is depends on everyone’s communication and technical skills. I’m fortunate enough, all these years, to have worked with wonderful people, enabling me to make a living in an industry I’ve come to love.

I’ll most likely going to be working as a tester for many more years to come.

Today, however, I am putting this blog on an indeterminate hiatus. I’m not sure when I’ll be back. There’s not much to say really, except that I would like to take the time and energy I’ve been putting here somewhere else that may or may not work.

For now, all that’s left to say is a huge thank you for following along. 🙂

 

 

Cypress: Printing Information to the CLI

Most people will run tests written in Cypress via the built-in test runner. It provides much of the information people need when looking at tests and checking whether it is doing what it is supposed to do – test status, command logs, app preview for each test run, plus snapshots of test steps. Very useful when looking at test failure points.

Some people, however, like to run Cypress tests using the terminal or the command-line interface. Sometimes, we don’t necessarily have to see the test running over the app UI. For one, I can start writing a draft of a new set of tests while the existing test suite runs in the background; I will want to know if there are failing tests, but not get distracted by them running on the test runner. That’s how tests run on a CI server too; we just want the test results.

Cypress works well for both scenarios. There’s just less information displayed on the CLI from running tests by default. To help us debug failing tests without opening the test runner, we could print out information we need from the test as it runs. If we want, we can show network request and response pairs, or simple variable values. Often, I find that printing out the URL at certain point for some tests helps me understand test results better. I can also click that URL to redirect me to the page afterwards if there are details I want to check out later for myself.

In order to print that URL to the terminal, we’ll need to add a task to Cypress as a plugin. To do that, we open the plugins/index.js file and add a log task there, like so:

After that, we can now use the log task inside our tests. Here’s an example:

Help Yourself Perform Tasks With Personal Shortcut Commands

In a recent automation work I’ve been asked to take part in, running a single test safely, according to peers, generally follow a three-step process:

  1. Delete existing feature files:  rm -rf *.feature
  2. Create updated feature files:  PROJECT_DIRECTORY=../<dir> APP=<app> TEST=automated ruby create_tests.rb, where app is the name of the app you want to test
  3. Run the desired specific test:  cucumber --tags @<tag>

This means I have to re-run these three steps over and over for every single test I want to review. That can get tiring easily, especially if I have to re-type them repeatedly, or even if I copy-paste. Using the arrow keys in the terminal helps, but sometimes commands can get lost in the history and then it becomes a bit of a hassle to find them.

There should be a way for me to run an automated check I want to review, given just the app name and the test tag. It would be nice if I can run a specific test using a shorter command but still following the same process as provided.

I decided to set aside a little bit of time to write a personal script, and used Makefile because I’ve had experience with that before.

My personal short command for running a test:  make test app=<app> tag=<tag>

And here’s what the script looks like, which runs the known commands step-by-step plus displays some information on what’s currently happening:

Now I won’t have to worry about remembering what commands to type in as well as the sequence of the commands. I can give more focus on actually reviewing the test itself, which is what’s more important.

Is There Really Nothing We Can Do?

“I’ll wait for the code to get pushed to the Staging server before I continue testing because the data there is a lot more stable.”

“It’d be a waste of time trying to teach people how to program when it feels like they don’t have the motivation for it.”

“There’s a high chance things will break after a code merge with the production branch. It’s been that way ever since. We’ll just have to fix those that we can until the release.”

“I wish there was an easy way to spin up a version of our apps in a local environment. That should help us test things faster.”

Some problems become the status quo. It’s worth revisiting them, asking ourselves whether there’s really nothing we can do about it or we’ve just become comfortable with complaining.

Lessons from Richard Bach’s “Jonathan Livingston Seagull”

I’ve always kept a copy of Richard Bach’s “Jonathan Livingston Seagull” within reach, for those days when it seems necessary to remind myself of Jonathan’s story – of struggle, of questions and learning, of constantly challenging himself, and of keeping true to his curiosities. I’ve re-read it a number of times in the past several years (it’s a short book, digestible in a few hours), and it has never failed to uplift my spirits. It always feels like talking to a great friend that I’ve never seen for an extended period of time.

Here are some favorite lines from the book:

  • Do you have any idea how many lives we must have gone through before we even got the first idea that there is more to life than eating, or fighting, or power in the Flock? A thousand lives, Jon, ten thousand! And then another hundred lives until we began to learn that there is such a thing as perfection, and another hundred again to get the idea that our purpose for living is to find that perfection and show it forth. The same rule holds for us now, of course: we choose our next world though what we learn in this one. Learn nothing, and the next world is the same as this one, all the same limitations and lead weights to overcome.
  • Jonathan Seagull discovered that boredom and fear and anger are the reasons that a gull’s life is so short, and with these gone from his thought, he lived a long fine life indeed.
  • “You can go to any place and to any time that you wish to go,” the Elder said. “I’ve gone everywhere and everywhere I can think of.” He looked across the sea. “It’s strange. The gulls who scorn perfection for the sake of travel go nowhere, slowly. Those who put aside travel for the sake of perfection go anywhere, instantly. Remember, Jonathan, heaven isn’t a place or a time, because place and time are so very meaningless.”
  • “To fly as fast as he thought, to anywhere that is,” he said, “you must begin by knowing that you have already arrived.”
  • “Don’t believe what your eyes are telling you. All they show is limitation. Look with your understanding, find out what you already know, and you’ll see the way to fly.”
  • “Look at Fletcher! Lowell! Charles-Roland! Judy Lee! Are they also special and gifted and divine? No more than you are, no more than I am. The only difference, the very only one, is that they have begun to understand what they really are and have begun to practice it.”
  • “Why is it,” Jonathan puzzled, “that the hardest thing in the world is to convince a bird that he is free, and that he can prove it for himself if he’d just spend a little time practicing? Why should that be hard?”
  • “Oh, Fletch, you don’t love that! You don’t love hatred and evil, of course. You have to practice and see the real gull, the good in every one of them, and to help them see it in themselves. That’s what I mean by love. It’s fun, when you get the knack of it.”
  • We’re free to go where we wish and to be what we are.

Trying Out Cypress with Circle CI

Circle CI has been around a while but I’ve never tried their service before. There hasn’t been much of a reason to do so; at work I mostly stuck with a local Jenkins instance because it got the job done. But I recently had the urge to try it out for a private project that I have. I wanted to see if it plays well with Cypress, a test tool I’ve been using for some time.

A search tells me that there’s already a Cypress-Docker-CircleCI example on Github, from Cypress themselves. Cool, I just need to copy their settings to my own project and make changes accordingly.

Here’s how the package.json file looks like:

You’ll see a cy:circle-junit command in there, which does the same thing as cy:run (which runs tests on a terminal) but also builds a JUnit report.

To run our tests on Circle CI, we’re going to need a circle.yml file inside our project, which contains the following:

From this file Circle CI is supposed to checkout the test code, run the cy:circle-junit command, which installs Cypress and other dependencies inside a Docker image, saves that image in a cache (and restores that cache for every succeeding test runs as long as the dependencies remain the same), runs our tests inside a container, creates a simple report, and stores test artifacts afterwards. Looks straightforward. 🙂

Now let’s see if things work!

Connecting my Cypress project on Circle CI and pushing code changes on the remote repository automatically creates test runs that shows up on a neat dashboard like so:

And we can zoom in on the details of every test run, which looks like this:

Awesome! Looks like I’ll continue using their service for this project, and maybe on other projects as well. I’m off to adding proper tests to the suite!

 

Remember to Focus on Helping People

It’s easy to get caught up on writing a lot of automation, adding more process steps, and implementing stricter policies, believing we need them, because we think we’ll be safe from risks that way. We might have had a history of being carelessly bitten in the past.

So it is good that we’ve chosen to do something. But we have to be aware of the potential to get lost in the details.

Why did we have to do this work in the first place?

We don’t just want to add one more test to the suite. We don’t just want another meeting. We don’t just want customers to pay a fee when they request something for the nth time. What we want is to remember the big picture, what we want is to focus on helping people.