In an ember-cli acceptance test I want to verify that the data in a form gets correctly transmitted to the backend server. So I am thinking that I should somehow “refresh the page” to see that my data submitted by a form is rendered as expected.
But what is the best way to achieve something like this in my test? Should I somehow restart the Ember application? Or unload my application’s store and then refresh the route?
Alternatively I guess I could query the backend directly from my test, but I would prefer to express everything through the front end Ember app.
I’m not sure this is what you’re asking but you may want to try something like ember-cli-mirage to fake your server responses when doing acceptance testing.
Actually I’m already using mirage to fake the server API.
My question though is really about the best way to verify in the test that the data created by the user gets correctly submitted to the backend (in essence that the models have been saved).
So my initial approach is that the acceptance test should work mainly through the UI layer and so the way to test this is to reload the app and make sure the modified data is reflected in the app.
Another option might be for my test code to examine the ember data models directly, I guess by grabbing a reference to the store
Or even to query the backend to see if the user edits have been submitted. In this case I could examine the mirage data structures through server.db
However, as I said above, these other approaches do not seem to me as clean as going through the app UI for the verification
Ah I think understand better, I’m not sure there is a clean way to do this since it would require controlling state on the server from your client tests. Personally I test the client interactions with fake api and the server interaction with server side tests and do the integration between the two manually. I haven’t encountered many bugs that aren’t covered by the two sides.
I don’t have an answer to the original “refresh” problem but we use a simple xhr stub that truly verifies the endpoint / payload / verb / etc
Here is one such example of how we use this. We submit a form during a click event on the page - we use a simple stub helper (just wraps fauxjax) to assert if the payload we submitted was actually the one my ajax code sent over the wire.
var response = {id: 1, name: 'baz'};
var request = JSON.stringify({id: 1, name: 'baz'});
stubEndpointForHttpRequest("/foo/bar", response, "POST", 201, request);
Next to ensure your test “fails” and gives you a reason why (ie- payload expected name “baz” but it was instead null) use my special xhr/fauxjax module instead of what qunit ships with out of the box
Now if your xhr matches (endpoint/ verb/ payload) the test is green (allowing you to assert what went over the wire/ and with what params). The module part is good to catch xhrs you stub’d but never fired (to let you know you don’t need to add that stub line). And finally it will also fail the test when an xhr is fired that you didn’t stub out (allowing for a legit tdd feedback loop like you expect/hope for)
With the new async / await pattern, I used the following:
test('the data is submitted', async function(assert) {
assert.expect(1); // This is to make sure the async function waits for the validation.
server.post('/contacts', function(db, request) {
var json = JSON.parse(request.requestBody);
assert.deepEqual(json, {your: 'json'});
});
await visit('/contacts')
await fillIn('input', 'Sam');
await click('button');
});