Testability Is Really The Open/Closed Principle by Mark Seemann
When I talk with people about TDD and unit testing, the discussion often moves into the area of Testability - that is, the software's susceptibility to unit testing. A couple of years back, Roy even discussed the seemingly opposable forces of Object-Oriented Design and Testability.
Lately, it has been occurring to me that there really isn't any conflict. Encapsulation is important because it manifests expert knowledge so that other developers can effectively leverage that knowledge, and it does so in a way that minimizes misuse.
However, too much encapsulation goes against the Open/Closed Principle (that states that objects should be open for extension, but closed for modification). From a Testability perspective, the Open/Closed Principle pulls object-oriented design in the desired direction. Equivalently, done correctly, making your API Testable is simply opening it up for extensibility.
As an example, consider a simple WPF ViewModel class called MainWindowViewModel. This class has an ICommand property that, when invoked, should show a message box. Showing a message box is good example of breaking testability, because if the SUT were to show a message box, it would be very hard to automatically verify and we wouldn't have fully automated tests.
For this reason, we need to introduce an abstraction that basically models an action with a string as input. Although we could define an interface for that, an Action<string> fits the bill perfectly.
To enable that feature, I decide to use Constructor Injection to inject that abstraction into the MainWindowViewModel class:
public MainWindowViewModel(Action<string> notify) { this.ButtonCommand = new RelayCommand(p => { notify("Button was clicked!"); }); }
When I recently did that at a public talk I gave, one member of the audience initially reacted by assuming that I was now introducing test-specific code into my SUT, but that's not the case.
What I'm really doing here is opening the MainWindowViewModel class for extensibility. It can still be used with message boxes:
var vm = new MainWindowViewModel(s => MessageBox.Show(s));
but now we also have the option of notifying by sending off an email; writing to a database; or whatever else we can think of.
It just so happens that one of the things we can do instead of showing a message box, is unit testing by passing in a Test Double.
// Fixture setup var mockNotify = MockRepository.GenerateMock<Action<string>>(); mockNotify.Expect(a => a("Button was clicked!")); var sut = new MainWindowViewModel(mockNotify); // Exercise system sut.ButtonCommand.Execute(new object()); // Verify outcome mockNotify.VerifyAllExpectations(); // Teardown
Once again, TDD has lead to better design. In this case it prompted me to open the class for extensibility. There really isn't a need for Testability as a specific concept; the Open/Closed Principle should be enough to drive us in the right direction.
Pragmatically, that's not the case, so we use TDD to drive us towards the Open/Closed Principle, but I think it's important to note that we are not only doing this to enable testing: We are creating a better and more flexible API at the same time.
