2 Replies - 1602 Views - Last Post: 08 October 2015 - 06:52 PM

#1 rgfirefly24  Icon User is offline

  • D.I.C Lover
  • member icon


Reputation: 446
  • View blog
  • Posts: 2,177
  • Joined: 07-April 08

Unit Testing of private / internal methods

Posted 08 October 2015 - 03:21 PM

So a discussion was had recently on unit testing and coverage vs encapsulation. I've always been told that you do not write tests against internal or private methods, but one of the other developers said that it's better to make private methods internal and use AssemblyVisibleTo in order to make them visible to your test assembly. What are your thoughts on this? Do you think that for testing purposes it's better to set all non public methods as internal, or do you follow the same principle that you only should test public methods.

With that, do you also write tests for all conditions, say you have a try/catch that throws a certain exception in the case where an action times out. Would you write a test that specifically throws that error, or do you just write tests that test the core execution path?

My thoughts are that you don't write tests against non-public methods simply because they are used as supporting methods and will/should get covered by other tests that enter through a public method. As far as the testing of methods, I've always written tests to test catch conditions where I expect the results and not really for general catches. Meaning that if I explicitly say that I should catch TimeoutException then I'll write a test for it, but if I have a general Exception catch, and I know it will get hit if a specific object is null, I won't write a test that sets that object null.

Is This A Good Question/Topic? 0
  • +

Replies To: Unit Testing of private / internal methods

#2 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5894
  • View blog
  • Posts: 20,121
  • Joined: 05-May 12

Re: Unit Testing of private / internal methods

Posted 08 October 2015 - 06:24 PM

For a brand new code base, only test against public methods. For existing code, you maybe forced to test both public and private methods unless you are willing to take on the overhead and risk of refactoring the existing code.
Was This Post Helpful? 0
  • +
  • -

#3 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5894
  • View blog
  • Posts: 20,121
  • Joined: 05-May 12

Re: Unit Testing of private / internal methods

Posted 08 October 2015 - 06:52 PM

For me the factor that will determine whether I will be forced to test against the private methods is how tightly coupled the code is. If the code is loosely coupled and follows the Liskov Substitution Principle through some form of dependency injection, then I should be able to test everything through public methods only. This is because I should be able to mock all the dependencies to coerce conditions, as well as examine the resultant state. I can also test each of the dependencies in a similar manner. The lowest level dependency that I cannot mock any inputs or outputs for should be written so trivially that no test is really needed because code inspection will be sufficient.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1