Unit Tests

The first of eight (8) Test Types looks at the foundational level of testing.

Unit Testing

Any RICE object (Report, Integration, Conversion, Extension) that requires change should undergo Unit Testing to validate that the basic changes are valid.

The following assumptions apply to Unit Testing:

  • Approval and sign-off of Unit Tests will be required from those who authored the Acceptance Criteria.  This may be obtained prior to or during Functional Review.
  • The Unit Test occurs in the Development (DEV1) or Data Conversion (DEV2) environment (as appropriate).
  • Any RICE object must be successfully Unit Tested before they can be promoted from the Development environment (DEV1 / DEV2) to the Test environment (TST1)
On This Page
    Add a header to begin generating the table of contents

    Overview & Objective

    A Unit Test validates that an individual component within a RICE object works as designed. It is the testing of changes made to a smallest elements of the Solution, those typically produced by one person or a pair of developers.

    That said, partially complete objects should be made available for concurrent Functional Testing if the changes being made will take more than one (1) day to complete.  Typically, changes to any incremental (i.e., non-Vendor delivered) RICE element require Unit Tests.

    The objective is to validate that developed object(s) meet the given design specifications. This is why it is important to complete and gain sign-off of the corresponding Acceptance Criteria, as well as the functional and technical specifications identifed by a Story. A RICE element that meets the captured criteria and specifications is complete.

    Scope

    • In: A Unit Test validates changes made to the smallest components of the Solution, such as such as a field, a piece of code, or a look-up.  Any custom or modified object should be Unit Tested for accuracy prior to being identified as 'complete' and ready for review and further testing.
    • Out: Unit Tests are not usually expected to address Vendor delivered objects (i.e., Package Software, Application, Tools). Unit Testing is assumed to have been completed by the software vendor for delivered components.

    Timing & Responsibility

    Solution Analysts or other Delivery Team members are responsible for the creation, execution and maintenance of Unit Tests.  It is the responsibility of the person who produced or modified the element to Unit Test it.

    At the end of the each Sprint cycle, any RICE element worked on during that Sprint should have been Unit Tested to ensure that the object meets the specified functional and quality requirements.

    A.K.A.

    Unit Tests are not typically known by any other name.

    Dependencies with Other Test Types

    • Prior: Unit Tests are not dependent upon any other test type.
    • Subsequent: Unit Tests are a dependency for Functional Tests.  Functional Tests should not need to validate changes made to individual components which can be validated using Unit Tests.

    Automation

    Unit Tests which validate code changes should automated when and where possible.  These tests will be re-executed many times.

    Solution Types

    • Product: All RICE objects should have multiple Unit Tests associated with it.
    • System: If any RICE objects are created, each should have associated Unit Tests.
    • Service:  Unit Test are rarely applicable to Service Solutions.

    Test Conditions

    Unit Testing is the most opportune time to conduct negative testing.  This is the best time to try "breaking" the Solution.

    Test Data

    Unit Test data is created by the same individual(s) who create and execute the tests themselves.

    Test Scripts

    to migrate

    Test Cases

    to migrate

    Test Scenarios

    to migrate

    The next type of testing to review are Functional Tests.

    Scroll to Top