Most people I talk about this agree that you should only test your API methods. If you assume that the purpose of a class private methods is to support the public methods, then the fact that your public methods are working correctly kind of implies that your private methods are also working correctly.
When I have a private method that is somewhat complex and that I really think should be unit tested, I simply make it package-private (no modifier) so it's not exposed in the class API but can still be accessed by the test class.
Addressing your questions specifically:
What gives? Is this a design smell? Should I refactor somehow?
It doesn't sound like a design smell. On the contrary, having more private methods than public methods probably means that your class code is modular and follows the encapsulation principle.
Given that I should only be able to write code after a failing test, how would I go about classes that have very few public methods, such as most of my activities? Did I miss something?
Assuming you are creating a new class from scratch, I would do something like this:
- Design the class API methods
- For each API method:
- Write the unit tests for the method
- Write the code until the tests pass
- Refactor the method, extracting private methods as needed
If you do it this way, you can be sure that your private methods are covered, since you tested their functionality through the public method.
Also, a code coverage tool such as JaCoCo or Cobertura may be helpful in finding which parts of your code lack proper testing.
