An analysis of unit tests of a flight software product line

  • Authors:

  • Dharmalingam Ganesan;Mikael Lindvall;David Mccomas;Maureen Bartholomew;Steve Slegel;Barbara Medina;Rene Krikhaar;Chris Verhoef;Lisa P. Montgomery

  • Affiliations:

  • Fraunhofer Center for Experimental Software Engineering, 20740 College Park, MD, USA;Fraunhofer Center for Experimental Software Engineering, 20740 College Park, MD, USA;NASA Goddard Space Flight Center (GSFC), 20771 Greenbelt, MD, USA;NASA Goddard Space Flight Center (GSFC), 20771 Greenbelt, MD, USA;NASA Goddard Space Flight Center (GSFC), 20771 Greenbelt, MD, USA;NASA Goddard Space Flight Center (GSFC), 20771 Greenbelt, MD, USA;VU University Amsterdam, Department of Computer Science, 1081 HV Amsterdam, The Netherlands;VU University Amsterdam, Department of Computer Science, 1081 HV Amsterdam, The Netherlands;NASA Independent Verification and Validation Facility, 100 University Drive, 26554 Fairmont, WV, USA

  • Venue:
  • Science of Computer Programming
  • Year:
  • 2013

Quantified Score

Hi-index 0.00

Visualization

Abstract

This paper presents an analysis of the unit testing approach developed and used by the Core Flight Software System (CFS) product line team at the NASA Goddard Space Flight Center (GSFC). The goal of the analysis is to understand, review, and recommend strategies for improving the CFS' existing unit testing infrastructure as well as to capture lessons learned and best practices that can be used by other software product line (SPL) teams for their unit testing. The results of the analysis show that the core and application modules of the CFS are unit tested in isolation using a stub framework developed by the CFS team. The application developers can unit test their code without waiting for the core modules to be completed, and vice versa. The analysis found that this unit testing approach incorporates many practical and useful solutions such as allowing for unit testing without requiring hardware and special OS features in-the-loop by defining stub implementations of dependent modules. These solutions are worth considering when deciding how to design the testing architecture for a SPL.