Nsryjdtyk

You can use PrivateObject Class

Class target = new Class();

PrivateObject obj = new PrivateObject(target);

var retVal = obj.Invoke("PrivateMethod");

Assert.AreEqual(retVal, expectedVal);

“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 "PrivateObject" 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 "PrivateObject" and also discusses if testing of private methods are logical or not.

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<DateTime> _getNow = delegate () { return DateTime.Now; };





       //construktor for testing purposes where you "can change DateTime.Now"

       internal protected MyWatch(Func<DateTime> 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<DateTime> _getNowForTesting = delegate () { return nowforTesting; };



    MyWatch myWatch= new MyWatch(_getNowForTesting );

    nowforTesting = baseTime.AddMinute(1); //skip minute

    //TODO check myWatch

}



[TestMethod]

public void TestStabilityOnFebruary29()

{

    Func<DateTime> _getNowForTesting = delegate () { return new DateTime(2024, 2, 29); };

    MyWatch myWatch= new MyWatch(_getNowForTesting );

    //component does not crash in overlap year

}

}

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);

You can make a wrapper class around the class that contains the private method you want to test.
This wrapper class contains a public method called Call_MyPrivateFunction and which in turn calls the private function of its base class.

Please note that the access level of the method schould change to [protected]

Code Example:

public class Order

{

    public int Quantity { get; set; }



    protected bool OrderIsBig ()

    {

        //This is the method we want to test. It needs to be protected in stead of private. Else... no cigar

        return Quantity > 100;

    }

}



//Use this wrapper class in your unit test.

public class FakeOrder : Order

{



    public bool Call_OrderIsBig()

    {

        //This makes the actual call to the protected method "OrderIsBig"

        return OrderIsBig();

    }

}

The unit test code could look like:

FakeOrder order = new FakeOrder();

order.Quantity = 200;



bool isBig = order.Call_OrderIsBig();   //Make a call to a public method of the FakeOrder class which in turn makes a call to the protected method.

TL;DR: 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.

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.

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