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?
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)
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() {
Ember.run(this.application, 'destroy');
}
});
test('visiting index route should return a user', function(assert) {
var user = server.create('user',{first_name:'Jordan',last_name:'Riser'});
console.log(user);
visit('/'+user.short_url);
console.log(store);
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?
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
Acceptance Tests
Describes feature/shows bug from the end-users view point
The only place in the stack you normally mock ajax requests
Like selenium except the are executed in the runtime
Runs slowest of all tests in the stack
Integration Tests
Describes the expected behavior of a web component*
Pass data in, assert against the rendered html output
Verify the integration of web component and model
Runs quickly compared to acceptance/selenium tests
Unit Tests
Usually describes the expected behavior of single function/model
Setup your object with a given state/ assert behavior
Verify the lowest level behavior of any given object (or objects)
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
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).
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.
