-
Book Overview & Buying
-
Table Of Contents
Build Your Own Web Framework in Elixir
By :
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.