Design-for-Testability for Object-Oriented Software
There are many reasons why object-oritened design and development has become the norm for software creation. Two primary resons are the positive impacts that abstraction/inheritance and information hiding have on the development process.
As much as inheritance and information hiding and software design, they have disturbingly negative consequences on testing.
Software Testability
"To test a component, you must be able to control its input (and internal state) and observe its output. If you cannot control the input, you cannot be sure what has caused a given output. IF you cannot observe the output of a component under test, you cannot be sure how a given input has been processed."
The goal of DFT(Design-for-testability) for object-oriented systems is to increase both the ease and value of testing such that the benefits of OO design and development are fully realized.
This paper presents a set of practical design-for-testability techniques that can impact both the ease and value of testing. Each of these techniques is based upon the concept of a software contract. We have used these techniques on a wide variety of development projects during the past ten years and have consistently improved the ease and value of our testing.
1. an 'invariant' expression that defines consistency for the class's state-space
2. a precondition for each method that defines the conditions under which the method can be invoked, and
3. a postcondition for each method that defines precisely what the method does.
* 저자는 2.4 Using data assertions에서 위의 software contract에 대한 check를 data assertion을 사용하여 행할 수 있다고 설명하는 듯 하다.
3.0 Use of Software Contracts
This section extends the use of assertions to handle inheritance relationships and method sequencing.
3.1 Down-calling
Down-call is a technique that can be used to ensure consistency across a class's public interface. Down-calling is a mechanism that can be applied to ensure that the entire interface (both systactic and semantic) is consistent for both non-polymorphic and polymorphic mehtods.
(논문에서는 polymorphic관계에 있어서 interface가 상위레벨에만 있어야 한다고 설명하는 듯 하다. 왜냐하면 하위 클래스가 상위 클래스의 method를 override하였을 경우 클래스들간의 consistency가 깨질 수 있는 위험을 없애기 위함이다.)
3.2 Sequencing Contraints
(즉, syntatic이란 문법에 맞게 구현되었는지의 확인을 가리킨다. 논문은 이와 함께 semantic 즉, method등의 사용이 적절한지 또한 제어할 수 있어야 할 것이라고 설명한다. 논문에서는 각 method에서 state-diagram에 기반한 state를 확인하면서 이에 대한 제어를 가능하게 한다.)
4.0 Conclusions