use-ember-get-and-set and model relationships test

Consider this code in model unit test:

test('user relationship', function(assert) {
  const contact = this.store().modelFor('contact');
  const relationship = get(contact, 'relationshipsByName').get('user');
  assert.equal(relationship.key, 'user');
  assert.equal(relationship.kind, 'belongsTo');
});

This will throw an error because we’re not using Ember.get getter for the user property. But we can’t do it because relationshipsByName is an Ember.Map which has different get function.

My first idea was to add some optional settings to this rule where we would define particular preceding properties which shouldn’t throw an error.

I’m almost sure that this won’t be the only case, especially when we’re using some JQuery addons which can also have their own getters (for example pickadate.js).

WDYT?

[jonpitch]

I have a use case where I often override mirage routes in a test in order to simulate different API results. For example:

//  /mirage/config.js
this.get('some/route', function() {
  return { status: 'ok' };
});

// /tests/acceptance/some-test.js
test('i want to verify what happens when the api throws a 500', function(assert) {
  server.get('some/route', function() {
    return new Mirage.Response(500, { }, {
      errors: [{
        code: '500',
        title: 'run for your life'
      }]
    });
  });

  // assert things
});

Currently server.get throws a linting error. Has there been any discussion about a whitelist functionality or ignoring server.get entirely? This is listed in the Mirage docs. My current workaround is to:

const { get: GET } = server;
GET('some/route', ...);

[netes]

I think so 😃