Get current model data in acceptance test

I am trying to access the model being returned after visiting a url in an acceptance test.

I am not outputting any of it to a template since I will be taking some of it and storing it to local storage using an addon. So I can’t using find() to find an element on the page and check it’s contents to determine if what I want is being returned.

I started a stack overflow here

But haven’t received an answer that helps explain how to do this. I could really use some help as this is sort of blocking me from continuing (unless I drop trying to follow TDD)

So far I have tried a few things, and in the stack overflow I have tried this

test('Returns a user', function(assert) {
  // Generate a user
  var user = server.create('user',{first_name: 'Jordan'});
  // Visit the index page with the users short_url
  visit('/' + user.short_url);
  var route = this.application.__container__.lookup('route:index');

  // Assert that the model the user we created by checking the first name we passed in
  assert.equal(route.model.first_name,'Jordan','Model returns user with first name Jordan');

But I can’t seem to get the model from that container lookup.

Can someone help me understand how I would do this?

You would usually reach into the cache/store directly (ember-data or otherwise). Here is one such example

module('Acceptance: My Feature Here', {
    beforeEach: function() {
        application = startApp();
        store = application.__container__.lookup('store:main');
    afterEach: function() {, 'destroy');

Another quick note -depending on what you have planned this may/may not be the ideal place to look at the model. I showed the example above to give the “how” but w/ more context you mind find this better at the integration or unit level. If you think this is a great fit keep at it, but a good rule of thumb is “acceptance testing is a black box simulation from the product owner/ or end users point of view” (free and clear of implementation detail like this).

That said, I often reach into the store for specifics at times because it helps tell the “story” of the test/ or show the production bug (another good fit for acceptance testing at times) :smile:

I will try this, thanks.

Is there somewhere the differences in tests are defined? I know they may not be set in stone and can be a little flexible but I guess I don’t really know the separation in logic that each test should follow.

So I wrote my acceptance test (also I’m still using ember cli 1.13.7 so I don’t have integration tests yet) but I’m having trouble getting the info I’m looking for from the store.

I has this

import Ember from 'ember';
import { module, test } from 'qunit';
import startApp from 'bidr/tests/helpers/start-app';

var store;

module('Acceptance | index route', {
  beforeEach: function() {
    this.application = startApp();
    store = this.application.__container__.lookup('store:main');

  afterEach: function() {, 'destroy');

test('visiting index route should return a user', function(assert) {
  var user = server.create('user',{first_name:'Jordan',last_name:'Riser'});
  assert.equal(store.get('name'), 'Jordan Riser');

The store is a class when I log it, how do I get the data out of it that was set?

It all depends on the store you are using -if ember-data what version do you have in your app?

Ember data is 1.13.7 in the app I’m currently working on.

Honestly I’m not sure what that api looks like but I’m willing to bet it has something like a “find” or “peek” you could use. In my simple-store I would simply crack it open by using the find api

store.find(‘user’, 1);

About testing and what to use/when … this seems like something everyone (eventually) defines from their own experience but if you want my opinion on the subject :smile:

Acceptance Tests

  1. Describes feature/shows bug from the end-users view point
  2. The only place in the stack you normally mock ajax requests
  3. Like selenium except the are executed in the runtime
  4. Runs slowest of all tests in the stack

Integration Tests

  1. Describes the expected behavior of a web component*
  2. Pass data in, assert against the rendered html output
  3. Verify the integration of web component and model
  4. Runs quickly compared to acceptance/selenium tests

Unit Tests

  1. Usually describes the expected behavior of single function/model
  2. Setup your object with a given state/ assert behavior
  3. Verify the lowest level behavior of any given object (or objects)
  4. Runs faster than any test as you only touch one object**

*I realize integration tests can be used for something other than web components in ember but I often find they are “most commonly used” for this purpose (please forgive any over generalization above)

**often unit testing is described as “only one function/method/class” but a better description (when you use tdd as a development tool) is it’s the lowest level test you can write as you decompose a problem (meaning it can be a single model/ but often it can show how 2 different models work together for relationships (like hasMany/ belongsTo)

I will keep these in mind thank you for the opinion.

As far as the test at hand goes, I seem to be getting somewhere to some degree, but now the assertion is failing because it’s receiving undefined instead of what I expect.

I put the repo on github with the test in question if it helps you understand the other working parts

I’m using ember-cli-mirage to mock the API and just the standard RESTAdapter to connect to it with ember-data

I don’t use mirage or ember-data day-to-day but when I opened the app I can see the error coming from your mirage config.

It looks like db.items is undefined (the reason for the stacktrace shown below). Can you take it from here? If not you might ping Sam in the #testing channel on slack (he is super helpful/ knows this inside and out).

You could also use ember-data-factory-guy, which is made for just such an issue: this way:

or even easier you could do:

user = make('user');

Man I hate to throw another library in here just to test a different library though, but that sort of looks like what I am wanting. I just don’t understand why this test seems to be making my life so difficult right now. I’m tracking down that error right now on a github issue, since that where() function works in development mode just seems to be yelling at me in testing for some reason.