Our First Test

From the beginning, Elixir was developed with ExUnit, Elixir’s testing framework, as part of the core library. As a result, most of the test tooling we’ve come to utilize in our production applications is straight out of the Elixir core. This means that if we have Elixir and are familiar with what’s available, we can write effective tests without bringing in other libraries.

Write our first test

Let’s write our first test in our rain alert app, Soggy Waffle. Soggy Waffle makes calls to an API and gets data back from it. It then standardizes that data according to its terms and data structures for the rest of the application. While those calls to the API aren’t something we’ll focus on in the course, the response transformation is an excellent example of code that can be tested in isolation. Let’s take a look at the code we’ll be testing.

Note: If you want to code along with the examples, you should do so inside the provided Soggy Waffle application, adding test files in the locations we indicate before the examples. Don’t worry though, because we will be providing these updates as we go along the course.

In theory, Soggy Waffle could work with any weather API as long as it returns a timestamp and the weather conditions. As a best practice, our application translates the API response into a list of SoggyWaffle.Weather structs that it defines in lib/soggy_waffle/weather.ex with two fields, one for the timestamp, datetime, and one for whether or not the weather condition translates to rain.

The SoggyWaffle.Weather struct is defined in line 4.

This means that our ResponseParser module will hold a lot of information specific to the API we choose. In this case, that’s openweathermap.org. Notice the module attributes in the code as well as the comment about where that information came from.

Our test will need to pass in a response, and it’ll expect the response data to be in the shape of a list of SoggyWaffle.Weather structs that it’s defined.

Now let’s open up a new test file at soggy_waffle/test/soggy_waffle/weather_api/response_parser_test.exs in the provided Soggy Waffle code and start writing our first test!

Before running our test, let’s first go over what it’s doing. This is a pretty basic test, but already quite a bit is going on. An assert macro is being called (line 13), and there are assertions inside a list comprehension (line 16). Let’s look at each piece separately.

Assert macro

The assert call at line 13 works because if the function evaluates to true or something “truthy,” the assert will pass. In our case, we’re handing it a pattern match. If a successful pattern matches, it returns the data that matched the pattern, which is “truthy.” If we want to assert that a list is empty, use Enum.empty?/1. ExUnit also provides the opposite, refute, which will only pass if the expression is given as a parameter that evaluates false or nil.

Note: Be careful, though, as refute doesn’t work with a pattern match in the way you’d expect. If a pattern doesn’t match, a MatchError is raised. Also, don’t make the common mistake of thinking refute will pass with an empty list (refute []). The refute function will only pass if the expression it’s given evaluates to false or nil. The [] list is empty, but it’s still a list.

List comprehensions

The last part for us to look at is the list comprehension at line 16. A list comprehension here means that we want to apply the same assertions to multiple pieces of data.

Note: An Enum. each would work just as well here, and the choice of a list comprehension is purely a style choice in this case.

Using a list comprehension implies an assertion about the shape of our response—that it’s enumerable. If the result can’t be iterated through, the test will raise a Protocol.UndefinedError, revealing the bad value.

Let’s now look at the assertions inside the code block.

assert match?(
         %Weather{datetime: %DateTime{}, rain?: _rain},
         weather_record
       )

The match?/2 function is the other way of asserting on a pattern match. This assertion is focused solely on the shape of the data and not on the values provided. Even though match? doesn’t bind a value like using = would, we’ll still get a compile warning if we don’t use an _ before the variable in the pattern.

assert is_boolean(weather_record.rain?)

This assertion still focuses on the shape of the data and not on a specific value because converting weather IDs is additional functionality. Unit tests are typically quick to run, and keeping them focused on a single aspect of our code can make finding errors faster and easier. We’ll add other tests shortly to focus on specific values in the response.

Try it yourself

Update the files and then press “Run” to verify the test. If the test is written correctly, it’ll pass, and we’ll see a lovely green dot representing a passed test.