Created July 26, 2011
Last updated July 26, 2011
Object-oriented and Testability
In object-oriented, I think that you pay attention to the
Module cohesion and coupling ,
regularize entities , consider the responsibility of the class. I think that there is testability in the considerings too.
In short , please pay attention to the testability.
The Information technology software product evaluation:Quality characteristics and guidlines for their use(ISO/IEC9126) defines 6 main quality characteristics.
In 6 quality , there is the Maintainability. The Testability defined in the Maintainability.
Concretely , the Testability is that the characterizes the effort needed to verify (test) a system change.
If you want to understand the quality characteristics , please refer to No.1 in Reference.
For example , when the program is modified, the re-testing 1 is needed. At this time , If the testing is automated , the testability is good because it takes the few cost and man-hour.
If this testability is bad , the following might happen. ( I don't want to hear... )
- In the testing , bugs are found.
- Modifying.
- But , when modifying , bugs are created... Or bugs that has not been actualized up to now is actualized by having modifyied the bug.
- Return 1...
- The bug curve doesn't settle for a long, long time.
- Go to the Death march 2.
-----
1:
I think that you re-test the modifyied program. But none modified program is also necessary to be re-tested.
Because , the confirming that there are no influence by modifying is needed. The re-testing is called the
Regression test.
2:
The reason of the Death march is not only the testability. if anything , by problem of the project management.
By too short time , too few budgets , worker's technology too shortage (New employee exists) and often specification updating , I think that the testability become bad and the project go to the death march.
3:
There are the Project Scope Management , Project Time Management , Project Cost Management , Project Quality Management , Project Human Resource Management , Project Risk Management , Project Procurement Management , Project Communications Management and Project Integration Management.
If you need details , please study the
PMBOK.
The followings are points that you might want to consider.
- When you design , you might want to clarify the points that the automation of the testing (unit testing) is not easy. And you might want to decreases it.
In my experience , the following points are not easy to do automate testing.
(1)Window (or Dialog , Widget ... ) 1
(2)Processing to which it takes time 2. For example , network.
(3)Boundary. For examle , reading and writing external datas. For example , DB , File , stdout. 3
- You might want to facilitate to make a stub or driver.
Stub is dummy method (or class). For example , when you want to test a program whick access DB, you may make mock object 4.
Driver is a program which calls target method ( or uses target class ) in testing.
For example , if a setter 5 only exists for attribute , the setter is called at the driver. But because confirming , the getter is needed. Please define and create the getter.
- You might want to clarify the points that the specification is not often updated.
Please do sharing and making for parts 6.
Updating specification of datas structure is seldom than it of processes. Please divide.
- You should not use interactive association and dependency. Please confirm that whether simple association and dependency cannot be used.
Especially, interactive dependency is dangerous.
If interactive associations exists , if the algorithm of garbage collection is the Reference count , it is troublesome (The memory leak is generated easily.).
If interactive dependency exists , when unit testing , you must test 2 class at the same time. Therefore , the testing becomes difficult.
Note : Even if interactive association and dependency doesn't exist in class diagram , if the contents are interactive , it is dangerous (more dangerous).
When unit testing , no problem is occurred. But , when the specification is updated , there is a case that specifying the extent of the impact might become difficult.
- Logging. (output trace log)
When unit testing , if logging is not done , I think that we can finish the unit testing. But, when integration Testing , if bugs exists , the analysis is difficult.
In details, the destination and level of logging is defined external file , this file must be checked.
Note : Security relates, too.
Please check followings too.
(1)Is Logging configuration file analyzable?
=>If no , you might want to shutdown the application.
(2)Does the destination exist? Writable? Is disk size OK?
=>If no , you might want to shutdown the application.
- At setter and so on , strict parameter checking , status checking
In common classes and library, please check strictly.
Other , form user input at window and from file , the datas should be strictly checked. And if checking NG , please inform user by dialog , output log. (Of course , the information should have cause and coping process.)
The encapsulation , which is one of three large elements of object-oriented , exists for this. I think so.
As a result, when unit testing , many bugs are discovered. And after integration Testing , discovered bugs is able to decreased , you can decrease man-hour.
- You should understand that all patterns cannot be examined no matter how it tests.
If you don't understand , you must understand that.
Even if you test by white-box testing, which is C0, C1 , C2, you doesn't test all patterns.
For example,
a = b / c;
If c == 0 , it is bug. But , C0, C1 , C2 doesn't extract this parttern.
Other , when you program malti thread , many pattern exists... (We can not test...)
Therefore , you should understand that all patterns cannot be examined no matter how it tests.
When you do the above-mentioned , the man-hour that you design and program increases. But the total man-hour decreases.
-----
1:
When you use a tool (For example
UWSC (Attention : link page is in Japanese) ) , you can automate.
But , in general , you should not combine programs about window and about logical. Please divide.
2:
In general , the unit testing is done at many times. If it takes time to test , you can not test at many times.
There is a case that we must hasten a program speed even if the specification doesn't exist. Because , there is a case that the total man-hour (contains testing) is fewer.
3:
I think that it can automate. But , the test program ( driver or stub ) must have prepare the data of DB or file, must have ckeck the output file. Making them need many man-hour...
4:
A mock object is stub.
5:
Setter and getter is methods which set and get attributes. In VBA , they are the Property Let , Property Set , Property Get procedure.
If you need details , please read "
Encapsulation , Attributes and Operations".
6:
In my experience , few person shares program. Many person use shared method ( or class)...
The following tables are pages that I referred to create this page.
I doesn't assume the responsibility of any damage that occurs because of the use of this page.
Microsoft ,Windows ,Visual Basic and Excel are registered trademarks of Microsoft Corporation in the United States and other countries.
Visual Basic® for Applications may represent a VBA.
Mac ,Mac OS ,Mac OS X ,AppleScript are trademarks of Apple Inc., registerd in the U.S. and other countries.
Sun, Sun Microsystems, Sun Microsystems Computer Corporation, the Sun logo, the Sun Microsystems Computer Corporation logo, Solaris, Java, JavaSoft, JavaScript, HotJava, JDK, and all Java-based trademarks or logos are trademarks or registered trademarks of Sun Microsystems, Inc.
PMBOK is a trademark of the Project Management Institute.
Other brands and their products are trademarks or registered trademarks of their respective holders and should be noted as such.
The author of this page and these companies do not have any relationship.
