Test coverage is good. 100% test coverage is absolutely reachable without insane amounts of effort<sup>\[1]</sup>, except of course for those this-can-never-happen-but-lets-check-for-it-nevertheless assertions. <sup>\[1]: assuming reasonably testable code</sup> Especially when talking about error handlers, these *have* to be covered by tests. The “happy path” will be implicitly tested by normal usage. But if things go wrong – you want to make sure things still go your way. It would be a shame if a silly little mistake would mean your error handling code would itself produce an error. Proper errors also make it easier for users of the API to figure out why their code isn't working – they are an important feature of your code. In the context of a web API, checking all input can be crucially important for security – defensive programming should be the rule, not an accidental feature. Obviously, this validation needs to be tested! Another tip: In your example, your code has an extraordinary amount of indentation. This can be a sign that your function should be split up into multiple smaller functions that can be tested separately. Closures are also difficult to test; using named functions increases testability. Also, long cascades of the form if (a) { if (b) { if (c) { happy_path; } else { error_c; } } else { error_b; } } else { error_a; } can be rewritten as if (!a) { error_a; } if (!b) { error_b; } if (!c) { error_c; } happy_path These “guards” make the code more linear and in my experience both easier to understand and easier to test.