Filed under: Java, Public speaking, Selenium, Technical debt, Test automation, — Tags: 4 rules of simple design, Clean code — Thomas Sundberg — 2017-09-28
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.
Kent Beck suggested four, seemingly, simple rules in his book “Extreme Programming Explained: Embrace Change.” I’ve paraphrased them below:
The rules are really easy to write down but it takes a lot of practice to use them well.
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.
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.
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.
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.
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.
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.
This blog post was first published at TechBeacon.
I would like to thank Malin Ekholm for proof reading.
RSS