Computer Science

Unit Testing

Unit testing is a software testing method where individual units or components of a program are tested in isolation to ensure they function as intended. It involves writing and running tests for specific functions or modules to identify and fix errors early in the development process. Unit testing helps improve code quality, maintainability, and overall software reliability.

Written by Perlego with AI-assistance

6 Key excerpts on "Unit Testing"

Index pages curate the most relevant extracts from our library of academic textbooks. They’ve been created using an in-house natural language model (NLM), each adding context and meaning to key research topics.
  • Official (ISC)2 Guide to the CSSLP
    • Mano Paul(Author)
    • 2016(Publication Date)
    • CRC Press
      (Publisher)
    drivers and stubs can come in handy. Implementing drivers and stubs is a very common approach to Unit Testing. Drivers simulate the calling unit whereas stubs simulate the called unit. In our case, the getShippingRate() method will be the driver because it calls the getCurrencyConversionRate() method, which will be the stub. Drivers and stubs are akin to mock objects that alleviate Unit Testing dependencies. Drivers and stubs also mitigate a very common coding problem, which is the hard coding of values inline code. By calling the stub, the developer of the driver does not have the need to hard code values within the implementation code of the driver method. This helps with the integrity (reliability) of the code. Additionally, drivers and stubs programming eases the development with third party components when the external dependencies are not completely understood or known ahead of time.
    Unit Testing also facilitates collective code ownership in agile development methodologies. With the accelerated development efforts and multiple software teams collectively responsible for the code that is released, Unit Testing can help identify any potential issues raised by a programmer on the shared code base before it is released.
    Unit Testing provides many benefits, including the ability to:
    • Validate functional logic.
    • Find out inefficiencies, complexities, and vulnerabilities in code, as the code is tested after being isolated into units, as opposed to being integrated and tested as a whole. It is easier to find that needle in a haystack when the code is isolated into manageable units and tested.
    • Automate testing processes by integrating easily with automated build scripts and tools.
    • Extend test coverage.
    • Enable collective code ownership in agile development.

    5.4.1.2 Integration Testing

    Just because Unit Testing results indicate that the code tested is functional (reliable), resilient (secure), and recoverable, it does not necessarily mean that the system itself will be secure. The security of the sum of all parts
  • The Project Manager's Guide to Health Information Technology Implementation
    Unit Testing is the testing of individual software components to ensure that they function as designed without generating unexpected errors prior to integration with other components. Generally, this testing is completed during the software's development and includes items such as checking the spelling of displayed items, ensuring they are in the correct location on the system screen, and checking that data is saved as expected. This concept also applies to COTS systems, in which the software is configured to meet the organization's processes. If, for example, there is an option of what happens when the user double clicks on a patient name in the patient list, does the expected result occur? Unit Testing is also applicable for any ongoing changes made to the system during operations and maintenance. This is also called “component testing” and is the only type of testing with which the developers should be involved.
    Once development is complete, the code is moved to a dedicated test environment where all changes are controlled to minimize the impact to the ongoing testing processes. For smaller systems, testing may occur in a combined development/test environment. In this environment, functional testing is conducted to determine that the integrated components function as designed.
    Functional testing is completed by the testing staff and is based on the functional requirements. Defined test scripts are used to perform functional testing; each script is written to verify a specific requirement or a group of requirements. A sample test script is in Table 11.1 . Besides testing how the integrated components function, based on the requirements, functional testing ensures that the code follows the organizations business processes. This includes a series of tests using normal and erroneous data that should mimic what real users would enter.
    Table 11.1 Portion of Sample Test Script
    # Task Data Expected Outcome P/F Comment
    1 Enter URL <URL to be opened> Website appears with logo in top right corner, login/password fields and privacy verbiage at the bottom P
    2 Enter login/password and select “Enter” Login=testrn; PW=testrn The home screen of the application appears and displays… F Received the error “error verbiage documented here”
    3
    Testing the integration or connection between multiple modules, multiple systems, or portions of a single system is called system integration testing
  • Software Engineering for Embedded Systems
    eBook - ePub

    Software Engineering for Embedded Systems

    Methods, Practical Techniques, and Applications

    • Robert Oshana, Mark Kraeling(Authors)
    • 2019(Publication Date)
    • Newnes
      (Publisher)
    Unit Testing and structural coverage analysis focus on the behavior of an executing application and so are aspects of dynamic analysis. Unit, integration, and system test use code compiled and executed in a similar environment to that being used by the application under development.
    Unit Testing traditionally employs a bottom-up testing strategy in which units are tested and then integrated with other test units. In the course of such testing, individual test paths can be examined by means of structural coverage analysis. There is clearly no need to have a complete code set to hand to initiate tests such as these.
    Unit Testing is complemented by functional testing, a form of top-down testing. Functional testing executes functional test cases, perhaps in a simulator or in a target environment, at the system or subsystem level.
    Clearly, these dynamic approaches test not only the source code, but also the compiler, linker, development environment, and potentially even target hardware. Static analysis techniques help to produce high-quality code that is less prone to error, but when it comes to proving correct functionality there is little alternative but to deploy dynamic analysis. Unit test or system test must deploy dynamic analysis to prove that the software actually does what it is meant to do.
    Perhaps the most telling point with regard to the testing of dynamic behavior—whether by static or dynamic analysis—is precisely what is being tested. Intuitively, a mathematical model with inherent approximations compared with code being compiled and executed in its native target environment suggests far more room for uncertainty.
    If the requirement is for a quick fix solution for some legacy code that will find most problems without involving a deep understanding of the code, then the prediction of dynamic behavior via static analysis has merit. Similarly, this approach offers quick results for completed code that is subject to occasional dynamic failure in the field.
  • Maximizing Benefits from IT Project Management
    eBook - ePub

    Maximizing Benefits from IT Project Management

    From Requirements to Value Delivery

    • José López Soriano(Author)
    • 2016(Publication Date)
    • CRC Press
      (Publisher)
    Unit/individual tests . These are tests that will focus on verifying that each component, considered individually, complies with the specifications prepared for operation. The responsibility for carrying out such tests is the programmer or programmer analyst who is developing each component, and the purpose is to ensure that the component is working properly. Unit test results should provide reasonable assurance that the component is working according to specification. However, this test does not offer any conclusions about how this component will interact with the other components of the global system.
  • Integration tests . These tests will be performed by personnel with advanced experience relative to those involved in Unit Testing. Their responsibility will include testing the subsystem or module to which those unit components belong. They will review validated unit test results, and then perform the designated integration testing to ensure that the different components can handle the required maximum load and level of stress and that they are properly integrated and interact correctly to result in a functional and operational subsystem that meets the test indicated in the relevant design specifications. This process is repeated successively at progressively higher levels of integration, ending in a complete system test.
  • The test plan should also include provisions regarding the actions to be taken when a unit or system test fails. The plan should specify the variety of incidents that could cause modules and components to be returned to technical teams for correction and rectification. It should identify the process for doing this, and for arranging the repeated iterations of tests needed until we have an information system that is clean of errors.
    It is very important that the various test conditions are defined from the perspective of customer acceptance. To that end, test conditions should correspond to the criteria for product acceptance, and as such should be discussed and approved by users who have defined the behavior of the system they are seeking to obtain. This allows information system testing to engage all relevant stakeholders in the process, which facilitates public awareness and the accountability of everyone involved in the testing activities.
  • Testing Computers Systems for FDA/MHRA Compliance
    • David Stokes(Author)
    • 2003(Publication Date)
    • CRC Press
      (Publisher)
    Prior to System Integration Testing the individual applications or modules will have either been defined as mature and standard in the market place or will have been subjected to Software Module Testing at an appropriate level. The purpose of Software Integration Testing is, therefore, to ensure that the various software components all function correctly together.
    At a higher level, Software Integration Testing is also used to test the interfaces between different systems. In order to evaluate the functioning of the interface it is necessary that the individual systems (or at least those functions in the system responsible for handling the interface) have been fully tested.
    When defining Software Integration Tests the purpose is not to challenge test the individual modules or systems, but to ensure that the modules or systems function correctly together in a robust, reliable and predictable manner. Where appropriate, stress testing (or challenge testing) may be part of this.
    The objectives of the Software Integration Tests should be clearly traceable to the appropriate sections of the Software Design Specification(s). Meeting the objectives of the Software Design Test Scripts should clearly demonstrate that the overall system is designed and operates as specified.
  • The Lean Electronic Health Record
    eBook - ePub

    The Lean Electronic Health Record

    A Journey toward Optimized Care

    • Ronald G. Bercaw, Kurt A. Knoth, MBA Snedaker(Authors)
    • 2017(Publication Date)
    Be sure to define, in advance, what defects are and how you will prioritize them. If you haven’t done this already in your EHR project, doing so before testing is important. Even if you’ve built a great system, you are bound to find errors early in the testing phase. Define how you’ll prioritize and handle defects and errors. For example, a defect may be anything that is not built according to the specifications. An error may be something that is built according to specifications but does not work as designed. In either case, you should define what a critical, high, medium, and low priority defect (and/or error) is and how you will address these. For example, you may determine that all critical and high defects and errors cause testing to stop until resolved. For medium and low, you may batch them into a development cycle at the end of a test phase, such as at the end of Unit Testing.
    In general, you should have test plans that define what is to be tested, at what stage it will be tested (unit or integrated, for example), who will test it, how results will be documented, and how issues will be addressed. Testing is an iterative process, but issues should become far less numerous the further into the testing process you get. Figure 9.1 shows the conceptual steps for testing and functional requirement validation (sometimes used interchangeably with user acceptance testing). For more on software testing in general, see the Resources section at the end of this chapter.
    Figure 9.1 Testing phases.

    Unit and Functional Testing

    Your functional and technical requirements form the foundation of unit and functional testing. For the purposes of the EHR, a unit might be a specific module such as an ED module or your revenue management module. Functional testing, of course, tests the function of that portion of the software. This is the initial phase of testing that makes sure the build is accurate and complete. Some elements that should be tested during this phase are listed here along with questions you should be asking and answering.
    1. Are all major functions present? This is a very basic question and should easily be answered. A project plan should have a list of all major functions required and their status, so this should really be just a final check to make sure no defined work has been accidentally missed.