anchor.diff:  :marked
     ## The _async_ function in _beforeEach_
   
  -  Notice the `async` call in the `beforeEach`. 
  +  Notice the `async` call in the `beforeEach`, made necessary by the asynchronous `TestBed.compileComponents` method.
     The `async` function arranges for the tester's code to run in a special _async test zone_
     that hides the mechanics of asynchronous execution, just as it does when passed to an [_it_ test)(#async).
   
   #compile-components
   :marked
     ## _compileComponents_ 
  -  In this example, `Testbed.compileComponents` compiles one component, the `DashboardComponent`. 
  +  In this example, `TestBed.compileComponents` compiles one component, the `DashboardComponent`. 
     It's the only declared component in this testing module.
   
     Tests later in this chapter have more declared components and some of them import application
     modules that declare yet more components.
     Some or all of these components could have external templates and css files.
  -  `TestBed.compileComponents` compiles them all asynchonously at one time.
  +  `TestBed.compileComponents` compiles them all asynchronously at one time.
     
     The `compileComponents` method returns a promise so you can perform additional tasks _after_ it finishes.
  +  The promise isn't needed here.
   
     ### _compileComponents_ closes configuration
  -  After `compileComponents` runs, the current `TestBed` instance is closed to further configuration.
  +  Calling `compileComponents` closes the current `TestBed` instance is further configuration.
     You cannot call any more `TestBed` configuration methods, not `configureTestModule` 
     nor any of the `override...` methods. The `TestBed` throws an error if you try.
   
  
positive.code:   The router seems particularly challenging.
  .l-sub-section
    :marked
      The [discussion below](#routed-component) covers testing components that requre the router.
  :marked
    The immediate goal is to test the `DashboardHeroComponent`, not the `DashboardComponent`, and there's no need
    to work hard unnecessarily. Let's try the second and third options.
  
negative.code:   there is no `done` function to call as there is in standard Jasmine asynchronous tests.
  
    Some functions called within a test (such as `fixture.whenStable`) continue to reveal their asynchronous behavior.
  .l-sub-section
    :marked
      The `fakeAsync` alternative, [covered below](#fake-async), removes this artifact and affords a more linear coding experience.
  
  #when-stable
  :marked
    ## _whenStable_
    The test must wait for the `getQuote` promise to resolve in the next turn of the JavaScript engine.
  
    This test has no direct access to the promise returned by the call to `testService.getQuote` 
    which is private and inaccessible inside `TwainComponent`.
  