Unit testing private methods in C

Question

Visual Studio allows unit testing of private methods via an automatically generated accessor class  I have written a test of a private method that compiles successfully  but it fails at runtime  A fairly minimal version of the code and the test is     in project MyProj class TypeA       private List lt TypeB gt  myList   new List lt TypeB gt          private class TypeB               public TypeB                                  public TypeA                    private void MyFunc                   processing of myList that changes state of instance                in project TestMyProj            public void MyFuncTest         TypeA Accessor target   new TypeA Accessor          following line is the one that throws exception     target myList Add new TypeA Accessor TypeB         target MyFunc           check changed state of target     The runtime error is   Object of type System Collections Generic List 1 MyProj TypeA TypeA Accessor TypeB   cannot be converted to type  System Collections Generic List 1 MyProj TypeA TypeA TypeB      According to intellisense - and hence I guess the compiler - target is of type TypeA Accessor  But at runtime it is of type TypeA  and hence the list add fails   Is there any way I can stop this error  Or  perhaps more likely  what other advice do other people have  I predict maybe  don t test private methods  and  don t have unit tests manipulate the state of objects

User · Answer

You can use PrivateObject Class Class target   new Class    PrivateObject obj   new PrivateObject target   var retVal   obj Invoke  quot PrivateMethod quot    Assert AreEqual expectedVal  retVal    Note  PrivateObject and PrivateType are not available for projects targeting netcoreapp2 0 - GitHub Issue 366

User · Answer

Another option that has not been mentioned is just creating the unit test class as a child of the object that you are testing  NUnit Example    TestFixture  public class UnitTests   ObjectWithPrivateMethods        Test      public void TestSomeProtectedMethod                 Assert IsTrue this SomeProtectedMethod      true   Failed test  result false              This would allow easy testing of private and protected  but not inherited private  methods  and it would allow you to keep all your tests separate from the real code so you aren t deploying test assemblies to production  Switching your private methods to protected methods would be  acceptable in a lot of inherited objects  and it is a pretty simple change to make    HOWEVER     While this is an interesting approach to solving the problem of how to test hidden methods  I am unsure that I would advocate that this is the correct solution to the problem in all cases  It seems a little odd to be internally testing an object  and I suspect there might be some scenarios that this approach will blow up on you   Immutable objects for example  might make some tests really hard     While I mention this approach  I would suggest that this is more of a brainstormed suggestion than a legitimate solution  Take it with a grain of salt   EDIT  I find it truly hilarious that people are voting this answer down  since I explicitly describe this as a bad idea  Does that mean that people are agreeing with me  I am so confused

User · Answer

Extract private method to another class  test on that class  read more about SRP principle  Single Responsibility Principle  It seem that you need extract to the private method to another class  in this should be public  Instead of trying to test on the private method  you should test public method of this another class  We has the following scenario  Class A   outputFile  Stream -  someLogic arg1  arg2    We need to test the logic of  someLogic  but it seem that Class A take more role than it need violate the SRP principle   just refactor into two classes Class A1       A1 logicHandler  A2    take A2 for handle logic       outputFile  Stream Class A2       someLogic arg1  arg2    In this way someLogic could be test on A2  in A1 just create some fake A2 then inject to constructor to test that A2 is called to the function named someLogic

User · Answer

In VS 2005 2008 you can use private accessor to test private member but this way was disappear in later version of VS

User · Answer

From the book Working Effectively with Legacy Code        If we need to test a private method  we should make it public  If   making it public bothers us  in most cases  it means that our class is   doing too much and we ought to fix it     The way to fix it  according to the author  is by creating a new class and adding the method as public   The author explains further       Good design is testable  and design that isn t testable is bad     So  within these limits  your only real option is to make the method public  either in the current or a new class

User · Answer

There is nothing called as standard or best practice  probably they are just popular opinions     Same holds true for this discussion as well   It all depends on what you think is a unit   if you think UNIT is a class then you will only hit the public method  If you think UNIT is lines of code hitting private methods will not make you feel guilty  If you want to invoke private methods you can use  quot PrivateObject quot  class and call the invoke method  You can watch this indepth youtube video   http   www youtube com watch v Vq6Gcs9LrPQ   which shows how to use  quot PrivateObject quot  and also discusses if testing of private methods are logical or not

User · Answer

Another thought here is to extend testing to  internal  classes methods  giving more of a white-box sense of this testing  You can use InternalsVisibleToAttribute on the assembly to expose these to separate unit testing modules   In combination with sealed class you can approach such encapsulation that test method are visible only from unittest assembly your methods  Consider that protected method in sealed class is de facto private    assembly  InternalsVisibleTo  MyCode UnitTests    namespace MyCode MyWatch        pragma warning disable CS0628   invalid because of InternalsVisibleTo     public sealed class MyWatch               Func lt DateTime gt   getNow   delegate      return DateTime Now                construktor for testing purposes where you  can change DateTime Now         internal protected MyWatch Func lt DateTime gt  getNow                       getNow   getNow                   public MyWatch                                          And unit test   namespace MyCode UnitTests     TestMethod  public void TestminuteChanged           watch for traviling in time     DateTime baseTime   DateTime Now      DateTime nowforTesting   baseTime      Func lt DateTime gt   getNowForTesting   delegate      return nowforTesting          MyWatch myWatch  new MyWatch  getNowForTesting        nowforTesting   baseTime AddMinute 1     skip minute       TODO check myWatch     TestMethod  public void TestStabilityOnFebruary29         Func lt DateTime gt   getNowForTesting   delegate      return new DateTime 2024  2  29          MyWatch myWatch  new MyWatch  getNowForTesting          component does not crash in overlap year

User · Answer

Ermh    Came along here with exactly the same problem  Test a simple  but pivotal private method  After reading this thread  it appears to be like  I want to drill this simple hole in this simple piece of metal  and I want to make sure the quality meets the specs   and then comes  Okay  this is not to easy  First of all  there is no proper tool to do so  but you could build a gravitational-wave observatory in your garden  Read my article at http   foobar brigther-than-einstein org  First  of course  you have to attend some advanced quantum physics courses  then you need tons of ultra-cool nitrogenium  and then  of course  my book available at Amazon      In other words     No  first things first   Each and every method  may it private  internal  protected  public has to be testable  There has to be a way to implement such tests without such ado as was presented here   Why  Exactly because of the architectural mentions done so far by some contributors  Perhaps a simple reiteration of software principles may clear up some missunderstandings   In this case  the usual suspects are  OCP  SRP  and  as always  KIS   But wait a minute  The idea of making everything publicly available is more of less political and a kind of an attitude  But  When it comes to code  even in then Open Source Community  this is no dogma  Instead   hiding  something is good practice to make it easier to come familiar with a certain API  You would hide  for example  the very core calculations of your new-to-market digital thermometer building block--not to hide the maths behind the real measured curve to curious code readers  but to prevent your code from becoming dependent on some  perhaps suddenly important users who could not resist using your formerly private  internal  protected code to implement their own ideas   What am I talking about      private double TranslateMeasurementIntoLinear double actualMeasurement     It s easy to proclaim the Age of Aquarius or what is is been called nowadays  but if my piece of sensor gets from 1 0 to 2 0  the implementation of Translate    might change from a simple linear equation that is easily understandable and  re-usable  for everybody  to a pretty sophisticated calculation that uses analysis or whatever  and so I would break other s code  Why  Because they didn t understand the very priciples of software coding  not even KIS   To make this fairy tale short  We need a simple way to test private methods--without ado   First  Happy new year everyone   Second  Rehearse your architect lessons   Third  The  public  modifier is religion  not a solution

User · Answer

Yes  don t Test private methods       The idea of a unit test is to test the unit by its public  API        If you are finding you need to test a lot of private behavior  most likely you have a new  class  hiding within the class you are trying to test   extract it and test it by its public interface   One piece of advice   Thinking tool       There is an idea that no method should ever be private   Meaning all methods should live on a public interface of an object     if you feel you need to make it private  it most likely lives on another object   This piece of advice doesn t quite work out in practice  but its mostly good advice  and often it will push people to decompose their objects into smaller objects

User · Answer

One way to test private methods is through reflection  This applies to NUnit and XUnit  too   MyObject objUnderTest   new MyObject    MethodInfo methodInfo   typeof MyObject  GetMethod  SomePrivateMethod   BindingFlags NonPublic   BindingFlags Instance   object   parameters     parameters here    methodInfo Invoke objUnderTest  parameters

[c#] Unit testing private methods in C#

Examples related to c#

Examples related to unit-testing

Examples related to mstest