Unit Testing Test case preparation Guidelines and checklist

Unit Testing


The following are the suggested action points based on which a test case can be derived and executed for unit testing.

Test case action which acts as input to the software/feature under test:

1. Validation rules of data fields do not match with the program/data specification.
2. Valid data fields are rejected.
3. Data fields of invalid class, range and format are accepted.
4. Invalid fields cause abnormal program end.

Test case action point to check output from the software/feature under test:

1. Output messages are shown with misspelling, or incorrect meaning, or not uniform.
2. Output messages are shown while they are supposed not to be; or they are not shown while they are supposed to be.
3. Reports/Screens do not conform to the specified layout, with misspelled data labels/titles, mismatched data label and information content, and/or incorrect data sizes.
4. Reports/Screens page numbering is out of sequence.
5. Reports/Screens breaks do not happen or happen at the wrong places.
6. Reports/Screens control totals do not tally with individual items.
7. Screen video attributes are not set/reset as they should be.

Test case action points to check File Access

1. Data fields are not updated as input.
2. “No-file” cases cause program abnormal end and/or error messages.
3. “Empty-file” cases cause program abnormal end and/or error messages.
4. Program data storage areas do not match with the file layout.
5. The first and last input record (in a batch of transactions) is not updated.
6. The first and last record in a file is not read while it should be.
7. Deadlock occurs when the same record/file is accessed by more than 1 user.

Test case action points to check internal Logic of the software/feature under test:

1. Counters are not initialized, as they should be.
2. Mathematical accuracy and rounding do not conform to the prescribed rules.

Test case action points to check Job Control Procedures:

1. A wrong program is invoked and/or the wrong library/files are referenced.
2. Program execution sequence does not follow the JCL condition codes setting.
3. Run time parameters are not validated before use

Test case action point to check the program documentation

1. Supportive documentation (Inline Help, Manual etc.) is not consistent with the program behavior.
2. The information inside the operation manual is not clear and concise with the application system.
3. The operational manual does not cover all the operation procedures of the system.

Test case action point to check program structure (through program walkthrough)

1. Coding structure does not follow coding standards.

Test case action point to check the performance of the software/feature under test:

1. The program runs longer than the specified response time.

Sample Test Cases:

1. Creation of record with valid data set.
2. Rejection of record with invalid data set.
3. Error handling upon empty file.
4. Batch program run with test data set.

– Happy Testing
Reference: testingqa.com


The Need of Unit Testing

Unit Testing


The developers in your company do not believe in testing their code or doing unit testing. How do you tackle this problem and explain them the need of unit testing?


The Need of Unit Testing:a) Unit testing gives programmers measurable confidence in the source code they produce.

b) Unit testing uncovers defects in source code shortly after it is written, which saves valuable time and resources, sometimes by orders of magnitude.

c) Unit testing significantly reduces the amount of debugging necessary by avoiding defects in the first place and by catching those that do occur while they are relatively easy to detect and fix.

d) Unit testing avoids the practice of testing everything at once when it is significantly more expensive in terms of cost, development team morale, and customer satisfaction.

e) Unit testing helps you focus on exactly what is important for a module so that when all of your tests run successfully, you can be reasonably sure that your module has no major defects.


Unit test framework – An Introduction

Unit Testing


Unit test frameworks are software tools to support writing and running unit tests, including:

  • a foundation on which to build tests
  • the functionality to execute the tests
  • the functionality to report their results.



Unit tests usually are developed concurrently with production code, but are not built into the final software product. The relationship of unit tests to production code is shown below:

clip_image002

An application is built from software objects linked together and the unit tests use the application’s objects, but exist inside the unit test framework. Advantages of this framework are:

– The production code is not cluttered up with built-in unit tests.
– The size of the compiled application tends to be kept smaller for the same reason.
– The tests can be run separately from the application, so the objects can be tested in isolation.

A single unit test should test a particular behavior within the production code. Its success or failure validates a single unit of code. Well-written tests set up an environment or scenario that is independent of any other conditions, then perform a distinct action and check a definite result. These tests should avoid dependencies on the results of other tests (called test coupling), and they should be short and simple.

By starting with tests of the most basic functionality, then gradually building to tests of compound objects and behaviors, a unit test framework can be used to verify very complex architectures. Having such a test framework to build upon not only is much easier than developing standalone tests, but also produces more thorough, effective tests. A comprehensive suite of unit tests enables rapid application development, since the effects of every change can be immediately and thoroughly verified.

Unit tests are white box (structural) tests, since the test framework is able to access the internal structure of the code being tested.

Most object-oriented languages provide access protection, preventing outside classes from accessing protected or private code elements. Because of this, unit tests often are written to test only the public interfaces of the objects tested. This encourages the design of objects with discrete, testable interfaces and a minimum of complex hidden behavior. Thus, writing testable objects promotes good object-oriented development practices.