Abstract
We analyze Test Driven Development (TDD) from cognitive and social perspectives. Based on our analysis, we suggest a technique for controlling and monitoring the TDD process by examining measures that relate to the size and complexity of both code and tests. We call this approach Measured TDD. The motivation for TDD arose from practitioners’ tendency to rush into code production, skipping the required testing needed to manufacture quality products. The motivation for Measured TDD is based on difficulties encountered by practitioners in applying TDD. Specifically, with the need to frequently refactor the unit, after every few test and code steps have been performed. We found that the suggested technique enables developers to gain better control over the development process.
Highlights
Test Driven Development (TDD), an agile software development practice, aims to systematically overcome some of the characteristic problems of software development processes [1, 2, 3]
We introduce a technique, named Measured TDD, that is based on size and complexity measures and that continuously monitors the TDD process
In this paper we present a technique for function development that uses size and complexity measures for monitoring and controlling the TDD process
Summary
Test Driven Development (TDD), an agile software development practice, aims to systematically overcome some of the characteristic problems of software development processes [1, 2, 3]. We analyze this phenomenon from a human perspective and argue that TDD can only partially solve the problems associated with traditional testing since additional conditions are needed in order to exhaust its benefits. In the subsequent sub-section, based on two data sets, we conclude that TDD processes should be more closely controlled in order to better exhaust their potential This conclusion constitutes the motivation for the Measured TDD technique. The following reflection of a practitioner, Ron Jeffries, explains how TDD supports the testing from the cognitive perspective (http://c2.com/cgi/wiki?RonJeffries): "A key aspect of this process: don't try to implement two things at a time, don't try to fix two things at a time. Being a detail-oriented and explicit process, TDD improves one's understanding of what should be developed since the test must be written prior to the writing of the code. These data sets, as well as other data, motivated us to further
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
