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

 

Advertisements

Posted on April 5, 2007, in Uncategorized. Bookmark the permalink. 1 Comment.

  1. 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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: