We Keep Coding

How do I write unit tests for subclass with parameterized base class

Given that I have a class in one assembly called GBase with a constructor that takes 2 parameters and a subclass of GBase (call it GDerived) that takes the same parameters, how do I separate these so that I can unit test the subclass?
In OtherAssembly:
public class GBase
{
public GBase(ParamType1 param1, ParamType2 param2)
{
...
}
protected ParamType1 SomeProperty { get; set; }
// other stuff
}
In ThisAssembly:
public class GDerived : GBase
{
public GDerived(ParamType1 param1, ParamType2 param2)
:base(param1, param2)
{
// new code
SomeProperty = newCalculatedValue;
// other stuff
}
// other stuff
}
The original GBase class is legacy code, as is the general structure of the program -- changing the structure is out of the question due to the codebase size (10k lines plus) - none of which has ever had a unit test written for it until very recently.
So now I want to write a test (using NUnit) for the subclass constructor to verify the correct properties are populated with the correct values. Note the test classes are in the same project as the tested classes.
[TestFixture]
public class GDerivedTests
{
[Test]
public void GDerivedConstructor_ValidParams_PropertiesSetCorrectly()
{
var newGDerived = new GDerived(parameter1, parameter2);
Assert.That(SomeProperty == parameter1;
}
}
This is a very crude rep of what we have to deal with, and there are cases other than setting a property in the base class we need to test. I just don't even know for sure where to start. I have Michael Feathers' book Working Effectively with Legacy Code but it doesn't seem to cover this pervasive "design pattern", used extensively throughout the code we are dealing with. Is it because it's so simple any blinking idjyot should know how to deal with it, or is it because it's a rare case? Somehow I don't think it's either, but I could be wrong...
One possible method I thought of is to extract an interface for the base class and mock the base class constructor - but I'm not sure of the details on how to do that. Note we are all relative newbies at unit testing on the team, no experience to draw on. Not coding newbies, just unit test newbies.
TIA,
Dave

To start with: keep it simple! In your example, the only thing you can test is SomeProperty. Everything else is in the base class which you seem that you don't want to test so a test method GDerivedConstructor_ValidParams_PropertiesSetCorrectly() makes no sense. Long-term, it could be wise having tests for it though.
Tests typically contain three elements known as AAA: Arrange, Act and Assert. So write your test like this:
[Test]
public void GDerivedTestOfSomeProperty()
{
// arrange
ParamOfSomeProperty expected = ValueWeAreLookingFor; // this is something that you
// have in newCalculatedValue
// act
GDerived actual = new GDerived(
AnyValueThatMakesThisTestWork1, // maybe null?
AnyValueThatMakesThisTestWork2); // maybe null?
// assert
Assert.AreEqual(expected, actual.SomeProperty);
}
That's it for a start. Go from here. You will soon see that you get lots of redundant code so you possibly want to re-engineer that after a while.
Mocking makes sense for testing the base class or when the base class does some weird stuff with the objects that are injected. In this case, pass in mocks instead of real objects. I personally would use a mocking framework that does all the job for you and you can also use this for testing the base class itself. A famous example is moq.
On a side note: you'll be better off if you move your test classes into its own project. Testing code should not be released for various reasons plus building, testing and deploying may get easier if they are separated.

Should you have duplicate unit tests for seperate methods that share the same private implementation?

I am building a business layer for our large enterprise application, and we're currently sitting at just under 500 unit tests. The scenario is that we have two public methods, public AddT(T) and public UpdateT(T) that both make an internal call to private AddOrUpdateT(T) since a lot of the core logic is the same between both, but not all; they are different.
Because they are separate public API (regardless of private implementation), I wrote unit tests for each API, even though they are the same. This might look like
[TestMethod]
public void AddT_HasBehaviorA()
{
}
[TestMethod]
public void UpdateT_HasBehaviorA()
{
}
Currently for this particular business object there are around 30 unit tests for adding, and 40 unit tests for updating, where 30 of the update tests are the same as the add tests.
Is this normal, or should I be abstracting the common behavior out into a public helper class that is unit tested in isolation, and the two API's just use that helper class instead of a private method that has the implementation?
What is considered a best practice for these situations?

First of all, it's important to understand why you want to cover those methods by unit tests, because that's going to influence the answer. Only you and your team knows this, but if we assume that at least part of the motivation for unit testing is to get a trustworthy regression test suite, you should test the observable behaviour of the System Under Test (SUT).
In other words, unit tests should be black box tests. The tests shouldn't know about the implementation details of the SUT. Thus, the naive conclusion you could draw from this is that if you have duplicate behaviour, you should also have duplicate test code.
However, the more complex your system becomes, and the more it relies on common behaviour and strategies, the harder it becomes to implement this testing strategy. This is because you'll have a combinatorial explosion of possible ways through the system. J.B. Rainsberger explains it better than I do.
A better alternative is often to listen to your tests (a concept popularized by GOOS). In this case, it sounds like it would be valuable to extract the common behaviour into a public method. This, however, doesn't itself solve the problem of combinatorial explosion. While you can now test the common behaviour in isolation, you also need to prove that the two original methods (Add and Update) use the new public method (instead of, e.g., some copy-and-pasted code).
The best way to do that is to compose the methods with the new Strategy:
public class Host<T>
{
private readonly IHelper<T> helper;
public Host(IHelper<T> helper)
{
this.helper = helper;
}
public void Add(T item)
{
// Do something
this.helper.AddOrUpdate(item);
// Do something else
}
public void Update(T item)
{
// Do something
this.helper.AddOrUpdate(item);
// Do something else
}
}
(Obviously, you'll need to give the types and methods better names.)
This enables you to use Behaviour Verification to prove that the Add and Update methods correctly use the AddOrUpdate method:
[TestMethod]
public void AddT_HasBehaviorA()
{
var mock = new Mock<IHelper<object>>();
var sut = new Host<object>(mock.Object);
var item = new object();
sut.Add(item);
mock.Verify(h => h.AddOrUpdate(item));
}
[TestMethod]
public void UpdateT_HasBehaviorA()
{
var mock = new Mock<IHelper<object>>();
var sut = new Host<object>(mock.Object);
var item = new object();
sut.Update(item);
mock.Verify(h => h.AddOrUpdate(item));
}

It is a good practice to avoid duplication as much as possible. This aids code readability and maintainability (and probably other *ablilities ;-)). It also makes testing easier as you can start to test the common functionality in one place and not have to have so many duplicate tests. Also, duplication in tests is bad as well.
Another best practice is to only write unit tests for functionality that has unique logic. If in your Add and Update methods, you are only calling another method, there is no need to write unit tests at that level, you should be focusing on the called method.
Which brings up back to the initial point of not duplicating code and if you have private methods that share duplicate code, it may be a good idea to break it out into something else that you can run tests against.

"Since a lot of the core logic is the same between both, but not all; they are different."
I think you should have separate unit tests for these, because as you say they are not exactly the same. Also, what if you later change the implementation to call two different methods? Then your unit tests will only be testing one of them because they are coupled to the implementation detail of the two methods. The tests will pass, but you may have introduced a bug.
I think a better approach is to test both methods but add helper methods/classes to do the common work.

Unit Testing with AOP/PostSharp

I'm trying to use PostSharp to implement a security aspect in order to apply method level authorisation checks in my repository layer.
The concept is outlined here.
However these authorisation checks are getting in the way during unit testing, making them more into integration tests.
What would be the best way to isolate these as unit tests, essentially ignoring/mocking the security aspect so that I can just test the actual class behaviour without the need to initialise a bunch of security information?
Does AOP inherently conflict with unit testing?

To answer your 2nd question first, no, AOP doesn’t inherently conflict with unit testing. Usually I’d say it’s best to unit test the methods and the aspects separately.
In your case, there are several options.
The easiest is simply to have the unit test setup method make sure the thread has the required permissions.
If you don’t want to do that, there are two ways you could separate things out for your unit test.
The first is to extract all the code from the methods that you are applying security aspects to into separate methods like this:
[SecurityAspect]
void DoSomething()
{
DoSomethingInternal();
}
void DoSomethingInternal()
{
// this is the real code
}
Then you can run your unit tests against all the unsecured ‘internal’ methods – which tests the logic in them without worrying about security.
The second approach would be to inject a mock permissions tester into the aspect itself. To be able to do this, you would have to define a separate class and interface that does the actual logic of testing the security, something like this (assuming it’s a Thread that you pass in to verify the security):
public interface IPermissionsChecker
{
bool HasPermissions(Thread thread);
}
This is your permissions checker for your live system:
public class RealPermissionsChecker : IPermissionsChecker
{
public bool HasPermissions(Thread thread)
{
// do your real work here
}
}
And this is the one you’ll use in your unit tests
public class MockPermissionsChecker : IPermissionsChecker
{
public bool HasPermissions(Thread thread)
{
return true;
}
}
Now you need to define your aspect something like this:
public class SecurityChecker : OnMethodBoundaryAspect
{
IPermissionsChecker _checker;
public override void OnEntry(MethodExecutionArgs args)
{
if (!_checker.HasPermissions(Thread.CurrentThread))
throw new SecurityException("No permissions");
}
}
The only remaining issue is the need to inject the correct permissions checker into the aspect.
The slightly hacky way I've done this before is to make _checker a static field, and provide a static method to initialize it:
public class SecurityChecker : OnMethodBoundaryAspect
{
private static IPermissionsChecker _checker;
public static void InjectChecker(IPermissionsChecker checker)
{
// best put some code here to make sure this is only called once,
// as well as doing thread synchronization
if (_checker == null)
_checker = checker;
}
The fact that InjectChecker is static means you can access it from your app startup (or unit test startup) code. I suspect unit test purists would frown on this - and you do have to make sure you do call it at app startup, but I think it is the simplest way to inject the checker into the aspect, circumventing the fact that the rest of your code can't directly access instances of the aspect.
The more complicated alternative is to override RunTimeInitialize() in your aspect - this method is called by PostSharp when the aspect is initialized. You'd probably do something like this:
public override void RuntimeInitialize(MethodBase method)
{
base.RuntimeInitialize();
this._checker =PermissionsCheckerProvider.Current.GetChecker();
}
You'll see that requires you to define another class:
public class PermissionsCheckerProvider
{
// make sure you set this at app startup, either to the mock or to the real checker
public static PermissionsCheckerProvider Current { get; set;}
public IPermissionsChecker GetChecker()
{
}
}
This approach guarantees that the method will attempt its initialization at the right time, but then you have the problem of making sure you have supplied an appropriate current provider before the aspect attempts to initialize. So I personally would probably go for the first approach to keep things simple.
There's some discussion about dependency injection and RuntimeInitialize here. https://codereview.stackexchange.com/questions/20341/inject-dependency-into-postsharp-aspect

Two links that extensively answer your question:
Recording of a webinar on the subject, with two different opinions: Matt Groves and myself
Official PostSharp documentation about testing of aspects

If you are using Typemock in your unit tests you can use something like
MyAspect myAspectMock = Isolate.Fake.Instance<MyAspect>(Members.MustSpecifyReturnValues);
Isolate.Swap.AllInstances<MyAspect>().With(myAspectMock);
This allows you to control what tests the aspects are used on, and which ones are not, allowing you to test the method itself, and with the advices applied.
Presumably there would be a similar mechanism with other mocking frameworks

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

Moderator Note: There are already 39 answers posted here (some have been deleted). Before you post your answer, consider whether or not you can add something meaningful to the discussion. You're more than likely just repeating what someone else has already said.
I occasionally find myself needing to make a private method in a class public just to write some unit tests for it.
Usually this would be because the method contains logic shared between other methods in the class and it's tidier to test the logic on its own, or another reason could be possible be I want to test logic used in synchronous threads without having to worry about threading problems.
Do other people find themselves doing this, because I don't really like doing it?? I personally think the bonuses outweigh the problems of making a method public which doesn't really provide any service outside of the class...
UPDATE
Thanks for answers everyone, seems to have piqued peoples' interest. I think the general consensus is testing should happen via the public API as this is the only way a class will ever be used, and I do agree with this. The couple of cases I mentioned above where I would do this above were uncommon cases and I thought the benefits of doing it was worth it.
I can however, see everyones point that it should never really happen. And when thinking about it a bit more I think changing your code to accommodate tests is a bad idea - after all I suppose testing is a support tool in a way and changing a system to 'support a support tool' if you will, is blatant bad practice.

Note:
This answer was originally posted for the question Is unit testing alone ever a good reason to expose private instance variables via getters? which was merged into this one, so it may be a tad specific to the usecase presented there.
As a general statement, I'm usually all for refactoring "production" code to make it easier to test. However, I don't think that would be a good call here. A good unit test (usually) shouldn't care about the class' implementation details, only about its visible behavior. Instead of exposing the internal stacks to the test, you could test that the class returns the pages in the order you expect it to after calling first() or last().
For example, consider this pseudo-code:
public class NavigationTest {
private Navigation nav;
#Before
public void setUp() {
// Set up nav so the order is page1->page2->page3 and
// we've moved back to page2
nav = ...;
}
#Test
public void testFirst() {
nav.first();
assertEquals("page1", nav.getPage());
nav.next();
assertEquals("page2", nav.getPage());
nav.next();
assertEquals("page3", nav.getPage());
}
#Test
public void testLast() {
nav.last();
assertEquals("page3", nav.getPage());
nav.previous();
assertEquals("page2", nav.getPage());
nav.previous();
assertEquals("page1", nav.getPage());
}
}

Personally, I'd rather unit test using the public API and I'd certainly never make the private method public just to make it easy to test.
If you really want to test the private method in isolation, in Java you could use Easymock / Powermock to allow you to do this.
You have to be pragmatic about it and you should also be aware of the reasons why things are difficult to test.
'Listen to the tests' - if it's difficult to test, is that telling you something about your design? Could you refactor to where a test for this method would be trivial and easily covered by testing through the public api?
Here's what Michael Feathers has to say in 'Working Effectively With Legacy Code"
"Many people spend a lot of time trying ot figure out how to get around this problem ... the real answer is that if you have the urge to test a private method, the method shouldn't be private; if making the method public bothers you, chances are, it is because it is part of a separate reponsibility; it should be on another class." [Working Effectively With Legacy Code (2005) by M. Feathers]

As others have said, it is somewhat suspect to be unit testing private methods at all; unit test the public interface, not the private implementation details.
That said, the technique I use when I want to unit test something that is private in C# is to downgrade the accessibility protection from private to internal, and then mark the unit testing assembly as a friend assembly using InternalsVisibleTo. The unit testing assembly will then be allowed to treat the internals as public, but you don't have to worry about accidentally adding to your public surface area.

Lots of answers suggest only testing the public interface, but IMHO this is unrealistic - if a method does something that takes 5 steps, you'll want to test those five steps separately, not all together. This requires testing all five methods, which (other than for testing) might otherwise be private.
The usual way of testing "private" methods is to give every class its own interface, and make the "private" methods public, but not include them in the interface. This way, they can still be tested, but they don't bloat the interface.
Yes, this will result in file- and class-bloat.
Yes, this does make the public and private specifiers redundant.
Yes, this is a pain in the ass.
This is, unfortunately, one of the many sacrifices we make to make code testable. Perhaps a future language (or a even a future version of C#/Java) will have features to make class- and module-testability more convenient; but in the meanwhile, we have to jump through these hoops.
There are some who would argue that each of those steps should be its own class, but I disagree - if they all share state, there is no reason to create five separate classes where five methods would do. Even worse, this results in file- and class-bloat. Plus, it infects the public API of your module - all those classes must necessarily be public if you want to test them from another module (either that, or include the test code in the same module, which means shipping the test code with your product).

A unit test should test the public contract, the only way how a class could be used in other parts of the code. A private method is implementation details, you should not test it; as far as public API works correctly, the implementation doesn't matter and could be changed without changes in test cases.

IMO, you should write your tests not making deep assumptions on how your class implemented inside. You probably want to refactor it later using another internal model but still making the same guarantees that previous implementation gives.
Keeping that in mind I suggest you to focus on testing that your contract is still holds no matter what internal implementation your class currently have. Property based testing of your public APIs.

How about making it package private? Then your test code can see it (and other classes in your package as well), but it is still hidden from your users.
But really, you should not be testing private methods. Those are implementation details, and not part of the contract. Everything they do should be covered by calling the public methods (if they have code in there that is not exercised by the public methods, then that should go). If the private code is too complex, the class is probably doing too many things and in want of refactoring.
Making a method public is big commitment. Once you do that, people will be able to use it, and you cannot just change them anymore.

Update: I have added a more expanded and more complete answer to this question in numerous other places. This is can be found on my blog.
If I ever need to make something public to test it, this usually hints that the system under test is not following the Single Reponsibility Principle. Hence there is a missing class that should be introduced. After extracting the code into a new class, make it public. Now you can test easily, and you are following SRP. Your other class simply has to invoke this new class via composition.
Making methods public/using langauge tricks such as marking code as visible to test assembilies should always be a last resort.
For example:
public class SystemUnderTest
{
public void DoStuff()
{
// Blah
// Call Validate()
}
private void Validate()
{
// Several lines of complex code...
}
}
Refactor this by introducing a validator object.
public class SystemUnderTest
{
public void DoStuff()
{
// Blah
validator.Invoke(..)
}
}
Now all we have to do is test that the validator is invoked correctly. The actual process of validation (the previously private logic) can be tested in pure isolation. There will be no need for complex test set up to ensure this validation passes.

Some great answers. One thing I didn't see mentioned is that with test-driven development (TDD), private methods are created during the refactoring phase (look at Extract Method for an example of a refactoring pattern), and should therefore already have the necessary test coverage. If done correctly (and of course, you're going to get a mixed bag of opinions when it comes to correctness), you shouldn't have to worry about having to make a private method public just so that you can test it.

If you are using C# you can make method internal. That way you don't pollute public API.
Then add attribute to dll
[assembly: InternalsVisibleTo("MyTestAssembly")]
Now all the methods are visible in your MyTestAssembly project. Maybe not perfect, but better then making private method public just to test it.

Why not split out the stack management algorithm into a utility class? The utility class can manage the stacks and provide public accessors. Its unit tests can be focussed on implementation detail. Deep tests for algorithmically tricky classes are very helpful in wrinkling out edge cases and ensuring coverage.
Then your current class can cleanly delegate to the utility class without exposing any implementation details. Its tests will relate to the pagination requirement as others have recommended.

In java, there's also the option of making it package private (ie leaving off the visibility modifier). If your unit tests are in the same package as the class being tested it should then be able to see these methods, and is a bit safer than making the method completely public.

Private methods are usually used as "helper" methods. Therefore they only return basic values and never operate on specific instances of objects.
You have a couple of options if you want to test them.
Use reflection
Give the methods package access
Alternatively you could create a new class with the helper method as a public method if it is a good enough candidate for a new class.
There is a very good article here on this.

Use reflection to access the private variables if you need to.
But really, you don't care about the internal state of the class, you just want to test that the public methods return what you expect in the situations you can anticipate.

In your update you say that it's good to just test using the public API.
There is actually two schools here.
Black box testing
The black box school says that the class should be considered as a black box that no one can see the implementation inside it. The only way to test this is through the public API -- just like the user's of the class will be using it.
white box testing.
The white box school thinks it naturally to use the knowledge about the implementation of the class and then test the class to know that it works as it should.
I really cannot take side in the discussion. I just thought it would be interesting to know that there are two distinct ways to test a class (or a library or whatever).

in terms of unit testing, you should definitely not add more methods; I believe you would better make a test case just about your first() method, which would be called before each test; then you can call multiple times the - next(), previous() and last() to see if the outcomes match your expectation.
I guess if you don't add more methods to your class (just for testing purposes), you would stick to the "black box" principle of testing;

You should never ever ever let your tests dictate your code. I'm not speaking about TDD or other DDs I mean, exactly what your asking. Does your app need those methods to be public. If it does then test them. If it does not then then don't make them public just for testing. Same with variables and others. Let your application's needs dictate the code, and let your tests test that the need is met. (Again I don't mean testing first or not I mean changing a classes structure to meet a testing goal).
Instead you should "test higher". Test the method that calls the private method. But your tests should be testing your applications needs and not your "implementation decisions".
For example (bod pseudo code here);
public int books(int a) {
return add(a, 2);
}
private int add(int a, int b) {
return a+b;
}
There is no reason to test "add" you can test "books" instead.
Never ever let your tests make code design decisions for you. Test that you get the expected result, not how you get that result.

I would say it is a bad idea for I am not sure whether you get any benefit and potentially problems down the line. If you are changing the contract of a calls, just to test a private method, you're not testing the class in how it would be used, but creating an artificial scenario which you never intended to happen.
Furthermore, by declaring the method as public, what's to say that in six months time (after forgetting that the only reason for making a method public is for testing) that you (or if you've handed the project over) somebody completely different won't use it, leading to potentially unintended consequences and/or a maintenance nightmare.

First see if the method ought to be extracted into another class and made public. If that's not the case, make it package protected and in Java annotate with #VisibleForTesting.

Private methods that you want to test in isolation are an indication that there's another "concept" buried in your class. Extract that "concept" to its own class and test it as a separate "unit".
Take a look at this video for a really interesting take on the subject.

There are actually situations when you should do this (e.g. when you're implementing some complex algorithms). Just do it package-private and this will be enough.
But in most cases probably you have too complex classes which requires factoring out logic into other classes.

I tend to agree that the bonuses of having it unit tested outweigh the problems of increasing the visibility of some of the members. A slight improvement is to make it protected and virtual, then override it in a test class to expose it.
Alternatively, if it's functionality you want to test separately does it not suggest a missing object from your design? Maybe you could put it in a separate testable class...then your existing class just delegates to an instance of this new class.

I generally keep the test classes in the same project/assembly as the classes under test.
This way I only need internal visibility to make functions/classes testable.
This somewhat complicates your building process, which needs to filter out the test classes.
I achieve this by naming all my test classes TestedClassTest and using a regex to filter those classes.
This of course only applies to the C# / .NET part of your question

I will often add a method called something like validate, verify, check, etc, to a class so that it can be called to test the internal state of an object.
Sometimes this method is wrapped in an ifdef block (I write mostly in C++) so that it isn't compiled for release. But it's often useful in release to provide validation methods that walk the program's object trees checking things.

Guava has a #VisibleForTesting annotation for marking methods that have enlarged scope (package or public) that they would otherwise. I use a #Private annotation for the same thing.
While the public API must be tested, sometimes it's convenient and sensible to get at stuff that wouldn't normally be public.
When:
a class is made significantly less readable, in toto, by breaking it up into multiple classes,
just to make it more testable,
and providing some test access to the innards would do the trick
it seems like religion is trumping engineering.

I usually leave those methods as protected and place the unit test within the same package (but in another project or source folder), where they can access all the protected methods because the class loader will place them within the same namespace.

No, because there are better ways of skinning that cat.
Some unit test harnesses rely on macros in the class definition which automagically expand to create hooks when built in test mode. Very C style, but it works.
An easier OO idiom is to make anything you want to test "protected" rather than "private". The test harness inherits from the class under test, and can then access all protected members.
Or you go for the "friend" option. Personally this is the feature of C++ I like least because it breaks the encapsulation rules, but it happens to be necessary for how C++ implements some features, so hey ho.
Anyway, if you're unit testing then you're just as likely to need to inject values into those members. White box texting is perfectly valid. And that really would break your encapsulation.

In .Net there is a special class called PrivateObject deigned specifically to allow you to access private methods of a class.
See more about it on the MSDN or here on Stack Overflow
(I am wondering that no one has mentioned it so far.)
There are situations though which this is not enough, in which case you will have to use reflection.
Still I would adhere to the general recommendation not to test private methods, however as usual there are always exceptions.

Very answered question.
IHMO, the excellent answer from #BlueRaja - Danny Pflughoeft is one of the best.
Lots of answers suggest only testing the public interface, but IMHO
this is unrealistic - if a method does something that takes 5 steps,
you'll want to test those five steps separately, not all together.
This requires testing all five methods, which (other than for testing)
might otherwise be private.
Above all, I want to stress that the question "should we make a private method public to unit test it" is a question which an objectively correct answer depends on multiple parameters.
So I think that in some cases we have not to and in others we should.
Making public a private method or extracting the private method as a public method in another class (new or existing)?
It is rarely the best way.
A unit test has to test the behavior of one API method/function.
If you test a public method that invokes another public method belonging to the same component, you don't unit test the method. You test multiple public methods at the same time.
As a consequence, you may duplicate tests, test fixtures, test assertions, the test maintenance and more generally the application design.
As the tests value decreases, they often lose interest for developers that write or maintain them.
To avoid all this duplication, instead of making the private method public method, in many cases a better solution is extracting the private method as a public method in a new or an existing class.
It will not create a design defect.
It will make the code more meaningful and the class less bloat.
Besides, sometimes the private method is a routine/subset of the class while the behavior suits better in a specific structure.
At last, it also makes the code more testable and avoid tests duplication.
We can indeed prevent tests duplication by unit testing the public method in its own test class and in the test class of the client classes, we have just to mock the dependency.
Mocking private methods?
While it is possible by using reflection or with tools as PowerMock, I think that it is often a way to bypass a design issue.
A private member is not designed to be exposed to other classes.
A test class is a class as another. So we should apply the same rule for it.
Mocking public methods of the object under test?
You may want to change the modifier private to public to test the method.
Then to test the method that uses this refactored public method, you may be tempted to mock the refactored public method by using tools as Mockito (spy concept) but similarly to mocking private methods, we should avoid to mock the object under test.
The Mockito.spy() documentation says it itself :
Creates a spy of the real object. The spy calls real methods unless they are > > stubbed.
Real spies should be used carefully and occasionally, for example when
dealing with legacy code.
By experience, using spy() generally decreases the test quality and its readability.
Besides, it is much more error-prone as the object under test is both a mock and a real object.
It is often the best way to write an invalid acceptance test.
Here is a guideline I use to decide whether a private method should stay private or be refactored.
Case 1) Never make a private method public if this method is invoked once.
It is a private method for a single method. So you could never duplicate test logic as it is invoke once.
Case 2) You should wonder whether a private method should be refactored as a public method if the private method is invoked more than once.
How to decide ?
The private method doesn't produce duplication in the tests.
-> Keep the method private as it is.
The private method produces duplication in the tests. That is, you need to repeat some tests, to assert the same logic for each test that unit-tests public methods using the private method.
-> If the repeated processing may make part of the API provided to clients (no security issue, no internal processing, etc...), extract the private method as a public method in a new class.
-> Otherwise, if the repeated processing has not to make part of the API provided to clients (security issue, internal processing, etc...), don't widen the visibility of the private method to public.
You may leave it unchanged or move the method in a private package class that will never make part of the API and would be never accessible by clients.
Code examples
The examples rely on Java and the following libraries : JUnit, AssertJ (assertion matcher) and Mockito.
But I think that the overall approach is also valid for C#.
1) Example where the private method doesn't create duplication in the test code
Here is a Computation class that provides methods to perform some computations.
All public methods use the mapToInts() method.
public class Computation {
public int add(String a, String b) {
int[] ints = mapToInts(a, b);
return ints[0] + ints[1];
}
public int minus(String a, String b) {
int[] ints = mapToInts(a, b);
return ints[0] - ints[1];
}
public int multiply(String a, String b) {
int[] ints = mapToInts(a, b);
return ints[0] * ints[1];
}
private int[] mapToInts(String a, String b) {
return new int[] { Integer.parseInt(a), Integer.parseInt(b) };
}
}
Here is the test code :
public class ComputationTest {
private Computation computation = new Computation();
#Test
public void add() throws Exception {
Assert.assertEquals(7, computation.add("3", "4"));
}
#Test
public void minus() throws Exception {
Assert.assertEquals(2, computation.minus("5", "3"));
}
#Test
public void multiply() throws Exception {
Assert.assertEquals(100, computation.multiply("20", "5"));
}
}
We could see that the invocation of the private method mapToInts() doesn't duplicate the test logic.
It is an intermediary operation and it doesn't produce a specific result that we need to assert in the tests.
2) Example where the private method creates undesirable duplication in the test code
Here is a MessageService class that provides methods to create messages.
All public methods use the createHeader() method :
public class MessageService {
public Message createMessage(String message, Credentials credentials) {
Header header = createHeader(credentials, message, false);
return new Message(header, message);
}
public Message createEncryptedMessage(String message, Credentials credentials) {
Header header = createHeader(credentials, message, true);
// specific processing to encrypt
// ......
return new Message(header, message);
}
public Message createAnonymousMessage(String message) {
Header header = createHeader(Credentials.anonymous(), message, false);
return new Message(header, message);
}
private Header createHeader(Credentials credentials, String message, boolean isEncrypted) {
return new Header(credentials, message.length(), LocalDate.now(), isEncrypted);
}
}
Here is the test code :
import java.time.LocalDate;
import org.assertj.core.api.Assertions;
import org.junit.Test;
import junit.framework.Assert;
public class MessageServiceTest {
private MessageService messageService = new MessageService();
#Test
public void createMessage() throws Exception {
final String inputMessage = "simple message";
final Credentials inputCredentials = new Credentials("user", "pass");
Message actualMessage = messageService.createMessage(inputMessage, inputCredentials);
// assertion
Assert.assertEquals(inputMessage, actualMessage.getMessage());
Assertions.assertThat(actualMessage.getHeader())
.extracting(Header::getCredentials, Header::getLength, Header::getDate, Header::isEncryptedMessage)
.containsExactly(inputCredentials, 9, LocalDate.now(), false);
}
#Test
public void createEncryptedMessage() throws Exception {
final String inputMessage = "encryted message";
final Credentials inputCredentials = new Credentials("user", "pass");
Message actualMessage = messageService.createEncryptedMessage(inputMessage, inputCredentials);
// assertion
Assert.assertEquals("Aç4B36ddflm1Dkok49d1d9gaz", actualMessage.getMessage());
Assertions.assertThat(actualMessage.getHeader())
.extracting(Header::getCredentials, Header::getLength, Header::getDate, Header::isEncryptedMessage)
.containsExactly(inputCredentials, 9, LocalDate.now(), true);
}
#Test
public void createAnonymousMessage() throws Exception {
final String inputMessage = "anonymous message";
Message actualMessage = messageService.createAnonymousMessage(inputMessage);
// assertion
Assert.assertEquals(inputMessage, actualMessage.getMessage());
Assertions.assertThat(actualMessage.getHeader())
.extracting(Header::getCredentials, Header::getLength, Header::getDate, Header::isEncryptedMessage)
.containsExactly(Credentials.anonymous(), 9, LocalDate.now(), false);
}
}
We could see that the invocation of the private method createHeader() creates some duplication in the test logic.
createHeader() creates indeed a specific result that we need to assert in the tests.
We assert 3 times the header content while a single assertion should be required.
We could also note that the asserting duplication is close between the methods but not necessary the same as the private method has a specific logic :
Of course, we could have more differences according to the logic complexity of the private method.
Besides, at each time we add a new public method in MessageService that calls createHeader(), we will have to add this assertion.
Note also that if createHeader() modifies its behavior, all these tests may also need to be modified.
Definitively, it is not a very good design.
Refactoring step
Suppose we are in a case where createHeader() is acceptable to make part of the API.
We will start by refactoring the MessageService class by changing the access modifier of createHeader() to public :
public Header createHeader(Credentials credentials, String message, boolean isEncrypted) {
return new Header(credentials, message.length(), LocalDate.now(), isEncrypted);
}
We could now test unitary this method :
#Test
public void createHeader_with_encrypted_message() throws Exception {
...
boolean isEncrypted = true;
// action
Header actualHeader = messageService.createHeader(credentials, message, isEncrypted);
// assertion
Assertions.assertThat(actualHeader)
.extracting(Header::getCredentials, Header::getLength, Header::getDate, Header::isEncryptedMessage)
.containsExactly(Credentials.anonymous(), 9, LocalDate.now(), true);
}
#Test
public void createHeader_with_not_encrypted_message() throws Exception {
...
boolean isEncrypted = false;
// action
messageService.createHeader(credentials, message, isEncrypted);
// assertion
Assertions.assertThat(actualHeader)
.extracting(Header::getCredentials, Header::getLength, Header::getDate, Header::isEncryptedMessage)
.containsExactly(Credentials.anonymous(), 9, LocalDate.now(), false);
}
But what about the tests we write previously for public methods of the class that use createHeader() ?
Not many differences.
In fact, we are still annoyed as these public methods still need to be tested concerning the returned header value.
If we remove these assertions, we may not detect regressions about it.
We should be able to naturally isolate this processing but we cannot as the createHeader() method belongs to the tested component.
That's why I explained at the beginning of my answer that in most of cases, we should favor the extraction of the private method in another class to the change of the access modifier to public.
So we introduce HeaderService :
public class HeaderService {
public Header createHeader(Credentials credentials, String message, boolean isEncrypted) {
return new Header(credentials, message.length(), LocalDate.now(), isEncrypted);
}
}
And we migrate the createHeader() tests in HeaderServiceTest.
Now MessageService is defined with a HeaderService dependency:
public class MessageService {
private HeaderService headerService;
public MessageService(HeaderService headerService) {
this.headerService = headerService;
}
public Message createMessage(String message, Credentials credentials) {
Header header = headerService.createHeader(credentials, message, false);
return new Message(header, message);
}
public Message createEncryptedMessage(String message, Credentials credentials) {
Header header = headerService.createHeader(credentials, message, true);
// specific processing to encrypt
// ......
return new Message(header, message);
}
public Message createAnonymousMessage(String message) {
Header header = headerService.createHeader(Credentials.anonymous(), message, false);
return new Message(header, message);
}
}
And in MessageService tests, we don't need any longer to assert each header value as this is already tested.
We want to just ensure that Message.getHeader() returns what HeaderService.createHeader() has returned.
For example, here is the new version of createMessage() test :
#Test
public void createMessage() throws Exception {
final String inputMessage = "simple message";
final Credentials inputCredentials = new Credentials("user", "pass");
final Header fakeHeaderForMock = createFakeHeader();
Mockito.when(headerService.createHeader(inputCredentials, inputMessage, false))
.thenReturn(fakeHeaderForMock);
// action
Message actualMessage = messageService.createMessage(inputMessage, inputCredentials);
// assertion
Assert.assertEquals(inputMessage, actualMessage.getMessage());
Assert.assertSame(fakeHeaderForMock, actualMessage.getHeader());
}
Note the assertSame() use to compare the object references for the headers and not the contents.
Now, HeaderService.createHeader() may change its behavior and return different values, it doesn't matter from the MessageService tests point of view.

The point of the unit test is to confirm the workings of the public api for that unit. There should be no need to make a private method exposed only for testing, if so then your interface should be rethought. Private methods can be thought as 'helper' methods to the public interface and therefore are tested via the public interface as they would be calling into the private methods.
The only reason I can see that you have a 'need' to do this is that your class is not properly designed for testing in mind.

First Unit Test (VS2010 C#)

This is my first encounter with unit testing and I am trying to understand how can this concept be used on a simple date validation.
The user can select a ToDate that represents the date until a payment can be made. If our date is not valid the payment cant be made.
private void CheckToDate(DateTime ToDate)
{
if (Manager.MaxToDate < ToDate.Year)
//show a custom message
}
How can unit tests be used in this case?
Regards,
Alex
Thanks for your answers:
As suggested by many of you I will split the function and separate the validation from the message display and use unit tests just for this.
public bool IsDateValid(DateTime toDate)
{
return (Manager.MaxToDate < toDate.Year);
}

Yes it is possible. But unit testing changes design of your class. To make possible unit testing of this code, you should made following changes:
Make your method public. (It is possible to make it protected, but for simplicity make it public).
Extract all external dependencies of this method to interface, so you can mock them. Then you can use some mocking library (moq, Rhino.Mocks) to simulate real dependencies and write asserts.
Write test.
Here is sample code.
The class under test:
public class ClassUnderTest
{
public IManager Manager {get;set;}
public IMessanger Messanger {get;set}
public ClassUnderTest (IManager manager, IMessanger messanger)
{
Manager = manager;
Messanger = messanger;
}
private void CheckToDate(DateTime ToDate)
{
if (Manager.MaxToDate < ToDate.Year)
//show a custom message
Messanger.ShowMessage('message');
}
}
Test:
[TestFixture]
public class Tester
{
public void MessageIsShownWhenDateIsLowerThanMaxDate()
{
//SetUp
var manager = new Mock<IManager>();
var messanger = new Mock<IMessanger>();
var maxDate = DateTime.Now;
manager.Setup(m => m.MaxToDate).Returns(maxDate);
var cut = new ClassUnderTest (manager.Object, messanger.Object);
//Act
cut.CheckToDate();
//Assert
messanger.Verify(foo => foo.ShowMessage("message"), Times.AtLeastOnce())
}
}
Design change, introduced by test gives you nice decoupling in system. And tests could be written for specific classes, when external dependencies are event not written.

Sure thing :-) Detecting that the custom message is shown can require a little trick (I assume you mean a messagebox displayed on a GUI, but the idea is the same even if the message is displayed differently).
You can't detect mssage boxes from unit tests, neither you want to launch the whole GUI environment from your unit tests. The easiest way to work around this is to hide the actual code displaying a message box in a separate method, ideally in a distinct interface. Then you can inject a mock implementation of this interface for your unit tests. This mock does not display anything, just records the message passed to it, so you can check it in your unit test.
The other issue is that your method is private. Check first where it is called from, and whether it can be called via a public method without too much complication. If not, you may need to make it (temporarily) public to enable unit testing. Note that the need to unit test private methods is usually a design smell: your class may be trying to do too much, taking on too many distinct responsibilities. You may be able to extract some of its functionality into a distinct class, where it becomes public, thus directly unit testable. But first you need to have those unit tests, to ensure you are not breaking anything when refactoring.
You then need to set up the Manager.MaxToDate prior to the test with a suitable date, and call CheckToDate with various parameters, check that the result is as expected.
The recommended reading for similar tricks and more is Working Effectively with Legacy Code.

Unit testing is best done on the public interface of your classes. So, I'd suggest you either make this public, or look to test it indirectly (through the public methods you do expose).
As for "Is it possible to create unit tests for something like this?", it depends on how pure you want to be on the concept of Unit Tests, how user-dependent you want them to be, and what exactly //show a custom message does.
How pure do you want your unit tests to be? If you don't care if they are dirty hacks, then you can use reflections to expose the private method to your unit tests, and just call it directly. This is in general a bad practice, though, because your private functions by definition are subject to change. Otherwise you'd just make them public.
If //show a custom message prints to the console, then you can make silent-running tests fairly easily. If you actually want to verify the output, you'd have to hook into your Console.Out, so you can see what got printed, and add corresponding assertions.
If //show a custom message uses MessageBox.Show, then you may have to make a UI Automated Test to be able to test this. Your tests will not be able to run silently in the background, and will break if you're moving your mouse while the test is running.
If you don't want to make a UI Automated Test just to test the logic of this class, the best way I know of is to modify your class to use dependency injection. Encapsulate all of the actual output code (MessageBox.Show) into another class, abstract it via an interface or abstract base class, and make it so your original class takes a reference to the abstract type. This way you can inject a mock in your tests, and it won't actually output to the screen.
public interface INotification
{
void ShowMessage(string message);
}
public class MessageBoxNotification : INotification
{
public void ShowMessage(string message)
{
MessageBox.Show(message);
}
}
public class MyClass
{
private INotification notification;
public MyClass(INotification notification)
{
this.notification = notification;
}
public void SomeFunction(int someValue)
{
// Replace with whatever your actual code is...
ToDate toDate = new SomeOtherClass().SomeOtherFunction(someValue);
CheckToDate(toDate);
}
private void CheckToDate(DateTime ToDate)
{
if (Manager.MaxToDate < ToDate.Year)
notification.Show("toDate, too late!: " + toDate.ToString());
}
}
Your unit test would make it's own custom INotification class, pass it to the constructor of MyClass, and invoke the SomeFunction method.
You'll probably want to abstract things like Manager, and the classes involve in computing ToDate in a similar way.

Introducing unit testing often makes you think more actively about code design (if you didn't already). Your case is interesting in this aspect. It is tricky to test, and one reason for that is that it does two different things:
It validates the date
It reacts on a failed validation by showing a message
A well-crafted method does only one thing. So, I would recommend refactoring the code a bit so that you get a validation method that does nothing but validates. This method will be very simple to test:
public bool IsDateValid(DateTime toDate)
{
// just guessing on the rules here...
return (Manager.MaxToDate >= toDate.Year);
}
This will also make the validation code far more reusable, since it moves the desicion on how to treat the result to the calling code.