Maybe this is the JavaScript Stockholm Syndrome talking, but I've come to really like structuring code based on the type of calls being made. It guides me to extract the synchronous parts and cover them in unit tests. The async parts of my programs are usually talking to a database, a service, or the file system, which are all things that I'd naturally want to exclude or mock in unit tests anyways. I wind up with fast, simple unit tests for the parts of my program that are heavy on branching and calculation.
90% of the time, the programs I'm writing do not logically branch as a result of async calls. I might have to handle errors and abort a process gracefully (which promises and/or the async library do quite elegantly), but those cases feel different than deciding what to do based on the result of an async operation. Because there are few logical branches in these parts of my programs, I get a lot of coverage just by writing one or two integrated tests that exercise all those external systems and verify that they are hooked up correctly.
This idea of a functional core that can be tested with unit tests and an imperative shell that can be tested with integrated tests comes to me from Gary Bernhardt: https://www.destroyallsoftware.com/talks/boundaries. The 90% figure could be dumb luck or inexperience, but so far so good.
90% of the time, the programs I'm writing do not logically branch as a result of async calls. I might have to handle errors and abort a process gracefully (which promises and/or the async library do quite elegantly), but those cases feel different than deciding what to do based on the result of an async operation. Because there are few logical branches in these parts of my programs, I get a lot of coverage just by writing one or two integrated tests that exercise all those external systems and verify that they are hooked up correctly.
This idea of a functional core that can be tested with unit tests and an imperative shell that can be tested with integrated tests comes to me from Gary Bernhardt: https://www.destroyallsoftware.com/talks/boundaries. The 90% figure could be dumb luck or inexperience, but so far so good.