Anti-Patterns In Unit Testing

Test driven development (TDD) is a paradigm where test cases are written based on stories or requirements before any coding is started. It can be difficult to wrap your brain around the idea of writing tests first if you haven’t developed that way before. Sometimes you don’t know what you need to test until you’ve built it. The idea with TDD is to start with the basic business requirements for testing and build to the test, then if anything else needs to be testing because it came up in the development process tests for it can be created. Unit tests are test cases that are designed to test specific units of your code. Unit tests are code themselves and so require maintenance and have their own set of design patterns and anti-patterns. An anti-pattern is an observed pattern of behavior, typically repeated, that is ineffective at best and directly harmful at worst. Anti-patterns in unit tests are patterns seen throughout a test suite that may seem like a good way to do things but in effect cause more damage than good. This is far from a comprehensive list of anti-patterns you will find in unit tests. The ones listed here are some of the more common ones you’ll find. Check out the link to StackOverflow for a much larger list of patterns. Just like healthy design patterns, anti-patterns are not something that people set out to create but are patterns that are noticed over time and across developers and code. Use the ones listed here to help guide you when you are writing test code and so you know what to avoid or when you are working with someone else’s code so that you can easily recognize something that may need to be refactored. Episode Breakdown No structure when creating test cases. Test code is also code and should have a structure to it so that it can be easily read and altered if needed. Not having a structure to test code makes it hard to understand and maintain. A simple structure is to organize the code into the different stages of the testing process. Arrange, Act, Assert are the most common testing phases, though they could be in the Gherkin Given, When, Then or anything that breaks the test code into sections based on what is happening in the code. The Arrange, or Given, stage is used to initialize any variables and dependencies of the thing you are testing. This is where you set your mock data that is test specific. The Act, or When, stage calls the unit of code, method or function, you are actually testing. This is typically a very small section of the testing code, often a single line. The Assert, or Then, stage verifies that the unit of code called actually did what was expected. It checks the outputs and verifies that calls to mocked dependencies like repositories were made. There is too much setup to run the test cases. Tests require an excessive amount of setup just to be able to run. This may be in the Arrange stage of the individual tests or in a setup method that runs before the tests. There can be hundreds of lines of code in some cases where there is too much setup needed. This makes it almost impossible to understand what is being tested because of all the extra in the setup. Typically this occurs because of poor use of mocking or code that hasn’t been built with testing in mind resulting in the test being too tightly coupled to the implementation of the code. The result is that tests become brittle and unable to be maintained as any change to the code would require a massive rewrite of the setup for the test. Improper clean up after tests have been run. Most testing suites/frameworks will either have a clean up method that is run after each test or after all the tests have run. Your code in this method will remove objects from memory, close files, etc. Improper cleanup occurs when the code that cleans up the mocks and anything...