Testing Contexts

It’s time to test the M of the MVC, models. Phoenix generates a module in test/support/data_case.ex to serve as a foundation for your tests that interact with the database. In our case, Accounts and Multimedia contexts both work with the database. The data_case handles setup and teardown of the database and integrates with Ecto.Sandbox to allow concurrent transactional tests. Crack it open and import the fixtures we just defined:

Let’s take a look in more detail.

On line 12 we import our test helpers inside the using block. The using block serves as a place for defining macros, common imports and aliases. We also see a setup block for handling transactional tests. A transactional test runs a test and rolls back any changes made during the test. This transactional technique allows tests to reset the database to a known state quickly between tests.

Phoenix also generates an errors_on function for quickly accessing a list of error messages for attributes on a given schema. You’ll see that function come into play as we write tests for our contexts.

Testing User Accounts

Let’s start with user account registration. In truth, most context-related functionality will be tested with our integration tests as they insert and update records, but not all. Error and exception flows are some of the trickiest parts of our application to get right. We will explicitly try to catch some error conditions as close to the breaking point as possible. For us, since our context layer is the one that interacts directly with our database code, we’ll build such cases there. Create a new file test/rumbl/accounts_test.exs that looks like this:

On line 2, we use Rumbl.DataCase to set up our DB dependent tests. We pass the async: true option so the test runs concurrently. Then, on lines 15 and 22, we build valid and invalid users and assert the expected results of trying to register a new user account with Accounts.register_user. In the remaining tests, on lines 37, 46, and 27, our error checking is a bit more intentional. We set a username that’s too long and assert that we got a specific error back. Likewise, we set a password that is too short and then test for a specific error.

We close by setting a password that is too short and then test for a specific error. For these tests, we use the errors_on function defined on Rumbl.DataCase. errors_on is convenient for quickly retrieving errors from the changeset. Keep in mind errors_on is just a function. You can create a custom version if you need to test custom behavior.

Now let’s run our tests:

All green.

Next, let’s introduce a testing feature in ExUnit called the describe block. Sometimes, you need to apply the same setup code to many different tests. Describe blocks allow us to apply different test setups to a whole block of tests. For example, we need a user record to test Accounts.authenticate_by_username_and_pass, so we create a describe block with its own setup and three tests, like this:

Let’s break it down. We start by defining a new describe block on line 4 which creates a user fixture having a hardcoded valid email and password.

Next, on line 8, we test that authenticate_by_username_and_pass returns our user when we provide a correct email and password. Following our valid authentication tests, we then test for the two possibile user authentication failures, a bad password or missing email on lines 15 and 20.

Now let’s run our tests again:

We’re still happily green.

Testing the Multimedia Context

Let’s test the data access features in our Multimedia context. Create a new file at test/rumbl/multimedia_test.exs that looks like this:

We programmatically create categories and later fetch them. Our tests verify that they are in alphabetical order. Now let’s run our tests:

Success!

Everything looks good, so let’s now test the video functions of our Multimedia context, which is a little more involved than the previous tests:

We started by grouping our tests together with a new describe block for testing video functionality. On line 7, we create a video, picking off the id field with a pattern match. When we fetch a video, we verify correctness by matching against the id key of the Video record. Then, we do the same with a second video record. This test handles fetching a list of videos. Next, on line 15, we test the get_video function. We use the same technique to fetch a single video using get_video.

Next, on line 21 and 32 we test creation of videos with both valid and invalid user input. We verify a few attributes for the valid test and match against an error tuple for the invalid one. We’re specifically testing our change set functionality. We used a similar approach to test video updates on lines 38 and 47.

Next, we tested delete_video. We ran assertions to verify both the :ok tuple and that the video no longer exists on a subsequent fetch.

Finally, we checked out the ability to return a changeset for tracking video changes on line 64. These tests cover a lot of ground, but they’re quite simple.

Now let’s run our tests:

As expected, they are all green. Before we write more tests, let’s take a short break and talk about the Ecto Sandbox.