This question already has an answer here:

Is it recommended that TDD be always practiced in a project, or are there cases when it should be avoided?

Should we all adopt TDD?

Is it standard practice in major software companies?

marked as duplicate by Doc Brown, gnat, BЈовић, Bart van Ingen Schenau, GlenH7 Apr 4 '14 at 13:35

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

up vote 8 down vote accepted

Factors Limiting Industrial Adoption of Test Driven Development, a research paper from 2011, reviewed 9,462 papers on TDD, and included 48 studies as a basis for their research. The paper covers the topic of why TDD may not be used in depth, but for ease of reference, here's a summary:

  • Development time: Development time could be considered a business-critical factor for adopting new practices within an organization. Depending on the maturity of the organization, an up-front loss (in this case, increased development time) might overshadow a long-term gain (e.g., decreased overall project time, or increased product quality – both of which were reported in many of our included studies). Hence, internal organizational pressure might risk the proper usage of TDD.
  • Experience/knowledge: When observing collected data from the included primary studies, we noticed that participants in the experiments (either students or professionals) were mostly provided with some training or tutorial on how to perform TDD. In several cases, the knowledge improved as participants would progress with the experiment. We expect that lack of knowledge or experience with TDD could create problems in its adoption.
  • Design: There is no massive empirical support that the lack of design should be considered as a limiting factor for industrial adoption of TDD. However, there are a handful of studies reporting problems regarding lack of design in TDD, particularly in the development of larger, more complex systems. Moreover, the lack of upfront design has been one of the main criticisms of TDD since its introduction and even if the evidence supporting this criticism is sparse, so is the evidence contradicting it.
  • Skill in testing: Since TDD is a design technique where the developer undertakes development by first creating testcases and then writes code that makes the test cases pass, it relies on the ability of the developer to produce sufficiently good test cases. Additionally, one study reports on the risk it brings to adopt TDD without having adequate testing skills and knowledge. We find it interesting that there are no explicit investigations of the quality of test cases produced by developers in TDD.
  • TDD adherence: The combined view of five industrial case studies state that the inclusion of the lack of TDD adherence as a limiting factor. Basically, the studies state that (1) it is important to adhere to the TDD protocol, and (2) developers do stray from the protocol in several situations. It is however far from certain that there is a clean-cut cause-effect relationship between low TDD adherence and low quality. Not unlikely, confounding factors (e.g., tight development deadlines) might lead to both low TDD adherence and poor quality
  • Domain and tool specific issues: Proper tool support for test automation is vital for the successful adoption of TDD. With the wide variety of studies reporting domain- and tool-specific issues as a limiting factor in the adoption of TDD, the factor would be difficult to ignore.
  • Legacy code: TDD, in its original form, does not discuss how to handle legacy code. Instead, the method seems to assume that all code is developed from scratch, using TDD as the development method. As this is seldom the case in large development organization, adoption of TDD might be problematic. A lack of automated regression suites for legacy code hampers the flexibility provided by the quick feedback on changes provided by the regression suites, and may leave developers more anxious about how new changes may unexpectedly affect existing code.
  • The automatic assumption seems to be that TDD can't be applied in any shape or form to brown field developments which simply isn't the case. – Robbie Dee Apr 4 '14 at 10:41

I think it all comes down to a simple question: Does it have to work? If it does, then I would say it is best to do TDD, on the majority of cases.

To me, the exceptions are very lightweight pieces of code. Weight the effort of manually testing every single procedural branch in the code. If this effort is smaller than that of writing automated tests, then I'd say it wouldn't be a problem to not do TDD. By the way, if you have to run the manual tests more than once, that effort is multiplied.

So, if we think about it, there's hardly any useful kind of software to which the effort of manually testing (multiple times) would be lower than writing automated tests. I can only think of small proof-of-concepts and demonstration code, but even then I'd prefer to practice TDD, because such prototypical code may grow to become full functioning software.

Now, as for TDD as official practice in major companies, I can only answer based on the company I work for, and no, it isn't. There are companies that require unit tests to be written by the end of an iteration, with an "acceptable" range of code coverage, but that is completely different to practicing TDD.

In any case, we, as software developers, professionals, have to decide whether or not to practice TDD, not our contractors.

  • Is "writing the test first" the standard in major software companies? – Joel Apr 4 '14 at 0:53
  • Edited to include your last question. – MichelHenrich Apr 4 '14 at 1:47

Some cases I can think of when one might not want to to TDD are:

  • minor changes to old systems that have no tests.
  • minor changes to old systems that have no test framework.
  • design and development of visual items and effects.
  • tight deadlines and a disinclination to produce quality work.

TDD shouldn't be used when some alternative approach is more appropriate. The key thing to remember is that the alternative approaches aren't so much manual testing, as things like:

  • Write and review a detailed design document
  • Produce a complete design in a CASE tool, press the 'generate code' button.
  • Create a set of unit tested reusable components, assemble a solution from them
  • Express the problem in terms of mathematics, create a provably-correct solution
  • Define a custom language in which it is easy to express the solution
  • Write code that makes the monkey dance, hit refresh.

Automated testing being especially difficult for some reason is one factor that might guide the choice of design method. But it is far from the key factor; in fact several of the other approaches will end up doing as much, or more, automated testing than TDD.

One thing I learned about dealing with legacy code which I did this for medium and big projects with > 1 million lines of code, it makes sense to use TDD here as well. But it is much harder to get your code there in tests.

Normally legacy code bases doen't have any tests in place so fixing a bug and writing a unit test for it is a good starting point to get some. But normally you have to refactor the code a little bit before you can write these tests. There is a really good book out where you can learn a lot about TDD with legacy code ( breaking dependencies, how to write the first test and so on ) :

  • mio - what's that? – Robbie Dee Apr 4 '14 at 10:30
  • Lines of code, I just changed it. – KimKulling Apr 4 '14 at 11:03
  • It still remains... – Robbie Dee Apr 4 '14 at 11:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.