I encountered the following text in an article on the ModelViewPresenter pattern and my brain blue-screened:

Passive View usually provides a larger testing surface than Supervising Controller because all the view update logic is placed in the presenter.

I haven't come across this particular jargon before and I'm rather puzzled about what exactly constitutes the "testing surface" of a design pattern. Would someone please enlighten me regarding what the term means and also what it means for one design pattern to have a larger (or smaller) "testing surface" than another?

  • in addition to Robert's excellent answer I would suggest the authors of that statement may be being a bit shortsighted. It sounds as if the Total Testing Area will be the same, but the piece , the 'Controller' or whatever they have to get done by 5pm on Friday is less so they like that. – Andyz Smith Nov 19 '13 at 1:49

The testing surface of an object is the collective area that is encompassed by the public properties, methods and constructors of that object (its Application Programming Interface, or API). The term "testing surface" is essentially a proxy term for how much programming effort will be required to unit test an object.

Things that can increase the testing surface of an object:

  • Objects that have a greater number of public members have a greater testing surface, because there are more end-points to test.

  • Members that have more complex logic in them have a greater testing surface, because a test is required for each "bifurcation" (e.g. the two sides of an if statement).

  • Members that have a greater number of parameters in them increase the testing surface, because it increases the number of different combinations of parameter values that the member uses.

  • Boundary conditions (such as nulls, transition between positive and negative numbers, and off-by-one conditions) increase the testing surface, because a greater number of tests are required to indentify and test those boundary conditions).

  • Exceptions to normal control flow (such as thrown exceptions) increase the testing surface, because you need tests to insure that those exceptions are accounted for, and that they are working properly under the right conditions.

Things that can decrease the testing surface of an object:

  • Good design practices.

  • A simpler API design

  • The practice of TDD (Test-Driven Design), which makes your code more testable in the first place, and decreases the need for exotic tests.

  • Design by Contract, if the programming language supports it directly, reduces the testing surface, because it already accounts for incorrect input or contract violations (assuming that the contract conditions are correctly specified).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.