9 Automated Testing Practices To Avoid Tutorial (Escape Pitfalls)

If you're in software development, you know that building competitive products requires regular testing.

But how do you avoid common automation testing practices traps?

Without testing, your software probably won't work as it should, and you'll struggle to find customers willing to pay for it.

Relying solely on manual testing to find defects or bugs can use up a lot of time and resources. It's also a repetitive and expensive process.

Automating the repetitive parts of your testing process can help you build better quality software in less time and for less money.

Automating tests also allow you to test more code with better accuracy in less time. Automation frees up QA resources to carry out manual tests that can’t be automated. But done correctly, automated unit tests also act as a safety net for developers who need to refactor and release code to production quickly and with confidence.

Beware, though—many novice developers and testers fall into the same common automation testing practices traps.

These traps can be found in all types of testing, including unit testing, integration testing, and end-to-end testing.

Fortunately for you, I recently caught up with Ramona Schwering on the TestGuild Automation Podcast, and she shared some invaluable advice on the best testing practices from an expert developer who was once a tester (what I like to call a unicorn). :)

Ramona Schwering is a developer at Shopware AG, which has developed an open-source, e-commerce system for online stores. With five years of experience in QA, Ramona understands better than most how to get maximum results from automated testing and their automation tool.

Without further ado, let's get into Ramona's nine tips for better automating testing!

Tip #1 – Avoid slow tests and slow execution times

Throughout the development process, your software will become more complex every day. But the more complex the software, the more complicated testing becomes.

An automation framework with tests that take weeks to write and months to execute are a pain point for everyone. Developers don't want to wait around forever for results, and testers don't want to spend their time writing or repeating the same tests.

Targeting simple or repetitive elements for testing will significantly reduce the testing lead time. It will also free up personnel for tests that require manual attention or more exploratory testing.

Avoiding slow tests altogether can also prevent a rift from forming between developers and testers.

Tip #2 – Ensure your tests are clear and easy to explain

Most people spend way more time reading source code than writing it, so making your code as easy to read as possible is an excellent decision.

It'll never read like Hemingway, but that doesn't mean it can't be readable to anyone but you.
Yoni Goldberg considers this the Golden Rule for testing: one must instantly understand the test's intent.

You will love yourself (and your team members will pat you on the back) for making your tests readable.

When you read those same tests a year down the road, you won't be thinking, “What was I doing?” or “What was this test even for?”

If you don't understand what a test is for, you obviously can't use it. And if you can't use a test, what value does it have to you or your team?

A test that you can’t understand has NO value.

Unreadable code is also a debugging nightmare.

Tip #3 – Don't use too much abstraction

Try to keep your tests simple. Don't use too much abstraction.

Remember: automation tests are NOT production code.

Don’t take this the wrong way.

Of course, you should treat testing like production code with the same value, but there are some patterns, some conventions that are important for production code but not suitable to test code

The Don't Repeat Yourself (DRY) principle urges testers to avoid duplication at all costs.

But if you over-apply the DRY principle to your tests, it will make them more challenging to read and understand.

So, this pattern might be great for production code, but you should re-think using it for automation code. Instead, maybe use some documentation duplication to make the intent of the test clearer. Remember: test readability trumps the DRY principle.

Tip #4 – Isolate your tests wherever possible

When you're testing repeatedly but not making any changes between tests, you're not providing consistent value.

If your new test relies on a successful previous test, you're asking for trouble. If the previous test failed or corrupted the data, any subsequent tests will likely fail or provide incorrect results.

Isolating your tests will give you more consistent results, and accurate and consistent results will make your tests worthwhile.

Ramona said her first step before testing is always to reset her application to a clean installation. That way, she can ensure every test uses the same data and is protected from any outside factors.

Her second step is to create the data she needs for the test using an API request. The tests can run independently, and the order of the tests doesn't matter.

The Guild Wants YOU

If you've read this far you know how important it is to stay up to date with the latest in test automation, tooling, processes, and practices. One of the best ways is to become a TestGuild member. Join now at no cost!

Tip #5– Prioritize testing mission critical elements

There are only so many hours in a day, and so much testing that one can perform during those hours, so it helps to prioritize which tests are most important.

Prioritizing different elements for testing will reduce the chances of a critical element going wrong.

When prioritizing testing one element over another, there are a couple of questions you should ask yourself:

• How likely is it that a user will encounter an error here?
• Which areas cannot afford to have errors?

If an area is unlikely to have an error and isn't mission critical, then it's not high on the list of testing candidates.

Conversely, areas like user registration or checkout can't afford to have any errors.

In high-value areas, detailed testing is paramount.

Tip #6 – Follow a clear testing structure

A clear testing structure will keep your tests clean and consistent.

The AAA testing pattern is an easy and effective structure to follow to ensure good code quality, regardless of what programming language you are using.

Each test should have three stages:

1)Arrange – Start by defining what you need to begin your scenario. Then consider the different variables and ask yourself what you need to ensure your test works. After which, you should arrange your tasks into logical steps.
2)Act – Carry out the testing following the steps you created for yourself.
3)Assert – After testing, assert the status of whatever you tested.

Adopting the AAA pattern will keep your automation testing on the right track.

Tip #7 – Don't write a test based on selectors that may change

Writing tests based on something that might change in the future, like CSS selectors, can result in failed tests.

This can in turn lead to a head-scratching scenario where your test failed without a bug, and you're scrambling to work out why.

Of course, there's no bug to be found; your test is just outdated.

Instead, you should focus on selectors less prone to change, like data attributes. Your developers are unlikely to change those any time soon.

Included in this tip is a bonus tip – don't test implementation details!

Testing implementation details can give you false positives and false negatives.

The test can break when you refactor the application, giving you a false negative. Or the test might not fail when you break the application code, leaving you with a false positive.

Tip #8 – Don't use fixed waiting times

Fixed waiting times in tests are a terrible idea for several reasons.

A test can fail if it takes less time to execute than the website takes to react. You can either wait too long, which makes your test slow and inefficient, or not wait long enough, which can also lead to test failure if your app loads for too long.

Instead, try waiting for changes in the UI just like your users would. It might mean waiting for a loading spinner to disappear, for an animation to end, or for all the text to be fully loaded.

This way, you know for sure you're not cutting the test short.

Tip #9 – Don't use foobars as placeholder names

Imagine a fellow developer looking at a test you wrote six months ago. Also imagine, from her perspective, what must go through her head when she reads “foobar.”

She might ask, what does the test do? What does foobar stand for here? Is it a product? A customer's name? Something essential or completely inconsequential?

Using foobar (and other similar placeholder names) can make your test harder to understand.
Instead, use names or placeholders connected to a real product. That way, anyone reading your test will know what your test is for.

Ramona advises you to think about your test like a friendly assistant. It should make your life easier, not fill you with dread!

If you haven't yet done so, I highly recommend you apply these tips to your automation framework projects to improve your testing efforts.

I hope you find Ramona's testing tips helpful.

Parting Actionable Advice from Ramona

If there is just one concept to take away from this post, it’s this:

Think about your test like a friendly assistant not a hindrance or something you don't want to work with. Tests should make your life easier, not harder.

I think that sums up everything up nicely.