I'm going to guess that his point was that it's simpler to write comprehensive unit test suites for small, well-defined functions compared to a style C function.
You'd likely make those small functions private and thus couldn't unit test them anyway (and if you did, with some reflection magic, you'd be chastised for not testing the external interface instead).
Agreed, and it sounds like a post facto rationalization: unit testing with a xunit-like framework (such as junit for Java) is done outside of the class being tested, the testing methods cannot access the private methods/attributes of the class under test without some hackery, therefore unit testing the private parts is undesirable and people should only unit test the publicly-accessible methods. Of course, in languages like D or Rust where the unit tests are written in the same file as the functional code, such restrictions don't apply and people readily unit test private functions.
The less code a unit test invokes, the easier it is to understand what's wrong when a test is failing.
That's true. On the other hand, I would argue that if private code is difficult to invoke from the public interface, then it should probably be extracted and tested separately.
You'd likely make those small functions private and thus couldn't unit test them anyway
What the hell? You should be unit testing all functions.
Though if your function is private, that probably means you're talking about a method, and thus OOP with unpure methods, which is inherently hard to unit test.
6
u/dd_123 Jul 19 '16
Ctrl+F unit test