“Did I do something good today?” – question I asked myself after a day of refactoring a long and repetitive test suite and ending up with TestSuite and TestSuiteOld. Was it a good time investment? Yes, I did spend more time than I planned working with this 2500+ lines monster, but looking at our goals next time we would change this component wouldn’t be soon. The old suite worked just fine and now we have two files, different styles and a day spent not on testing new features or working on items from automation backlog (I’m a Quality Engineer a.k.a. Software Developer in Test). Was it worth it?
Gut feeling told me – yes, it was. First of all, I (finally) learned how this component works. More important, I’ve lighted a guiding light for creating less testing debt – tests for this component are now easier to create: common code is moved to setUp and private methods, tests are on average 7-15 lines shorter and work with data providers.
Few weeks ahead (surprise!) we need to change this exact component. Today on retrospective my team members told me they were happy that I managed to write several good cases that caught issues. All thanks to refactoring, it was so easy to create those tests that I was surprised it was mentioned. All I had to think is what data to put in new data providers. For me real issue was why it was me who caught these issues, but that’s another story.
Test/check automation code should be treated same way as production code (1, 2) and should be clean. It wil give you shorter cycle time, less bugs and happier team. To stop creating technical debt “Stop Writing Crappy Code“, stop it right now and write it good this time. It will pay of rather soon.