How Good Habits Improved My Test Automation Skills

I struggled to make my tests modular, easy to write and easy to maintain. Nonetheless, learning some good DRY habits, Page Object patterns and reducing the amount of multitasking significantly reduced the effort I have to make in order to write manageable and clean tests.

There are various reasons which may be stopping you from developing good habits in test automation. Short-term projects, complex frontend code, mobile projects which involve some experimentation or the lack of a suitable tool that can do that for you. Discontinuity is also quite common when you do not know enough. However, changing your habits will have a significant impact on improving the quality of your tests. Make sure to keep reading if you want to learn the good practice.

Keep Your Tests DRY

The good old piece of advice: Don’t Repeat Yourself. Sounds easy, right? In fact, it is simple, but as a newbie, you might feel the immanent need for creating longer files, because the more code you produce, the more you have achieved, right? WRONG. Why is it so? It is similar to minimalistic design. At first, you either design or write tests as descriptively as you can. Then, you reduce the amount of code in your actual specs using helpers, page objects and other smart methods. How does it help? Less code to write usually means less effort.

What my work used to look like:

What it looks like today:

Oh my, where did all the lines go? You can minimise the amount of code only if you understand the process of reduction and how the underlying structure works. Therefore, I will not explain what happened between case #1 and case #2. Note that even case #2 can still be slightly improved, but I am sure you have noticed.

Structure Your Tests into Sections

Whether you are writing your first tests or you are already experienced in the field, planning/structuring matters a lot! There is no way to just jump into writing tests without planning them out first. How exactly can you do that?

Since you are reading this post, I am quite sure that you have heard about SitePrism, a Page Object Model DSL for Capybara. However, in case you did not, please go here. This will immensely reduce the amount of time you spend on writing tests. SitePrism lets you divide web app into pages and pages into sections.

When designing tests I developed a habit of drawing screenshots and dividing them into sections and elements, which gives me a visual representation of the elements I am going to work with, e.g.:

You will find this practice extremely helpful because it simplifies the page you are working with. I would call this Reverse Prototyping. Given you have these, the next step for you would be opening atom/sublime or whatever editor you choose to use. Each screenshot drawn as a whole represents a separate page and for each of them you need to create a file called your_awesome_page.rb. Pages include sections(your_awesome_section.rb), and sections include modals(your_awesome_modal.rb), you can go even further and divide your modals, but, well, I do not imagine this ever being useful.

Find the Pattern

You have probably noticed that testing is about repetition. While switching between the projects you take part in, it will likely turn out that quite big chunks of your tests are almost identical. Therefore, why not use earlier tests as a reference point? When planning tests you can usually think of two parts:

• the tests you can `quote` from your old projects,
• new tests that you have to experiment with.

If you like the idea of referring to your old tests, make sure you do not delete them from your computer. Github repositories can be deleted and no one would care if you keep your testing treasures there.

Some things that can be repeated between projects:

• login,
• registration,
• adding user,
• active admin,
• and many many more.

Nonetheless, one thing has to be taken into account when referring to your previous work. Looking back at what you have done before, you can always improve, so do not do it without reflecting on what to do better.

Never Multitask

Some people say that the only way they can complete their work, or work more efficiently, is by multi-tasking. I am sure that all of you know at least this one guy or gal who keeps on saying “Look how awesome I am, how focused I am on coding when watching tv series or talking to you.” Bulls***, they’re just wrong. I am not a psychologist myself, nor am I a productivity expert, but from my own experience, I can tell that multitasking is the biggest pain of working in a software development company. Why? Imagine the following case:

You are working on project X, testing a new complex feature requiring you to log in with multiple users simultaneously. Out of the blue, you get a slack message from the PM of project Y: “Hey, can you check one thing for me? It’s really urgent, and the client is mad”.

At first, when I was an inexperienced QA Engineer, I would willingly go for it and do whatever I was asked. But coming back to the previous task would often be painful. I would not really know where I stopped and I had to start over to do it thoroughly. Or I would have to guess where I stopped and kept going from the estimated point.

Multitasking itself is as dreadful as reading the previous sentence. Instead, you should prefer to roll the following way: “Yes I will help you mate, but in 20 minutes because I have a thing to finish”. That’s it. You will never have to multi-task again. I think multitasking is harmful, and so do some more credible people in the field. For more on that subject refer to this article.

All in all, when writing automated tests, it is a good thing to start with preparing a concise plan of what to do and then divide it into smaller tasks. Before you start working on your tests, find a relevant window in your calendar to complete the work and set your Slack status to `busy`. Personally, I like writing tests after successful deployments because then I know that I have some time which I can fruitfully `spend on` continuous test development.