Testing the web server with ExUnit
Automated testing is a key part of any software, especially in a dynamic-typed language such as Elixir. It is one of the catalysts for writing deterministic software while documenting the expected behaviors of its components. Due to this reason, we will be making an effort to test everything we build in this book, including the Cowboy-powered web application we have built in this chapter.
In order to test our web application, we first need to be able to run our application on a different port in the test environment. This is to ensure that other /static/bad.html
environments do not interfere with our tests. We also can use an application-level configuration to set a port on which the Cowboy server listens to all the requests. This will allow us to separate the test port from the development port.
So, let’s update our application to use the configured port or default it to 4040
using an @port
module attribute:
lib/cowboy_example/application.ex
defmodule CowboyExample.Application do @moduledoc false use Application @port Application.compile_env( :cowboy_example, :port, 4040 ) @impl true def start(_type, _args) do children = [ # Add this line {Task, fn -> CowboyExample.Server.start(@port) end} ] opts = [ strategy: :one_for_one, name: CowboyExample.Supervisor ] Supervisor.start_link(children, opts) end end
We can make sure that the application configuration is different for different Mix environments by adding the config/config.exs
file, and setting a different port in our config for the test environment. We will also be updating the logger to not log warnings. So, let’s add a config file with the following contents:
config/config.exs
import Config if Mix.env() == :test do config :cowboy_example, port: 4041 config :logger, warn: false end
Note
Mix.Config
has been deprecated in newer versions of Elixir. You might have to use the Config
module instead.
Now, let’s add tests for our server endpoints. In order to test our web server, we need to make HTTP requests to it and test the responses. To make HTTP requests in Elixir, we will be using Finch, a lightweight and high-performance HTTP client written in Elixir.
So, let’s add Finch to our list of dependencies:
mix.exs
defmodule CowboyExample.MixProject do # ... defp deps do [ {:cowboy, "~> 2.8"}, {:finch, "~> 0.6"} ] end end
Running mix deps.get
will fetch Finch and all its dependencies.
Now, let’s add a test file to test our server. In the test file, we will be setting up Finch to make HTTP calls to our server. In this section, we will only be testing the happy paths (200
responses) of our root and greet
endpoints:
test/cowboy_example/server_test.exs
defmodule CowboyExample.ServerTest do use ExUnit.Case setup_all do Finch.start_link(name: CowboyExample.Finch) :ok end describe "GET /" do test "returns Hello World with 200" do {:ok, response} = :get |> Finch.build("http://localhost:4041") |> Finch.request(CowboyExample.Finch) assert response.body == "Hello World" assert response.status == 200 assert {"content-type", "text/html"} in response.headers end end describe "GET /greeting/:who" do test "returns Hello `:who` with 200" do {:ok, response} = :get |> Finch.build("http://localhost:4041/greet/Elixir") |> Finch.request(CowboyExample.Finch) assert response.body == "Hello Elixir" assert response.status == 200 assert {"content-type", "text/html"} in response.headers end test "returns `greeting` `:who` with 200" do {:ok, response} = :get |> Finch.build("http://localhost:4041/greet/ Elixir?greeting=Hola") |> Finch.request(CowboyExample.Finch) assert response.body == "Hola Elixir" assert response.status == 200 assert {"content-type", "text/html"} in response.headers end end end
As you can see in the preceding module, we have added tests for the two endpoints using Finch. We make calls to our server, running on port 4041
in the test environment, with different request paths and parameters. We then test the response’s body, status, and headers.
This should give you a good idea of how to go about testing a web server. Over the next few chapters, we will be building on top of this foundation and coming up with better ways of testing our web server.