Search NASA⌕ Search

SEARCH · Search NASA

Results for “test-driven development”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

7 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Test Driven Development of Scientific Models

Test-Driven Development (TDD) is a software development process that promises many advantages for developer productivity and has become widely accepted among professional software engineers. As the name suggests, TDD practitioners alternate between writing short automated tests and producing code that passes those tests. Although this overly simplified description will undoubtedly sound prohibitively burdensome to many uninitiated developers, the advent of powerful unit-testing frameworks greatly reduces the effort required to produce and routinely execute suites of tests. By testimony, many developers find TDD to be addicting after only a few days of exposure, and find it unthinkable to return to previous practices. Of course, scientific/technical software differs from other software categories in a number of important respects, but I nonetheless believe that TDD is quite applicable to the development of such software and has the potential to significantly improve programmer productivity and code quality within the scientific community. After a detailed introduction to TDD, I will present the experience within the Software Systems Support Office (SSSO) in applying the technique to various scientific applications. This discussion will emphasize the various direct and indirect benefits as well as some of the difficulties and limitations of the methodology. I will conclude with a brief description of pFUnit, a unit testing framework I co-developed to support test-driven development of parallel Fortran applications.

Clune, Thomas L.↗
NASA NTRS2014

Test Driven Development of Scientific Models

Test-Driven Development (TDD), a software development process that promises many advantages for developer productivity and software reliability, has become widely accepted among professional software engineers. As the name suggests, TDD practitioners alternate between writing short automated tests and producing code that passes those tests. Although this overly simplified description will undoubtedly sound prohibitively burdensome to many uninitiated developers, the advent of powerful unit-testing frameworks greatly reduces the effort required to produce and routinely execute suites of tests. By testimony, many developers find TDD to be addicting after only a few days of exposure, and find it unthinkable to return to previous practices.After a brief overview of the TDD process and my experience in applying the methodology for development activities at Goddard, I will delve more deeply into some of the challenges that are posed by numerical and scientific software as well as tools and implementation approaches that should address those challenges.

Overview of TDD Process↗
NASA NTRS2022

Flight Rule Design, Implementation, Verification, and Validation for the Psyche Mission

NASA Jet Propulsion Lab (JPL)’s upcoming mission Psyche will begin its journey to the asteroid (16) Psyche in late 2022 in an effort to better understand its origins and, in turn, better understand our own. Operating the spacecraft safely will require the dedicated efforts of a small team that understands the spacecraft’s operational constraints, as well as a set of powerful spacecraft models designed to catch command errors that can pose risks to mission success. One of the responsibilities of the operations team is to ensure adherence to a set of Flight Rules written by spacecraft and instrument experts that are designed to mitigate these risks. Psyche’s innovations in Flight Rule design principles and advancements in the tools and processes used to implement and check Flight Rules are discussed. A comparison of Psyche’s approach to Flight Rules to other JPL missions will provide lessons learned for future missions that must perform constraint checking during operations. Flight Rule development faces several major challenges. First, flight rule developers must work with Subject Matter Experts (SME) to write the rules in a way that captures the intent of the constraint in a straightforward, enforceable manner. Second, software implementers must correctly interpret flight rules into code so that it meets the original intent of the SME. Finally, a means must be provided for SMEs to validate flight rule implementations without requiring them to understand the underlying software. Innovative processes intended to efficiently close the loop between stakeholders and software developers are described, such as the use of test-driven development to provide stakeholders with easy-to-review implementations. New guidelines for flight rule writing, designed to address these challenges, are described for future missions to adopt and build upon. Psyche Mission System has a variety of new and heritage tools that improve in the Flight Rule validation and checking process. Psyche developed a powerful, new tool called RandSEQ and made significant improvements to Octopusjam, two valuable tools that aid the development of Flight Rule unit tests. Advancements in the models and processes for performing sequence validation with SEQuence GENerator (SEQGEN), the primary, high-heritage tool used for automated flight rule checks on Psyche, are described. The development of new software and the advancements to existing software put Psyche at the forefront of Flight Rule technology. All missions must perform detailed constraint checking, so a comparison of Psyche’s approach to some of these items to the approaches taken by other missions such as Dawn, M2020, and Europa Clipper is done, specifically to examine SME-developer communication, tools used, and development process. Lessons learned from this comparison will be provided.

Weise, Tim↗
NASA NTRS2013

Adoption of Test Driven Development and Continuous Integration for the Development of the Trick Simulation Toolkit

This paper describes the adoption of a Test Driven Development approach and a Continuous Integration System in the development of the Trick Simulation Toolkit, a generic simulation development environment for creating high fidelity training and engineering simulations at the NASA/Johnson Space Center and many other NASA facilities. It describes what was learned and the significant benefits seen, such as fast, thorough, and clear test feedback every time code is checked-in to the code repository. It also describes a system that encourages development of code that is much more flexible, maintainable, and reliable. The Trick Simulation Toolkit development environment provides a common architecture for user-defined simulations. Trick builds executable simulations using user-supplied simulation-definition files (S_define) and user supplied "model code". For each Trick-based simulation, Trick automatically provides job scheduling, checkpoint / restore, data-recording, interactive variable manipulation (variable server), and an input-processor. Also included are tools for plotting recorded data and various other supporting tools and libraries. Trick is written in C/C++ and Java and supports both Linux and MacOSX. Prior to adopting this new development approach, Trick testing consisted primarily of running a few large simulations, with the hope that their complexity and scale would exercise most of Trick's code and expose any recently introduced bugs. Unsurprising, this approach yielded inconsistent results. It was obvious that a more systematic, thorough approach was required. After seeing examples of some Java-based projects that used the JUnit test framework, similar test frameworks for C and C++ were sought. Several were found, all clearly inspired by JUnit. Googletest, a freely available Open source testing framework, was selected as the most appropriate and capable. The new approach was implemented while rewriting the Trick memory management component, to eliminate a fundamental design flaw. The benefits became obvious almost immediately, not just in the correctness of the individual functions and classes but also in the correctness and flexibility being added to the overall design. Creating code to be testable, and testing as it was created resulted not only in better working code, but also in better-organized, flexible, and readable (i.e., articulate) code. This was, in essence the Test-driven development (TDD) methodology created by Kent Beck. Seeing the benefits of Test Driven Development, other Trick components were refactored to make them more testable and tests were designed and implemented for them.

Penn, John M.↗
NASA NTRS2014

pFUnit 3.0 Tutorial Advanced

This tutorial will introduce Fortran developers to unit-testing and test-driven development (TDD) using pFUnit. As with other unit-testing frameworks, pFUnit, simplifies the process of writing, collecting, and executing tests while providing clear diagnostic messages for failing tests. pFUnit specifically targets the development of scientific-technical software written in Fortran and includes customized features such as: assertions for multi-dimensional arrays, distributed (MPI) and thread-based (OpenMP) parallellism, and flexible parameterized tests.These sessions will include numerous examples and hands-on exercises that gradually build in complexity. Attendees are expected to have working knowledge of F90, but familiarity with object-oriented syntax in F2003 and MPI will be of benefit for the more advanced examples. By the end of the tutorial the audience should feel comfortable in applying pFUnit within their own development environment.

Test Driven using pFUnit↗
NASA NTRS2022

The Psyche Planning Software Subsystem: Creating a Robust Toolset for a Discovery-class Mission

Psyche is a Discovery-class mission to the small metal-rich asteroid (16) Psyche, and is slated to launch in 2022. Psyche, like many missions, requires low-cost activity planning and sequence generation that serves as the backbone to overall uplink design. Such tools must be maintainable over long periods of operations, and powerful enough to solve complex issues that deep-space one-off missions encounter. In this paper we introduce cost-effective solutions that leverage inner- and open-source principles to meet a variety of common and novel use cases.The uplink process that was designed to meet these challenges is presented, as well as the data-flow through the high-level architecture of the planning software subsystem. The user-facing planning tools are described, particularly the Science Opportunity Analyzer, the Plan Editor, Psyche’s planning automation in the Blackbird framework, and Psyche Simulation Reports. All these applications are either new or have been substantially revamped to meet Psyche’s concept of operations. In particular, ensuring the entire toolchain can correctly process epoch-relative activities is discussed. Underlying the main applications are a common set of dependencies developed and maintained by a new cross-mission association of planning developers. In this way, Psyche can inherit well-tested functionality which saves effort and ensures its developers can focus on solving domain challenges. Quality control of the applications and libraries is ensured with a code-review and unit-test based novel ‘CM lite’ process. Collaboration with international industry and academia using the open-source modules is already occurring.The planning and scheduling software is designed to maximize operator awareness of the integrated plan at every step of the process and use common interfaces and file formats to easily transfer information. Design choices plus the team’s test-driven development process enables more expansive capabilities compared to the decentralized planning and sequence generation functions typical of Discovery-class orbiters without significant development cost increases. Benefits and drawbacks of Psyche’s approach are discussed, including comparison to other missions and tools where appropriate.

Ramanathan, Keshav↗
NASA NTRS2013

Soil Moisture Active Passive Mission: Fault Management Design Analyses

As a general trend, the complexities of modern spacecraft are increasing to include more ambitious mission goals with tighter timing requirements and on-board autonomy. As a byproduct, the protective features that monitor the performance of these systems have also increased in scope and complexity. Given cost and schedule pressures, there is an increasing emphasis on understanding the behavior of the system at design time. Formal test-driven verification and validation (V&V) is rarely able to test the significant combinatorics of states, and often finds problems late in the development cycle forcing design changes that can be costly. This paper describes the approach the SMAP Fault Protection team has taken to address some of the above-mentioned issues.

Earth↗