The Life-Changing Magic of Tidying Up Your Software Tests

You have too many tests. Your tests are too messy. Your tests flake out sometimes and you don’t even know where to begin fixing it. “The whole test suite needs an overhaul. A complete rewrite.”

If any of this sounds familiar, you might be in a position to change the way you approach your work and revolutionize your career as a software test practitioner. Does that sound flashy and theatrical? Good!

It’s time to start thinking passionately about how the practice of automating checks for software affects your own life and the lives of the people around you.

Imagine your automated software tests as a house. Walk into the first function that runs, firing up the test libraries. Exist in the bespoke parallelization method you wrote to bring down the execution time of the regression suite. Have a cup of coffee in your biggest page object file.

Is there anywhere to sit? Are there dark corners where spiders might be spinning webs? Is there light classical music playing, or just a cacophony of pots and pans being banged together?

Would you invite another practitioner to come over and take a look at your tests?

As test practitioners, we should have systems of automated tests and supporting documentation that we can be proud can be of. Not just for our own peace of mind, but for the good of the products we support.

Tidy up your tests for your own happiness, for your fellow developers’ happiness, and for your product owner’s happiness (not to mention their bottom line.)

The first step to achieving your ideal level of confidence is visualizing an airtight test suite in your dream software development lifecycle

Before you can begin tidying up your tests, you need to identify what an ideal test suite would do for you.

• You might want a system that catches regressions as early in the development process as possible.
• If your application is customer-facing, you might envision tests that would spot visual bugs across all your users’ most-used browsers at any viewport size.
• Test failures would be communicated promptly and clearly, and be simple to triage.
• The documentation and test cases would be up-to-date and searchable.

Once you and your team have figured out your ideal testing paradigm, you’re ready to start the work of tidying up your tests and moving closer to quality nirvana.

A tidy test system is one where you can confidently access the information you need about the application under test.

Some people view their tests as a cage, protecting the world from a potentially harmful entity within. Rather, your tests should be an open door, letting anyone gain access to the application so they can learn about it and, if necessary, heal it.

Your test system should be full of things that bring you peace of mind.

Don’t, for example, keep end-to-end tests around which derive their pre-existing conditions from the successful run of prior tests. If this seems like the only way to provide confidence in the capability being exercised by the test, it’s a sign that you might need to rethink how you’re testing this part of the application. Devise a way to set up test states for these tests, or decompose them to provide equivalent coverage at the unit and component test layers.

Cascading test failures caused by dependent tests only invite chaos, shame, and churn into your development process.

By ridding your test system of tests which slow down your release cycle, you become more focused and deliberate about the effective tests that you’ve kept.

Don’t be afraid to delete a test. Removing it could bring a pang of fear that you’ve lost some coverage. That’s good!

Hesitation shows that covering that functionality is truly important to your project, and now you’ve cleared some space to rewrite the test in a way that gets you closer to your ideal state.

A tidy test suite will improve your work relationships and your career

The purpose of overhauling your test code isn’t just to make it look pretty in your editor. Your goal is to create an environment that improves your team’s effectiveness.

You know your team and your project well enough to be able to do this in a way that aligns with the group’s tastes and working agreements. When you’re reading through your old tests, you’re also evaluating their purpose and usefulness to the project. Deleting tests that no longer serve a purpose — and writing improved tests in their place — can bring you and your fellow developers closer together.

Begin by sorting your tests. As you go, focus on finding tests that are still truly useful, instead of on rooting out tests that have worn out their welcome. Organize the good tests by category, closely examining each one line by line. Ask yourself, “Does this tell me what I need to know about the application? What is its purpose?”

For example, the WebDriver test which checks the logic of a component of a page through the browser that duplicates coverage provided by that component’s many unit tests. Let it go with gratitude, and move on.

In this way, tidying doesn’t have to be a cold, fruitless deletion of code. By investigating where your confidence in the application is being provided, you heighten your awareness of all aspects of the project, and of your teammates’ contributions.

This is where the power of tidying up your tests truly lies, much like mentoring and pair programming. Its lasting effects come from the practice of doing what is right for the application, for your team, and, ultimately, for your career.

Tidying up your old test code is a means of detoxing your work life.

By getting rid of and re-organizing your tests, you effectively get rid of the tech debt which has accumulated like dust over your system over time. Don’t be surprised if you start to actually enjoy sitting down at your desk every day as a result.

Put your tech debt in order to gain clarity about the codebase you want

Have you ever seen a test failure come up from a test that you love, that’s been rock solid since the day you implemented it? Tidying up your tests is more than just improving the state of your project: in the process of tidying, you can use the truly inspired tests you created in the past to help guide you into the future.

There are some automated tests that just bring us joy. Maybe they cover a complex requirement in an elegant way. Maybe they’re simple, reliable tests that dutifully cover some of the most important parts of your application.

It’s worth acknowledging the tests that make you recall what you love about being a test automation practitioner.

As you organize your old tests, start with the longest-running, flakiest tests that don’t cover anything too risky. Work your way to the end where you will deal with the cooler, more sentimental tests that make you feel like a testing genius.

Keep the tests that you remember saving your hide, that make you feel proud of your contributions to the project.

Just recall that even tests that are very elegant, or use novel methods that only a genius (you six months ago) could have written, sometimes need to be taken out of your practice. What do you do with these tests?

If you truly want to acknowledge their greatness before you bid them farewell, you can find new ways to honor these tests.

• You might write a blog post about what made the test so great.
• Run a learning session with your team to describe what the test did, how it worked, and how you will get the coverage that this test used to deliver going forward.
• Run the test one last time so it has a ceremonial standalone report in your test reporting portal history

Me, I like to print the test out and put it on a boat and have a little viking funeral for it. Do whatever suits you.

Create a healthy code culture by surrounding yourself with tests and documentation that make you happy

It may sound unbelievable, but tidying up your tests can have drastic effects, not just on your ability to take action, but on your team’s happiness. For many teams, taking control of their tests is the first step toward taking control of the entire project.

Strive for simplicity and visual order when rewriting tests. Consider how you feel whenever you debug or change an existing test in the test system that you’ve designed.

Linting and code style is a good place to start. As we develop more test code, we might diverge from old ways of doing things. Newlines, end-of-line delimiters, and code spacing may be different from file to file, or function to function, in your test code.

Settle on a single convention for your code and apply it universally.

It might help to divide and conquer. If you’re tidying up browser automation tests, start by organizing your page objects, then your test files, then move onto helper library files and config files.

Reshaping all this code may not change the outcome of the tests during runtime, but it affects the code’s readability, inviting collaborators to read it and change it confidently and joyfully.

You might find that organizing your code systematically doesn’t just improve your ability to read and change the code. In fact, it can also positively affect your disposition.

Many test practitioners got into coding from other careers. They could have started their professions as “manual testers” and taken on test automation as a learning project. It’s common to feel as if you’re surrounded by people who “really know how to code” and that the test code will never have a chance to truly be excellent.

I don’t buy it. In fact, it’s often quite the opposite — this negative internalization manifests itself in untidy code.

Anyone who can write working tests has to ability to tidy them up and organize them.

As an added benefit, the practice of tidying your tests will bolster your confidence and help you join the ranks of the impressive people around you. You can level up just by tidying up!

You only have to refactor once to make a lasting change in your project

It can be daunting to imagine maintaining a test suite that meets the high standards of the ideal system in your imagination. Won’t you be chasing tech debt for the rest of your life?

This is the wrong way to think about it. Rather, if you organize your tests and documentation so that the system provides maximum confidence and ease, you only ever have to do a comprehensive overhaul once in the project’s life.

This big change should be approached as a special event. It will be a crucial and dramatic change in the lifecycle of your application — a fresh start on your path to ideal test coverage.

It won’t be easy. You’ll need buy-in from product leadership and your peers on the development team. Depending on the size of your existing test codebase, you might spend days or weeks on this reorganization effort.

It is important to approach the existing canon of tests and documentation with the respect it deserves. Communicate with the code, and listen to each assertion’s case for relevance. If you show the tests that you care, they will respond.

Read over the test cases documented in your test case management system. Do these still reflect the coverage being guaranteed by your automated tests?

If your team conducts manual testing, do they follow the documented test cases? Are they aligned with the real requirements of your product?

Rewrite or discard documented test cases that no longer reflect the reality of your testing practices.

If it’s important enough to record your team’s testing process, the documentation can be replaced with newer, fresher prose.

Read your automated test code line by line.

If you get used to opening yourself to hearing the language of the tests as you read the code, you clarify your relationship with the tests and the application under test. Keep listening and you will gain an intuitive sense of which tests are still of use to you.

Though a massive test overhaul is a one-time assignment, your day-to-day relationship with your tests is likewise important. Pay attention to tests which flake out or take too long to run, and thank them for their efforts.

Inquire into the difficulties these tests are experiencing. You keep these tests online because of the confidence they provide and the ease of extensibility they promise. How can you find ways to keep those joyful conditions alive while attending to imperfect tests in your suite?

Though it may be hard, you’re going to have to let go of some really cool tests

The most difficult part of tidying up your tests could very well be throwing old tests away. It can be difficult to delete old code, even if you’re not getting much use out of it any more. After all, it took some effort to manifest that test into existence.

Thankfully, there are some tricks to make this removal process easier.

Start by determining the purpose of the test and decide whether that purpose is still being fulfilled. Was it written as the only check for some feature of your application which is now mature and comprehensively covered by other tests?

If you hesitate to answer, dive into other tests which might exercise the same feature tangentially or as a side effect, and find out. If the feature failed and this test did not exist, when would you find out about it? How?

Be clear about the purpose of each test. Be willing to get rid of tests that no longer serve a unique purpose. The reason you wrote a test was to make a specific part of your application easier to work with.

Would it be any less risky, or in fact safer, to work with the application if the test was gone? Is its purpose being fulfilled?

By cutting away or breaking up all the unnecessary tests, you’re creating your ideal programming environment and improving your team’s ability to work with the code.

In the end, this process can be extremely simple, though by no means easy. Investigate each test — each line of each test — and listen for its purpose as you read. If the test’s purpose is duplicated elsewhere, or the purpose no longer makes sense for your project, get rid of it.

You will dig deep. You will read corners of the code that you haven’t thought about in a long time. And, in the end, you will emerge with a tidy, healthy, extendable codebase that will bring confidence and joy to you and your team.