Coding Chica

Why am I putting emphasis on test driven development in so many of my posts?

No, test driven development is not a silver bullet.

• Creating tests requires careful consideration of edge cases and distinct scenarios that may be important for the logic in question (under the current implementation or a possible future one).
  • Code Coverage reports help, but they do not guarantee the quality of the tests, only that the line or branch of logic in question was exercised during the test.
• It takes time to write test, especially good ones.
  • Often the test classes will be larger than the runtime code itself.
  • Tests require maintenance and upkeep, just like runtime code.
  • Tests themselves need to be sufficiently isolated from other tests, so we can run them in parallel without race conditions / data collisions.
• Unit tests cannot find all bugs. Some behaviors will only be uncovered when classes or components work together.

However, there are benefits to testing as you go:

• Designs and code layout will more likely support unit testing, as the roadblocks are resolved as the code is being added.
• Likely to have high code coverage (without duplication) as we are adding tests for the logic we are about to add to the runtime code as we go.
• The TDD cycle of: 1) Write a failing test, 2) Make the test pass, 3) Refactor, is more likely to quickly uncover any test flakiness, rather than just testing at the end.
• As we have automated unit testing with high code coverage, we are better positioned to quickly and confidently refactor any methods during our TDD cycles or during peer reviews / subsequent testing / deployment troubleshooting.
• TDD should help developer productivity remain relatively constant, as the only tests we need to account for are those for code changes we are directly making and are therefore familiar with.

We are investing up-front, so that the team can reap the time savings and still deploy with confidence in the future. Maintenance costs should decrease. As we find bugs, we also add tests to cover those missed scenarios and create a contract with ourselves and future developers working on the code.

Some step-by-step TDD-based posts include: