It’s good practice to keep the number of lines in a function limited (here’s Martin Fowler elaborating the point and here’s an ESlint rule to enforce it). To break a long function, we need to identify the parts that are abstract enough to be extracted to new and smaller functions.

The negative of this is that we’ll end up with more functions, but the positive is that these smaller functions are easier to read and test. Another benefit is that the smaller functions are easier to reuse in other contexts.

Complex functions often lead to complex tests

Some developers prefer the top-down testing strategy where only the bigger functions are tested, hoping that their smaller parts (usually private) _“just work”_®! They may believe that good test coverage is a guarantee that all execution paths have a good quality, but test coverage is a terrible metric to begin with. Besides, good tests that cover many use cases of complex functions are usually expensive, complex, and hard to read. This approach is also known as black-box testing:

Black-box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings.

#javascript-tips #functional-programming #testing #javascript