0

I was learning about TDD, I have few questions about it.

  1. Should I test private method in Springmvc Service? In other related questions, there are two main point about testing private method, one is negative because it may break the packaging; one is postive that some private method maybe really important. My question is, private method in Spring service sometimes are independent parts that make up a complete function, they have their own function, in my opinion, these private methods in spring Service are different from those in normal Object Classes, and I tend to test them。

  2. Should I use protected or package-protected level for private methods in Spring Service? When I use Mockito, the document says

It is very easy to work around - just change the visibility of method from private to package-protected (or protected). I can't understand it because it is really rare to see protected/package-protected mthods in service.

SiYu Liu
  • 1
  • 1
  • Does this answer your question? [How do I test a private function or a class that has private methods, fields or inner classes?](https://stackoverflow.com/questions/34571/how-do-i-test-a-private-function-or-a-class-that-has-private-methods-fields-or) – Raedwald Jul 24 '21 at 10:01

1 Answers1

2

With test-driven development (TDD) you write the test before the implementation. From this it follows that you can't (immediately) have any private methods. In TDD, you add only enough code to pass all tests.

A slightly more sophisticated view is that the most common TDD process is red-green-refactor. The red and green phases still can't produce any private methods, but in the refactor phase, you are free to extract some of the existing code (already covered by tests) to private helper methods, as long as you don't break any tests.

Thus, TDD can produce private methods, but they will already be covered by tests. Thus, asking whether private methods should be covered by tests when following TDD makes little sense. In TDD, all production code is covered by tests, because no production code is written unless it's to make a test pass.

In practice, an application code base will need some Humble Objects and other infrastructure code that you can't easily unit test. That's not really part of the TDD process, though.

In any case, you shouldn't attempt to directly unit test internal implementation details. Private methods should, if at all possible, be covered through the System Under Test's public API.

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • Thanks a lot, it helps a lot. But I'm still confused that, in projects based on Spring, the public methods are mainly the entrance of a business process, and sometimes, the whole process was split into many sub processes, and most of them are private methods. This make the situation very complex to only test the public method, it might not be accurate. Is this a common phenomenon or our design is not good enough? – SiYu Liu Aug 01 '21 at 04:46
  • @SiYuLiu *"the whole process was split into many sub processes, and most of them are private methods."* But those private methods were already covered by unit tests, weren't they? – Mark Seemann Aug 01 '21 at 16:09