…focusing on building a set of tests for EACH individual function…

Yep, agreed. If you follow Kent Beck’s TDD ideas, you should only be testing the feature/public API, like you said sendEmail. If you setup a few good stubs for that, you’d get 100% coverage as well and could move onto the other tests. Then if you changed the implementation, you wouldn’t have to change all the tests I wrote for the individual units.

I’m not covering TDD, though, just why pure functions are cool: only need stubs, easy for you to test your ideas, and you have massive confidence when you wire them together. Nothing wrong, everything right with deleting these tests once your public interface is legit. Not a panacea, though, for sure.

I am waiting for the update of this post. Regarding your comment: I fully support having tests like unit, property, integration, integrated (e2e) tests. Unfortunately these terms are very often understood in a different ways by different people…
My biggest concern regarding what you showed in this series is focusing on building a set of tests for EACH individual function.
I prefer to employ hexagonal architecture (ports and adapters) and build a set of unit tests for given “functionality” (input port functionality) instead of tests each “internal function” individually.
In this case i would only create a set of unit tests (with stubs and spies as test doubles for external services like reading template, getUserEmail, creating transport ) for sendEmail function (having the same signature as the one you have). It would allow me to cover all scenarios (based on different input/different stubs) of this function by asserting sendEmail side effects (if we have any ) and its return value. I will not test any of internal functions like : getEmailTemplateAndAttachments, renderEmailAndGetEmailService, filterCleanFilesAndMapToAttachments, createMailOptions and more. At the current stage these are not my “units of reusability” – they are only “helpers” (albeit very useful) for building sendEmail function. All that allows me to easily refactor sendEmail – as long as all tests for sendEmail are passing i can ruthlessly refactor it (yes i will drive it to extract as many pure functions as possible).

After i am done with these unit tests, i would build some integration tests for code communicating with outside world (can use nock or real implementations) and at the end i would build a single e2e test which would execute sendEmail function with real adapters passed.

Your mind is in the RIGHT place, this is exactly the weakness unit tests have whether they use FP programming with stubs, or non-FP with mocks and stubs: if the stub is wrong, and the test passes, it’s a false positive despite 101% test coverage. This is exactly the reason for integration tests.

I’d caution against spy, though, as he’s just a mock that can act as a stub; i.e. he is explicitly made for testing side effects. That’s the point of this whole series; to avoid mocks, to avoid creating side effects.

“…too much focused on particular functions (units) not on behaviour”

YES! Absolutely. You want to test units first. If those fail, you’re behavior will fail. Units are faster to run with stubs that have no time, no side effects like network calls, reading disk, etc. AND can be run concurrently. Once those pass, then you run the property tests, like jsverify, which are longer, random, and tackle every avenue of positive/negative tests around data types. Finally, you do the integration tests to ensure your actual interfaces are correct. Now, some of those can be mocked (supertest, nock, etc), but even if your local server just returns stubbed data, you can guarantee your contracts are correct. What you found is exactly what we want to find in integration tests… they are just longer and probably won’t work if your unit tests fail.

Unit (like these posts show), property testing, integration testing, and if you have UI stuff, Functional Testing. … I only focused on unit to show people how they don’t need mocks.

…. now, do we HAVE to use integration testing to surface these issues (beyond hiring you full time to code with me, heh)?

No, there are 2 other options:
1. Strong Typing
2. Total Functions

Types would of caught that error before I even attempted to run the tests, in a second whether Flow or TypeScript . This is another cost of dynamic languages: propertyThatExists.somethingThatDoesnt === undefined, no error.

The second option is to use total functions. If we did, createMailOptions would returned an Error or rejected the Promise after validating the from was undefined.

Unfortunately your code is broken. Function getEmailService is returning Maybe and you are not handling that Maybe anywhere. In your sendEmail function you treat emailService as a regular object but it will be either Just or Nothing. I was expecting this to be uncovered somehow… maybe with integration tests but in your integration test you simply copy’n paste (with minor modifications) sendEmailSafe from server.js to sandbox.js so you are testing only sending functionality not full end2end behaviour (which is actually not bad albeit it doesn’t allow one to uncover the bug).
One solution would be to simply spy createTransport function to check if it receives a valid parameter (an object with host, port and and secure:false)

My biggest concern regarding your approach is that it is too much focused on particular functions (units) not on behaviour. It is a matter of TDD vs BDD