It's been a long chapter, but we are almost done! We now need to incorporate this API into our AngularJS controller and service. Actually, we only need a small addition to the service, a small change to the controller, and no changes at all to the view.

First, in our service static/js/todo_list.js, we'll need to add a method to handle toggleDone:

'use strict';

// define the model to handle the data
var TodoList = function ($http) {
  // ... same as before ...

  // the new method
  store.toggleDone = function(id) {
    return $http.post('/api/v1/todos/' + id + '/toggle_done').then(returnTodos);
  }

  return store;
};

In static/js/todo_list_controller.js, we'll change the $scope.toggleDone method to use this new TodoList.toggleDone method:

$scope.toggleDone = function(todo) {
  TodoList.toggleDone(todo.id).then(function(todos){
    $scope.todos = todos;
  });
}

That's it! We're ready for the grand finale. Let's run all of our specs and features at once:

It all works. Was all the effort worth it? Think about it a bit and we'll come back to discuss the pros and cons of BDD.

There's another very interesting trick we can pull off. Let's try to run our feature file against the public todomvc.com website's implementation of a todo list manager. Although the implementation is totally different, the features we are testing for should be the same.

Here's what happens:

Both features pass. You should see your browser open up with the very stylish TodoMVC version of the todo list:

This neat trick was made possible by the fact that our features and markup were tailored to match that of the todomvc.com version of the site. But it shows a very interesting high-level use for feature files. We can totally reimplement an app and test its features very easily. Also, being able to target any URL with our features is very useful for testing out QA or staging servers running various versions of our code. We can easily integrate such feature tests with a continuous integration system such as Travis CI or Jenkins to make sure our overall features are working throughout the development and deployment process. This is very important, as realistic development will involve locally running sites, QA and staging servers, and even production systems. We can target anything and our specs will work the same way, since we've decided to use outside-in, black-box specs that do not assume any control of the running application from within the specs. This also explains why we set Capybara.run_server to false, since our specs do not start the servers we are going to hit.

Another important detail is the before hook that resets the page. Since we are using a black-box approach, we can't just wipe out a database to reset the state of the application. That means all of our actions will persist from one scenario to the next. In order to start from a clean slate, we're marking all items as completed and then clearing them. That is pretty easy, given the simplicity of the todo list manager app. However, for more complex apps with more stateful interactions, it may be very tricky to reset to a clean state. Managing state for specs is the greatest challenge for black-box testing. Often, you will need to create accounts or use an admin interface to manage state. You can also cheat a bit and use direct database queries or other non-black-box means to reset state. There are trade-offs in each scenario, but one benefit of sticking to the black-box approach is that you know you have full administrative capabilities in the app, since your specs require them just to run. You also get some testing of these administrative functions out of your specs.