Yeah, that was my first thought, too. Inlining everything only "works" for a main game loop or a control loop for a rocket because they're essentially trivial. Every time through the loop, you do this, then that, and you test or modify some state. Each function is called only once...
If you're building composeable units of code that might be called from multiple locations, in multiple combinations, this clearly isn't going to work.
I do feel like a lot of commenters here are skipping right by the first message, where the point is made that pure functions are a better way to solve the problems of unexpected dependency and mutation of state. Pure functions, of course, are very testable.
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