Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I learned to do Test Driven Development (TDD), Dependency Injection (DI) and Inversion of Control (IoC) all at the same time. When I write code using TDD I always end up using DI in my class's constructors. I am wondering if this is because of how I learned to do TDD, or if this is a natural side-effect of TDD.
So my question is this: Does following TDD principals and writing unit tests that do not depend on external services inevitably lead to DI?
Does following TDD and writing unit tests that do not depend on databases or external services inevitably lead to DI?
For wide definitions of DI, yes. Classes do not exist in a vaccuum, so they need to have their dependencies filled somehow. Sometimes just providing a value is fine. Sometimes you need to provide a mock in the constructor. Sometimes via IoC containers. Sometimes via private test accessor. It's all injecting some test thing into the class so it can work in isolation.
For people who already know about DI, but just have never seen the point, I think unit testing will almost invariably lead to using DI.
If you don't know about DI and are trying to write unit tests, some people will naturally reinvent DI, some will get frustrated and eventually discover DI through research, but you'd be surprised how often it simply won't occur to someone that there might be a better way to architect their software to make unit testing easier. Those people write off unit testing as intractable and give up.
Unit testing will lead to DI (since it forces you to create loosely coupled units). TDD not necessarily, since TDD can also be used for creating tests layer-by-layer, instead of "verbatim" unit tests. See this article
http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx
for an explanation of the differences.
Yes and no: TDD leads to writing well-structured code, which itself leads to DI.
By that I mean TDD generally sends you the right way with regards to encapsulation, SRP and reusability. It's not just about getting some tests round your code: it's about using those tests to flesh out a better design. If an object creates its own dependencies, then it's living within a specific context within a specific application and is likely to be woven into the application to a greater degree. DI is a good thing, not just from a testing point of view, but also from a code quality point of view.
As already pointed out in other answers, TDD does not require unit tests. You can just as well write integration/functional tests while doing TDD. Of the several ways to apply TDD, creation of unit tests would be the "fake it till you make it" way (see the book by Kent Beck for details).
As for "TDD inevitably leads to DI", it definitely does not. What one needs when writing unit tests is to isolate the unit being tested from the implementations of its external dependencies. And this can be done just as easily with or without DI. The best way, probably, is to use a proper isolation/mocking tool.
