Continuing the discussion from Testing individual components is easy:
I’m creating a new topic because I realised the original topic was about components as in “parts of ember” and what I was talking about what “instances of Ember.Component”. Apologies everyone!
The crux of this is that I’m having a tricky time unit testing Ember.Component objects. It’s interesting to call it unit testing given that an Ember.Component has two kinds: 1. A template-only variety which if I understand it correctly creates an Ember.Component instance behind the scenes, and 2. A variety that has both a template and a explicitly instantiated Ember.Component object.
How can I test the functionality in each of those cases? Ordinarily, for simple cases, I’d just skip it, but the thing I’m currently working on is quite complex (it’s a kind of WYSIWYG editor, but it has its own model and deals with multiple objects). I’m really interested in doing TDD with Ember (I’ve been sold on TDD for quite a while). Chances are I’ve got an architectural issue which is perhaps why it’s so hard for me to unit test these things.
I guess I’m probably viewing things as a series of scoped isolated integration tests. I don’t generally see there as being much of an actual difference between an integration test and a unit test most of the time - it’s just a matter of where you draw the lines in the sand.
Basically, I’d like to test the functionality of this Ember Component that I’ve built, but can’t seem to work out how to do so as an isolated unit.
One other thing is, could we possibly consider putting testing into the documentation around all of the code examples? I reckon that’d provide us all with an excellent resource in two ways: 1. It’d build a library of user-centric tests (Users of Ember, I mean - ie Programmers as consumers of Ember’s API), but 2. It’d also provide a massive pedagogical resource, making the possible uptake of ember much faster.