September 10, 2006 OOP, Unit Testing

Benefits of Testability

I have been having a hard sell of “testability is a good thing” at my work. I feel that unit testing leads to testability leads to good OO. The dynamic mocking application TypeMock.NET has not helped: nor has the article Stop Designing for Testability. TypeMock is a powerful application but I think that it can be misused to allow poor design with ease of unit testing. The pain that unit testing creates when dealing with a low testability test subject is experienced close to when the test subject was created. This gives the developer rapid feedback that there is a design issue. The feedback is experience while the developer is still in flow and can make the needed changes with the lest impact to schedule. So unit testing and testability are like an alarm indicating early that there is a design problem. This sounds like a good thing to me, something that I would not want to circumvent or avoid. There are a lot of other characteristics of design that are related to testability. In particular the list below are benefits to testability.

  • Understandability
  • Modifiability
  • Availability
  • Flexibility
  • Maintainability
  • Reliability
  • Usability
  • Changeability
  • Fault Tolerance

This list was gathered from Appendix D of Stefan Jungmayr’s thesis Improving testability of object-oriented systems.

If some or all of the list is important to your project then testability will help you get it.

4,370 Total Views

7 to “Benefits of Testability”

Trackbacks/Pingbacks

  1. codedancer says:

    Tools instead of testability…

  2. 14 facets of TypeMock.NET and Designing for Testability…

    There has been much talk about Designing for Testability lately.Basically the argument is: Should our Tests (Enabling Mock Insersions) Drive our design? or should we use tools to do it for us?Here is what 14 of are our community have to say a…

  3. [...] There was a pit stop at YAGNI and Testability as it had some bearing on the OCP. It was all kicked of by Benefits of Testability. Which was inspired by Dr. Stefan Jungmayr’s dissertation Improving testability of object oriented system. [...]

  4. [...] All the benefits that come with testability. [...]

  5. [...] Before you read what I wrote, you can read posts that say "don’t use Typemock" here, here,here and there are others. Most fear that Typemock will make it easy for you to write non testable code, or that your design will suffer for it. You can read my thoughts on this here and here. [...]

  1. Lenny says...

    There’s a strong argument for “don’t design for testability”. I don’t read that as “make bad designs”, but rather don’t let the testing framework dictate your design. Let the business needs dictate design and use a testing framework that allows adequate testing of your design.

    It seems to me it really boils down to a question of purity. If you’re on OO purist, then relying on “traditional” unit testing frameworks to drive your design (or that of your less capable peers) will be seen as a good thing. If, however, you are more concerned with business functionality and a solid design that meets the business needs, then TypeMock seems to fit the bill.

    Understanding a highly OO design can be just as daunting as groking spaghetti code. I’m not advocating the latter, just noting that complex OO designs that exist merely to support nUnit testing doesn’t necessarily translate to understandability or maintainability.

    Fault tolerance, reliability and changeability and the other features you list are provided by good unit tests – regardless of methodology. If the tests are valid and good, these features are protected by either nUnit or TypeMock. (While we’re on this point, bad tests can be written in any framework, so I think we’re both operating on the assumption “good” test are being written in either framework.)

    Another area of concern is legacy code. It would be very nice to be able to refactor all your old code to modern standards of OO purity, but that’s just not realistic (some might even say “that’s just crazy talk”). Budget or time constraints almost guarantee legacy code cannot be refactored adequately for a given project. Should the effort be made? Sure, but if something like TypeMock can help ensure existing functionality is protected while adding new features, why not take advantage of it?

    The point of software is to solve a problem. If said problem can be solved reliably and expediently with classes “firmly coupled”, why not allow TypeMock to help confirm proper functionality? Sure, it’s not “coding to interfaces” and not a truly OO design, but it solves the need. OO designs are a bit like normalizing a database. Just as a database can be “over normalized”, software designs can be “over OO’d”.

  2. jflowers says...

    Thanks for thoughtful response Lenny. :-)
    I don’t see how an xUnit framework acts as a force on the design of a product. I do see how trying to get control over a test subject and be able to observe a test subject can act as a force on design.
    The list of benefits including understandability and maintainability are not one man’s opinions. They were identified through empirical evidence.
    Your argument about complex OO as a reason to use TypeMock worries me. I would rather simplify the design and still not use TypeMock. I have never run into a situation were an overly complex design could not be simplified and improve testability.
    TypeMock is a wonderfully powerful tool. It is great for working with legacy code. I imagine that it is particularly good at reducing the desire and pressure to improve a bad design.
    Dynamic mocking reduces the readability of a unit test. I prefer static test doubles. In fact I prefer test stub recorders as the don’t decrease the readability.
    Please let me be clear I think that testability in a system when balanced with the other design principles creates the simplest design expressing all the qualities listed in this blog post. Testability is not about going to extremes just to make something testable.

  3. codedancer says...

    Tools instead of testability…

  4. Creative Coding by Eli Lopian says...

    14 facets of TypeMock.NET and Designing for Testability…

    There has been much talk about Designing for Testability lately.Basically the argument is: Should our Tests (Enabling Mock Insersions) Drive our design? or should we use tools to do it for us?Here is what 14 of are our community have to say a…

  5. JayFlowers > OOD Class Principles and Testability says...

    [...] There was a pit stop at YAGNI and Testability as it had some bearing on the OCP. It was all kicked of by Benefits of Testability. Which was inspired by Dr. Stefan Jungmayr’s dissertation Improving testability of object oriented system. [...]

  6. JayFlowers > A Tune-Up for TDD? says...

    [...] All the benefits that come with testability. [...]

  7. The Case For Typemock | Developer Home says...

    [...] Before you read what I wrote, you can read posts that say "don’t use Typemock" here, here,here and there are others. Most fear that Typemock will make it easy for you to write non testable code, or that your design will suffer for it. You can read my thoughts on this here and here. [...]

Leave a comment

*

here