With this refactored code, we can now create our first test. Create a new hello_test.exs file in the same directory, and add the following:

In our test file, we use Code.require_file to load our HelloWorld definition from hello.exs. Before defining our test, we invoke ExUnit.start to start up ExUnit so it can run the tests we define.

Within our HelloWorldTest module, we use ExUnit.Case to "hook into" ExUnit. It creates the test macro that we use to define our test, which ExUnit then runs. And finally, in our test itself we assert that the string returned from our hello function is as expected. The assert macro will fail the test if its argument is not true.

You can run the test with elixir hello_test.exs. You should see output similar to:

The output shows how many tests were run and how many of those tests failed. As it runs it outputs a dot (which should be green if your terminal supports colors) for each successful test executed, in real time.

It also mentions a "randomized seed". Each time ExUnit runs, it executes the queued tests in a randomized order. That "seed" represents, in an indirect way, the specific order in which the tests ran this time, used for advanced test debugging. We won’t need to concern ourselves with this part of the output for any of the exercises in this book.

Lastly, the test output also has "Hello, World" at the top. This is because we never removed the IO.puts call at the end of our main hello.exs file. When we did Code.require_file in hello_test.exs to load our HelloWorld module, Elixir ran everything in the file. It ran the code within the defmodule block to define our module, but also that IO.puts statement, which is why "Hello, World" is printed out before our test even ran!

Right now our hello.exs file is trying to do two different things. First, it defines a HelloWorld module to encompass a testable and reusable way to greet the world. It’s trivially simple now, but we will be greatly expanding the functionality later in this chapter.

Secondly, hello.exs has a small "script" at the end that directly runs the code contained in our module.

Whenever we have two concerns like this, it is a good idea to separate them out. As we’ve seen, this way of structuring things has already lead to a minor problem around that print statement, IO.puts(HelloWorld.greet()) running during our tests, muddying our output. Other developers in the future may want to use our module and will hit a similar issue. Everytime they try to load our module, we’ll be printing out into their console. An undesirable side-effect, indeed!

In Elixir, we differentiate between files meant for "scripting" and files meant for "reusable libraries" by the file extension. .exs files are meant to be run directly, and are expected to have side-effects when run. .ex files are meant to be compiled and run, but to have no side-effects when they are initially loaded.

Let’s apply these principals by refactoring our implementation.

First, let’s rename hello.exs to hello.ex to make it clear its not a script file. Additionally, let’s remove the print statement from the file, too.

Since we renamed our file, we need to update the import in our test, too. A test is meant to be invoked directly and is not meant to be re-used, so we will keep the .exs extension.

Lastly, we will create a new script.exs file to contain our small little script. If we really want to print that beautiful "Hello, World" string to our console, we can run that directly!

Nice! We can verify everything is still working by running our test and seeing the rogue "Hello, World" printing is gone:

And if we invoke our new script file directly, we can also see that things are working on that front, too:

With that out of the way, we can move onto making our HelloWorld even more featureful.

Let’s start with the test:

We’ve created a new test that asserts what we outlined above. Now, we’re going to run it. We run it even though we haven’t implemented the functionality to make sure our test is working. If it is, then it should fail. You would be surprised, but its not uncommon to write a test that doesn’t quite work, that always passes because the test itself was incorrect.

When you run it, you’ll see something like this:

We see one dot for our first test, which is still passing. Our new test fails because our greet function is not implemented. Specifically, there is no HelloWorld.greet/1 implemented. In Elixir, a function definition consists of two parts: the name and the number of parameters, or arity. The function we do have implemented is actually HelloWorld.greet/0, and that is the one our first test uses with great success.

Let’s try fixing the error and getting the test to pass by adding a new greet/1 function.

The string concatenation operator in Elixir is <>. More specifically, it is the binary concatenation operator. All strings in Elixir are represented by a contiguous sequence of bytes known as binaries. If that sounds obscure, don’t worry - we’ll dig more into it in a later chapter. For now, just know that we can append two binaries with the <> operator, and strings are technically binaries, so we can use it to append two strings, too.

If we run elixir hello_test.exs again, we will see that all tests are passing. Sweet!

Now that our tests are passing, we can look to see if there is anyway to make our code a bit more elegant or simple. The tests we have allows us to change things around with confidence, as we know that any mistake we may make will be caught by them.

In both greet functions, we have a "Hello" string that is shared. That indicates to us that there is some degree of duplication across the two functions that we can eliminate. The functions are of course quite similar, the only difference being that greet/0 has a hard-coded noun of "World". In fact, we can make that more clear by changing the code like so, to leverage greet/1 and thus eliminate the duplication of the "Hello" string:

This pattern of having lower-arity functions that pass along certain values to call higher-arity functions with is quite common in Elixir. It’s so common that Elixir provides a special operator to do it more succinctly, the \\ default argument operator.

Update your module with the code below to see it in action:

The Elixir compiler under the hood will do exactly what we just did manually: define a greet/0 function that calls greet/1 with the default value of "World".

With our refactor done, run your tests once more to verify everything is working. This is what TDD empowers us to do: pursue elegance with confidence, knowing that the tests will keep us within safe bounds.

With this change, we’ve seen how the Test-Driven Development (TDD) cycle works. It’s pretty simple:

This process is sometimes referred to more simply as "red, green, blue". Red to represent the usual color of the failing test in the terminal, green to represent the color of the passing test, and blue to arbitrarily represent the refactoring step.

Throughout this book, we will use this cycle as we explore new Elixir concepts. You may encounter many who propose that this sort of TDD cycle should be used for all code you create. I’m not personally so dogmatic: I mainly use TDD here because I think it is a great way to learn a new language, as the tight feedback cycle familiarizes one with invoking ones code and the sort of runtime and compiler errors the language has. I like to think of TDD as another tool in a software developer’s toolkit, and by the end of this book you will be well on your way to mastering the style.

Let’s make the change to fix our failing test. We need to add a new function greet/2 that takes in our new language parameter. That paramater needs to default to "English" if not explicitly provided, so our existing tests keep on working as before.

Here we use if and else to determine what greeting to use. The statement next to the if is evaluated, and if it evaluates to a truthy value, the block underneath it is executed. If the statement evaluates to a falsy value, then the else block is executed instead.

If we run our tests again, we will see they are all passing.

To get our test to pass, we need to handle this third case in our existing code. In addition to if and else for when you have one or two different cases to handle in your code, Elixir also has the conveniently named case expression for handling any number of cases.

Here we can see it in action:

To use case, we provide a paramater and then define a series of clauses that could match the parameter. After each clause we have an arrow -> and then the code we want to execute if the parameter matches that clause.

If we run our tests, we see that everything is passing:

Our HelloWorld module is looking pretty good, but it currently has one major flaw: it doesn’t handle the case of an unknown language. If I call it with the "Gibberish" language, for example, it won’t know what to do!

Let’s update it to handle this case. As always, before we start adding any functionality, let us first add a test outlining what we want:

If we run the test, we will see an error:

Here our test hit an error when executing. That CaseClauseError says that our case statement does not have a clause that matches the parameter, "Gibberish". What we want is a clause that matches any language parameter we may provide to the greet/2 function.

Let’s add it:

And if we run it, we see our tests pass:

For string and other constants, like "English", the match only succeeds if the value in the clause and the parameter match exactly. If the case clause contains a variable, however, it will match any parameter. Moreover, Elixir will assign the value of the matched parameter into the variable.

This also means that the clauses in the case block are matched from top to bottom. In fact, if we moved our lang → clause to the top, none of our other clauses would get matched, since our variable clause matches everything!

That may all seem like a bunch of "Gibberish" to you, but don’t worry! What I’ve described is the "pattern matching" that is at the core of Elixir. We will see it again and again in how other parts of Elixir works, and build up understanding slowly but surely.

Here are some additional exercises you can do. Each of these involve updating the test with the new requirements, then updating the implementation to make the tests pass. As always: start with the test!