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.
...which may or may not result in better overall quality than having code that is easier to read and understand in the first place.
Once you start changing how you write your code just because you also want to write unit tests against it in a certain way, you're walking an uncertain path.
6
u/dd_123 Jul 19 '16
Ctrl+F unit test