To support ever shorter release cycles you need to automate testing, and to do that, you need to use a program that can verify your desired behavior. One option is to use tools that can record and replay a scenario, but those are a nightmare to maintain, and you'll probably end up writing the code needed for automating the tests yourself.
For automating the testing of a web application, Selenium is a better way. It takes some programming skills, however, and you must take care to ensure that your tests are easy to understand and maintainable.
Writing maintainable, easy to understand tests might seem hard, but not if you follow these four, simple rules of design.
Simple rules for simplified tests
Kent Beck suggested four, seemingly, simple rules in his book “Extreme Programming Explained: Embrace Change.” I’ve paraphrased them below:
- All tests must pass. The test you are writing always must pass.
- Express your intent. It must be very clear what we are verifying.
- No duplication. Duplication in code leads to lots of problems when you must change something. Updating in many places is hard.
- Keep it small. Your test system should be easy to understand. Reduce the cognitive burden on your users by not requiring them to remember a lot of details.
The rules are really easy to write down but it takes a lot of practice to use them well.
All tests must pass
The first rule, test pass, is relatively easy: Either a test passes or it doesn't. There’s not much to think about here. Just make sure that the test always passes, and you will be fine.
Express your intent
This rule is a bit harder. How do you express what you mean? Use simple words; don’t try to explain too much at the same time. Don’t assume that the reader has a lot of background. This is hard, and it’s even harder when you are in the middle of all of the details and everything seems perfectly clear to you.
One way to verify that the intent is easy to understand is to explain the solution to someone who has less knowledge about the details. If they have a hard time understanding what you mean, you have more work to do.
No duplication
This might seem easy. Spotting the same code in more than one place can be done using good tools. But you also need to spot duplication in concepts, and that’s more difficult.
Keep it small
This rule is partly a matter of opinion in that what is small to you may not be small to me. As a rule of thumb, every method should do one thing, and every class should do one thing. In this way, each will be focused and will usually stay rather small.
One nice property about these rules is that you can iterate over them. Follow them one at a time, and improve your code. Expressing intent may reveal duplication. Removing duplication may help you to express intent better.
Tests and technical debt
It is easy to accumulate technical debt in code. But technical debt associated with your tests is extra expensive because you use the test code to verify that you haven’t broken the system. If you understand, trust, and maintain your test, then you have a good chance to catch regressions early, perhaps even before you install the system in any test environment. The rules of design are essentially about repaying technical debt.
You can amortize technical debt by rewriting or refactoring the code, but rewriting is expensive and complicated. Refactoring is safer, as you can do it in many small steps while the system keeps running.
The only way to learn to refactor code by actually doing it. It is like swimming—you need to practice. Just reading a book about Archimedes' principle won’t make you a swimmer.
In my upcoming session at SeleniumConf, I will repay some of the technical dept by applying the rules in a live coding session, and I will make the code available on GitHub afterwards.
This means that you can read the code, you can read my commits and see the steps I took. It also means that you can start at the same starting point as I did and follow each step yourself as a way to practice and learn.
Follow the steps, iterate, and simplify your tests
Make sure all of your tests pass. Express your intent. Don’t duplicate. Keep your tests small. Following these four rules isn’t always easy, but if you do so you’ll create software that stands the test of time.
For more on these test automation rules and how I've used them in practice, see my talk at SeleniumConf Berlin. My presentation will be live-streamed, and available on YouTube following the conference as well.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
