A practical guide towards agile test-driven development for scientific software projects
October 08, 2020 Β· Declared Dead Β· π arXiv.org
"No code URL or promise found in abstract"
Evidence collected by the PWNC Scanner
Authors
Tom-Robin Teschner
arXiv ID
2010.03896
Category
cs.SE: Software Engineering
Citations
3
Venue
arXiv.org
Last Checked
4 months ago
Abstract
Software testing has received much attention over the last years and has reached such critical importance that agile software development practices put software testing at its core. Agile software development is successfully applied in large-scale industrial software developments but due to its granular responsibilities with roles assigned to various members of the development team, these practices may not be applicable to scientific code development, especially in an academic environment, where it is not uncommon that the codebase is developed, maintained and used by a single person. Even for collaborative scientific software development, financed through external grants, the end-users are typically still part of the development team. This is in contrast to how software is developed in many industries, where the development team and end-users are two separate entities. There are, however, many good code development practices that can be adopted for scientific software projects. Specifically, the intention of this article is to take the centrepiece of agile software development and tailor it to scientific and academic, single-user code development. In this study, a c++ starter project is developed and made available, based on the meson build system, which provides native support for software testing. It is used to show how a simple linear algebra application, found in many scientific and academic applications, can be developed and how simple unit, integration and system tests can be created that are managed through the meson build system. In this way, we are able to minimise software defects and reduce the risk to interpret incorrect data generated by erroneous software that may result in the wrong conclusions to be drawn. Each layer of testing presents one additional layer of protection and we will explore how these may be incorporated with minimum overhead to produce bug-free software.
Community Contributions
Found the code? Know the venue? Think something is wrong? Let us know!
π Similar Papers
In the same crypt β Software Engineering
R.I.P.
π»
Ghosted
R.I.P.
π»
Ghosted
Microservices: yesterday, today, and tomorrow
π
π
The Cartographer
A Survey of Machine Learning for Big Code and Naturalness
R.I.P.
π»
Ghosted
An Overview on Smart Contracts: Challenges, Advances and Platforms
R.I.P.
π»
Ghosted
Slither: A Static Analysis Framework For Smart Contracts
R.I.P.
π»
Ghosted
ContractFuzzer: Fuzzing Smart Contracts for Vulnerability Detection
Died the same way β π» Ghosted
R.I.P.
π»
Ghosted
Federated Learning: Strategies for Improving Communication Efficiency
R.I.P.
π»
Ghosted
In-Datacenter Performance Analysis of a Tensor Processing Unit
R.I.P.
π»
Ghosted
Deep Convolutional Neural Networks for Computer-Aided Detection: CNN Architectures, Dataset Characteristics and Transfer Learning
R.I.P.
π»
Ghosted