Three Essential Tips for Writing Break-Resistant, Low-Maintenance Tests

If you’re in the test automation business then you know the importance of writing tests that last beyond a single testing life cycle.  Despite our best efforts, test scripts can break and will sometimes need maintenance - which is why this wasn’t titled “Three Essential Tips for Writing Break-Proof, No-Maintenance Tests”.  Not even the oiliest snake oil salesman could sell us on a magic testing pill that results in perfect tests, but there are measures we can take to reduce the chance of a test breaking as well as the frequency of maintenance.  Think of the following three tips as a short, handy checklist that you skim right before designing and writing test cases.


Finely Hone Test Scope and Verifications and/or Validations

Ask yourself:  What is the purpose of the test, and what exactly needs to be verified or validated?  The scope of a test case should be clear with a singular responsibility.  Fight against your desire to test all things at once and think “modular”, as a suite of test scripts with overlapping scope are inefficient and tests with broad scope are more likely to break down over time.  Ideally, you are either creating new tests or modifying exists tests while working from an organized, well-documented, and modular repository of test scripts.


Limit Dependencies

Test cases should be as independent as possible, in terms of reliance on other test cases and hardcoding in general.  The possible drawbacks of overly dependent test cases include:

  • When making test cases dependent on each other, you lose the flexibility to execute test cases individually or out of order
  • Executing a string of test scripts just as setup for one test slows down the entire process
  • You can’t always control when external inputs referenced in the test case change, and when this does occur it can result in broken tests
  • Debugging is trickier if a defects root cause actually stems from an entirely different test case
  • Maintaining a suite of overly dependent test cases is difficult

Sometimes we have to write tests with dependencies, this is especially unavoidable when integration testing, and in those instances put the dependencies outside of the main scenario in some kind of well-documented and organized header or setup file just before the test script executes.  This will make maintenance easier later when things change.


Readability Makes for Easier Maintenance

The more readable the test case, the more quickly whoever is handling maintenance can grasp what’s going on in order to make the necessary changes.  Modification becomes trickier if a lower level programming language is involved as it takes time to wrap your head around what someone else coded or, if you happen to be the author, reacquaint yourself with something made five versions ago.  If you’re not able to use a testing solution based on business readable English, then it is especially critical that key information is concisely documented; most importantly what is being tested, the purpose, and any related key inputs and outputs.

Interested in automating your testing and deploying with confidence? Contact Sales for a Cycle demo.

This post was written by:

James Prior
Technical Pre-Sales Consultant

James has been working in software pre-sales and implementation since 2000, and has more recently settled into focusing on technical pre-sales. He takes care of our hands-on demonstrations, and eagerly awaits your request to see our Cycle test automation software in action. Drop him a line at: james.prior[at]tryonsolutions[dot]com.

Recommended Content



Global Engineering Group Upgrades WMS with Tryon Solutions & Cycle

Global Engineering Group Upgrades WMS with Tryon Solutions & CycleOur customer is a global, high-technology engineering group founded in 1862. The company is a leader in tools and tooling systems for metal cutting; equipment, tools and services for the mining and...

Checklist: Deciding which Tests to Automate

Essential Checklist for Deciding Which Tests to Automate To automate or not to automate?That is the question a lot of test professionals ask themselves- when deciding what tests should be run by software and which ones are best performed by people?To help, we've come...

Cycle & Behavior Driven Development: How It Works Demo

What We Covered: High level explanation of Cycle as a behavior-driven test automation solution Overview of advantages including collaboration, lower maintenance, streamlining, and how Cycle is used to mitigate deployment risk Overview of Cycle interface, syntax, key...