Unit Testing

9 Key excerpts on "Unit Testing"

• 

  eBook - PDF

  Software Quality Assurance

  Integrating Testing, Security, and Audit

  • Abu Sayed Mahfuz(Author)
  • 2016(Publication Date)
  • Auerbach Publications

    (Publisher)

  Unit Testing The unit test is a method in which a programmer tests whether individual units of source code are fit for use. This testing process is usually conducted by the development team or programmer and not by testers as it requires detailed knowledge of the internal design and code. This is the most “micro” scale level of the testing pro-cess. It is not always easily done unless the application has a well-designed architecture with tight code and may require developing automated tools. 66 SOFTWARE QUALITY ASSURANCE Integration Testing Integration testing is a phase in software testing in which individual software modules are combined and tested as a group. This kind of test is an important part of the traditional life cycle because it applies to the integration aspect of the system or software development process. It amounts to the testing of the combined parts of an application to deter-mine if they function together correctly. This testing process is usually conducted by testing teams. The “parts” can be code modules, individ-ual applications, and (more importantly) client and server applications on a network. Incremental Integration Testing This type of integration testing reflects the realities of the develop-ment process. It describes the continuous testing of an application as new func-tionality is added. It implies the various aspects of an application’s functionality are independent enough to work separately before all the parts of the pro-gram are completed. This type of testing is done by programmers or by specially desig-nated testers. Functional Testing Functional testing is a black box testing that bases its test cases on the specifications of the software component under test, which is geared to validate the functional requirements of an application. Functional testing can amount to a trace of the requirement to con-firm its implementation in code, or it can be an actual scenario-driven performance evaluation.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Software Testing and Quality Assurance

  Theory and Practice

  • Kshirasagar Naik, Priyadarshi Tripathy(Authors)
  • 2011(Publication Date)
  • Wiley-Spektrum

    (Publisher)

  CHAPTER 3 Unit Testing

  Knowledge is of no value unless you put it into practice.

  — Anton Chekhov

  3.1 CONCEPT OF Unit Testing

  In this chapter we consider the first level of testing, that is, Unit Testing. Unit Testing refers to testing program units in isolation. However, there is no consensus on the definition of a unit. Some examples of commonly understood units are functions, procedures, or methods. Even a class in an object-oriented programming language can be considered as a program unit. Syntactically, a program unit is a piece of code, such as a function or method of class, that is invoked from outside the unit and that can invoke other program units. Moreover, a program unit is assumed to implement a well-defined function providing a certain level of abstraction to the implementation of higher level functions. The function performed by a program unit may not have a direct association with a system-level function. Thus, a program unit may be viewed as a piece of code implementing a “low”-level function. In this chapter, we use the terms unit and module interchangeably.

  Now, given that a program unit implements a function, it is only natural to test the unit before it is integrated with other units. Thus, a program unit is tested in isolation, that is, in a stand-alone manner. There are two reasons for testing a unit in a stand-alone manner. First, errors found during testing can be attributed to a specific unit so that it can be easily fixed. Moreover, Unit Testing removes dependencies on other program units. Second, during Unit Testing it is desirable to verify that each distinct execution of a program unit produces the expected result. In terms of code details, a distinct execution refers to a distinct path in the unit. Ideally, all possible—or as much as possible—distinct executions are to be considered during Unit Testing. This requires careful selection of input data for each distinct execution. A programmer has direct access to the input vector of the unit by executing a program unit in isolation. This direct access makes it easier to execute as many distinct paths as desirable or possible. If multiple units are put together for testing, then a programmer needs to generate test input with indirect relationship with the input vectors of several units under test. The said indirect relationship makes it difficult to control the execution of distinct paths in a chosen unit.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Instant Approach to Software Testing

  Principles, Applications, Techniques, and Practices

  • Dr Anand Nayyar, Anand Nayyar(Authors)
  • 2019(Publication Date)
  • BPB Publications

    (Publisher)

  So, the main question is how the organizations develop these stable software systems and how the software systems are contributing effectively in businesses for attaining success by working correctly? The answer is Software Testing. Software Testing ensures that the software systems are efficient, without errors, scalable and as per the organizational requirements. So, nowadays, every small to large scale industries have separate and effective software testing department to test software products before implementing and delivering at the client side.

  Software testing is regarded as the most important component in Software Development Life Cycle (SDLC). It primarily performs the tasks of verifying the software under development to meet the requirements of Verification and Validation and delivering the software within the budget and time frame.

  Software testing is termed as well-laid and defined procedure of detecting and correcting bugs in the software.

  Testing Definition’s & Overview

  In 1979, Glenford Myers defined, “Testing is the process of executing a program or system with the intent of finding errors ” in his book titled “The Art of Software Testing ”.

  In 1983, Bill Hetzel defined “Testing is any activity aimed at evaluating an attribute of a program or systems. Testing the measurement of software quality ” in his book titled “Complete Guide to Software Testing ”.

  Other definitions of testing are as follows:

  • Testing is a concurrent lifecycle process of engineering, using and maintaining testware in order to measure and improve the quality of the software being tested.
  • As per IEEE 610 (Software Engineering Terminology): “The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component” .
  • As per IEEE 829 (Test Documentation): “The process of analysing a software item to detect the difference between existing and required conditions (i.e. Bugs) and to evaluate the features of the software items”.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Software Engineering

  The Current Practice

  • Vaclav Rajlich(Author)
  • 2016(Publication Date)
  • Chapman and Hall/CRC

    (Publisher)

  Verification ◾ 155 complete correctness of software—are nevertheless able to intercept a large number of bugs and satisfy reasonable stakeholder expectations. When developing testing techniques, programmers face software discontinuity that is an essential difficulty of software and was discussed in chapter 1. Because of it, the software may give a correct result for a specific value, for example, for the value 1, but for the very next value, 0, it can have a bug because, in one of the state-ments somewhere in the code, it attempts to divide by this value. There is a large variety of software testing techniques and contexts. The tests of the new code are created from scratch as a part of the software change. There is also the testing of the old code that was not supposed to be impacted by the change, and the tests make sure that this is indeed the case. These tests are called regression tests , because their purpose is to prevent regression of what was already function-ing before. The system tests verify software comprehensively, without regard to what is new and what is old; they are done during the phase of change conclusion and verify the complete functionality of the software baseline. Unit tests verify individual modules (units) of the program, for example, classes or class methods. Functional tests verify correctness of a specific func-tionality of the whole program. If the program has a graphical user interface (GUI), the features that are available to the user are tested in these functional tests. Furthermore, there are structural tests that guarantee that the tests exe-cuted certain parts of the programs, and the testing coverage specifies the parts that the structural tests must execute. The tests are aggregated into test suites that test various aspects of software and contain unit, functional, and struc-tural tests. There is a distinction between the production code and the scaffolding or har-ness code.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Introduction to Scientific and Technical Computing

  • Frank T. Willmore, Eric Jankowski, Coray Colina, Frank T. Willmore, Eric Jankowski, Coray Colina(Authors)
  • 2016(Publication Date)
  • CRC Press

    (Publisher)

  Another note on ambiguity and terminology: software is a fairly young discipline, so some literature or online guides invert the scale of functional and integration tests such that integration tests are proposed as a finer granularity than functional tests, or use “func-tional test” in place of “system test” as the largest scale of test. Presented here, is the more common notion that the major types of tests, ordered from smallest scope to largest scope, are unit, followed by functional, then integration, and finally system tests. 17.4.1 Unit Tests A unit test typically exercises a single function. The goal is to have the finest granularity possible. For object-oriented systems, the unit may be a class, especially if that class has a limited public interface. Many unit test enthusiasts will adhere to a rule of one assertion per test case, but this is not a strict requirement for a test case to be considered a unit test. It is nonetheless preferable to limit the number of assertions in each case and only group together those assertions that are truly related within the project’s domain. Judicious divi-sion of assertions across multiple cases provides the most fine-grained, and thus most informative, feedback. This is particularly true when edge cases for a function or module are involved. 242 Introduction to Scientific and Technical Computing Another important aspect of well-written unit tests is isolation of the test cases from other units of code in the project. In high numbers, unit tests are the most powerful and useful tests to have, as they provide high levels of insight and confidence into the workings of each component of a project. Isolation is one key aspect of this power. As a simple example, imagine a module that issues a greeting to persons in the language of their current location.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Software Testing as a Service

  • Ashfaque Ahmed(Author)
  • 2009(Publication Date)
  • Auerbach Publications

    (Publisher)

  Tests are based on coverage of code statements, branches, paths, conditions, loops, and so on. For white box testing, test coverage is also done so that how much of the application has been tested in a release is known. Unit Testing ◾ —Unit Testing is done by developers themselves. It is the most “micro” scale of testing, to test particular functions or code mod-ules. It is typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. It is not always easily done unless the application has a well-designed archi-tecture with tight code; it may require developing test driver modules or test harnesses. Incremental integration testing ◾ —Continuous testing of an application as new functionality is added requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the program are completed or that test drivers be developed as needed; it is done by programmers or by testers. Integration testing ◾ —Testing of combined parts of an application to deter-mine if they function together correctly. The parts can be code modules, indi-vidual applications, client and server applications on a network, and so on. This type of testing is especially relevant to client/server and distributed systems. Functional testing ◾ —Black box–type testing geared to functional require-ments of an application; this type of testing should be done by testers. This does not mean that the programmers should not check that their code works before releasing it (which of course applies to any stage of testing). System testing ◾ —Black box–type testing that is based on overall requirements specifications; it covers all combined parts of a system. In the hierarchy of testing types, system testing comes below user acceptance testing.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Introduction to Software Engineering

  • Ronald J. Leach(Author)
  • 2018(Publication Date)
  • Chapman and Hall/CRC

    (Publisher)

  The second major topic covered in this chapter is software integration. Software integration is the process of combining individual software modules and subsystems into a single working product. Software integration is not a trivial task, especially if the individual software units were developed in different locations or even by different companies and organizations that are separated geographically. Integration into fully distributed systems, software that lives primarily in the cloud, and Software as a Service (SaaS) can cause special difficulties. This coordinated situation in software integration is typical in much of modern software development. As was true of software testing, there are issues in which parts of the integration process can be automated and others that must be done manually.

  6.1 TYPES OF SOFTWARE TESTING

  There are several ways of viewing software from the perspective of testing. For software that is written in procedural languages such as C, Ada, Modula2, or FORTRAN, the fundamental unit is the function. Some languages such as Ada distinguish between a function, which may perform a computation and return a value, and a procedure, which performs a computation without returning a value. (FORTRAN uses the term subroutine instead of procedure.) Languages such as these are often called procedural or imperative languages. We will use the term procedural in this book. We will also use the term module to refer to a function, procedure, or subroutine as necessary.

  For procedural languages, there is a natural hierarchy of items to be tested:

  • Module

  • Unit

  • Subsystem

  • System

   

  The preferred testing approach is to develop a systematic way of testing an individual source code module. The tested modules are then combined into larger testable groupings that are then called units, subsystems, or systems, depending on how large they are or how much of the eventual complete software system is being combined. The process of combining tested modules into larger ones, especially systems, is called integration. The most common terms used to describe testing in this hierarchy are Unit Testing and system testing.

  Once a software system has been through the gamut of tests, it may be subjected to additional testing to determine how the software functions with heavy load on the computer (in the case of a multiprocessing system). Another test of the software may be to examine system behavior if the essential tables and other data structures of the software are close to being filled up. This additional testing is called stress testing or performance testing

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Fundamentals of Software Engineering

  Designed to provide an insight into the software engineering concepts

  • Hitesh Mohapatra, Hitesh Mohapatra, Amiya Kumar Rath(Authors)
  • 2020(Publication Date)
  • BPB Publications

    (Publisher)

  Walkthrough is another testing technique in which the program code is sequentially executed manually by the reviewer. What the code does is also important in desk checking, an informal process where the programmer or some one else, who understands the logic of the program works through the code with a paper and pencil. The programmer executes each instruction by using test cases that may or may not be written down. In one sense, the reviewer acts as the computer, mentally checking each step, and its results for the entire set of computer instructions.

  Among the list of automated checking in Table 9.2 , there is only one static technique which checks syntax. Syntax checking is typically done by a compiler. Errors in syntax are uncovered but the code is not executed. For the other three automated techniques, the code is executed.

  Unit Testing

  Unit Testing , sometimes called module testing is an automated technique. In Unit Testing, each module is tested alone in an attempt to discover any error that may exist in the module’s code. Since modules coexist and work with other modules in programs and systems, they must be tested together in large groups.

  Figure 9.1: Testing process

  Except for small programs, system should not be tested as a single, monolithic unit. Figure 9.1 shows a four-stage testing process where system components are tested, the integrated system is tested and, finally system is tested with the customer’s data. On completion of acceptance testing the sign-on procedure takes place between the developer and customer where the handing over of the application system takes place.

  Integration Testing

  Integration testing is done by combining the modules and testing them together. Integration testing is gradual. The integration plan is guided by the module dependency graph of the structure chart. The structure chart shows the chronological arrangement of various modules calling each other. Hence, by examining the structure chart the integration plan is developed. The structure chart is shown in Figure 9.2

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Foundations of Software Engineering

  • Ashfaque Ahmed, Bhanu Prasad(Authors)
  • 2016(Publication Date)
  • Auerbach Publications

    (Publisher)

  In some cases, where a class has many method calls, it becomes difficult to determine the integration issues if they arise. In those cases, the class can be broken down into smaller classes. Each class can then have one method to test; thus, testing becomes easier.

  Integration testing is purely technical in nature. It does not test the business logic. Business logic is always tested during Unit Testing.

  Test-driven development (i.e., test first development) is a great environment to ensure that your software product does not suffer from business logic problems because all the business logic issues are trapped at the most minute level (i.e., class level). See Chapter 2 for details on test-driven development. Continuous integration and continuous integration testing, on the other hand, ensure that you never have to worry about integration issues. This is because integration issues in a continuous integration environment are handled at the most minute level (i.e., during the integration of a class). If integration is done at a higher level, then there will be many constituents (i.e., many classes) involved during the integration. There could be many errors at one time when the integration happens at a higher level. In that case, going through and fixing all those errors will be a problem and will take a lot of time.

  9.9 System Testing

  System testing is part of validation. It is also known as black box testing because the source code is not used or required for this testing. This testing is done by running the executable code of the software product. It is done by the software testers.

  System testing is actually a group of various testing types done together to check various aspects of the software product. For example, functional testing is carried out to check the business logic aspects of the software product. On the other hand, nonfunctional testing is done to check aspects such as performance, security, and usability of the software product.

  During system testing, we check if the software works as per the requirements and design specifications. We do system tests on the application (system) alone if it does not need to be integrated with other software or hardware systems. However, if some integration with external system(s) is needed, then we carry out system testing after such integration with these systems, in which case there could also be separate integration specification documents for such external systems. If this is the case, then these documents also become the basis for our testing.

  Sign up to read

  Learn more about book