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

Kou, Hongbing; Johnson, Philip M.; Erdogmus, Hakan

doi:10.1007/s10515-009-0058-8

Cited by 27 publications

(27 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This Eclipse plug-in identified different types of activities performed by developers (defined in Table 1 ) on the heuristics defined in Kou et al [58] . Besouro also gathered the duration of each performed activity.…”

Section: Triangulating Qualitative Results With Quantitative Datamentioning

confidence: 99%

Findings from a multi-method study on test-driven development

Romano

Fucci

Scanniello

et al. 2017

Information and Software Technology

View full text Add to dashboard Cite

a b s t r a c tContext: Test-driven development (TDD) is an iterative software development practice where unit tests are defined before production code. A number of quantitative empirical investigations have been conducted about this practice. The results are contrasting and inconclusive. In addition, previous studies fail to analyze the values, beliefs, and assumptions that inform and shape TDD. Objective: We present a study designed, and conducted to understand the values, beliefs, and assumptions about TDD. Participants were novice and professional software developers. Method: We conducted an ethnographically-informed study with 14 novice software developers, i.e., graduate students in Computer Science at the University of Basilicata, and six professional software developers (with one to 10 years work experience). The participants worked on the implementation of a new feature for an existing software written in Java. We immersed ourselves in the context of our study. We collected qualitative information by means of audio recordings, contemporaneous field notes, and other kinds of artifacts. We collected quantitative data from the integrated development environment to support or refute the ethnography results. Results: The main insights of our study can be summarized as follows: (i) refactoring (one of the phases of TDD) is not performed as often as the process requires and it is considered less important than other phases, (ii) the most important phase is implementation, (iii) unit tests are almost never up-to-date, and (iv) participants first build in their mind a sort of model of the source code to be implemented and only then write test cases. The analysis of the quantitative data supported the following qualitative findings: (i), (iii) , and (iv) . Conclusions: Developers write quick-and-dirty production code to pass the tests, do not update their tests often, and ignore refactoring.

show abstract

Section: Triangulating Qualitative Results With Quantitative Datamentioning

confidence: 99%

Findings from a multi-method study on test-driven development

Romano

Fucci

Scanniello

et al. 2017

Information and Software Technology

View full text Add to dashboard Cite

show abstract

“…Several projects [11,12] infer TDD phases from low-level IDE edits. They all build on top of HackyStat [13], a framework for data collection and analysis.…”

Section: Related Work and Conclusionmentioning

confidence: 99%

TDDViz: Using Software Changes to Understand Conformance to Test Driven Development

Hilton

Nelson

McDonald

et al. 2016

Agile Processes, in Software Engineering, and Extreme Programming

View full text Add to dashboard Cite

Abstract.A bad software development process leads to wasted effort and inferior products. In order to improve a software process, it must be first understood. Our unique approach in this paper uses code and test changes to understand conformance to the Test Driven Development (TDD) process.We designed and implemented TDDViz, a tool that supports developers in better understanding how they conform to TDD. TDDViz supports this understanding by providing novel visualizations of developers' TDD process. To enable TDDViz's visualizations, we developed a novel automatic inferencer that identifies the phases that make up the TDD process solely based on code and test changes.We evaluate TDDViz using two complementary methods: a controlled experiment with 35 participants to evaluate the visualization, and a case study with 2601 TDD Sessions to evaluate the inference algorithm. The controlled experiment shows that, in comparison to existing visualizations, participants performed significantly better when using TDDViz to answer questions about code evolution. In addition, the case study shows that the inferencing algorithm in TDDViz infers TDD phases with an accuracy (F-measure) of 87%.

show abstract

“…Jenny accesses her report through a convenient link in the IDE, or through the TestRoots website 7 , entering the project's ID. Jenny's online project report summarizes her development behavior in the IDE over the whole recorded project lifetime.…”

Section: Testing Analyticsmentioning

confidence: 99%

“…When registering the project, Jenny estimated the working time she would spend on testing to equal 50%. Using the generated report, 7 http://testroots.org/report.html…”

Section: Testing Analyticsmentioning

confidence: 99%

“…WatchDog has an intermediate position, as it does both and also allows its users to make comparison among themselves. Hackystat with its Zorro extension was one of the first solutions that aimed at detecting TDD activities [7,8], similar to the education-oriented TDD-Guide [9] and the prototype TestFirstGauge [10]. In contrast to WatchDog, Hackystat did not focus on the IDE, but offered a multitude of sensors, from bug trackers like Bugzilla to build tools like ant.…”

Section: Related Toolsmentioning

confidence: 99%

See 1 more Smart Citation

How to catch 'em all

Beller

Levaja

Panichella

et al. 2016

Proceedings of the 3rd International Workshop on Software Engineering Research and Industrial Practice

View full text Add to dashboard Cite

As software engineering researchers, we are also zealous tool smiths. Building a research prototype is often a daunting task, let alone building an industry-grade family of tools supporting multiple platforms to ensure the generalizability of results. In this paper, we give advice to academic and industrial tool smiths on how to design and build an easy-to-maintain architecture capable of supporting multiple integrated development environments (IDEs). Our experiences stem from WatchDog, a multi-IDE infrastructure that assesses developer testing activities in vivo and that over 2,000 registered developers use. To these software engineering practitioners, WatchDog provides real-time and aggregated feedback in the form of individual testing reports.

show abstract

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

Cited by 27 publications

References 31 publications

Findings from a multi-method study on test-driven development

Findings from a multi-method study on test-driven development

TDDViz: Using Software Changes to Understand Conformance to Test Driven Development

How to catch 'em all

Contact Info

Product

Resources

About