testing guide updates

source/testing/acceptance.md

@@ -188,8 +188,8 @@ export default Ember.Test.registerHelper(
     'shouldHaveElementWithCount',
     function(app, assert, selector, n, context) {
 
-    var el = findWithAssert(selector, context);
-    var count = el.length;
+    let el = findWithAssert(selector, context);
+    let count = el.length;
     assert.equal(n, count, 'found ' + count + ' times');
   }
 );
@@ -202,7 +202,7 @@ Here is an example of an async helper:
 ```tests/helpers/dblclick.js
 export default Ember.Test.registerAsyncHelper('dblclick',
   function(app, assert, selector, context) {
-    var $el = findWithAssert(selector, context);
+    let $el = findWithAssert(selector, context);
     Ember.run(function() {
       $el.dblclick();
     });
@@ -217,7 +217,7 @@ into one helper. For example:
 
 ```tests/helpers/add-contact.js
 export default Ember.Test.registerAsyncHelper('addContact',
-  function(app, assert, name, context) {
+  function(app, assert, name) {
     fillIn('#name', name);
     click('button.create');
   }

source/testing/testing-models.md

@@ -7,6 +7,9 @@ Let's assume we have a `Player` model that has `level` and `levelName`
 attributes. We want to call `levelUp()` to increment the `level` and assign a
 new `levelName` when the player reaches level 5.
 
+> You can follow along by generating your own model with `ember generate
+> model player`.
+
 ```app/models/player.js
 export default DS.Model.extend({
   level:     DS.attr('number', { defaultValue: 0 }),
@@ -25,9 +28,12 @@ Now let's create a test which will call `levelUp` on the player when they are
 level 4 to assert that the `levelName` changes. We will use `moduleForModel`:
 
 ```tests/unit/models/player-test.js
-moduleForModel('player');
+moduleForModel('player', 'Unit | Model | player', {
+  needs: []
+});
 
-test('levelUp', function(assert) {
+
+test('should increment level when told', function(assert) {
   // this.subject aliases the createRecord method on the model
   var player = this.subject({ level: 4 });
 
@@ -36,8 +42,8 @@ test('levelUp', function(assert) {
     player.levelUp();
   });
 
-  assert.equal(player.get('level'), 5);
-  assert.equal(player.get('levelName'), 'Professional');
+  assert.equal(player.get('level'), 5, 'level gets incremented');
+  assert.equal(player.get('levelName'), 'Professional', 'new level is called professional');
 });
 ```
 
@@ -48,6 +54,9 @@ declarations are setup properly.
 
 Assume that a `User` can own a `Profile`.
 
+> You can follow along by generating your own user and profile models with `ember
+> generate model user` and `ember generate model profile`
+
 ```app/models/profile.js
 export default DS.Model.extend({
 
@@ -64,17 +73,17 @@ Then you could test that the relationship is wired up correctly
 with this test.
 
 ```tests/unit/models/user-test.js
-moduleForModel('user', {
+moduleForModel('user', 'Unit | Model | user', {
   // Specify the other units that are required for this test.
   needs: ['model:profile']
 });
 
-test('profile relationship', function(assert) {
+test('should own a profile', function(assert) {
   var User = this.store().modelFor('user');
   var relationship = Ember.get(User, 'relationshipsByName').get('profile');
 
-  assert.equal(relationship.key, 'profile');
-  assert.equal(relationship.kind, 'belongsTo');
+  assert.equal(relationship.key, 'profile', 'has relationship with profile');
+  assert.equal(relationship.kind, 'belongsTo', 'kind of relationship is belongsTo');
 });
 ```
 

source/testing/testing-routes.md

@@ -12,6 +12,12 @@ our application. The alert function `displayAlert` should be put into the
 `ApplicationRoute` because all actions and events bubble up to it from 
 sub-routes and controllers.
 
+> By default Ember cli does not generate a file for its application route.  To
+> extend the behavior of the ember application route we will run the command
+> `ember generate route application`.  Ember CLI does however generate an application
+> template, so when asked whether we want to overwrite `app/templates/application.hbs`
+> we will answer 'n'.
+
 ```app/routes/application.js
 export default Ember.Route.extend({
   actions: {
@@ -26,8 +32,6 @@ export default Ember.Route.extend({
 });
 ```
 
-This is made possible by using `moduleFor`.
-
 In this route we've [separated our concerns](http://en.wikipedia.org/wiki/Separation_of_concerns):
 The action `displayAlert` contains the code that is called when the action is 
 received, and the private function `_displayAlert` performs the work. While not 
@@ -40,7 +44,7 @@ Here is an example of how to unit test this route:
 ```tests/unit/routes/application-test.js
 let originalAlert;
 
-moduleFor('route:application', {
+moduleFor('route:application', 'Unit | Route | application', {
   beforeEach() {
     originalAlert = window.alert; // store a reference to window.alert
   },
@@ -50,7 +54,7 @@ moduleFor('route:application', {
   }
 });
 
-test('Alert is called on displayAlert', function(assert) {
+test('should display an alert', function(assert) {
   assert.expect(2);
 
   // with moduleFor, the subject returns an instance of the route

source/testing/unit-testing-basics.md

@@ -11,6 +11,8 @@ common cases.
 
 ### Testing Computed Properties
 
+> You can follow along by generating your own model with `ember generate model some-thing`.
+
 Let's start by looking at an object that has a `computedFoo` computed property
 based on a `foo` property.