Writing your first Ember.js Acceptance Test

Jun 22, 2015

Table of contents:

1. What are we building?
2. What is an Acceptance Test?
3. Create the first Acceptance Test
4. Creating a new Route
5. Adding to the template
6. Conclusion

Last week I set the foundation for a new little mini-series here on Culttt all about building an Ember.js application using Test Driven Development.

Previously we’ve covered a lot of the basics when it comes to getting to grips with Ember.

However, I feel learning how to write tests should really be through Test Driven Development, rather than just learning the syntax of what to write.

In today’s tutorial we’re going to be writing our first Ember.js Acceptance Tests, watching it fail, and then writing just enough code to make it pass.

What are we building?

Before we jump into the code, first I want to set the scene. We’re going to be building a collaborative todo list.

This means that a user will be able to create a list of tasks, and other users can leave comments to help them out.

So we’re going to need a tasks list, tasks and replies. We’ll also need to get into the nitty gritty of user accounts, authentication etc, etc, but we’ll cross those bridges when we come to them.

What is an Acceptance Test?

The first thing we need to do is to generate the Acceptance Test. An Acceptance Test tests the application from the outside in and generally requires the whole application to be running.

Acceptance tests are concerned with user interaction and application flow and will deal with a much greater scope of the application.

For example, an Acceptance test will assert that the user can log in, create a new post and friend another user.

Create the first Acceptance Test

If you followed along with last week’s post you should have a blank Ember application ready to go. If you missed last week’s post I would recommend reading it first so you can follow along.

We can use the Ember generate command to create a new Acceptance Test:

ember g acceptance-test task-list

This will create a new file called task-list-test.js under the tests/acceptance directory.

At the bottom of this file, we can write out first test:

test("Count the number of tasks", function (assert) {
  visit("/");
  andThen(function () {
    var tasks = find(".task-list .task");
    assert.equal(tasks.length, 3);
  });
});

In this test we’re visiting the home page:

visit("/");

Next we pull the .task items from the DOM:

var tasks = find(".task-list .task");

And then we assert that there are 3 items in the list:

assert.equal(tasks.length, 3);

visit() and find() are two of Ember’s test helpers. There are quite a few more test helpers, but we’ll cover them as we need them.

If you run the tests you will see that this test should fail:

ember test

With the failing test in place, we can now write the code to make it pass!

Creating a new Route

The first thing we need to do is to create a new route.

ember g route tasks

This will create the route files and it will update the router to look like this:

export default Router.map(function () {
  this.route("tasks");
});

The task list is the most important part of this application so we’re going to set the path to "/":

export default Router.map(function () {
  this.route("tasks", { path: "/" });
});

Adding to the template

One of the files that was generated when we created the route was tasks.hbs under the templates directory.

By default Ember will look for this template file when calling the tasks route.

To make the test pass we need to add some HTML that will represent the task list and the task items:

<section>
  <ul class="task-list">
    <li class="task">One</li>
    <li class="task">Two</li>
    <li class="task">Three</li>
  </ul>
</section>

Now if you re-run the tests, you will see that the test we wrote earlier passes.

Conclusion

We haven’t accomplished a great deal of functionality in today’s tutorial because a static HTML list of to do items is about as much use as a chocolate fireguard.

However, we have seen the basic flow of Test Driven Development in action.

In Test Driven Development, you use the test to “drive” the development of the intended functionality.

By writing the test first, you create the expectation of what the functionality should achieve. Then you incrementally move towards that goal.

In next week’s tutorial we will look at making the task list dynamic!

This tutorial (and the rest of this mini-series) is greatly inspired by this talk by Toran Billups at Ember Conf 2015.

If you are interested in watching an excellent walkthrough of Test Driven Development for Ember applications, or a total masterclass in using Vim, I would highly recommend watching that video.

I think I’ve watched it about 10 times now!