Add test asserting no unnecessary inverse work

[asakusuma]

Ensures that if inverse: null, inverseFor is not called.

Test for #4225. Addresses #4236.

cc @krisselden @stefanpenner @pangratz

[asakusuma]

The test fails without the original PR commit. Still need to add a test to ensure inverse searching is not done if a specific relationship is indicated for the inverse.

[stefanpenner]

This test needs to assert the final state is as expected, the test as-is would pass if the input data was merely incorrect.

[asakusuma]

I feel like a "final state" test should be separate from the test added in this PR. The final state and avoiding unnecessary work are two distinct concerns/expectations.

Additionally, the relationship integration tests already assert final state of relationships where inverse is explicitly set to null. Is there some additional specific concern that we need to test here?

[stefanpenner]

sorta, so, this only tests that an explicit method for handling inverses is NOT called, but that isn't refactoring friendly. A more robust test would also include a scenario where the both the method is called and isn't called. That way the test would fail, if the mechanism of calculating inverses changed was refactored out. Which would hopefully force the refactorer to consider this scenario.

My suggestion should be a small addition to your existing tests, and would provide a high confidence regression test.

[asakusuma]

Ah, that makes sense. I'll update the PR.

[stefanpenner]

@asakusuma sorry, I was having a hard time trying to convey what i meant here Thanks for your patience.

[asakusuma]

@stefanpenner no problem, thanks for the guidance. I've updated the tests accordingly.

@krisselden @pangratz it's going to take some reworking in order to test that inverse resolution work is not done when inverse is explicitly set. findPossibleInverses is a local function and hence not exposed for spying. I believe this should be tackled in a separate PR.

EDIT: link to findPossibleInverses:

data/addon/-private/system/relationships/ext.js

Lines 246 to 263 in e5636f3

	//If inverse is specified manually, return the inverse
	if (options.inverse) {
	inverseName = options.inverse;
	inverse = Ember.get(inverseType, 'relationshipsByName').get(inverseName);
	assert("We found no inverse relationships by the name of '" + inverseName + "' on the '" + inverseType.modelName +
	"' model. This is most likely due to a missing attribute on your model definition.", !Ember.isNone(inverse));
	inverseKind = inverse.kind;
	} else {
	//No inverse was specified manually, we need to use a heuristic to guess one
	if (propertyMeta.type === propertyMeta.parentType.modelName) {
	warn(`Detected a reflexive relationship by the name of '${name}' without an inverse option. Look at http://emberjs.com/guides/models/defining-models/#toc_reflexive-relation for how to explicitly specify inverses.`, false, {
	id: 'ds.model.reflexive-relationship-without-inverse'
	});
	}
	var possibleRelationships = findPossibleInverses(this, inverseType);

[stefanpenner]

@asakusuma the updated tests look wonderful, thank you :)