Let’s explore some of the ways Kent suggests making your automation fun again for you and your team.

Why Aren’t the Developers Testing their Code?

I’ve always found it strange that someone who develops production code for complicated applications would have issues with writing unit or test automation code.

I previously believed it was just the lame teams that I’ve worked with that had a hard time with automation. It turns out, however, that many of the folks I’ve interviewed on TestTalks have had the same experience.

There could be a few reasons for this. Some common ones might be:

• Culture Issues
• Training Issues
• Tooling issues

These are the three I usually hear about, but Kent C. Dodds brought up a fourth one that no had ever mentioned to me, which is that the tool is just not fun to use.

What Does Fun Have to Do with Test Automation?

Most of us would agree that knowing how to code and having some API to code against is very different from having a good experience using that API.

The problem some developers have with tools like Selenium is the limitations on the integration with developer tools, which gives them a bad experience when trying to create automated tests.

It’s just one of many reasons why developers like Kent aren’t huge fans of Selenium. Funny–Kent even said that all the times that he has spent with Selenium has left him with some painful memories.

I love Selenium but this is a sentiment I hear from many hardcore developers when discussing automation testing.

So How do You Convince Your Developers that Testing is Fun?

The first thing you can do to try to rid your teams of their anti-testing attitudes is to make it easier to write tests in your framework.

The easier it is for developers to write tests, the better experience they will have, and the happier they will be.

Ensuring that your tool fits into your developers’ workflow and that it has developer-grade debugging features will also go a long way.

Why are developer debugging capabilities vital when it comes to making developers happy?

As far as testing tools are concerned, one of the most important problems to solve is discovering the answers to “What’s broken, and how do I fix it?”

You’ll want to make finding an answer as short as possible, so improving the developers’ test debugging experience is a paramount objective of any testing tool.

When there is a failure, or an error thrown somewhere, your tool should show you the testing error. It should also show you what line that error occurred on, and give you the context of the code around it with supplemental info including the exact stack trace.

Testing Confidence and Saving Time Happiness

Besides making tests fun to create and debug, you also need to explain the time benefits developers would gain if they embraced automation.

Imagine if every time a developer made a change to their code for a new feature or refactor they had to manually verify that they didn’t break something.

Doesn’t sound like much fun, does it?

Instead, what if when they make a change they have tests that automatically kick off and verify that nothing was broken due to their change.

Now that sounds like fun to me.

It should also give your developers a sense of confidence in knowing that the code they introduced to the code base will not break anything.

Does Your Team Need a Developer Automation Education?

Another reason some developers don’t like testing is because they really don’t know how to test.

These developers tend to write really poor automated unit tests that cause them headaches later on because they are unreliable and hard to maintain.

They may be aware that they are the reason why the tests are awful, but they might blame automation or the tools and say it’s not worth it.

Since no one wants to deal with poorly written tests that aren’t added value, it becomes a burden.

Frankly, I wouldn’t like testing either if that was my experience.

So making sure that people are writing proper tests that are free of implementation details and are easy to write and maintain can really help improve people’s attitude toward testing.

Examples of Developer Friendly Automation Tools

Kent also shared some tools he believes can make testing more fun for developers.

Jest – Facebook Created JavaScript Testing Framework

For unit-level automated tests, Jest is a great developer-friendly tool that’s easy to configure and set up.

It has features that make it easy to do TDD–its watch mode, for instance. And you can easily run tests in parallel with it. It’s even intelligent enough to know to on runs tests that are relevant to the files you’ve changed since your last commit to your code repository.

This is awesome if you have hundreds (or even thousands) of tests that take a long time to run since it will only run the ones that are relevant to your changes.

On top of that, it runs your tests in parallel. If one of your tests fail and you make another change when you rerun, Jest is smart enough to know to rerun the failing test from the previous run first.

This allows you to find out as quickly as possible whether your changes fixed those tests.

Cypress.io

Another developer-friendly tool for developers who also need to perform browser-based automation is Cypress.io.

Upon discovering Cypress about two years ago, Kent liked it so much that he hasn’t felt a need to look at anything else.

Cypress is incredible because it allows you to look at the browser, open the developer tools and pin what the application looks like at a specific point during the test run.

You can look at what the DOM looks like at the same time, making debugging broken tests is a breeze.

Because of the aforementioned features and more, Cypress and Jest are virtually guaranteed to help make automation testing fun again.

How to Get Your Developers Up to Speed with the Latest in Automation Testing?

If you feel overwhelmed with staying up to date with all the latest automation testing tools and best practices check out my annual online conference dedicated 100% to just automation testing — Automation Guild.

Copyright text 2019 by Joe Colantonio | TestTalks Privacy Policy Disclaimer All the contents of the Blog, EXCEPT FOR COMMENTS, constitute the opinion of the Author and the Author alone; they do not represent the views and opinions of the Author’s employers, supervisors, nor do they represent the view of organizations, businesses or institutions the Author is a part of. Privacy Policy | Sitemap