Refreshing the page in an acceptance test

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);

here is the stub helper

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)

I’ve done something like this for verifying a payload

test('the data is submitted', function(assert) {'/contacts', function(db, request) {
    var json = JSON.parse(request.requestBody);
    assert.deepEqual(json, {your: 'json'});

  fillIn('input', 'Sam');

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.'/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');