ember-cli-custom-assertions
ember-cli-custom-assertions copied to clipboard
In util tests, custom asserters are not curried with context.
So I've got a custom assertion. In an integration test I use it like this:
assert.foo('bar', 'baz');
But in a util test, I have to invoke my custom assertion like this:
assert.foo(null, 'bar', 'baz');
I assume that in util tests the custom assertion function is not being curried with context.
@lolmaus I wasn't sure how best to handle this case or how to work around it within unit tests. Ideally we could support both use cases without having the null
placeholder argument. I'm open to all ideas on how to get around this.
Only some custom assertions need access to the context. Have user explicitly pass the context when necessary.
Well all acceptance tests should make use of the context.
Even for stuff like assert.false(bool)
?
For example, I've just implemented an assert.almostEqual()
assertion for floats. Why would I want to pass a context into it?
Okay, I figured it out.
The official unit test example demonstrates this usage:
module('Unit | model | foo', {
beforeEach: function() {
assertionInjector();
},
});
It makes sense because unit tests have no application instance to pass.
But it results in an unwanted argument in ALL custom assertions that use arguments:
test("bar", function(assert) {
const model = this.subject();
assert.baz(null, model.bar()); // <- unwanted first argument
});
I dared to look into the subj's source and found ~~that the context argument is actually never used~~ this:
if (context) {
args.unshift(context);
}
https://github.com/dockyard/ember-cli-custom-assertions/blob/v0.0.4/test-support/assertions.js#L41-L43
So my issue can be resolved with:
module('Unit | model | foo', {
beforeEach: function() {
assertionInjector("just pass whatever arg here, it's not used anyway");
},
});
test("bar", function(assert) {
const model = this.subject();
assert.baz(model.bar()); // <-- yay, no unnecessary arguments!
});
I'll keep this open as a reminder to properly document the matter.
I'm not providing my own README edit as my previous edit was neither accepted nor given specific directions to make it acceptable.
Ah, sorry, I read unshift
as shift
.
I believe this nuisance can be resolved by reverting this commit: https://github.com/dockyard/ember-cli-custom-assertions/commit/5a5b3ebc88ad02131218faf4ffee7e1ce29be786#diff-2c881d7ac1eb00900cc9af8de52152aeL41
I. e. unshift unconditionally.
Why was the condition introduced in the first place?
What about integration tests? How would I use, for example, the contains assertion from the README in an integration test?
I figured it out: just pass this to assertionInjector
:
import { assertionInjector } from 'dummy/tests/assertions';
moduleForComponent('my-component', 'Integration | Component | my component', {
integration: true,
beforeEach() {
assertionInjector(this);
}
});
I assume the best practice would be to pass this
in ordinary unit tests as well.
@lastobelus thanks!