Was sind die häufigsten Missverständnisse über testgetriebene Entwicklung?

The "TDD is too slow" is the most popular misconception. 4 reasons why: 1. Developers don't like to write automated tests in general. Writing tests obviously takes more time than skipping them. 2. TDD requires a learning leap. It's a mindset switch, and changing habits takes time. 3. Time-to-gratification extends with TDD. Currently, an individual hit it right after hacking the solution and a quick manual check (e.g., clicking around). With TDD, it takes a bit more time since we build the software in baby steps against gradually evolving tests. 4. Technical/creative people don't think long-term. Therefore, "fast" means the feature is delivered ASAP and somehow works. Fixing bugs is a usual process that nobody relates to being "slow".

This is not a misconception. TDD adds software modules (the tests) that have tight coupling to the code (if the coupling is not tight, then the tests are only superficial). I have had clients where this doubles the architectural footprint of the code base. That of course includes tests but it's a fool's game to believe that you don't have to maintain those, too. Both of these slow you down. Because it is based on local incremental changes, TDD leads to local optimizations. In the long term that leads either to major rework or to increased discovery and maintenance costs. Again, this is an empirical finding from several of my clients. The problem is so bad that I have had 2 clients engage me just to help convert them from TDD to BDD.

Test-Driven Development is often seen as complex, costly, and suited only for tech giants. This misconception overlooks TDD's adaptability across organizations of all sizes. The key to successful TDD implementation lies in making its benefits visible to developers, ensuring accessibility to supportive tools, and integrating TDD seamlessly with existing workflows. TDD tools and best practices must be standardized and supported across organization and integrated with existing build, deployment tools. When standardized practices are adopted, TDD enhances code quality, reduces bugs, and streamlines development processes. Far from being prohibitive, TDD is a valuable methodology that, when properly leveraged, can significantly boost efficiency

Indeed, while objections to Test-Driven Development (TDD) often focus on the perceived time and effort required upfront, it's essential to consider the long-term advantages. By writing tests first, developers can prevent issues from arising later in the development cycle, saving time on debugging, fixing, and rewriting code. Early error detection and bug prevention mitigate risks and costs associated with addressing issues later in the process. Additionally, TDD fosters confidence in code refactoring and improvement, as tests ensure the correctness and functionality of the codebase. Ultimately, TDD can lead to accelerated development and reduced technical debt over time.

In my experience having TDD means that the application is thoroughly tested and bug-free is one of the biggest misconceptions and in reality, we can not predict 100% that code after satisfying all the tests will be bug-free. Instead, Along with TDD, we should keep an eye on the code review and acceptance criteria to have full coverage of the code. TDD is slow and best for small or large organizations this also rolled out in my mind when we were implementing the TDD but with experience now I can say that this is also a misconception since TDD is the safety criteria and act as a safety layer for your fast-paced development.

The most common misconception is that it is a testing technique. It is not: it is a technique that supports emergent design. From that perspective, the designs that emerge from TDD are bottom-up design. One exercises TDD by writing tests and then writing the code — it is only methods that can be tested, so this approach focuses the design on the methods rather than the whole. One can find several results that support this finding in the research literature. The result is that the coupling and cohesion metrics suffer. This is not something that can be fixed by adding other approaches: using TDD as your architecture discovery tool leads to fatally flimsy and tangled architectures. Again, this is empirical, researched. and published.

From my experience, I found nothing is enough when it's about testing and making sure the quality of the product we are building. Even a combination of different types of test (integration tests, functional tests, end to end tests). In addition to writing different types of tests to ensure quality product, we need to ensure the quality of our tests as well. There are a number of potential reasons. 1. Developers generally do not tend to test their own code. Some folks do but possibly don't test failures. 2. There are ways to deceive the coverage tools by writing unnecessary test cases or excluding specific classes from code coverage. I would recommend mutation tests in the automation process to find out the quality of the tests.

TDD does not replace thinking. Compare it to any other tool in life. Using a specific type of hammer will not make you a carpenter overnight. It will not ensure that you are able to build that wardrobe you set out to build. Using your tools well is an important aspect of accomplishing your goals, but even expert craftsmanship will not remedy a faulty blueprint. It is the same in software development: following a misguided idea using a rigorous TDD approach will ensure that your code looks and acts the way you designed it in your mind. Nothing more, nothing less. Make a bad judgement call, misalign your contracts design, or forget to encapsulate your concepts, and your code will still be lackluster.

ATDD/BDD/TDD only address 1/2 of the testing quadrant. You still need all the non-functional/quality attribute/usability/exploratory tests. ATDD/BDD/TDD is necessary, but not sufficient for a quality product.

Well written tests are generic enough to test for accuracy of meeting the acceptance criteria, without being specific to the code.

ATDD/BDD is not rigid. Of course, it demands that you understand the desired behavior of the system before you write code. But why wouldn't you want to know that? Unclear requirements are a #1 complaint of developers.

My biggest misconception was that TDD meant writing a test for each and every function. This didn't make sense, so I abandoned the whole concept and wrote E2E tests instead. But I've realized that TDD is about testing behavior, not individual functions. It aims to test all behaviors with the minimum number of tests needed, allowing code refactoring without breaking tests. This understanding has reshaped my approach to TDD.

SRP and the test pyramid are not TDD concepts, they are general software design and testing approach principles respectively. TDD in itself is simple. Write your tests first, think about your code's interactions to the outside world, work iteratively. Make it work, make it clean, make it fast, repeat. TDD being a simple process does not mean it is easy. As outlined above in the "TDD is enough" misconception: it will not solve all of your challenges for you. You still need to be well-versed and competent in software development. Replace "TDD" with "writing tests" and most of this section would hold true. This section would be a lot more accurate if it started with: "TDD is a simple technique, but writing good tests is not easy."

I would remove this section altogether, and replace it with "TDD and Unit Testing are the same thing". This entire block discusses situations in which the nature of the project or the codebase makes it difficult to write tests. While "being able to write automated tests" is a precondition for practicing TDD, the arguments are not TDD specific. This is akin to saying: "Wearing a seat-belt is not universally applicable, because in some situations it is very difficult to drive a car."

ATDD/BDD is harder to automate for legacy code, but it is still applicable. You can come up with ATDD/BDD scenarios for UI, graphics, AI, and other areas. They may be more difficult to automate, but the behavior can be described. For example, Given a system has been trained to recognize images of dogs When the system is given 1000 new images Then the system correctly identifies 999 or more

Instead of TDD, consider using assertions in your code. When I review TDD code, or go to a TDD tutorial, I find that most of the tests are just assertions that have been remoted out of the code. Leave them in the code. Use administrative mechanisms to turn them off when you ship — or direct them to invoke code that notifies you of a bug. Consider a development cycle driven by system tests. Derive those from your use cases. Start a "walking skeleton" architecture with abstract base classes that are meagerly filled in. Then code up the test for a use case, and elaborate your code to support the use case. Use the test to drive development.

I find TDD to be helpful when i really don’t know what to do. Thinking about “what is the smallest part of this problem i could test.” Has been very helpful to me at moving forward and discovering the best implementation.

One very persistent misconception of TDD is that it drives or should drive the design of your application, that it eliminates the need for some minimal upfront design. The 'design of your application' actually has multiple aspects. TDD should not drive the decisions of how to separate concerns, which code units to create or not or how these code units should be depending on each other. TDD can have a positive impact however with the design of the 'interfaces' of code units and components. TDD can expose some code units that are too tightly coupled, but I would say that is about the extent of TDD in the context of the design of your application.

“TDD is the only way, or the only correct/best way.” Often when working with code, you are not sure what you want. You often have to iteratively arrive at a solution, that you yourself didn't know you wanted prior to reaching it. If you know what you want to build, as in you know the set of features required, and have a basic idea of how you're going to develop them, then TDD is a great choice. But if you're not sure, then perhaps consider other things before TDD.

TDD is not a synonym for "unit testing". Throughout this article, this seems to be the most deeply rooted misconception, although it is not mentioned as one of the most commonly held incorrect beliefs. Test Driven Development, is the act of writing your test code before writing your implementation, and doing so in an iterative manner. Unit testing is the practice of writing fast, isolated, and specific test cases that assert the correctness of your code. These terms are very different, though they are often used interchangeably (even in this article, for that matter). A test-last approach will get you many of the benefits mentioned in this article.