What are the types of bugs test-driven development is most effective at catching? [closed]

Closed开发者_运维知识库. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

How can the repetition of a very short development cycle help to remove bugs from your software? What bugs is TDD most effective in catching, when implemented correctly? And why?

Thanks in advance!

---

TDD forces you to think from the perspective of "consuming" the code you are going to write. This point of view helps to place you (the developer) into a position where you need to think about how your API will be structured as well as how you would verify the requirements of the implementation.

TDD helps identify defects in areas like:

• Requirements. Is it clear what the code will need to do. Is it possible to verify the invariants or end-effects of the code. Are the success criteria defined in the requirements or are they vague or absent.
• Ease of Use. Can you effectively use the code you plan on writing to achieve the kinds of things that are needed by end users, or by other code that it will integrate with in the future.
• Testability. Is the code verifiable based on the accessible data or objects in the design. Is it possible to confirm that things will function as they should.
• Edge Cases. It's often easier to identify and respond to edge cases by identifying their existance up-front. WHen edge cases crop up late in the game, there's an inclination to try to "force" the existing design to accomodate them, rather than rethinking the design.
• Exception Handling. When you start writing tests cases, you begin to realize areas where you may want to be able respond to errors or exceptional conditions. This can help plan your exception handling strategy, the kinds of exceptions to throw, what information to include, etc.

TDD also help to improve the level of coverage in tests because it brings testing to the foreground, rather than making it an "after the fact" activity. When testing happens last, it is most prone to be omitted or short-shrifted due to time and budget constraints, or due to the natural drop in enthusiasm and motivation on the part of the developer.

---

Design "bugs": if you're generally doing TDD, you naturally end up with a testable design. In turn, that tends to reduce coupling etc - leading to a code base which is simply easier to work with.

Also, I've found TDD can make it easier to think about corner cases in certain situations - but the design benefit is more important, IMO.

---

The null- or zero-valued parameter case is for me the bug most differentially caught by TDD. I tend to write my tests first with this case, just as a way of flushing out the API, without regard for the value: "Oh, just toss a null in there; we'll put a real value in the next test." So my method is initially written to handle that particular edge case, and repeatedly running that test (along with all the others) throughout the red-green-refactor process keeps that edge case working right. Before using TDD, I would forget about null or zero parameters fairly frequently; now, without really trying, they're handled as a natural consequence of the way I apply TDD.