A week ago I have decided to share my experience of the journey to the center of earth, sorry TDD world. You can find the first part here. Today I am sharing the misconceptions I have in the beginning. These misconceptions are still in the air
Table of Contents
Part 2 – Common Misconceptions
Once a developer told me that he/she used to do TDD on his last job. Few senior developers from a different team used to write all tests and passed to their team and they just write production code to pass those tests. I thought WOW!! how lucky he is! he has some experience with TDD. Now, I know how novice we were.
TDD is not just about writing tests before writing production code, TDD is to write just enough production code to pass a test and all other preceding tests
Beginner Misconceptions
Writing all or multiple Tests before start on coding
Please check the TDD Life cycle from previous post You can created your test list but do not write the full test. This should be done in small increments in which the developer must build up the functionality of the object under development.
TDD always ensures complete code coverage
If you want 100% or higher test coverage, TDD is not enough or not the right tool for you. Generally TDD provides higher test coverage but do not guarantee 100%. And also, many TDDers including me are not running after 100% test coverage.
TDD is a replacement of QA
No matter how good you are will TDD, still, need some extra pair of eyes before features go to production. It may change QA process a bit, but not a
TDD is too Time Consuming
Many developers or technical directors or managers still thinking the Business/Production team would never approve as it takes more time. Actually, following TDD helps you to save some iterations. Check
Rainer Hahnekamp’s post do things faster with Test-Driven Development
Test Driven Development is a nice to have not a must have
Test Driven Development is a nice to have not a must have and if you’re on a budget it can be cut – is totally wrong. And also, I have seen using TDD brings the smile on your customer’s face. In addition, good TDD also prevents building a system that difficult to use
TDD makes sure you don't need to do any up front design
When programmers know a little about TDD they may think that there is no need for architectural design, because TDD claims to evolve that from tests. But it’s not true. If you do not decide about design, you’ll stop using TDD by asking IS TDD DEAD
Startup Misconceptions
- No need to organize Tests code base – You must treat your tests code same as your production code
- Debug your test when you don’t understand your test – TDD should reduce your debugging time. If you need to debug to understand what are you testing please remove that test
- Write tests to test third-party code or invoke third party libraries in your tests – You should Mock third-party libraries, avoid invoking those in your unit tests
- Start with Integration Tests to do TDD – Nope, you should start with Acceptance test or Unit Test, not with
end-to-end test.
TDDer’s Misconceptions
- Multiple Asserts can be added to a single test — One test should have one assert with a proper failing reason and test name
- Single changes may cause changing multiple test setup — Can be avoided
- Don’t test properties — Property value testing is absolutely fine
if it is used in production code - A single class should have single test file — Not really, a complex class should have a folder with multiple test files
- Integration test and unit test for a system should stay in one project or module — Not necessarily, this will slow down your continuous test feedbacks. Time-consuming Integration test should be isolated to run only on your build agent
- Everything should be tested with unit tests — Nope, Acceptance, Integration or UI test can cover some part of your code that is not covered on your unit tests
This is not all, there are many more TDD misconceptions. Here, I just listed most commons one.
Next up we’ll write about different types of tests and their obligations.