We also talk about testing private members in nunit.

When I saw muddle talking about testing non-public members in his blog, I suddenly thought that I had asked this question on csdn. At that time, I thought I would say, the test should also follow the OOP principle. I feel very touched and have a new view on this issue.

My current idea is that private members should not be tested.

First, nunit and other tools should be used to test External Interfaces. Especially in test-driven development, when you write test case, it actually forces you to stand on the user's standpoint, write a test case, that is, write a use case, which enables youProgramWith a deeper understanding, users obviously should not be aware of the Implementation Details of Private Members. If you also test Private Members, this effect of unit testing will be broken.

Second, Private Members will be called by public members. Therefore, the test on Private Members is implemented during the test of public members. If private members are already complex and must be tested separately, you should consider whether your design is too complicated. In many cases, private members have a test requirement because the design violates the single responsiblity principle. You need to separate private members that implement complex functions and write them into an independent class.

There is a saying in XP: trying to make your ownCodeWhen it becomes easier to test, a good design will emerge, so there will be a saying that testing is the design. When the classes you write are difficult to test, you should consider whether bad smell appears in your design.