Integrate Ember resolver helpers
wbyoung opened this issue · comments
There's an open ticket on the ember-qunit project to split out the Ember stuff from the qunit stuff.
With that completed, it'd be great to integrate the moduleFor style helpers.
Let me know if I can help out with this in some way.
Sounds good. Thanks for taking the initiative. Let me know when it's ready, I'll try to find some free time to work on it.
Great. Based on briefly looking at the code for this module, I don't think it will be that hard to integrate.
I'd propose the following syntax:
// basic use
describe('controller:posts', function() {
});
// allow needs to be defined
describe('controller:comments', { needs: ['controller:posts'] }, function() {
});
// allow user to define their own description rather than forcing the use of resolver syntax
describe('Comments controller', 'controller:comments', { needs: ['controller:posts'] }, function() {
});
// custom description without options specifying needs
describe('Comments controller', 'controller:comments', function() {
});I think the above covers all permutations of what we would want to support.
I'm basing this off of some use with Rails and RSpec where the value used in describe was used to define the context for the test. If this feel too magical, we can do something more explicit like a testFor family of functions as were described over here.
I dislike the idea of having to associate the describe block with the subject since it's a bit more complicated than describing the name. I'm also not a fan of implicit subjects either.
What if we call describe like usual but add helper methods to build/create these contained objects?
describe('CommentsController', function() {
it("does comment things", function() {
buildController('comments', { needs: ['controller:posts'] });
});
});We could also extend that syntax into buildComponent, buildModel, and so on for the rest of the contained Ember objects.
@BlakeWilliams the proposed syntax would still allow describing with a custom subject allowing you to avoid the implicit subject. There are a few ways to be more explicit.
First, just use the long form version above where you actually specify the subject and the piece that needs to become the subject of the test:
describe('A comments controller', 'controller:comments', function() {
});Alternatively, use the implicit syntax, but nest it:
describe('A comments controller', function() {
describe('controller:comments', function() {
});
});The alternative, slightly more verbose approach would be to define a testFor family of functions. This is similar to what you're suggesting, but would cover all its that occur inside it. See the link in the original description for more details on that.
That combined with needs could cause some awfully long describe calls. I just feel like describe and the actual building of the object should be separated.
I'd much rather just build the object inside of each spec or make a helper method to build it for me in that spec if it has a complicated setup.
Thank you for your work on this - it will be great to have an easier way to create test subjects.
However, while moduleFor and friends are a great fit for the qunit API, perhaps such a faithful port of that API to mocha is not optimal? I have an RSpec/Rails background as well and I can see what you are aiming at with this syntax. While that feels natural in RSpec, it feels, well, a bit odd to me in a mocha context.
Also I'm not a fan of implicit subjects because subject is not a great name when you have enough specs that the top of the file (with the describe line that would explain what the subject is) is far away from the spec you are trying to understand.
I would like to +1 @BlakeWilliams preference of explicitly building up the object within the test (or beforeEach) - something along the lines of
describe('A controller of Foo', function() {
var fooController;
beforeEach(function () {
fooController = isolatedInstanceOf('controller:foo');
// I'm not in love with 'isolatedInstanceOf' name
// I'm sure something better can be found
});
// ... many lines ...
it('has a bar', function () {
expect(fooController.bar).to.exist;
});
});@wbyoung any updates with making ember-qunit framework agnostic?
I'd like to follow the same format as ember-qunit (describeComponent, describeModel.. etc)
Still waiting on emberjs/ember-qunit#22 and emberjs/ember-qunit#44.
I think there is no progress since few week (and who knows if something happend), but is there an option ton write a ember-qunit workaround via the new ember-cli-addon option?
To state it clear - write an interface allowing ember-mocha-adapter, run tests by utilizing the unit-test-helpers or will be there a completely different API (as stated few posts above) ?
Recently I saw another hard-rewrite of the standard Ember-Qunit API but this isn't probably sustainable.
Thx for any updates and suggestions.
@vire I think since there's a lot changing with Ember CLI, that there's not really too much incentive to prioritize getting emberjs/ember-qunit#22 and emberjs/ember-qunit#44 finished.
For now, if you're set on using Mocha, you may want to use containers directly to create unit tests, build up your own helper methods, or investigate what's going on with Ember CLI more (though I'm not very up to date on that).
For Ember CLI, please see https://github.com/jakecraige/ember-cli-qunit
and ember-cli/ember-cli#1295
CLI config looks pretty simple...
https://github.com/kristianmandrup/ember-cli-qunit/blob/master/index.js
But looks like the mocha adapter news a new shape in order to conform to this...
Hello! I am pretty new to using this. Has anyone been able to find a way to do this? I am trying to test my controller and I have done it with moduleFor when I had qunit setup, but now I am trying to do this with Mocha.
@danielmavila I plan to look into this but haven't found the time yet.
Looks like https://github.com/switchfly/ember-mocha accomplishes this 😄
@teddyzeenny is that a full replacement for ember-mocha-adapter? I'm assuming it's for use with the upcoming ember-cli.
@wbyoung this is instead of ember-qunit. It has ember-mocha-adapter as one of the dependencies.
@teddyzeenny thanks for the explanation.