My co-worker, Jason Kaiser, created a way for Promises not to fail, called sureThing. It has 3 benefits to your code that we’ll illustrate below including prior art in other programming languages so you know this isn’t some made-up concept.
A pure function:
const add = (a, b) => a + b
vs. a total function:
const addNumbers = (a, b) =>
( isNumber(a) && isNumber(b) )
? {ok: true, data: a + b}
: {ok: false, error: new Error(Either a or b aren't Numbers.)}
While same input, same output, no side effects sounds like the end all, be all… it’s not.
Welcome to Part 6, the final installment in this series. Below we cover unit testing the noop next, how to create pure functions that wrap noop so you can compose them, and finally using code coverage to strategically hit the last code that’s not covered.
(more…)
Welcome to Part 5 where we cover more about noops with a utility to test them, the “stub soup” that can happen if you don’t create small pure functions, and how we can utilize stubs instead of mocks to unit test larger functions. The most important part, though, is setting up Mountebank to show how integration tests can show problems in your unit tests despite 100% coverage. We use wrapping class instances as an example to show you the pitfalls Object Oriented Programming code can make for you.
(more…)