How to access model in route test?

Testing
1

I just started to use ember. Right now I’m struggling with the following test. What I would like to test is, that takingPicture, wich is defined in the route model, is set back to false This is done in the route action ‘scan’ like this:

then((response) => {
   Ember.set(this.currentModel, 'takingPicture', false);
}).catch(error => {
   ........

The questions are: 1. Why must I mock the currentModel ? 2. How do I check the value of takingPicture and the end of the test ?

test('it responds to scan action', function(assert) {
  var route = this.subject({
      currentModel: {
        takingPicture: true
      },
      store:{
        find: function() {
          return {
              canTakePicture: true
          };
        }
      },
      barcode:{
        scan: function() {
            return new Ember.RSVP.Promise((resolve) =>
              resolve("123456"));
        }
      },
      mqtt:{
        publish: function() {
            return new Ember.RSVP.Promise((resolve) =>
              resolve("hallo"));
        }
      }
  });
  route.send("scan");
});
1 Like
2

In the past I was very “test small units / isolated tests provide value” …but over time I’ve found that when you start to refactor these mock heavy tests (like you show above) they begin to slow the team down instead of speed it up/protect it. My advice would be to write an ember-testing acceptance test that shows this from the POV of the end user.

For example:

I have something like this in one of my apps - when I first view the page and submit a form I get an error or success banner. When a user navigates away and returns to that form I expect it’s reset (ie- not showing error or success). Instead of mocking / stubbing out deps of the route and testing we “reset” a specific property on the controller/component I simply write a test that shows how my customer came across this defect in the wild.

These tests are not without tradeoffs themselves (more setup for full(er) stack validation) but not fighting through an army of mock heavy tests will empower the team to move ahead when things change (especially from 1.x to 2.x). You won’t care that you refactored from controllers to components because all the acceptance tests pass. The only ripple/breaking changes you should have are for conditional logic (the best fit for a true unit test).

I’m not saying “don’t write unit tests” but instead - if you find yourself writing a great deal of mock/stub setup you might ask yourself “is the juice worth the squeeze” (meaning -the test needs to provide more value than it costs to write it/ maintain it).

1 Like
3

Agreed, but at this point, since I’m still new to Ember, it would feel a bit like cheating, if I wrote integration tests just because I do not know how to write unit tests.

1 Like