The Testable Object Pattern
Brad Wilson posted about Testable Object pattern which is a n interesting technique how to approach the fact that MVP Presenter constructor signature can change during the time and by that broke our tests already written
What he is suggesting is defining the new type which would inherit from presenter type and expose static factory parameter method and internally it would initialize elements of the the presenter constructor.
Looks cool except of the next things:
a) How we would handle different presenter constructors? (If we define overload Create methods we are breaking compatibility later again)
b) I’m not a big fun of creating *helper* types in test classes which are supposed only to support tests. Our tests should test only the “production” types, not the test types – no matter how primitive wrappers they would be…
I think much cleaner solution of the problem Brad is speaking is instead of defining new test type we should solve the problem in presenter type itself
Instead of constructor type of dependency injection we can use setter type and define inside of presenter two properties
IView View {set;}
IService Service {set;}
and then replace the presenter its constructor with static factory method (Presenter.CreateNewPresenter()).
That’s how we could solve the problem of test breaking changes of presenter constructor signature without adding additional types
Link to The Testable Object Pattern
Posted on April 5, 2007, in Uncategorized. Bookmark the permalink. 1 Comment.
.NET development and architecture 
Brad said…
Nikola, thanks for the kind words. 🙂
Here are my comments on your comments:
a) How we would handle different presenter constructors?
I’m a big believer in expressing service dependencies via constructors, so I don’t tend to have multiple constructors. Sometimes, if I’m not going to have a dependency injection container, I might offer two constructors like:
public MyObject(IService1 service1, IService2 service2) {…}
public MyObject() : this(new Service1(), new Service2()) {…}
b) I’m not a big fun of creating *helper* types in test classes which are supposed only to support tests. Our tests should test only the "production" types, not the test types – no matter how primitive wrappers they would be…
I’m not testing the test types. I’m making the tests more resilient to changing service dependencies during the lifetime of the object. I’d rather create helper types than change dozens or hundreds of tests (and I far prefer a factory method over [SetUp] and [TearDown]).
Thanks!
Brad