Chapter 8
Testing MVC

After reading through so many chapters, you might be wondering, “Where are all of the tests?” We strongly believe in writing tests as you go, but such an approach could be repetitive, awkward, and distracting in a book. Rather than present tests as we go, we decided to focus on presenting one concept at a time and save the tests for the end of each part. In this chapter, you’ll see us use techniques to test everything we built in the first part of the book. We might not test every single line of code we’ve written so far, but we’ll cover all of the concepts you’ll need to test everything.

Regardless of what you’re building or the language that you’re using, many testing principles remain the same. Let’s look at some of the principles we’d like to emphasize:

• Fast: We’re going to make sure our tests run quickly and can run concurrently wherever possible.

• Isolated: We want to have the right level of isolation in our tests. Tests that are too isolated won’t have enough context to be useful. Tests that aren’t isolated enough will be difficult to understand and maintain.

• DRY (Don’t Repeat Yourself): We want to eliminate unnecessary repetition in our tests.

• Repeatable: We want the same test on the same code to always yield the same result.

Both the Phoenix platform and Elixir have many features that simplify testing. Clean contracts between layers of the application make it easy to get to the right level of isolation. The focus on immutability, concurrency, and speed will help our tests run quickly. Functional programming will help keep our tests DRY and repeatable.

Before we go too much further, let’s settle on some common terminology, since different testing terms mean different things depending on which framework or language you’re using.

A unit test exercises a function for one layer of your application. For example, if you’re testing a web calculator, unit tests would exercise the Calculator module supporting your arithmetic. You might dedicate one or more tests to the add function on your calculator module.

An integration test focuses on the way different layers of an application fit together. Our integration tests in this chapter will generally do a request to a controller to use the things we’ve created so far. A single test will begin at our endpoint, run through our pipelines, read from the database, and render templates through views just as Phoenix requests would.

You may also encounter types of tests that we don’t cover here. For a larger project, you’d also possibly want to test how multiple actions work together. For example, a single acceptance test case might sign the user on, perform several calculations that might build on each other, and then sign off. You might also consider performance testing to see how your application performs under load. In this book, we focus strictly on unit and integration tests.

Enough background! We’re going to work through the various layers of our application. We’ll start with some of the tools we can use to run tests and shape the tests we write. Next, we’ll work through some integration tests and then focus on unit-testing the individual components.

Let’s get started.