move the DI stuff

Author: jackfranklin

docs/content/guide/unit-testing.ngdoc

@@ -36,149 +36,13 @@ We tried to make the right thing easy, but if you ignore these guidelines you ma
 untestable application.
 
 ## Dependency Injection
-There are several ways in which you can get a hold of a dependency. You can:
-1. Create it using the `new` operator.
-2. Look for it in a well-known place, also known as a global singleton.
-3. Ask a registry (also known as service registry) for it. (But how do you get a hold of
-the registry? Most likely by looking it up in a well known place. See #2.)
-4. Expect it to be handed to you.
 
-Out of the four options in the list above, only the last one is testable. Let's look at why:
+Angular comes with {@link di dependency injection} built-in, which makes testing components much
+easier, because you can pass in a component's dependencies and stub or mock them as you wish.
 
-### Using the `new` operator
-
-While there is nothing wrong with the `new` operator fundamentally, a problem arises when calling `new`
-on a constructor. This permanently binds the call site to the type. For example, let's say that we try to
-instantiate an `XHR` that will retrieve data from the server.
-
-```js
-function MyClass() {
-  this.doWork = function() {
-    var xhr = new XHR();
-    xhr.open(method, url, true);
-    xhr.onreadystatechange = function() {...}
-    xhr.send();
-  }
-}
-```
-
-A problem surfaces in tests when we would like to instantiate a `MockXHR` that would
-allow us to return fake data and simulate network failures. By calling `new XHR()` we are
-permanently bound to the actual XHR and there is no way to replace it. Yes, we could monkey
-patch, but that is a bad idea for many reasons which are outside the scope of this document.
-
-Here's an example of how the class above becomes hard to test when resorting to monkey patching:
-
-```js
-var oldXHR = XHR;
-XHR = function MockXHR() {};
-var myClass = new MyClass();
-myClass.doWork();
-// assert that MockXHR got called with the right arguments
-XHR = oldXHR; // if you forget this bad things will happen
-```
-
-
-### Global look-up:
-Another way to approach the problem is to look for the service in a well-known location.
-
-```js
-function MyClass() {
-  this.doWork = function() {
-    global.xhr({
-      method:'...',
-      url:'...',
-      complete:function(response){ ... }
-    })
-  }
-}
-```
-
-While no new dependency instance is created, it is fundamentally the same as `new` in
-that no way exists to intercept the call to `global.xhr` for testing purposes, other than
-through monkey patching. The basic issue for testing is that a global variable needs to be mutated in
-order to replace it with call to a mock method. For further explanation of why this is bad see: [Brittle Global
-State & Singletons](http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/)
-
-The class above is hard to test since we have to change the global state:
-
-```js
-var oldXHR = global.xhr;
-global.xhr = function mockXHR() {};
-var myClass = new MyClass();
-myClass.doWork();
-// assert that mockXHR got called with the right arguments
-global.xhr = oldXHR; // if you forget this bad things will happen
-```
-
-
-### Service Registry:
-
-It may seem that this can be solved by having a registry of all the services and then
-having the tests replace the services as needed.
-
-```js
-function MyClass() {
-  var serviceRegistry = ????;
-  this.doWork = function() {
-    var xhr = serviceRegistry.get('xhr');
-    xhr({
-      method:'...',
-      url:'...',
-      complete:function(response){ ... }
-    })
-}
-```
-
-However, where does the serviceRegistry come from? If it is:
-* `new`-ed up, the test has no chance to reset the services for testing.
-* a global look-up then the service returned is global as well (but resetting is easier, since
-only one global variable exists to be reset).
-
-The class above is hard to test since we have to change the global state:
-
-```js
-var oldServiceLocator = global.serviceLocator;
-global.serviceLocator.set('xhr', function mockXHR() {});
-var myClass = new MyClass();
-myClass.doWork();
-// assert that mockXHR got called with the right arguments
-global.serviceLocator = oldServiceLocator; // if you forget this bad things will happen
-```
-
-
-### Passing in Dependencies:
-Last, the dependency can be passed in.
-
-```js
-function MyClass(xhr) {
-  this.doWork = function() {
-    xhr({
-      method:'...',
-      url:'...',
-      complete:function(response){ ... }
-    })
-}
-```
-
-This is the preferred method since the code makes no assumptions about the origin of `xhr` and cares
-instead about whoever created the class  responsible for passing it in. Since the creator of the
-class should be different code than the user of the class, it separates the responsibility of
-creation from the logic. This is dependency-injection in a nutshell.
-
-The class above is testable, since in the test we can write:
-
-```js
-function xhrMock(args) {...}
-var myClass = new MyClass(xhrMock);
-myClass.doWork();
-// assert that xhrMock got called with the right arguments
-```
-
-Notice that no global variables were harmed in the writing of this test.
-
-Angular comes with {@link di dependency injection} built-in, making the right thing
-easy to do, but you still need to do it if you wish to take advantage of the testability story.
+Components that have their dependencies injected allow them to be easily mocked on a test by
+test basis, without having to mess with any global variables that could inadvertently affect
+another test.
 
 ## Additional tools for testing Angular applications