concept unit test in category functional programming
This is an excerpt from Manning's book Functional Programming in JavaScript.
The code samples for this book can be found at www.manning.com/books/functional-programming-in-javascript and at https://github.com/luijar/functional-programming-js. Feel free to check out the project and begin practicing functional programming on your own. I recommend that you run any of the unit tests and play with the different programs. At the time of this writing, because not all JavaScript ES6 features have been implemented across all browsers, I use the Babel transpiler (formerly known as 6to5) to convert ES6 code into equivalent ES5 code.
You create unit tests to ensure that code meets a problem specification and builds fences around all possible boundary conditions that may cause it to fail. I assume you’ve written unit tests before; you’ve likely experienced that testing imperative programs can be a daunting effort, especially in large code bases. Due to side effects, imperative code is susceptible to errors originating from false assumptions about the global state of the system. Likewise, tests can’t run independently of others, as they should, making it difficult to guarantee consistent results regardless of the order in which they’re called. This is unfortunate and is the main reason testing is often left until the end or, in most cases, skipped.
Generally, there are three testing categories: unit tests, integration tests, and acceptance tests. The testing pyramid in figure 6.1 shows that the influence of FP on your code is greater as you move from acceptance tests (top) to unit tests (bottom). This is evident because functional programming is a software-development paradigm that focuses on the design of functions and modules as well as the integration among its constituent parts.
