Testing individual components is easy

Testing
1

because of dependency injection, loading up your app in a clean state and testing individual components (models, views and controllers) is easy - @tom via Migrating from Ember.js to AngularJS | Hacker News

I think @tom is right. Seems like most people (me included) are focused on how to do integration tests. For sure we need integration/acceptance testing, and the work @ebryn is doing on ember-testing looks awesome, but i don’t think that’s enough. I don’t buy the integration-testing-instead argument. Seems like a cop-out. I can see making that choice for an individual project but as a community we should be defining best-practices that include both integration and unit tests.

So, if testing components is so easy, why are so few of us doing it?

Does anyone have examples they can share re: unit tests for ember-components?

I’ll try to collect some best practices and assemble them into a guide.

2

Since Ember does most of the work for you and you don’t want to write tests that are testing the framework.

Unit testing models, views, and controllers is quite easy from my experience. It was the integration tests that were hard.

Can you provide more details about what exactly you’re finding difficult to unit test?

3

Totally agreed. No need to test the framework itself. We should trust that the ember and the classes it generates behave as expected. The reason we can trust it is because those classes have awesome unit tests. I trust that ember will wrap my objects in a controller when I specify an itemController because the specs say so.

Custom code we write deserves the same. Like when we replace generated controllers, routes and views with application-specific behavior. We should be able to use TDD, write failing integration test, drop down to into unit tests, then red-green-refactor until the integration tests pass.

For example, let’s say I am coding the blog app from ember guides homepage (GitHub - tildeio/bloggr-client: The Source for the Ember Get Excited Video) and I want to add the edit post feature

Start with Integration test:

I would write a test like: “Given there is an existing post, when I visit the post, click edit, modify it’s contents and click done then my changes should be saved.”

The test is going to drive app from end-user perspective (clicking, etc) and it would fail cause there is no edit button yet.

Now I start writing some unit tests

  • PostController#edit() changes isEditing to true
  • PostController#doneEditing() changes isEditing to false
  • PostController#doneEditing() sends commit() to store

Might also write one for PostView. Could see skipping this as it really just tests the template. Curious if/how others would test this. Anyway, tests verify that:

  • PostView shows edit button when isEditing=false
  • PostView shows editor when isEditing=true

Awesome. Mine too actually, at least for the most part.

What would help me (and i hope others) is having patterns and best practices to build from. It’s not rocket science but there are lots of decisions to make. Like for example if/when to test bindings and computed properties. As it stands I feel like I am trying to re-invent the wheel.

I guess what i am wondering is how/when do other people write unit tests for their routes/controllers/views/models? I want to find 3-4 solid examples of each.

4

This is precisely the problem I’ve encountered – the bindings / compuputed properties are fine in simple cases (e.g, anything shown in the examples) and they usually work in more complicated scenarios, but occasionally I’ve encountered ridiculously hard to find bugs involving bindings. Because I can’t always trust bindings to work, I end up having to unit test them, which is a pain.

1 Like
5

I have to say I’m completely in agreement here.

While things like automatically hooked up components are awesome for Ember’s general usability when it comes to programming, when it comes to building a unit text around them (perhaps because of DI?) we end up with responses like this one, on stack overflow:

This is apparently a pretty simple test for a component. Honestly I don’t find it so. Perhaps we could add some kind of method to Compoent that would auto-hook up the template for use when testing?

I hope you know what I’m talking about :slight_smile:

6

Hi, I’ve since asked a question on stack oveflow myself about this:

I’d be pretty keen to get the input of @wycats, @tomdale, @trek, @ebryn, @machty on this topic (or anyone else who might have interest in helping users gain traction in this stuff).

I’d be happy to create a documentation patch for unit testing, if that’s the thing to do. (Mostly I’ve just superbalked when it came to looking at submitting patches so far) TBH I didn’t really understand the Huafu post’s response on stack overflow very well and I don’t feel it answered the fundamental question of testing components anyway.

Would it be possible to create tests for each piece of documentation example code? It strikes me that that might be incredibly handy when building one’s own tests (also as a pedagogical tool for just how the thing works), not only that but it’d probably be incredibly insightful as to what it’s like being a consumer of all the APIs that exist (maybe it’s overkill, IDK).

I just realised, the original comment of “testing components is easy” was refererring to testing individual parts of Ember, not Ember.Component objects. I read that wrong when I was doing a search for testing components in Ember in discuss. I should probably break this out into a separate discussion, I guess?

Anyway, today I’m looking at the source. I’m happy to help out by creating documentation if need be. I just need someone with more understanding about the internals of the framework to help show me how I’d go about writing unit testing around a component which has no .js file and also one that does.