Software Testing

[yanarchy]

Software Testing Anti-Patterns

Software Testing Anti-Pattern List

1. Having unit tests without integration tests
2. Having integration tests without unit tests
3. Having the wrong kind of tests
4. Testing the wrong functionality
5. Testing internal implementation
6. Paying excessive attention to test coverage
7. Having flaky or slow tests
8. Running tests manually
9. Treating test code as a second class citizen
10. Not converting production bugs to tests
11. Treating TDD as a religion
12. Writing tests without reading documentation first
13. Giving testing a bad reputation out of ignorance

Anti-Pattern 11 - Treating TDD as a religion - YAAASSSSSSSSSSSS Thank god.
TDD stands for Test Driven Development and like all methodologies before it, it is a good idea on paper until consultants try to convince a company that following TDD blindly is the only way forward. At the time or writing this trend is slowly dying but I decided to mention it here for completeness (as the enterprise world is especially suffering from this anti-pattern).

Broadly speaking when it comes to software tests:

you can write tests before the respective implementation code
you can write tests at the same time as the implementation code
you can write tests after the implementation code
you can write 0 tests (i.e. never) for the implementation code
One of the core tenets of TDD is always following option 1 (writing tests before the implementation code). Writing tests before the code is a good general practice but is certainly not always the best practice.

Writing tests before the implementation code implies that you are certain about your final API, which may or may not be the case. Maybe you have a clear specification document in front of you and thus know the exact signatures of the code methods that need to be implemented. But in other cases you might want to just experiment on something, do a quick spike and work towards a solution instead of a solution itself.

For a more practical example, it would be immature for a startup to follow blindly TDD. If you work in a startup company you might write code that will change so fast that TDD will not be a big help. You might even throw away code until you get it “right”. Writing tests after the implementation code, is a perfectly valid strategy in that case.