DEV Community: Martin Nijboer

Using Ecto changesets for API request parameter validation

Martin Nijboer — Thu, 24 Feb 2022 20:23:26 +0000

As Elixir developers, we typically use Ecto.Changeset to validate proposed database records changes in Elixir. It has comprehensive field validation capabilities and standardized error reporting, both of which we can customize.

In this post, I will share how you can use Ecto.Changeset beyond the database context, and use it as an API validation mechanism. Combine it with Gettext, and you get easy error translation for your APIs.

Regular Ecto

If you’ve worked with Elixir, then you’ve probably seen Ecto schemas and changesets like this:

@primary_key {:user_id, :binary_id, autogenerate: true}

schema "users" do
  field :username, :string, unique: true
  field :password, :string, virtual: true, redact: true
  field :password_hash, :string
  field :first_name, :string
  field :last_name, :string
  field :is_banned, :boolean, default: false
  field :is_deleted, :boolean, default: false

  embeds_one :photo, Photo

  timestamps()
end

def changeset(user, attrs) do
  user
  |> cast(attrs, [:username, :first_name, :last_name, :password])
  |> validate_required([:username, :first_name, :password])
  |> shared_validations()
end

This is a regular Ecto.Schema for a users table, with a changeset/2 function that receives the User struct and the proposed database record changes as attrs.

Passing valid data to changeset/2

When passing valid data to the changeset function changeset/2, it will return the tuple {:ok, %Ecto.Changeset{valid?: true, changes: changes, ...}}. Where changes is a map of validated database record changes, like:

%{first_name: "Jane", last_name: "Doe", username: "janedoe"}

Passing invalid data to changeset/2

When passing invalid data to the changeset/2 function, it will return the tuple {:error, %Ecto.Changeset{valid?: false, errors: errors, ...}}. Where errors is a keyword list, like:

errors: [
  first_name: {"should be at least %{count} character(s)",
    [count: 3, validation: :length, kind: :min, type: :string]},
  last_name: {"should be at most %{count} character(s)",
    [count: 20, validation: :length, kind: :max, type: :string]},
  username: {"can't be blank", [validation: :required]}
]

Which is a bit unreadable, but with the help of Ecto.Changeset.traverse_errors(changeset, &translate_error/1) we can translate these errors in a human-readable map, like:

%{
  "first_name" => ["should be at least 3 character(s)"],
  "last_name" => ["should be at most 20 character(s)"],
  "username" => ["can't be blank"]
}

We’ll be using the changes and errors fields later in this post, so let’s keep them in mind. 😉

When creating a Phoenix project, translate_error/1 is provided by default. If you’ve chosen to install Gettext (installed by default for a Phoenix app), you get easy language translation of these errors for free.

API validation

Using Ecto.Changeset for database record changes is nice, but let’s take a look at API validation. I’ll use a JSON-based API in the following examples, because that’s what I’m most familiar with.

Basic controller

Below is an example of a basic Phoenix controller, which creates a User and an EmailAddress, and verifies and updates an existing EmailConfirmation. Each action has a function call. These three function calls happen in succession, and each must succeed before another can be called.

That means we will want to validate the request parameters before we start any of the function calls; because if one succeeds, a later one may fail when it receives invalid data.

# API.AccountController

action_fallback(API.FallbackController)

def create(conn, %{"account" => params}) do
  with {:ok, email_confirmation} <- verify_email_confirmation(params),
       {:ok, email_address} <- create_email_address(params),
       {:ok, user} <- create_user(params) do
    conn
    |> put_status(:created)
    |> render("create.json", user: user, email_address: email_address)
  end
end

def create(_conn, _params), do: {:error, :bad_request}

Let’s see how we can validate the input parameters, before we call any of the functions.

Basic validation

We could add a pattern match in the controller arguments, and add some manual validation in private functions in the same controller file.

With the pattern match def create(conn, %{"email" => _, "code" => _, "username” => _, "first_name" => _ "last_name" => _} = params) do we can guarantee all the fields that we need are present. There’s no validation of the values yet.

Because we lack an API validation library, we need to manually confirm the validity of each field in the controller:

email must be a valid email address, e.g. “john@example.com”
code must be a valid confirmation code, e.g. “123456”
username must be a valid string without spaces and special characters, e.g. “johndoe”
first_name and last_name must be strings with a minimum length of 3 characters and a maximum length of 20 characters.

We could do this with a private function:

# API.AccountController

defp validate_params(%{"email" => email, "first_name" => first_name, ...}) do
  with true <- is_email(email),
       true <- String.length(first_name) >= 3,
       true <- String.length(last_name) <= 20,
       ... do
    :ok
  else
    false -> :error
  end
end

But that gets dirty, fast. ❌

Using Ecto

Instead of doing validations manually, let’s create an Ecto.Schema and an accompanying changeset called AccountController.CreateAction that contains our validations, in the controller namespace:

# API.AccountController.CreateAction

embedded_schema do
  field(:email, :string)
  field(:code, :string)
  field(:username, :string)
  field(:first_name, :string)
  field(:last_name, :string)
end

def changeset(attrs) do
  %CreateAction{}
  |> cast(attrs, [:email, :code, :first_name, :last_name])
  |> validate_required([:email, :code, :first_name, :last_name])
  |> validate_length(:code, is: 6)
  |> validate_length(:username, min: 3, max: 10)
  |> validate_length(:first_name, min: 3, max: 20)
  |> validate_length(:last_name, min: 1, max: 20)
  |> validate_format(:email_address, @email_regex)
  |> validate_format(:username, @username_regex)
  |> validate_format(:first_name, @name_regex)
  |> validate_format(:last_name, @name_regex)
  |> update_change(:email, &String.downcase/1)
  |> update_change(:username, &String.downcase/1)
end

def validate_params(params) do
  case changeset(params) do
    %Ecto.Changeset{valid?: false} = changeset -> 
      {:error, changeset}

    %Ecto.Changeset{valid?: true, changes: changes} -> 
      {:ok, changes}
  end
end

I’m going a bit overboard with the validations, to show the extent to which you can validate API fields and values. It can be very fine-grained. 👌

In my own projects, I tend to abstract these validations into shared functions. For example, the first_name and last_name validations happen in both the CreateAction and in User schemas, so they share a separate validation function in User.

For example:

def validate_name(changeset, field) do
  changeset
  |> validate_format(field, @name_regex)
  |> validate_length(field, min: 3, max: 20)
end

Very nice. ✅

Implementation

OK. Let’s implement the validate_params/1 function of API.AccountController.CreateAction in the controller:

# API.AccountController

def create(conn, params) do
  with {:ok, attrs} <- CreateAction.validate_params(params),
       {:ok, email_confirmation} <- verify_email_confirmation(attrs),
       {:ok, email_address} <- create_email_address(attrs),
       {:ok, user} <- create_user(attrs) do
    conn
    |> put_status(:created)
    |> render("create.json", user: user, email_address: email_address)
  end
end

Much cleaner. So what happens here?

We call CreateAction.validate_params/1 before any other function gets involved. validate_params/1 receives the request parameters as a map, and validates them using changeset/1, returning either {:ok, attrs} or {:error, changeset}.

If the request parameters are valid, then the Ecto.Changeset struct contains the valid?: true and changes: changes fields. changes is the map of validated request parameters that we want to pass to our subsequent function calls as {:ok, attrs}.

If the request parameters are invalid, then the Ecto.Changeset struct contains the valid?: false field, and we pass the Ecto.Changeset back to our controller function as {:error, changeset}, where it gets picked up by the FallbackController.

Error messages

So when the API request body contains invalid parameters, we receive {:error, %Ecto.Changeset{}}. To process this error, we need a FallbackController. Luckily, this is provided by default in a Phoenix project.

If you’re missing FallbackController, then you can run one of the mix phx.gen tasks from https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.html and it will be generated for you.

Catching errors with FallbackController

The default FallbackController contains a fallback function like this:

# API.FallbackController

def call(conn, {:error, %Ecto.Changeset{} = changeset}) do
  conn
  |> put_status(:unprocessable_entity)
  |> put_view(ChangesetView)
  |> render("error.json", changeset: changeset)
end

Whenever a function inside a controller returns {:error, %Ecto.Changeset{}}, it is caught by this fallback function inside FallbackController. The function then renders the changeset errors as a message, and returns the connection with a 422 HTTP status code (:unprocessable_entity).

For example, it returns error messages like this:

%{
  "errors" => %{
    "code" => ["should be 6 character(s)"],
    "email_address" => ["has invalid format"]
  }
}

You can customize the error parsing with Ecto.Changeset.traverse_errors/2, but the default provided by Phoenix is a nice format for a frontend system to handle.

Translating error messages

If you have Gettext installed (which is installed by default in a Phoenix project), then you can add custom error translations for any language you need.

Since the error messages returned from Ecto.Changeset are always in a simple and specific format, like "is in valid" "can't be blank" and "should be at least 8 character(s)", we can easily add error translations for our API.

I won’t dive into the details of Gettext, but the previous example of a rendered error could easily be translated into this, in Spanish 🇪🇸:

%{
  "errors" => %{
    "code" => ["debe tener 6 caracter(es)"],
    "email_address" => ["tiene un formato inválido"]
  }
}

Not sure if this translates correctly, because I don't speak much Spanish. But it's a nice feature to have, right? 🤷

I hope you learned something today, and that this post will help you build better APIs in Elixir. The next post will be about Dialyzer, and why you should (always) use it for development. Godspeed, alchemists! ⚗️

More information

Read about Ecto.Schema and embedded_schema here: https://hexdocs.pm/ecto/Ecto.Schema.html
Read about Ecto.Changeset and error messages from changeset validations here: https://hexdocs.pm/ecto/Ecto.Changeset.html
Read about FallbackController here: https://hexdocs.pm/phoenix/Phoenix.Controller.html#action_fallback/1
Read about Plug HTTP status codes here: https://hexdocs.pm/plug/Plug.Conn.Status.html
Read about Phoenix generators here: https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.html
Read about Gettext here: https://hexdocs.pm/gettext/Gettext.html

Using Elixir's "with" statement.

Martin Nijboer — Tue, 07 Dec 2021 12:22:04 +0000

Elixir has many features to make code readable, maintainable, and correct. One of them is the with statement. Unfortunately, the with statement can be confusing to work with, because there are some hidden assumptions on how it's used.

In this post, I will introduce you to why, where, and when you would want to use a with statement, and how you can deal with some of the challenges and underlying assumptions. Additionally, you’ll read about a readability and differentiation trick using annotation tuples.

1. The worst "case".

The use-case for with statements is apparent when we look at the worst case statement implementation. Nesting case statements quickly leads to a pyramid of unreadable code (literally! tilt your head 90°):

case is_email_address?(email) do
  true ->
    case String.length(code) === 6 do
      true ->
        case EmailConfirmations.get_email_confirmation(email) do
          %EmailConfirmation{} ->
            case EmailAddresses.get_email_address(email) do
              nil ->
                case Users.create_user(data) do
                  {:ok, user} ->
                    case EmailAddresses.create_email_address(user, email) do
                      {:ok, email_address} ->
                        ...

                      {:error, error} ->
                        :error
                    end

                  {:error, error} ->
                    :error
                end

              _email_address ->
                :error
            end

          nil ->
            :error
        end

      false ->
        :error
    end

  false ->
    :error
end

What this code does well, is matching all possible returns from every function that is called; therefore the code is correct.
What this code does badly, is it's unreadable for you, me, and any other developer looking at it.

We need something better to maintain readability, while keeping the case statement's functionality and correctness.

2. Simple "with" statements.

with statements work like case statements, but with a focus on successful function call results. The following statements are equivalent:

case Users.create_user(attrs) do
  {:ok, user} -> ...
  {:error, changeset} -> ...
end

with {:ok, user} <- Users.create_user(attrs) do
  ...
else
  {:error, changeset} -> ...
end

Let's see some examples.

Implicit handling of non-matching results.

with statements do not need to handle non-matching clauses. Instead, the with statement will return the non-matching clause directly to the parent scope.

The Phoenix framework comes with context generators that will output controller functions with with statements like this:

def create(conn, params) do
  with {:ok, user} <- Users.create_user(params) do
    conn      
    |> put_status(:accepted)      
    |> render("show.json", user: user)
  end
end

Where the function Users.create_user/1 can return either {:ok, user} or {:error, changeset}.

As you can see, the clause {:error, changeset} is not caught in the with statement. Let's see what this with statement does:

When the expected clause matches, because it is {:ok, user}, we continue with the function inside the with statement and user is available within the scope.
When the expected clause does not match, for example we receive {:error, changeset}, then the result is immediately returned to the parent scope (i.e. create/2).

Therefore, the function create/2 returns either the result of the successful clause (an updated conn) or {:error, changeset}.

Explicit handling of non-matching results.

We can explicitly handle the non-matching clauses in a with statement by using the else clause. The else clause requires us to pattern match on all non-matching results.

def create(conn, params) do
  with {:ok, user} <- Users.create_user(params) do
    conn      
    |> put_status(:accepted)      
    |> render("show.json", user: user)
  else
    {:error, changeset} ->
      {:error, changeset}
  end
end

This does the same as the previous example. It will return either the result of the successful clause (an updated conn) or {:error, changeset}.

Because we are explicitly handling non-matching clauses, we must add pattern matches for all non-matching clauses in the else block. If we miss a returned clause, we will receive a ** (WithClauseError) no with clause matching error.

This is the reason why Dialyzer will complain "The pattern can never match the type", because if a returned clause is not explicitly handled, it may crash the process at runtime.

3. Chained functions in "with" statements.

Chaining function calls in a with statement is fairly straightforward. We can rewrite the "case pyramid" from the introduction by chaining the consecutive expressions in a with statement:

with true <- is_email_address?(email),
     true <- String.length(code) === 6,
     %EmailConfirmation{} <- EmailConfirmations.get_email_confirmation(email),
     nil <- EmailAddresses.get_email_address(email),
     {:ok, user} <- Users.create_user(data),
     {:ok, email_address} <- EmailAddresses.create_email_address(user, email) do
  ...
end

Much cleaner and shorter than the original. And with syntax-highlighting in an IDE, this code will be much more readable.

Challenges.

In the previous examples, we always return :error when a function call does not return the desired result. But this is rarely what we want in practice.

We may want to differentiate between similar clauses in the else block.
We need to handle all non-matching clauses in the else block, of every chained function call, or we will introduce app-crashing bugs.
Dialyzer will definitely complain if any of the functions does not return an expected clause (i.e. :error in this example).

4. Advanced "with" statements.

Let's add custom error-handling, differentiation of function calls and results, and readability improvements.

Custom error-handling.

Let's introduce some custom error-handling to the rewritten "case pyramid" in a with statement:

with true <- is_email_address?(email),
     true <- String.length(code) === 6,
     %EmailConfirmation{} <- EmailConfirmations.get_email_confirmation(email),
     nil <- EmailAddresses.get_email_address(email),
     {:ok, user} <- Users.create_user(data),
     {:ok, email_address} <- EmailAddresses.create_email_address(user, email) do
  ...
else
  false -> 
    {:error, :bad_request}

  nil -> 
    {:error, :not_found}

  %EmailAddress{} -> 
    {:error, :conflict}

  {:error, changeset} -> 
    {:error, changeset}
end

Great! Now we can return different error messages depending on which non-matching clause is returned.

But what if the with statement has multiple functions that return the same non-matching results, and we want to handle each return differently?

For example, when two functions can return false, and one version must return {:error, :bad_request}, and the other must return {:error, :conflict}, like so:

with true <- is_email_address?(email),
     true <- EmailAddresses.is_available(email) do
  ...
else
  false ->
    # Return either '{:error, :bad_request} or '{:error, :conflict}'
end

Let's see how we can differentiate the returned false clause.

Differentiating non-matching clauses.

We can use a simple mathematical trick to differentiate the returned results. If x * y = z, then x * y + c = z + c must be true as well. Therefore we can add some annotation tuples to the function calls and clauses, and write the previous example as:

with {:is_email, true} <- {:is_email, is_email_address?(email)},
     {:is_available, true} <- {:is_available, EmailAddresses.is_available(email)} do
  ...
else
  {:is_email, false} ->
    {:error, :bad_request}

  {:is_available, false} ->
    {:error, :conflict}
end

By using tuples on both sides of the function calls, we can differentiate the returning values.

Improving readability for large "with" statements.

We can improve readability of large with statements by using the trick from the previous section. That is, by annotating function calls and pattern matches in the with and else block with tuples.

Let's rewrite the "case pyramid" with statement with annotation tuples:

with {:is_email, true} <- {:is_email, is_email_address?(email)},
     {:is_code, true} <- {:is_code, String.length(code) === 6},
     {:confirmation_fetch, %EmailConfirmation{}} <- {:confirmation_fetch, EmailConfirmations.get_email_confirmation(email)},
     {:email_fetch, nil} <- {:email_fetch, EmailAddresses.get_email_address(email)},
     {:user_create, {:ok, user}} <- {:user_create, Users.create_user(data)},
     {:email_create, {:ok, email_address}} <- {:email_create, EmailAddresses.create_email_address(user, email)} do
  ...
else
  {_, false} -> 
    {:error, :bad_request}

  {:confirmation_fetch, nil} -> 
    {:error, :not_found}

  {:email_fetch, %EmailAddress{}} -> 
    {:error, :conflict}

  {_, {:error, changeset}} -> 
    {:error, changeset}
end

In this with statement we chain six functions, and add the following tuples to make the code more readable: {:is_email, _}, {:is_code, _}, {:confirmation_fetch, _}, {:email_fetch, _}, {:user_create, _}, and {:email_create, _}.

Again, in an IDE with syntax-highlighting this will look much better.

5. Common issues and how to solve them.

Be mindful of all the possible returned values from the functions you call in a with statement. Properly handling matching and non-matching clauses will solve most of your issues.

Use formatting to make with blocks more readable.
Use the else block in a with statement to handle non-matching results manually.
Always pattern match all possible returned non-matching values in else blocks to prevent app-crashing bugs.
Use pattern matches on structs. For example with %User{is_banned: false} <- Users.get_user(id) do.
To differentiate function calls and results, annotate the function call and their results with tuples (e.g. {:is_email, true} and {:is_available, true}).
To make large with statements more readable, consider annotating function calls and their results with tuples (e.g. {:user_fetch, user} and {:user_update, updated_user}).
Dialyzer may show the warning "The pattern can never match the type". This means you've missed a result from one (or multiple) of the called functions in the else block. Add the missing return clause, and the warning will resolve.

I hope you learned something today. I'm a big fan of Elixir's with clause, and of all the other readability, maintainability, and code correctness features that Elixir offers. The next post will be about Dialyzer, and why you should (always) use it for development. Follow me to get a notification in January!

Deduplicating authentication and authorization tests in Elixir and Phoenix using macros.

Martin Nijboer — Tue, 19 Oct 2021 11:21:51 +0000

Writing the same tests over and over again can be frustrating and error-prone work. Yet that’s what happens when writing authentication and authorization tests for controller actions in Phoenix.

Controller actions like index, show, create, update, delete often require authentication and authorization tests, to check whether a User is allowed to do a certain action or access a route. You wouldn’t want a random user editing and hijacking another user’s data, right?

In this post, I’ll present a method to safely deduplicate authentication and authorization tests for Phoenix controller actions, using macros. We’ll use Elixir’s testing library ExUnit to test protected controller actions with the Phoenix framework.

A simple non-problematic example.

Let’s implement an example with two routes, one requires authentication and the other doesn’t. We need authentication tests for the authenticated route, to ensure non-authenticated users cannot access it.

The router file in /lib/app_web/router.ex:

defmodule AppWeb.Router do
  use AppWeb, :router

  # Public routes.
  scope "/" do
    pipe_through :api

    post "/create", UserController, :create
  end

  # Authenticated routes.
  scope "/user/:user_id" do
    pipe_through [:api, :authenticated]

    post "/update", UserController, :update
  end
end

To guarantee that a non-authenticated user cannot access the authenticated route /user/:user_id/update, we write the following test in /test/app_web/controllers/user_controller_test.exs:

defmodule AppWeb.UserControllerTest do
  use AppWeb.ConnCase

  import App.UsersFixtures

  describe "update/2" do
    setup do
      %{user: users_fixture()}
    end

    # Regular tests.
    test "with valid params, updates user", context do
      ...
    end

    # The authentication test.
    test "user is not authenticated, renders error", %{conn: conn, user: user} do
      path = Routes.user_path(conn, :update, user.user_id)

      assert conn
             |> post(path)
             |> json_response(401)
    end
  end
end

This test will make a post request to the UserController function update/2, which is represented in the router as the path /user/:user_id/update. The test then asserts that the response has a 401 HTTP status code.

This test will pass. We wrote one test for one authenticated route. Easy enough.

The problem.

But what if we have multiple authenticated routes?

The updated router file in /lib/app_web/router.ex:

defmodule AppWeb.Router do
  use AppWeb, :router

  # Public routes.
  scope "/", AppWeb do
    pipe_through :api

    post "/create", UserController, :create
  end

  # Authenticated routes.
  scope "/user/:user_id", AppWeb do
    pipe_through [:api, :authenticated]

    get  "/show", UserController, :show
    post "/update", UserController, :update
    post "/delete", UserController, :delete
    post "/posts/create", PostController, :create

    # Post author routes.
    scope "/posts/:post_id" do
      pipe_through :is_post_author

      post "/update", PostController, :update
      post "/delete", PostController, :delete
    end

    post "/create", TeamController, :create

    # Team member routes.
    scope "/teams/:team_id" do
      pipe_through :is_team_member

      get "/index", TeamController, :index
      get "/update", TeamController, :update
      get "/delete", TeamController, :delete
    end
  end
end

Yeah… That’s a lot of authentication tests. Each route requires almost the exact same authentication test, but each time we change only one variable; the route.

The new situation.

In the updated example, a User can own a Post and, via Team.Member, a Team object.

We will now need to write authentication tests for each authenticated route; 10 in this example. Every time we write a new authentication test, it will be near-identical to the previous one.

We will also need to test that User is not authorized to access Post when User does not own Post, and that User is not authorized to access Team when User is not a Team.Member. Again, these tests will be near-identical.

Error-prone.

First, writing all these tests is a lot of work. Second, it’s error-prone because you might miss a test, a configuration, forget to update the route, to woefully start copy-pasting… You’ll understand my concerns.

In a typical enterprise production-deployed Phoenix-based application, we can see 100s and sometimes 1000s of authentication and authorization tests. That’s >100 and >1000 possible points of failure.

We need a solution to standardize our test-suite without giving up readability and maintainability.

The solution: Macros.

In short, macros are special functions that insert a quoted expression into our application code (i.e. code that generates code). The long version of what macros are, and how they internally work, is a bit more complicated; but you don’t need expert knowledge to follow the rest of this post, because our implementation is relatively straightforward.

You can read more about macros here: https://elixir-lang.org/getting-started/meta/macros.html.

In this post I will create one macro that generates multiple authentication tests, and implement it in the original UserControllerTest example.

A macro called AuthenticationTestsMacro.

First, we create a module containing the authentication tests macro in the file /test/support/macros/authentication_tests_macro.ex.

defmodule AppWeb.AuthenticationTestsMacro do
  import ExUnit.Assertions

  defmacro test_user_authentication(:post, path) do
    # Mark the code as `generated`.
    quote generated: true do
      # Make `path` available in the test blocks.
      @path unquote(path)

      # Implement the first test.
      test "user is not authenticated, renders error", %{conn: conn} do
        assert conn
               |> post(path)
               |> json_response(401)
      end

      # Implement the second test.
      test "user is banned, render error", %{conn: conn} do
        import App.UsersFixtures
        import App.Users.SessionsFixtures

        alias App.Users

        user = user_fixture()
        token = session_fixture(user)

        Users.ban_user(user, true)

        assert conn
               |> put_req_header("authorization", token)
               |> post(path)
               |> json_response(401)
      end
    end
  end
end

Do you recognise the first test inside the macro? It’s from the original example, where we tested "user is not authenticated, renders error" inside UserControllerTest.

I added a second test "user is banned, renders error" to the macro. When we call the macro in a test module, both tests will be executed for the given path.

Let’s update UserControllerTest.

Now, we implement the macro in the controller test module /test/app_web/controllers/user_controller.exs. We can remove any authentication tests that were present; the macro covers these now.

defmodule AppWeb.UserControllerTest do
  use AppWeb.ConnCase

  import App.UsersFixtures

  # Import macros.
  import AppWeb.AuthenticationTestsMacro

  describe "update/2" do
    setup do
      %{user: users_fixture()}
    end

    # Regular tests.
    test "with valid params, updates user", context do
      ...
    end

    # Implement the macro.
    path = Routes.user_path(@endpoint, :update, "user_id")

    test_user_authentication(:post, path)
  end
end

We imported the macro with import AppWeb.AuthenticationTestMacro.

We generated the path that needs to be tested for authentication, with path = Routes.user_path(@endpoint, :update, "user_id").

Lastly, we call the macro with test_user_authentication(:post, path), where :post is the HTTP-method we use to request the controller action.

We can now run our tests again. They will pass.

Conclusion.

The result is a more readable, maintainable, and accurate test-suite.

Instead of writing authorization tests for each controller function, we can now implement one or more macros to test authentication and authorization for us. The macros will generate the code we need to test the controller functions, based on the arguments we give it.

Do you need 10 authentication tests for 10 different routes? Just implement a macro and pass it a different route each time.

Do you need 120 authentication and authorization tests to check whether User is authenticated and that User is a Member of Team? Just create two macros (one for authentication, and one for team membership) and implement them in each controller action test.

Do you want to check how your test macros are holding up? Just change a test in a macro so it fails, and watch your test-suite blow up.

It’s as easy as that. No more duplication.

What do you think? Is this the best way to generate authentication and authorization tests? Do you have an even better method? Let me know in the comments.

You can find a GitHub repo with a working example here: https://github.com/martinthenth/deduplicate-tests-example