Test-driven Development Practices Research Articles

Exploring the Connection between the TDD Practice and Test Smells—A Systematic Literature Review

Test-driven development (TDD) is an agile practice of writing test code before production code, following three stages: red, green, and refactor. In the red stage, the test code is written; in the green stage, the minimum code necessary to make the test pass is implemented, and in the refactor stage, improvements are made to the code. This practice is widespread across the industry, and various studies have been conducted to understand its benefits and impacts on the software development process. Despite its popularity, TDD studies often focus on the technical aspects of the practice, such as the external/internal quality of the code, productivity, test smells, and code comprehension, rather than the context in which it is practiced. In this paper, we present a systematic literature review using Scopus, Web of Science, and Google Scholar that focuses on the TDD practice and the influences that lead to the introduction of test smells/anti-patterns in the test code. The findings suggest that organizational structure influences the testing strategy. Additionally, there is a tendency to use test smells and TDD anti-patterns interchangeably, and test smells negatively impact code comprehension. Furthermore, TDD styles and the relationship between TDD practice and the generation of test smells are frequently overlooked in the literature.

Extending the SEMAT Kernel with the TDD practice

Coping with ever increasing complexity is one of the main challenges of software engineering. Applying proven practices through established software processes is a viable way to introduce consistency and tame complexity. The SEMAT is a novel meta-process aiming to encompass commonalities across a disparate set of different software processes. The goal is to create a framework, giving proper jumpstart to any proprietary customisation. This is crucial, as various types of software demand diverse software processes (there is no one-size-fits-all method). On the other hand, all processes strive for a disciplined application of valid development and maintenance routines. This paper analyses a set of methodologies for several software development lines to recognise common and specific development practices. A special emphasise is put on the test-driven development (TDD), showcasing its significant contribution in improving the total quality of the end product. The SEMAT Kernel is extended with additional set of alphas, which are elaborated in detail including containing states, transitions and dependencies. The TDD practice activities were analysed for each introduced alpha as state transition triggers. Consequently, the high-level development plan is expanded with newly defined alphas, providing a powerful tool for performing all sorts of system analysis.

Does test-driven development improve class design? A qualitative study on developers’ perceptions

Developers commonly affirm that writing unit tests improve internal quality of a software, besides a more obvious effect on external quality. This is particularly common among Test-Driven Development (TDD) pactitioners, who leverage the acting of writing tests to think about and improve class design. However, it is not clear how this effect occurs. This study investigates the developers’ perceptions on how the practice of TDD influences class design, by means of a qualitative study with 25 participants from 6 different companies in Brazil. In this paper, we share their opinions and experience. According to them, the practice of test-driven development does not drive directly the design, but gives them a safe space to think, the opportunity to refactor constantly, and subtle feedback given by unit tests, are responsible to improve the class design. We suggest developers to experiment the practice of TDD, as its effects look positive to software developers. As future work, tools may be developed to automatically warn developers about classes that have testability problems, or even to suggest them to practice TDD in specific parts of the code.

Test Driven Development: Advancing Knowledge by Conjecture and Confirmation

Test Driven Development (TDD) is a critical agile software development practice that supports innovation in short development cycles. However, TDD is one of the most challenging agile practices to adopt because it requires changes to work practices and skill sets. It is therefore important to gain an understanding of TDD through the experiences of those who have successfully adopted this practice. We collaborated with an agile team to provide this experience report on their adoption of TDD, using observations and interviews within the product development environment. This article highlights a number of practices that underlie successful development with TDD. To provide a theoretical perspective that can help to explain how TDD supports a positive philosophy of software development, we have revised Northover et al.’s conceptual framework, which is based on a four stage model of agile development, to reinterpret Popper’s theory of conjecture and falsification in the context of agile testing strategies. As a result of our findings, we propose an analytical model for TDD in agile software development which provides a theoretical basis for further investigations into the role of TDD and related practices.

Bug Localization in Test-Driven Development

Software development teams that use agile methodologies are increasingly adopting the test-driven development practice (TDD). TDD allows to produce software by iterative and incremental work cycle, and with a strict control over the process, favouring an early detection of bugs. However, when applied to large and complex systems, TDD benefits are not so obvious; manually locating and fixing bugs introduced during the iterative development steps is a nontrivial task. In such systems, the propagation chains following the bugs activation can be unacceptably long and intricate, and the size of the code to be analyzed is often too large. In this paper, a bug localization technique specifically tailored to TDD is presented. The technique is embedded in the TDD cycle, and it aims to improve developers' ability to locate bugs as soon as possible. It is implemented in a tool and experimentally evaluated on newly developed Java programs.

The effectiveness of test-driven development: an industrial case study

Test-driven development (TDD) is a software development practice, where test cases are incrementally written before implementing the production code. This paper presents the results of a multi-case study investigating the effectiveness of TDD within an industrial environment. Three comparable medium-sized projects were observed during their development cycle. Two projects were driven without TDD practice, while the third one introduced TDD into the development process. The effectiveness of TDD was expressed in terms of external code quality, productivity, and maintainability. Our results indicate that the TDD developers produced higher quality code that is easier to maintain, although we did observe a reduction in productivity.

Operational definition and automated inference of test-driven development with Zorro

Test-driven development (TDD) is a style of development named for its most visible characteristic: the design and implementation of test cases prior to the implementation of the code required to make them pass. Many claims have been made for TDD: that it can improve implementation as well as design quality, that it can improve productivity, that it results in 100% coverage, and so forth. However, research to validate these claims has yielded mixed and sometimes contradictory results. We believe that at least part of the reason for these results stems from differing interpretations of the TDD development style, along with an inability to determine whether programmers actually follow whatever definition of TDD is in use. Zorro is a system designed to automatically determine whether a developer is complying with an operational definition of Test-Driven Development (TDD) practices. Automated recognition of TDD can benefit the software development community in a variety of ways, from inquiry into the "true nature" of TDD, to pedagogical aids to support the practice of test-driven development, to support for more rigorous empirical studies on the effectiveness of TDD in both laboratory and real world settings. This paper describes the Zorro system, its operational definition of TDD, the analyses made possible by Zorro, two empirical evaluations of the system, and an attempted case study. Our research shows that it is possible to define an operational definition of TDD that is amenable to automated recognition, and illustrates the architectural and design issues that must be addressed in order to do so. Zorro has implications not only for the practice of TDD, but also for software engineering "micro-process" definition and recognition through its parent framework, Software Development Stream Analysis.

Realizing quality improvement through test driven development: results and experiences of four industrial teams

Test-driven development (TDD) is a software development practice that has been used sporadically for decades. With this practice, a software engineer cycles minute-by-minute between writing failing unit tests and writing implementation code to pass those tests. Test-driven development has recently re-emerged as a critical enabling practice of agile software development methodologies. However, little empirical evidence supports or refutes the utility of this practice in an industrial context. Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15---35% increase in initial development time after adopting TDD.

Modeling and simulation of open source development using an agile practice

The goal of this work is to study the effects of the adoption of agile practices on open source development. In particular, we started to evaluate the effects of TDD (Test Driven Development) since it is easer to apply in a distributed environment than most other agile practices. In order to reach this goal we used the simulation modeling approach. We developed a simulation model of open source software development process. The model was tuned using data from a real FLOSS project: Apache HTTP Server. To introduce the TDD practice in our FLOSS simulation model, we made some assumptions based on empirical results. The two FLOSS development models (nonTDD and TDD) were compared. The one incorporating the agile practice yields better results in terms of code quality.

The test bus imperative: architectures that support automated acceptance testing

Agile methods more specifically, test-driven development practices have begun to raise the software industry's awareness of automated acceptance testing. Many tools can be purchased to help testers write automatic scripts for testing the system through its user interface. Unfortunately, testing through the UI is slow, opaque, and dangerous. The software industry's increased awareness of automated testing benefits and potentials is good new for an industry that for decades has been beset by quality and productivity issues.