On the effectiveness of the test-first approach to programming

Abstract

/npsi/ctrl?action=rtdoc&an=5763742&lang=en http://nparc.cisti-icist.nrc-cnrc.gc.ca/npsi/ctrl?action=rtdoc&an=5763742&lang=frAccess and use of this website and the material on it are subject to the Terms and Conditions set forth at

The impact of Test-First programming on branch coverage and mutation score indicator of unit tests: An experiment

“…Therefore, more experienced and skilful students or professionals could potentially achieve more substantial improvements. It is consistent with the conclusions by Erdogmus et al [17]. Consequently, the positive effects of TF can be masked, to some extent, by the relative difficulty of the technique.…”

“…Some empirical findings [17,18,21,22,35] show that the answer to that question might be positive. The others [7-10, 19, 36-38] lead to the opposite conclusion.…”

“…Test-First (TF) Programming [1], also known as Test-Driven Development (TDD) [2] 1 , is a novel software development practice that has gained recent attention in professional settings [1,[3][4][5][6][7][8][9][10][11] and has made initial inroads into software engineering education [12][13][14][15][16][17][18][19][20][21][22]. However, bringing all members of development teams to accept a test-first work culture may be a tough task.…”

A multiple comparative study of test-with development product changes and their effects on team speed and product quality

“…Sometimes, they evolve their automated product tests and make their product changes at the same time, interleaving them, in support of a particular fine-grained feature. Alternatively, they might make their product changes first and then evolve their automated product tests, also in support of a particular fine-grained feature-some of those performing related studies have differentiated this approach from TFD by referring to it as "iterative test-last" (George and Williams, 2003;Pancur et al, 2003;Erdogmus et al, 2005;Janzen and Saiedian, 2006;Sanchez et al, 2007). So, developers sometimes vary when they change the product and when they change the automated product tests, even if they are making fine-grained changes for a particular feature.…”

“…We refer the reader to the relevant publications for more specific details on these studies. Williams et al (2003) Case Study -Higher Geras et al (2004) Controlled No difference - Abrahamsson et al (2005) Case Study No difference - Bhat and Nagappan (2006) Case Study Slower Higher Canfora et al (2006) Controlled Slower - Damm and Lundberg (2006) Case Study -Higher Sanchez et al (2007) Case Study -Higher Siniaalto and Abrahamsson (2007) Case Study -Higher Nagappan et al (2008) Case Study Slower Higher Muller and Hagner (2002) total time reliability George and Williams (2003) productivity (time) acceptance tests Maximilien and Williams (2003) LOC per month defect rate Pancur et al (2003) code coverage, tests passed Williams et al (2003) defect density Geras et al (2004) total effort unplanned failures Abrahamsson et al (2005) LOC, effort, productivity - Erdogmus et al (2005) productivity (# of tests) acceptance test conformance Madeyski (2005) acceptance tests passed Bhat and Nagappan (2006) time estimates defect density Canfora et al (2006) time to complete - Damm and Lundberg (2006) fault rate Janzen and Saiedian (2006) total effort internal metrics Gupta and Jalote (2007) effort, productivity acceptance tests passed Sanchez et al (2007) defect density, complexity Siniaalto and Abrahamsson (2007) program design, code coverage Nagappan et al (2008) time estimates defect density (2002) 2 months George and Williams (2003) 1 day (or less) Maximilien and Williams (2003) 7 months Pancur et al (2003) 5 months Williams et al (2003) 7 months Geras et al (2004) 1 day (or less) Abrahamsson et al (2005) 9 weeks Erdogmus et al (2005)…”