Automated tests are part of the product. Let’s treat them like that!
In many teams we worked in, test code was treated much less carefully than production code. It was expected to just work. Mindless copy and paste of setup code from one test case to another was never seen problematic, duplications widely accepted, and things were named randomly. This always leads to problems: gaps in assertions become pretty non-obvious; consolidating long running test suites becomes a cumbersome task; magic numbers need to be changed all across the suite, when they become outdated.
All of this affects the overall maintainability of our code base. Over the years we identified several good practices to prevent these problems and keep test code maintainable. Some borrowed from general good code quality standards, some specific for test code.
In this workshop, we are going to briefly discuss the properties of good test code. Then we’ll present our good practices and let you apply these to a prepared test suite. Lastly you will discuss action items in your day job.