Unit testing in object oriented software
A function or a procedure has a clearly defined input-output behavior, while a class does not have an input-output behavior specification. We can test a method of a class using approaches for testing functions, but we cannot test the class using these approaches. According to Davis the dependencies occurring in conventional systems are: Data dependencies between variables Calling dependencies between modules Functional dependencies between a module and the variable it computes Definitional dependencies between a variable and its types.
But in Object-Oriented systems there are following additional dependencies: Class to class dependencies Class to method dependencies Class to message dependencies Class to variable dependencies Method to variable dependencies Method to message dependencies Method to method dependencies Issues in Testing Classes: Additional testing techniques are, therefore, required to test these dependencies.
Another issue of interest is that it is not possible to test the class dynamically, only its instances i. Similarly, the concept of inheritance opens various issues e.
Skip to content. Change Language. Related Articles. Table of Contents. The main advantages of OO paradigm include increased reusability, reliability, interoperability, and extendibility.
With the adoption of OO paradigm, almost all the phases of software development have changed in their approach, environments, and tools. Though OO paradigm helps make the designing and development of software easier, it may pose new kind of problems.
Thus, testing of software developed using OO paradigm has to deal with the new problems also. Note that object-oriented testing can be used to test the object-oriented software as well as conventional software. OO program should be tested at different levels to uncover all the errors. At the algorithmic level, each module or method of every class in the program should be tested in isolation. For this, white-box testing can be applied easily. As classes form the main unit of object-oriented program, testing of classes is the main concern while testing an OO program.
At the class level, every class should be tested as an individual entity. At this level, programmers who are involved in the development of class conduct the testing.
Test cases can be drawn from requirements specifications, models, and the language used. In addition, structural testing methods such as boundary value analysis are extremely used. After performing the testing at class level, cluster level testing should be performed.
As classes are collaborated or integrated to form a small subsystem also known as cluster , testing each cluster individually is necessary. At this level, focus is on testing the components that execute concurrently as well as on the interclass interaction.
Hence, testing at this level may be viewed as integration testing where units to be integrated are classes. Once all the clusters in the system are tested, system level testing begins. At this level, interaction among clusters is tested. Usually, there is a misconception that if individual classes are well designed and have proved to work in isolation, then there is no need to test the interactions between two or more classes when they are integrated.
However, this is not true because sometimes there can be errors, which can be detected only through integration of classes. Also, it is possible that if a class does not contain a bug, it may still be used in a wrong way by another class, leading to system failure.
Metrics can be broadly classified into three categories: project metrics, product metrics, and process metrics. Project Metrics enable a software project manager to assess the status and performance of an ongoing project.
Product metrics measure the characteristics of the software product that has been developed. If all the methods of a class are assumed to be equally complex, then a class with more methods is more complex and thus more susceptible to errors. Process metrics help in measuring how a process is performing. They are collected over all projects over long periods of time. They are used as indicators for long-term software process improvements.
Harshit Srivastava. DigiFisk Programming Is Fun. Sandip Bhattacharya. Pranjal Srivastava. Frahaan Hussain.
0コメント