Design and Testability

There was a rather healthy public discussion and debate going on via Twitter today between Roy Osherove, Ayende Rahien, Colin Jack, me, and several others. Michael Feathers even dropped in at one point which was cool.  This all started when Roy twittered an interesting link to a post by Jacob Proffitt.

Most of the “debate” seemed to be all of us saying the same thing different ways and violently agreeing, but there were some honest to goodness points of contention.  Ayende has covered this at length, so I’d like to try to cover it as succinctly as possible which may also help matters. One of the big sticking points was the concept of “Design for testability”. I wanted to point out that TDD != “Design for Testability”.  So here goes my shot at trying to explain why TDD is not “Designing for Testability”, succinctly:

You should design with the goals of loose coupling and high cohesion in mind.  Using TDD is one really great and surefire (though not foolproof) way of getting you there. You can do it without TDD, but it’s much easier to get it wrong. When striving for a loosely coupled, highly cohesive design, using TDD as a method, you will likely need to perform interaction testing at some point. Mock objects and associated frameworks will assist in this effort and language-based mock objects and frameworks (i.e. those that are created using normal means for normal usage) are all you should need in this regard.

Most of those involved in the debate/discussion will hopefully understand my attempt above (even if they disagree). If I’ve failed in my succinctness, then allow me to elaborate. TDD is not always possible/effective/realistic in all situations. Roy pointed out SharePoint development, which is a great example of this. While you can go through a lot of rigormoral to achieve TDD in this situation, it’s probably going to involve a lot of frustration, inefficiency, and time that could be better spent bang-for-buck-wise.  In these situations, something like TypeMock would be excellent and a worth-while investment. For those not familiar, TypeMock does not use “normal” means to achieve some of it’s functionality. It uses, among other things, the Profiler API in order to create situations not normally available to regular run-of-the-mill C#/VB.NET code.  In this respect, TypeMock is an extremely powerful tool and enables TDD and interaction testing easily against otherwise insurmountable complexity.

So you see, SharePoint, in this example, is the big problem. It’s a poor design that doesn’t lend itself well to extensibility (and therefore testability) except the type of extensibility it prescribes (which is usually not enough and very frustrating for developers wishing to extend SharePoint). What I’m pushing for is to help developers (including MS developers – especially those on the SharePoint and ASP.NET design teams) understand these complexities and problems so that we won’t need to resort to extraordinary means to write good, tested good against these designs.

Simply put, I wish for an environment where TypeMock isn’t needed – or rather, where the extraordinary features of TypeMock aren’t needed. Now, don’t get me wrong, I don’t wish ill on Roy or his company. They’re smart people, they’ll come out with some other amazing tool and service that will blow us away and they’ll be doing quite well. Of this, I am quite sure!

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in Design, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Bingo. That’s it, thanks Jimmy.

  • Good post, and yeah I agree that this isn’t a discussion about whether to apply TDD.

    I don’t want to respond to it all here but I definitely think questioning some aspects of “design for testability” is worth doing. In fact questioning everything is (for me) a good idea (not least as any 2 approaches to design/development contradict each other).

    I’m also looking forward to the day when doing that inside ALT.NET does not result in people assuming that you want a highly coupled big ball of mud (which is definitely what happens now).

    On SharePoint, I agree but there is a world of difference between questioning the value of design for testability within some areas of your own application and producing something of that nature. I’m also not always sure that the approaches I’d use for designing a framework or application like SharePoint/ASP.NET always apply to exactly the same extent to your average LOB application.

    So yeah, by all means make more moving parts in ASP.NET/SharePoint replacable. You can also do the the same in your own applications which can work, but like everything else if you do it too much it can result in some unsatisfactory results. No silver bullet and all that.

    Does that mean rethinking, maybe not, but I do think some of the posts about designing for mockability do overhype the resulting design advantages and underplay the importance of thinking about how far you want to go with the approach.

  • Great post. It’s not only Sharepoint, but many Microsoft products.

  • @Eric: I deleted your post because it didn’t add value. I debated this because you tried to make a point or two in there, but it was lost in your bile.

    Please try again. I would like to hear your contrary points of view and issues of debate, but with less personal insults and bile spewing, please.

  • @Eric

    I’m not sure you’ll get any “this guy doesn’t get it” as much as “we don’t get this guy”. I’ve read the post about 3 times now, still not seeing what got you riled up. I haven’t met someone that enjoyed SharePoint development, and the comment seemed rather innocuous compared to your retort.

    If you’d _really_ like to join the conversation, abandon the anonymity. While it’s certainly your right to remain anonymous, those part of the conversation have dwindling patience from those pelting anonymously from the outside. At the least, it shows lack of courage.

  • I’ve said this in comments on my site, and I wish I’d gone into the distinction in the original post, but there’s a key point that is at the heart of talking across each other: “testability” is a quality, not a design. As such, achieving the quality of “testable” in a .Net project is dead-simple and requires no changes in design when you leverage Typemock’s power. In practical terms, that means that arguments that have “testability” as a sell point need to shift tactics to their *actual* benefits. TDD, DI, IoC may all be the bee’s knees, but they need to be chosen for their actual benefits and not for their ability to deliver “testability”.

  • @Jacob:

    You can (should) achieve testability in your design by following tried and true classic principles and practices, not by using a tool that abuses the framework. Use the tool when you have to, but when you’re in control of the design, not following DI/IoC/SoC/SOLID, etc is a recipe for disaster (TypeMock or no)

  • Hello,
    This is Moran from Typemock, please note the below info:

    Typemock Isolator – .Net Unit Testing software is releasing a free open source license, open source developers can use Typemock Isolator for Free!

    Also we are releasing a new tool called Typemock Racer which will solve a huge problem for multi-thread/multi-core software development.

    Typemock Isolator – is a mocking Framework for Unit Testing



  • @chad: “Use the tool when you have to, but when you’re in control of the design, not following DI/IoC/SoC/SOLID, etc is a recipe for disaster (TypeMock or no)”

    Yeah? Tell that to my users. Not that I never use SOLID principles. I just use them selectively–when I determine that they are needed for the project and not simply because someone has given them the imprimatur of holy writ.

  • @Jacob

    Stop being an ass on my blog. Please provide a details example of where it was inappropriate to use SOLID principles in your design and it was better for it.

  • @Chad: You keep calling me names. I wonder why you think that’s appropriate in a professional discussion or who you are trying to impress? It’s your blog, so by all means, be as abusive as you want. Heck, I’m not going to erase your comments on my blog either so feel free to be abusive there as well–oh, right…

    And here’s the thing about you demanding that I prove to you that I have projects that don’t need strict SOLID adherence: mine is the null hypothesis in this discussion. It’s you who are making claims of absolute applicability and the burden of proof is thus in your court. BTW, are you seriously taking the position that SOLID principles are beneficial for every conceivable software development project? Because that seems like a pretty daring stance to take. Are you seriously going to wire up a DI framework (or create even one interface) for a two-day, highly isolated project where projected maintenance is measured in hours and a complete re-write, if needed, is not only feasible but trivial? Because that kind of project makes up a measurable percentage of the projects I work on.

  • @Jacob

    I wasn’t aware this was a professioanl debate. Especially when you started out with bile, hurled insults, alleged that what i do every day isn’t ‘real worl’ and was generally dismissive of what most people hold to be best practice.

    As if in a serious effort to make yourself look more ridiculous, you offer nothing but derrisions and negativity. You dismiss DI as a waste of time on your blog and here and yet offer no alternative. You seek to confuse and belittle your readers and mine and generally only sour and not contribute.

    It is clear that you do not choose to offer alternatives becauseyou cannot and instead decide to troll on your blog and mine. You represent what I have spent most of my career fighting and cleaning up after. Your ideas, or rather dismissiveness of the good ideas of others with more experience and competency than you is symbolic of the atttitude that has cost my various employersover the years countless thousands and millions of dollars.

    So again, I say, if I’m wrong then prove it and make aserious contribution to this or any other discussion rather than just dumping on it.

    I dont care if your point is opposite of mine or anyone elses, as long as the point is not ‘DI is stupid’ which is what most of the posts that I saw on your blog seemed to say. If you’re so wise and pragmatic and ‘real world’ and not silicon tower, then it should be ratjer easy to illustrate for us how magnificent your designs and solutions are.

    bottom line: Contribute and stop dumping on what you (by your own admission) don’t understand or you’re just a troll.

  • @Chad: Again, I’m not the one belittling or questioning the professionalism of others. You are. And you continue to lie about me when you say I’ve admitted that I don’t understand DI, IoC, SoC or any other STUPID principle. And you’d better be very careful about claims of experience and competency because I have at least five years experience on you (and competency is inherently unprovable–though you can go through my, admittedly limited but far from non-existent, contributions to Subtext if you want examples of actual code I’ve written).

    And if I really thought “DI is stupid” would I be posting about cases where I’m using it?