When I write tests for certain types of objects, such as UI elements like Forms or UserControls, I often find myself altering my TDD pattern; instead of going test-first, I define and lay out the form’s controls, to provide a “skeleton”, then start writing behavioral tests (databinding/”unbinding”, display-mode behavior, etc). In doing so, I find myself dealing with non-public members. I also run into the same concern with other behavioral methods; I may want to focus on and exercise logic in some private helper called by another method, before worrying about the usage in the other method and its behavior.
To me, making everything public (and sometimes virtual) just to be able to unit-test everything is a smell; I don’t want other objects being able to call a helper, or directly access a textbox; but I need to know that the helper does its job and the textbox gets its value when the form loads.
The solution I arrived at some time ago is to create a “test proxy” for the actual object under test. The proxy derives from the object under test, and doesn’t hide or override any behavior, but it does provide internally-visible getters, setters and/or methods that make calls to non-public members of the object under test, allowing me to tell the object to perform certain actions of which I can then view the results, without requiring the test to also depend on proper integration within the object or making the method or some other member of interest public in production code just for testing purposes.
Advantages I see:
- Members’ visibility is not determined by whether you want a unit test or not.
- Finer control over what you can do with the object in a test allows for more flexible and extensible testing.
Disadvantages I see:
- Class count increases, with an extra level to develop just for testing purposes.
- Care must be taken not to somehow end up using the test proxy in production code (making the constructor or the entire class internal generally does the trick)
- Not a “pure” unit test as you are, at some level, dependent on integration between the proxy and actual object under test.
The question is, is this a valid way to architect unit tests, or does the fact that I have to do this indicate a problem with the code or the testing strategy?
My first reaction to this pattern is that you’re de-emphasizing the ‘D’s in TDD. Your code is tested but those tests are not driving your design so the code you end up with has a different structure than it would if you had written tests first. A structure with more inaccessible private state than necessary. In general I’ll argue that if you can’t test your class’ behavior using the public interfaces then you are either writing a test which doesn’t make sense (testing implementation details) or you have a poorly designed public interface.
However if you’re working with view classes this becomes a bit more complicated since you have “public” inputs and outputs via your view which you want to test but which are not necessarily exposed to the code using this view component. In that case I think it makes sense to give your tests access to that user interface; either by exposing those normally private attributes to the test (your proxy is one option and others may be available depending on the language you are using) or by writing some form of functional test which can drive the UI (again tools available depend on your environment).