Related
Mocking sealed classes can be quite a pain. I currently favor an Adapter pattern to handle this, but something about just keeps feels weird.
So, What is the best way you mock sealed classes?
Java answers are more than welcome. In fact, I would anticipate that the Java community has been dealing with this longer and has a great deal to offer.
But here are some of the .NET opinions:
Why Duck Typing Matters for C#
Develoepers
Creating wrappers
for sealed and other types for
mocking
Unit tests for WCF (and Moq)
For .NET, you could use something like TypeMock, which uses the profiling API and allows you to hook into calls to nearly anything.
My general rule of thumb is that objects that I need to mock should have a common interface too. I think this is right design-wise and makes tests a lot easier (and is usually what you get if you do TDD). More about this can be read in the Google Testing Blog latest post (See point 9).
Also, I've been working mainly in Java in the past 4 years and I can say that I can count on one hand the number of times I've created a final (sealed) class. Another rule here is I should always have a good reason to seal a class, as opposed to sealing it by default.
I believe that Moles, from Microsoft Research, allows you to do that. From the Moles page:
Moles may be used to detour any .NET
method, including non-virtual/static
methods in sealed types.
UPDATE: there is a new framework called "Fakes" in the upcoming VS 11 release that is designed to replace Moles:
The Fakes Framework in Visual Studio 11 is the next generation of Moles & Stubs, and will eventually replace it. Fakes is different from Moles, however, so moving from Moles to Fakes will require some modifications to your code. A guide for this migration will be available at a later date.
Requirements: Visual Studio 11 Ultimate, .NET 4.5
The problem with TypeMock is that it excuses bad design. Now, I know that it is often someone else's bad design that it's hiding, but permitting it into your development process can lead very easily to permitting your own bad designs.
I think if you're going to use a mocking framework, you should use a traditional one (like Moq) and create an isolation layer around the unmockable thing, and mock the isolation layer instead.
I came across this problem recently and after reading / searching web, seems like there is no easy way around except to use another tool as mentioned above.
Or crude of handling things as I did:
Create instance of sealed class without getting constructor called.
System.Runtime.Serialization.FormatterServices.GetUninitializedObject(instanceType);
Assign values to your properties / fields via reflection
YourObject.GetType().GetProperty("PropertyName").SetValue(dto, newValue, null);
YourObject.GetType().GetField("FieldName").SetValue(dto, newValue);
I almost always avoid having dependencies on external classes deep within my code. Instead, I'd much rather use an adapter/bridge to talk to them. That way, I'm dealing with my semantics, and the pain of translating is isolated in one class.
It also makes it easier to switch my dependencies in the long run.
It is perfectly reasonable to mock a sealed class because many framework classes are sealed.
In my case I'm trying to mock .Net's MessageQueue class so that I can TDD my graceful exception handling logic.
If anyone has ideas on how to overcome Moq's error regarding "Invalid setup on a non-overridable member", please let me know.
code:
[TestMethod]
public void Test()
{
Queue<Message> messages = new Queue<Message>();
Action<Message> sendDelegate = msg => messages.Enqueue(msg);
Func<TimeSpan, MessageQueueTransaction, Message> receiveDelegate =
(v1, v2) =>
{
throw new Exception("Test Exception to simulate a failed queue read.");
};
MessageQueue mockQueue = QueueMonitorHelper.MockQueue(sendDelegate, receiveDelegate).Object;
}
public static Mock<MessageQueue> MockQueue
(Action<Message> sendDelegate, Func<TimeSpan, MessageQueueTransaction, Message> receiveDelegate)
{
Mock<MessageQueue> mockQueue = new Mock<MessageQueue>(MockBehavior.Strict);
Expression<Action<MessageQueue>> sendMock = (msmq) => msmq.Send(It.IsAny<Message>()); //message => messages.Enqueue(message);
mockQueue.Setup(sendMock).Callback<Message>(sendDelegate);
Expression<Func<MessageQueue, Message>> receiveMock = (msmq) => msmq.Receive(It.IsAny<TimeSpan>(), It.IsAny<MessageQueueTransaction>());
mockQueue.Setup(receiveMock).Returns<TimeSpan, MessageQueueTransaction>(receiveDelegate);
return mockQueue;
}
Although it's currently only available in beta release, I think it's worthwhile keeping in mind the shim feature of the new Fakes framework (part of the Visual Studio 11 Beta release).
Shim types provide a mechanism to detour any .NET method to a user defined delegate. Shim types are code-generated by the Fakes generator, and they use delegates, which we call shim types, to specify the new method implementations. Under the hood, shim types use callbacks that were injected at runtime in the method MSIL bodies.
Personally, I was looking at using this to mock the methods on sealed framework classes such as DrawingContext.
I generally take the route of creating an interface and adaptor/proxy class to facilitate mocking of the sealed type. However, I've also experimented with skipping creation of the interface and making the proxy type non-sealed with virtual methods. This worked well when the proxy is really a natural base class that encapsulates and users part of the sealed class.
When dealing with code that required this adaptation, I got tired of performing the same actions to create the interface and proxy type so I implemented a library to automate the task.
The code is somewhat more sophisticated than the sample given in the article you reference, as it produces an assembly (instead of source code), allows for code generation to be performed on any type, and doesn't require as much configuration.
For more information, please refer to this page.
Is there a way to implement a sealed class from an interface... and mock the interface instead?
Something in me feels that having sealed classes is wrong in the first place, but that's just me :)
Most of the examples given in mocking framework website is to mock Interface. Let say NSubstitute that I'm currently using, all their mocking examples is to mock interface.
But in reality, I saw some developer mock concrete class instead. Is it recommended to mock concrete class?
In theory there is absolutely no problem mocking a concrete class; we are testing against a logical interface (rather than a keyword interface), and it does not matter whether that logical interface is provided by a class or interface.
In practice .NET/C# makes this a bit problematic. As you mentioned a .NET mocking framework I'm going to assume you're restricted to that.
In .NET/C# members are non-virtual by default, so any proxy-based methods of mocking behaviour (i.e. derive from the class, and override all the members to do test-specific stuff) will not work unless you explicitly mark the members as virtual. This leads to a problem: you are using an instance of a mocked class that is meant to be completely safe in your unit test (i.e. won't run any real code), but unless you have made sure everything is virtual you may end up with a mix of real and mocked code running (this can be especially problematic if there is constructor logic, which always runs, and is compounded if there are other concrete dependencies to be new'd up).
There are a few ways to work around this.
Use interfaces. This works and is what we advise in the NSubstitute documentation, but has the downside of potentially bloating your codebase with interfaces that may not actually be needed. Arguably if we find good abstractions in our code we'll naturally end up with neat, reusable interfaces we can test to. I haven't quite seen it pan out like that, but YMMV. :)
Diligently go around making everything virtual. An arguable downside to this is that we're suggesting all these members are intended to be extension points in our design, when we really just want to change the behaviour of the whole class for testing. It also doesn't stop constructor logic running, nor does it help if the concrete class requires other dependencies.
Use assembly re-writing via something like the Virtuosity add-in for Fody, which you can use to modify all class members in your assembly to be virtual.
Use a non-proxy based mocking library like TypeMock (paid), JustMock (paid), Microsoft Fakes (requires VS Ultimate/Enterprise, though its predecessor, Microsoft Moles, is free) or Prig (free + open source). I believe these are able to mock all aspects of classes, as well as static members.
A common complaint lodged against the last idea is that you are testing via a "fake" seam; we are going outside the mechanisms normally used for extending code to change the behaviour of our code. Needing to go outside these mechanisms could indicate rigidity in our design. I understand this argument, but I've seen cases where the noise of creating another interface/s outweighs the benefits. I guess it's a matter of being aware of the potential design issue; if you don't need that feedback from the tests to highlight design rigidity then they're great solutions.
A final idea I'll throw out there is to play around with changing the size of the units in our tests. Typically we have a single class as a unit. If we have a number of cohesive classes as our unit, and have interfaces acting as a well-defined boundary around that component, then we can avoid having to mock as many classes and instead just mock over a more stable boundary. This can make our tests a more complicated, with the advantage that we're testing a cohesive unit of functionality and being encouraged to develop solid interfaces around that unit.
Hope this helps.
Update:
3 years later I want to admit that I changed my mind.
In theory I still do not like to create interfaces just to facilitate creation of mock objects. In practice ( I am using NSubstitute) it is much easier to use Substitute.For<MyInterface>() rather than mock a real class with multiple parameters, e.g. Substitute.For<MyCLass>(mockedParam1, mockedParam2, mockedParam3), where each parameter should be mocked separately. Other potential troubles are described in NSubstitute documentation
In our company the recommended practice now is to use interfaces.
Original answer:
If you don't have a requirement to create multiple implementations of the same abstraction, do not create an interface.
As it pointed by David Tchepak, you don't want to bloating your codebase with interfaces that may not actually be needed.
From http://blog.ploeh.dk/2010/12/02/InterfacesAreNotAbstractions.aspx
Do you extract interfaces from your classes to enable loose
coupling? If so, you probably have a 1:1 relationship between your
interfaces and the concrete classes that implement them.
That’s probably not a good sign, and violates the Reused Abstractions
Principle (RAP).
Having only one implementation of a given interface is a code smell.
If your target is the testability, i prefer the second option from David Tchepak's answer above.
However I am not convinced that you have to make everything virtual. It's sufficient to make virtual only the methods, that you are going to substitute.
I also will add a comment next to the method declaration that method is virtual only to make it substitutable for unit test mocking.
However note that substitution of concrete classes instead of interfaces has some limitations.
E.g. for NSubstitute
Note: Recursive substitutes will not be created for classes, as
creating and using classes can have potentially unwanted side-effects
.
The question is rather: Why not?
I can think of a couple of scenarios where this is useful, like:
Implementation of a concrete class is not yet complete, or the guy who did it is unreliable. So I mock the class as it is specified and test my code against it.
It can also be useful to mock classes that do things like database access. If you don't have a test database you might want to return values for your tests that are always constant (which is easy by mocking the class).
Its not that it is recommended, it's that you can do this if you have no other choice.
Usually well designed project rely on defining interfaces for your separate components so you can tests each of them in isolation by mocking the other ones. But if you are working with legacy code /code that you are not allowed to change and still want to test your classes then you have no choice and you cannot be criticized for it (assuming you made the effort to try to switch these components to interfaces and were denied the right to).
Supposed we have:
class Foo {
fun bar() = if (someCondition) {
“Yes”
} else {
“No”
}
}
There’s nothing preventing us to do the following mocking in the test code:
val foo = mock<Foo>()
whenever(foo.bar()).thenReturn(“Maybe”)
The problem is it is setting up incorrect behavior of class Foo. The real instance of class Foo will never be able to return “Maybe”.
In a .NET windows app, I have a class named EmployeeManager. On instantiation, this class loads employees into a List from the database that haven't completed registration. I'd like to use EmployeeManager in unit test. However, I don't want to involve the database.
From what I understand about this scenario, I need an IEmployeeManager interface, which is only used for testing purposes. This doesn't seem right since the interface has no other use. However, it will allow me to create some EmployeeManager test class that loads employees without involving the database. This way, I can assign values that would have otherwise come from the database.
Is the above correct and do I need to Mock it? Mocking (Moq framework) seems to use lots of code just to do simple things such as assigning a property. I don't get the point. Why mock when I can just create a simple test class from IEmployeeManager that will provide what I need?
Inversion of control is your solution, not Mock objects. Here's why:
You mock the interface to make sure that some code that utilizes your IEmployeeManager is using it properly. You aren't using the test code to prove IEmployeeManager works. So there has to be another class that takes an IEmployeeManager, for instance, which you will actually be testing with your mock object.
If you are actually just testing EmployeeManager, you can do much better. Consider dependency injection. In this manner, you will expose a constructor for EmployeeManager that will take at least one parameter which is an interface. Your EmployeeManager code will internally use this interface for any implementation specific calls that it needs to make.
See Strategy Pattern
This will lead you into a whole, exciting world of Inversion of Control. And as you dig into that, you will find that problems like these have been effectively solved with IoC containers such as AutoFac, Ninject, and Structure Map, to name a few.
Mocking interfaces is great, and you can mock an interface that you then pass into IoC. But you'll find that IoC is a much more robust solution to your problem. And yes, while you might only be implementing a second alternative just for testing, it is still important to do for that very reason -- seperating the strategy under test from the business logic of EmployeeManager.
From what I understand about this scenario, I need an IEmployeeManager interface, which is only used for testing purposes. This doesn't seem right since the interface has no other use.
It's well worth creating the interface. Note also that the interface actually has multiple purposes:
The interface identifies roles or responsibilities provided by an actor. In this case, the interface identifies the roles and responsibilities of the EmployeeManager. By using an interface you're preventing an accidental dependency on something database specific.
The interface reduces coupling. Since your application won't depend on the EmployeeManager, you're free to swap out its implementation without needing to recompile the rest of the application. Of course, this depends on project structure, number of assemblies, etc., but it nevertheless allows this type of reuse.
The interface promotes testability. When you use an interface it becomes much easier to generate dynamic proxies that allow your software to be more easily tested.
The interface forces thought1. Ok, I kind of already alluded to it, but it's worth saying again. Just using an interface alone should make you think about an object's roles and responsibilities. An interface shouldn't be a kitchen sink. An interface represents a cohesive set of roles and responsibilities. If an interface's methods aren't cohesive or aren't almost always used together then it's likely that an object has multiple roles. Though not necessarily bad, it implies that multiple distinct interfaces are better. The larger an interface the harder it is to make it covariant or contravariant and, therefore, more malleable in code.
However, it will allow me to create some EmployeeManager test class that loads employees without involving the database.... I don't get the point. Why mock when I can just create a simple test class from IEmployeeManager that will provide what I need?
As one poster pointed out, it sounds like you're talking about creating a stub test class. Mocking frameworks can be used to create stubs, but one of the most important features about them is that they allow you to test behavior instead of state. Now let's look at some examples. Assume the following:
interface IEmployeeManager {
void AddEmployee(ProspectiveEmployee e);
void RemoveEmployee(Employee e);
}
class HiringOfficer {
private readonly IEmployeeManager manager
public HiringOfficer(IEmployeeManager manager) {
this.manager = manager;
}
public void HireProspect(ProspectiveEmployee e) {
manager.AddEmployee(e);
}
}
When we test the HiringOfficer's HireEmployee behavior, we're interested in validating that he correctly communicated to the employee manager that this perspective employee be added as an employee. You'll often see something like this:
// you have an interface IEmployeeManager and a stub class
// called TestableEmployeeManager that implements IEmployeeManager
// that is pre-populated with test data
[Test]
public void HiringOfficerAddsProspectiveEmployeeToDatabase() {
var manager = new TestableEmployeeManager(); // Arrange
var officer = new HiringOfficer(manager); // BTW: poor example of real-world DI
var prospect = CreateProspect();
Assert.AreEqual(4, manager.EmployeeCount());
officer.HireProspect(prospect); // Act
Assert.AreEqual(5, manager.EmployeeCount()); // Assert
Assert.AreEqual("John", manager.Employees[4].FirstName);
Assert.AreEqual("Doe", manager.Employees[4].LastName);
//...
}
The above test is reasonable... but not good. It's a state-based test. That is, it verifies the behavior by checking the state before and after some action. Sometimes this is the only way to test things; sometimes it's the best way to test something.
But, testing behavior is often better, and this is where mocking frameworks shine:
// using Moq for mocking
[Test]
public void HiringOfficerCommunicatesAdditionOfNewEmployee() {
var mockEmployeeManager = new Mock<EmployeeManager>(); // Arrange
var officer = new HiringOfficer(mockEmployeeManager.Object);
var prospect = CreateProspect();
officer.HireProspect(prospect); // Act
mockEmployeeManager.Verify(m => m.AddEmployee(prospect), Times.Once); // Assert
}
In the above we tested the only thing that really mattered -- that the hiring officer communicated to the employee manager that a new employee needed to be added (once, and only once... though I actually wouldn't bother checking the count in this case). Not only that, I validated that the employee that I asked the hiring officer to hire was added by the employee manager. I've tested the critical behavior. I didn't need even a simple test stub. My test was shorter. The actual behavior was much more evident -- it becomes possible to see the interaction and validate interaction between objects.
It is possible to make your stub test class record interactions, but then you're emulating the mocking frameworks. If you're going to test behavior -- use a mocking framework.
As another poster mentioned, dependency injection (DI) and inversion of control (IoC) are important. My example above isn't a good example of this, but both should be carefully considered and judiciously used. There's a lot of writing on the subject available.
1 - Yes, thinking is still optional, but I'd strongly recommend it ;).
Creating an IEmployeeManager interface in order to be able to mock is that way most .NET developers would go about making such a class testable.
Another option is to inherit from EmployeeManager and override the method you want to test so it will not involve the database - this too means you will need to change your design.
Extracting interface in your scenario is a good idea. I would not worry too much about the fact that you only need this for testing. Extracting this interface makes your code decoupled from database. After that you will have a choice between writing your own implementation for testing or use mocking framework to generate this implementation for you. This is a matter of personal preference. It depends on how familiar you are with mocking framework and whether you want to spend time learning new syntax.
In my opinion it is worth learning. It will save you a lot of typing. They are also flexible and don't always require an interface to generate test implementation. RhinoMocks for example can mock concrete classes as long they have empty constructor and methods are virtual. Another advantage is that mocking APIs use consistent naming so you will get familiar with 'Mocks', 'Stubs' etc. In your scenario by the way you need stub, not mock. Writing an actual mock manually may be more labor intensive than using framework.
The danger with mocking frameworks is that some of them are so powerful and can mock pretty much anything, including private fields (TypeMock). In other words they are too forgiving to design mistakes and allow you to write very coupled code.
This is a good read on the subject of hand written vs. generated stubs
By making your classes implement Interfaces you are not only making them more testable, you're making your application more flexible and maintainable. When you say "This doesn't seem right since the interface has no other use", is flawed since it allows you to loosely couple your classes.
If I could suggest a couple of books Head First Design Patterns and Head First Software Development will do a much better job of explaining the concepts then I could in a SO answer.
If you don't want to use a mocking framework like Moq, it's simple enough to roll your own mock/stubs, here is a quick blog post on it Rolling your own Mock Objects
Am trying to get started using TDD on a class which spits out an object belonging to a third party component. However am getting a bit confused in that apparently:
a) With unit tests objects should be tested in isolation
b) Third-party components should be wrapped into an adapter
Do these rules apply when writing tests for code which returns an instance of an object belonging to a third party component? As an example, here's the test so far:
// Arrange
string foodXml = "<food><ingredient>Cabbages</ingredient>" +
"<ingredient>Bananas</ingredient></food>";
IFoodMixer mixer = new FoodMixer();
// Act
// Smoothie is the third-party component object
Smoothie urgh = mixer.Mix(foodXml);
// Assert
Assert.AreEquals("Cabbages", urgh.Ingredients[0].Name);
Assert.AreEquals("Bananas", urgh.Ingredients[1].Name);
Apologies if this question seems a bit basic (or if the concept above seems a tad silly!) - am just struggling to understand how the two rules above could apply in this situation.
Thanks in advance for any advice given!
I would be practical with it. If Smoothie is just a data object, don't bother wrapping it.
There's something inside that FoodMixer which is creating the Smoothie in the first place. If that's a 3rd party component, I would wrap it up (you can delegate from a class to a static method if required), then dependency-inject the wrapper and mock it out in your unit test.
Your unit test is then describing the behaviour and responsibilities of your FoodMixer, independently of the SmoothieMaker (whether it's 3rd-party or otherwise). Part of the FoodMixer's responsibility is to ask the SmoothieMaker for a Smoothie, not to actually make the Smoothie itself. By mocking it out we can express that responsibility and class scope.
If your Smoothie is not just a data object but has rich behaviour, I would wrap that within your wrapped SmoothieMaker too.
Now you are completely decoupled from your 3rd party libraries, and you can unit-test easily as a useful by-product.
Look at mockito as a simpler way to create mocks automatically and verify assertions instead of using adapters.
There are also many good tutorial on mockito (and JMocks) that are also good TDD tutorials.
This question already has answers here:
Unit testing private methods in C#
(17 answers)
Closed 6 years ago.
I am currently involved in developing with C# - Here is some background:
We implement MVP with our client application and we have a cyclomatic rule which states that no method should have a cyclomatic complexity greater than 5.
This leads to a lot of small private methods which are generally responsible for one thing.
My question is about unit testing a class:
Testing the private implementation through the public methods is all fine... I don't have a problem implementing this.
But... what about the following cases:
Example 1. Handle the result of an async data retrival request (The callback method shouldn't be public purely for testing)
Example 2. An event handler which does an operation (such as update a View label's text - silly example I know...)
Example 3. You are using a third party framework which allows you to extend by overriding protected virtual methods (the path from the public methods to these virtual methods are generally treated as black box programming and will have all sorts of dependancies that the framework provides that you don't want to know about)
The examples above don't appear to me to be the result of poor design.
They also do not appear be be candidates for moving to a seperate class for testing in isolation as such methods will lose their context.
Doesn anyone have any thoughts about this?
Cheers,
Jason
EDIT:
I don't think I was clear enough in my original question - I can test private methods using accessors and mock out calls/ methods using TypeMock. That isn't the problem. The problem is testing things which don't need to be public, or can't be public.
I don't want to make code public for the sake of testing as it can introduce security loopholes (only publishing an interface to hide this is not an option because anyone can just cast the object back to its original type and get access to stuff I wouldn't want them to)
Code that gets refactored out to another class for testing is fine - but can lose context. I've always thought it bad practice to have 'helper' classes which can contain a pot of code with no specific context - (thinking SRP here). I really don't think this works for event handlers either.
I am happy to be proven wrong - I just am unsure how to test this functionality! I have always been of the mind that if it can break or be changed - test it.
Cheers, Jason
As Chris has stated, it is standard practice to only unit test public methods. This is because, as a consumer of that object, you are only concerned about what is publically available to you. And, in theory, proper unit tests with edge cases will fully exercise all private method dependencies they have.
That being said, I find there are a few times where writing unit tests directly against private methods can be extremely useful, and most succinct in explaining, through your unit tests, some of the more complex scenarios or edge cases that might be encountered.
If that is the case, you can still invoke private methods using reflection.
MyClass obj = new MyClass();
MethodInfo methodInfo = obj.GetType().GetMethod("MethodName", BindingFlags.Instance | BindingFlags.NonPublic);
object result = methodInfo.Invoke(obj, new object[] { "asdf", 1, 2 });
// assert your expected result against the one above
we have a cyclomatic rule which states
that no method should have a
cyclomatic complexity greater than 5
I like that rule.
The point is that the private methods are implementation details. They are subject to change/refactoring. You want to test the public interface.
If you have private methods with complex logic, consider refactoring them out into a separate class. That can also help keep cyclomatic complexity down. Another option is to make the method internal and use InternalsVisibleTo (mentioned in one of the links in Chris's answer).
The catches tend to come in when you have external dependencies referenced in private methods. In most cases you can use techniques such as Dependency Injection to decouple your classes. For your example with the third-party framework, that might be difficult. I'd try first to refactor the design to separate the third-party dependencies. If that's not possible, consider using Typemock Isolator. I haven't used it, but its key feature is being able to "mock" out private, static, etc. methods.
Classes are black boxes. Test them that way.
EDIT: I'll try to respond to Jason's comment on my answer and the edit to the original question. First, I think SRP pushes towards more classes, not away from them. Yes, Swiss Army helper classes are best avoided. But what about a class designed to handle async operations? Or a data retrieval class? Are these part of the responsibility of the original class, or can they be separated?
For example, say you move this logic to another class (which could be internal). That class implements an Asynchronous Design Pattern that permits the caller to choose if the method is called synchronously or asynchronously. Unit tests or integration tests are written against the synchronous method. The asynchronous calls use a standard pattern and have low complexity; we don't test those (except in acceptance tests). If the async class is internal, use InternalsVisibleTo to test it.
There is really only two cases you need to consider:
the private code is called, directly or indirectly from public code and
the private code is not called from public code.
In the first case, the private code is automatically being tested by the tests which exercise the public code that calls the private code, so there is no need to test the private code. And in the second case, the private code cannot be called at all, therefore it should be deleted, not tested.
Ergo: there is no need to explicitly test the private code.
Note that when you do TDD it is impossible for untested private code to even exist. Because when you do TDD, the only way that private code can be appear, is by an Extract {Method|Class|...} Refactoring from public code. And Refactorings are, by definition, behavior-preserving and therefore test-coverage-preserving. And the only way that public code can appear is as the result of a failing test. If public code can only appear as already tested code as the result of a failing test, and private code can only appear as the result of being extracted from public code via a behavior-preserving refactoring, it follows that untested private code can never appear.
In all of my unit testing, I've never bothered testing private functions. I typically just tested public functions. This goes along with the Black Box Testing methodology.
You are correct that you really can't test the private functions unless you expose the private class.
If your "seperate class for testing" is in the same assembly, you can choose to use internal instead of private. This exposes the internal methods to your code, but they methods will not be accessible to code not in your assembly.
EDIT: searching SO for this topic I came across this question. The most voted answer is similar to my response.
A few points from a TDD guy who has been banging around in C#:
1) If you program to interfaces then any method of a class that is not in the interface is effectively private. You might find this a better way to promote testability and a better way to use interfaces as well. Test these as public members.
2) Those small helper methods may more properly belong to some other class. Look for feature envy. What may not be reasonable as a private member of the original class (in which you found it) may be a reasonable public method of the class it envies. Test these in the new class as public members.
3) If you examine a number of small private methods, you might find that they have cohesion. They may represent a smaller class of interest separate from the original class. If so, that class can have all public methods, but be either held as a private member of the original class or perhaps created and destroyed in functions. Test these in the new class as public members.
4) You can derive a "Testable" class from the original, in which it is a trivial task to create a new public method that does nothing but call the old, private method. The testable class is part of the test framework, and not part of the production code, so it is cool for it to have special access. Test it in the test framework as if it were public.
All of these make it pretty trivial to have tests on the methods that are currently private helper methods, without messing up the way intellisense works.
There are some great answers here, and I basically agree with the repeated advice to sprout new classes. For your Example 3, however, there's a sneaky, simple technique:
Example 3. You are using a third party
framework which allows you to extend
by overriding protected virtual
methods (the path from the public
methods to these virtual methods are
generally treated as black box
programming and will have all sorts of
dependencies that the framework
provides that you don't want to know
about)
Let's say MyClass extends FrameworkClass. Have MyTestableClass extend MyClass, and then provide public methods in MyTestableClass that expose the protected methods of MyClass that you need. Not a great practice - it's kind of an enabler for bad design - but useful on occasion, and very simple.
Would accessor files work? http://msdn.microsoft.com/en-us/library/bb514191.aspx I've never directly worked with them, but I know a coworker used them to test private methods on some Windows Forms.
Several people have responded that private methods shouldn't be tested directly, or they should be moved to another class. While I think this is good, sometimes its just not worth it. While I agree with this in principle, I've found that this is one of those rules that cna be broken to save time without negative repercussions. If the function is small/simple the overhead of creating another class and test class is overkill. I will make these private methods public, but then not add them to the interface. This way consumers of the class (who should be getting the interface only through my IoC library) won't accidentally use them, but they're available for testing.
Now in the case of callbacks, this is a great example where making a private property public can make tests a lot easier to write and maintain. For instance, if class A passes a callback to class B, I'll make that callback a public property of class A. One test for class A use a stub implementation for B that records the callback passed in. The test then verify the the callback is passed in to B under appropriate conditions. A separate test for class A can then call the callback directly, verifying it has the appropriate side effects.
I think this approach works great for verifying async behaviors, I've been doing it in some javascript tests and some lua tests. The benefit is I have two small simple tests (one that verifies the callback is setup, one that verifies it behaves as expected). If you try to keep the callback private then the test verifying the callback behavior has a lot more setup to do, and that setup will overlap with behavior that should be in other tests. Bad coupling.
I know, its not pretty, but I think it works well.
I will admit that when recently writing units tests for C# I discovered that many of the tricks I knew for Java did not really apply (in my case it was testing internal classes).
For example 1, if you can fake/mock the data retrieval handler you can get access to the callback through the fake. (Most other languages I know that use callbacks also tend not to make them private).
For example 2 I would look into firing the event to test the handler.
Example 3 is an example of the Template Pattern which does exist in other languages. I have seen two ways to do this:
Test the entire class anyway (or at least relevant pieces of it). This particularly works in cases where the abstract base class comes with its own tests, or the overall class is not too complex. In Java I might do this if I were writing an extension of AbstractList, for example. This may also be the case if the template pattern was generated by refactoring.
Extend the class again with extra hooks that allow calling the protected methods directly.
Don't test private code, or you'll be sorry later when it's time to refactor. Then, you'll do like Joel and blog about how TDD is too much work because you constantly have to refactor your tests with your code.
There are techniques (mocks, stub) to do proper black box testing. Look them up.
This is a question that comes up pretty early when introducing testing. The best technique to solving this problem is to black-box test (as mentioned above) and follow the single responsibility principle. If each of your classes only have only one reason to change, they should be pretty easy to test their behavior without getting at their private methods.
SRP - wikipedia / pdf
This also leads to more robust and adaptable code as the single responsibility principle is really just saying that your class should have high cohesion.
In C# you can use the attribute in AssemblyInfo.cs:
[assembly: InternalsVisibleTo("Worker.Tests")]
Simply mark your private methods with internal, and the test project will still see the method. Simple! You get to keep encapsulation AND have testing, without all the TDD nonsense.