Who Should Take This Course, and Why?

Charles Kettering, an American inventor and the longtime head of research for General Motors, has a quote that applies well to our software testing approach:

“A problem well stated is a problem half-solved.”

Think of the tests as stating the problem that the code will solve. Once it’s done, writing the code becomes easier. Moreover, tests not only state the problem but also verify that the solution is correct. They’re an almost indispensable part of software engineering, and we believe it’s important to understand why and how to use them.

Why do we test our code?

Some developers write tests for their software while others don’t. There’s code running all over the world that doesn’t have a single test behind it. So, why do we test at all? We do it for a plethora of reasons, but they all fit into just two categories:

• Testing gives us confidence that our code works as expected. This is true for all kinds of testing, whether for automated tests performed by a machine or manual tests conducted by a human.
• Testing prevents breaking changes (also called regressions). Imagine having an existing codebase to work on to add a new feature. How can we feel confident that adding the new feature won’t break any of the existing features? In most cases, testing is the answer. If the existing codebase is well tested (automated, manual, or both), then we’ll feel safer making changes if the testing suite reveals that nothing broke.

Who is this course for?

This course is for people with a basic Elixir background who want to get better at the testing tools and practices of the Elixir ecosystem. We will skim over most Elixir concepts, such as the language constructs and data types, OTP, Ecto, and Phoenix. Instead of covering those, we’ll learn how to test those concepts and tools. Whether you’re fairly new to Elixir or you’re an Elixir expert, we think you’ll learn a few new things throughout the course.

Testing in Elixir

Elixir is an interesting and fairly unique programming language. It provides features and concepts that can be hard to test if we’ve never dealt with anything like them. Some features, such as concurrency and immutability, are standard in other programming languages but are more prominent in Elixir (and Erlang). Other features, such as resiliency or the OTP framework, are unique to Erlang and Elixir and can be challenging to test effectively.

From a more practical perspective, Elixir is an excellent language for writing a testing book because the tools and patterns when testing Elixir code are pretty consolidated in the Elixir community. One reason for this is that Elixir comes equipped with its own testing framework, ExUnit. We’ll explore ExUnit inside and out, and we’ll learn how to use it in many different situations to test our applications on various levels.

Note: Elixir is closely tied to its parent language, Erlang. As you likely know, Elixir compiles to the same bytecode as Erlang and runs on the Erlang virtual machine (commonly known as the BEAM). Elixir code often seamlessly calls out to Erlang code, and Elixir applications almost always depend on a few Erlang libraries. However, testing seems to be an area where the two languages have a bit less in common. The sets of tools and libraries used by the two languages don’t intersect much. For these reasons, we won’t really talk about testing in Erlang and will focus exclusively on testing in Elixir.