As you are writing a program, how do you understand how the program will behave?
You might have a model in your mind of what the program will do, but you can
be sure of it only when you exercise or
interact with your program in some way. Chapter 18 showed you how you can use
–spec to express what you think the input and
output types of a function should be; TypEr can check whether this is
consistent with the code itself.
Types don’t tell you how a program behaves, however, and testing is one of the best ways to understand how your code will function. We have been doing this informally throughout the book; each time we have given some definitions, we have immediately gone to the Erlang shell and tried them out in practice. When you’re developing in Erlang your coding and test cycles tend to be small. You write a few functions, and you test them. You add a few more, and you test them again. Repeating all of the tests in the shell every time becomes both time-consuming and error-prone.
In this chapter, we’ll introduce the EUnit tool, which gives you a framework for unit testing in Erlang. We’ll show how it is used in practice, as well as discuss how it supports what is known in software engineering circles as test-driven development.
The waterfall model of software development saw a software system being developed in a series of steps: first, the requirements of the system would be elucidated; on the basis of this, the ...