Bookfinder.js unit testing with mocha

[mikiher]

Adds unit tests for the search method and the TitleCandidates and AuthorCandidates classes in BookFinder.
As you can see from the commits progression, the tests were initially written using Jest, and then re-written to use Mocha (plus Sinon and Chai).

There aren't any fundamental differences between the two implementations, but they allowed me to examine the differences between Jest and Mocha by myself. My main observations were:

• Jest is more self-contained, it has built-in assertion, mocking, and coverage capabilities, and these capabilities are good enough to write adequate unit tests.
• Mocha requires additional libraries (like Chai for assertions and Sinon for mocking). Sinon and Chai provide similar and sometimes stronger capabilities, and their syntax is slightly more to my preference.
• Writing tests for both Mocha and Jest was relatively easy (given the wealth of information on both). Mocking was also quite easy in both. I found the Sinon API to be a bit more intuitive for my taste, and it allowed me a bit more flexibility.
• Mocha was much faster than Jest running tests. Running the 'npm test' command (in a dev container) took ~6-7 seconds in Jest, and about ~1-1.5 seconds on Mocha. A lot of this time is spent on loading of the framework in both cases, which will likely be amortized over many test suites, but running the tests themselves was also 4-5x faster on Mocha (typically reported by Mocha to be ~70-80 ms for the whole suite of 72 tests).

It is mainly due to the last point that I think I'd recommend Mocha over Jest at this point in time. Moving to jest in the future would be relatively easy if it becomes necessary/desirable (in fact, Jest can run my Mocha test as-is without any modifications, though the other way round is not true).

I also naturally made some changes to BookFinder itself while writing the tests, some of them just refactoring changes like
this, and some additional functionality like this.

As for the tests themselves, please judge for yourself.
I tried to use parametrized testing quite a bit because it reduces repetition.
I hope the test code and descriptions speak for themselves.

[mikiher]

Also added test coverage tooling with Istanbul (nyc)

[advplyr]

This is great, thanks for digging into this. The tests for me take about 100ms when not running in a dev container.

I still have to learn more about the tools but I like it so far. These decisions are easier to make because they don't impact users if we switch it up later.