Have you ever inherited a test code that you felt wasn’t easy to comprehend? Or, have you worked for teams that demanded a rewrite of automation test codebase because they found the current one unmaintainable? Have you ever had to modify a lot of tests when a small product functionality changed? Have you had developers asking you to ignore failed tests because they didn’t trust it? Has debugging a failed test taken you a lot longer than it should have?
If you’ve answered yes to any of the questions above, you would realize that it gives an indication about the “quality of your tests”.
Today, many software engineering teams emphasize having quality production code which is readable, extensible, maintainable, etc. They put in place some good practices to keep their production code clean.
But, many of those teams do not treat the automated test code in the same way. “That’s just a test and it is working fine!” attitude is widely prevalent. Many teams do not focus on or push themselves to improve the code quality of their automated tests and it is one of the reasons automated tests become viewed as a liability in the long run.
In this talk, I wish to convey the following:
- What is clean code
- Why should our automated test code be clean
- Some examples of how we can write clean code
- How to refactor tests to improve its quality
- Some techniques and practices by which we can achieve clean and maintainable test code
Lavanya is a passionate software engineer with experience in software testing and software development. She cares deeply about shipping quality products. She looks forward to working with teams that encourage learning and value a culture of feedback.
She occasionally writes non-technical articles on her blog: https://bitweft.com/