Jean — Thanks for your feedback.

I agree that people should test the functionality that the module uses is isolation but if you’re exposing functions or values for the sake of testing, then I think it’s a bad idea — I’ve seen this many times and it just ends up contributing to technical debt. We did this in the early 1990’s with C/C++ code and it was just a mess long term.

We use lambda-tester along with Proxyquire to mock out modules like S3, dynamo, etc., so that we can test functionality in isolation. If we added this to an article would probably confuse most people, since unit testing is still something that most devs forget to do. In addition to unit testing, we use lambda-tester to perform integration testing to verify that it’s working with the external services.

From a CTO perspective, unit testing is more about “code confidence” going into QA/Verification and then into production. We strive to get 100% coverage on everything we produce, not because we want all green bars, but because the language, Javascript, forces one to test every line due to it’s typeless and interpreted nature.

For what it’s worth, we group our tests into unit (no service interaction), integration (service interaction) and “full cream” (testing the real thing). I’ve found many times that code with 100% coverage doesn’t actually work in production because our mocks didn’t have the same behaviour (latency, edge cases, etc.) as the real thing.

-Richard