2

I am trying to unit test a class that has public and private methods and I want to unit test a particular method that has been set as private (protected abstract on the base). I cannot make the method public and I do not want to go through the full process to get this method tested, I am only concerned that the input argument to this method and the return meet an expectation.

I do not want to make the method public as this question highlights:

Making a private method public to unit test it...good idea?

My question would be, what are the various ways of testing private methods and which technique should I favour and why?

I have read this question (How do you unit test private methods?) but would like to know if the accepted answer is still the best answer or after years there is a better way.

If this question is considered a duplicate of How do you unit test private methods? I will add my comment there and ask for an update, please advise.

Community
  • 1
  • 1
Mr. Mr.
  • 4,257
  • 3
  • 27
  • 42

7 Answers7

6

If you can't meaningfully test the private methods of a class via the public methods then that would suggest something is wrong with the design of the class. If it is hard to test the class so that you wish to break down the tests to test a subset of its functionality then I would suggest breaking the class into its logical pieces and testing those individually.

Perhaps you have an opportunity to refactor the code so that the private methods become the public methods of some other class(es). A good example is a class that schedules some work on a timer to be processed at a later time. The work method would likely be implemented as private method making it difficult to test in a simple way without scheduling a timer and waiting around for it to execute the work method. Not ideal in a test where execution times should be very quick. A simple way around this is to split the scheduling work code into two seperate classes. The private work method then becomes the public method of the Worker class making it very easy to test. Whilst splitting the scheduling and worker code means you will struggle to achieve 100% coverage, you will at least cover the work code. A way around the problem is to use something like Quartz.net for implementing the scheduler class so that you can unit test the scheduler quite easily and the worker code as well.

Jack Hughes
  • 5,514
  • 4
  • 27
  • 32
  • 1
    +1 Yes you are right it could indicate some design flaw, but my reasoning is that it would take a lot of work to write a test for the already existing bit of functionality, which is kind of out of scope for the current change I am making. I do want to put tests in place around this fully but cannot do so right now. – Mr. Mr. May 30 '13 at 10:32
  • Your input here is actually something I agree with so would encourage people to up vote this answer so it does get the prominence it merits, although it was not possible to follow the recommendations in my specific case. – Mr. Mr. Jun 03 '13 at 08:17
2

I have read this question (How do you unit test private methods?) but would like to know if the accepted answer is still the best answer or after years there is a better way.

I would avoid the accepted answer.

I can jump into a tirade about testing the public interface and not worrying about the internals, but that might not be realistic.

There are two immediate options I can see:

  • Reflection to see the method, sort of a hack, but at least you can get some sort of test going. This is also likely the easiest to get working quickly.
  • Abstract the private method behaviour using something like the Strategy pattern and inject the behaviour into the object itself (or have the object internally new up the relevant strategy manually). This separate strategy item can then be tested independently.

That said, you shouldn't find yourself in this situation very often. If you do, you need to take a step back and review how you are designing your classes and possibly review them with a view to making them more open and testable.

Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
  • +1 Thanks for your input, I had thought about reflection too but was hoping to avoid it if possible as I suspect it would require a sizable amount of effort? – Mr. Mr. May 30 '13 at 10:33
  • @Monkieboy Not much really if you only do it for a small handful of items. Of course the code is more verbose and isn't strongly-typed or anything, but you may view that as an OK trade off. – Adam Houldsworth May 30 '13 at 11:04
1

In VS 2005, 2008 and 2010, you may have private accessor. You right click on a private function, and select "Create private accessor" ...

In VS 2012, this feature had somehow gone. The only handy way is to use PrivateObject. You may check MSDN for examples of using PrivateObject.

ZZZ
  • 2,752
  • 2
  • 25
  • 37
0

Use reflection. If you don't want to mess with reflection yourself, then you can use Microsoft's PrivateObject class located in Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. But there are problems in cooperating MSTest and NUnit - Using both MSTest and NUnit?

Community
  • 1
  • 1
nikita
  • 2,737
  • 2
  • 20
  • 26
0

Do you want to be able to call your private method in test and see how it works?

You can derive from your class and add public method that will call method you want to test. Very simple. Although I wouldn't advice testing private methods. I can't think of single reason to do it. I would love to see example that will change my mind.

Edit: Since this answer still gets some traffic I share this link. This blog post was created around 4 years after I posted my answer: https://enterprisecraftsmanship.com/posts/unit-testing-private-methods/

Piotr Perak
  • 10,718
  • 9
  • 49
  • 86
  • +1 Yes I agree, I don't really like testing the private method in isolation due to the brittleness it introduces in the future if the calling method is changed somehow, in this case there are no tests covering this but I think what I will do is actually inherit and call the base implementations going through the full flow even though I will mock out quite a lot of the internals and allow the test to evolve as changes occur in future revisions. – Mr. Mr. May 30 '13 at 12:52
  • What I did in the end was to derive from the class I wanted to test and did an override of my private method, captured the input and the output and used those in my test. – Mr. Mr. Jun 03 '13 at 08:16
  • 1
    There's even a name for what you did - "Extract and override" – Piotr Perak Jun 03 '13 at 10:16
  • Yes: http://taswar.zeytinsoft.com/2009/03/08/extract-and-override-refactoring-technique/ – Mr. Mr. Jun 03 '13 at 11:47
  • 4
    Private methods are perfectly valid testables, testing is not about the access level, access levels are a language construct only, testing is about asserting functionality, not being able to access the functionality is a limitation of the framework. Read these comments for more https://stackoverflow.com/a/249853/1441011 – Tjad Clark Feb 05 '18 at 10:07
  • Also, only protected methods are accessible from derived classes - not private methods. – Tjad Clark Feb 05 '18 at 10:17
  • @TjadClark you are right on private/protected methods accessibility from derived class. But it's just your opinion that it makes sense testing private methods. – Piotr Perak Feb 05 '18 at 13:18
  • Thing is, I have to test existing code. The code uses a private method that (all in one method) obtains a report, modifies/transforms the report data, then updates a database. Bad, BAD, design but I have neither the time, nor the go-ahead, to refactor it the way it should be done. Fortunately, MS seems to recognize that one is sometimes forced to test private methods and provides the PrivateObject class to do so. – EoRaptor013 Jul 10 '19 at 22:58
0

If you are using VS 2005 or above, use following steps

  1. Open a source code file that contains a private method.
  2. Right-click the private method, and select Create Unit Tests. This displays the Create Unit Tests dialog box. In the visible tree structure, only check box for the private method is selected.
  3. (Optional) In the Create Unit Tests dialog box, you can change the Output project. You can also click Settings to reconfigure the way unit tests are generated.
  4. Click OK. This creates a new file named VSCodeGenAccessors, which contains special accessor methods that retrieve values of private entities in the class being tested. You can see the new file displayed in Solution Explorer in the test project folder. If your test project had no unit tests before this point, a source code file to house unit tests is also created. As with the file that contains private accessors, the file that contains unit tests is also visible in your test project in Solution Explorer.
  5. Open the file that contains your unit tests and scroll to the test for the private method. Find the statements that are marked with // TODO: comments and complete them by following the directions in the comments. This helps the test produce more accurate results

For more information refer this

It looks that internally it uses reflection to call private method. But it works.

Priyang
  • 376
  • 2
  • 7
0

I actually came here for an answer to this question until I realized that I shouldn't be unit testing private methods. The reason for this, is because private methods are a piece in a process that is part of some larger logic.

Unit tests are intended to test against the interface of a class. The idea is that I am supposed to ensure quality control when using my class in the way that it is intended to. As a result, it's not useful to unit test a private method, simply because it will never be exposed to the consumer (whoever is implementing). You need to unit test against cases which the consumer can use your class.

If you find yourself with the absolute need to unit test something that is private, you might need to rethink the location of that method, or how your code is broken down. I've come to the conclusion that if I need to unit test a private method, 9/10 times it's a method that can be wrapped into a static utility class.

Serguei Fedorov
  • 7,763
  • 9
  • 63
  • 94