Look, there's no easy way to do this. I'm working on a project that is inherently multithreaded. Events come in from the operating system and I have to process them concurrently.
The simplest way to deal with testing complex, multithreaded application code is this: If it's too complex to test, you're doing it wrong. If you have a single instance that has multiple threads acting upon it, and you can't test situations where these threads step all over each other, then your design needs to be redone. It's both as simple and as complex as this.
There are many ways to program for multithreading that avoids threads running through instances at the same time. The simplest is to make all your objects immutable. Of course, that's not usually possible. So you have to identify those places in your design where threads interact with the same instance and reduce the number of those places. By doing this, you isolate a few classes where multithreading actually occurs, reducing the overall complexity of testing your system.
But you have to realize that even by doing this, you still can't test every situation where two threads step on each other. To do that, you'd have to run two threads concurrently in the same test, then control exactly what lines they are executing at any given moment. The best you can do is simulate this situation. But this might require you to code specifically for testing, and that's at best a half step towards a true solution.
Probably the best way to test code for threading issues is through static analysis of the code. If your threaded code doesn't follow a finite set of thread safe patterns, then you might have a problem. I believe Code Analysis in VS does contain some knowledge of threading, but probably not much.
Look, as things stand currently (and probably will stand for a good time to come), the best way to test multithreaded apps is to reduce the complexity of threaded code as much as possible. Minimize areas where threads interact, test as best as possible, and use code analysis to identify danger areas.
Update:
Some 10 years later perhaps the best way to test a private method, or any inaccessible member, is via @Jailbreak
from the Manifold framework.
@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;
This way your code remains type-safe and readable. No design compromises, no overexposing methods and fields for the sake of tests.
If you have somewhat of a legacy Java application, and you're not allowed to change the visibility of your methods, the best way to test private methods is to use reflection.
Internally we're using helpers to get/set private
and private static
variables as well as invoke private
and private static
methods. The following patterns will let you do pretty much anything related to the private methods and fields. Of course, you can't change private static final
variables through reflection.
Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);
And for fields:
Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);
Notes:
1. TargetClass.getDeclaredMethod(methodName, argClasses)
lets you look into private
methods. The same thing applies for
getDeclaredField
.
2. The setAccessible(true)
is required to play around with privates.
Best Answer
A controller unit test should test the code algorithms in your action methods, not in your data layer. This is one reason to mock those data services. The controller expects to receive certain values from repositories / services / etc, and to act differently when it receives different information from them.
You write unit tests to assert the controller behaves in very specific ways in very specific scenarios / circumstances. Your data layer is one piece of the app that provides those circumstances to the controller / action methods. Asserting that a service method was called by the controller is valuable because you can be certain that the controller gets the information from another place.
Checking the type of the viewmodel returned is valuable because, if the wrong type of viewmodel is returned, MVC will throw a runtime exception. You can prevent this from happening in production by running a unit test. If the test fails, then the view may throw an exception in production.
Unit tests can be valuable because they make refactoring much easier. You can change the implementation, and assert that the behavior is still the same by making sure all of the unit tests pass.
Answer to comment #1
If changing the implementation of a method-under-test calls for the change / removal of a lower-layer mocked method, then the unit test must also change. However, this shouldn't happen as often as you may think.
The typical red-green-refactor workflow calls for writing your unit tests before writing the methods they test. (This means for a brief amount of time, your test code won't compile, and is why many young / inexperienced developers have difficulty adopting red green refactor.)
If you write your unit tests first, you will come to a point where you know the controller needs to get information from a lower layer. How can you be certain it tries to get that information? By mocking out the lower layer method that provides the information, and asserting that the lower-layer method is invoked by the controller.
I may have misspoke when I used the term "changing implementation." When a controller's action method & corresponding unit test must be altered to change or remove a mocked method, you are really changing the behavior of the controller. Refactoring, by definition, means changing the implementation without altering the overall behavior and expected results.
Red-green-refactor is a Quality Assurance approach that helps prevent bugs & defects in code before they ever appear. Typically developers change implementation to remove bugs after they appear. So to reiterate, the cases you are worried about should not happen as often as you think.