Content deleted Content added
m Reverted edits by Cp nandani (talk) to last version by WikiCleanerBot |
Added URL to one of the references |
||
Line 288:
Because no more code is written than necessary to pass a failing test case, automated tests tend to cover every code path. For example, for a TDD developer to add an <code>else</code> branch to an existing <code>if</code> statement, the developer would first have to write a failing test case that motivates the branch. As a result, the automated tests resulting from TDD tend to be very thorough: they detect any unexpected changes in the code's behaviour. This detects problems that can arise where a change later in the development cycle unexpectedly alters other functionality.
Madeyski<ref name="Madeyski">Madeyski, L. "Test-Driven Development - An Empirical Evaluation of Agile Practice", Springer, 2010, {{ISBN|978-3-642-04287-4}}, pp. 1-245. DOI: 978-3-642-04288-1</ref> provided empirical evidence (via a series of laboratory experiments with over 200 developers) regarding the superiority of the TDD practice over the traditional Test-Last approach or testing for correctness approach, with respect to the lower coupling between objects (CBO). The mean effect size represents a medium (but close to large) effect on the basis of meta-analysis of the performed experiments which is a substantial finding. It suggests a better modularization (i.e., a more modular design), easier reuse and testing of the developed software products due to the TDD programming practice.<ref name="Madeyski" /> Madeyski also measured the effect of the TDD practice on unit tests using branch coverage (BC) and mutation score indicator (MSI),<ref>[http://madeyski.e-informatyka.pl/download/Madeyski10c.pdf The impact of Test-First programming on branch coverage and mutation score indicator of unit tests: An experiment. ] by L. Madeyski ''Information & Software Technology 52(2): 169-184 (2010)''</ref><ref>[http://madeyski.e-informatyka.pl/download/Madeyski07.pdf On the Effects of Pair Programming on Thoroughness and Fault-Finding Effectiveness of Unit Tests] by L. Madeyski ''PROFES 2007: 207-221''</ref><ref>[http://madeyski.e-informatyka.pl/download/Madeyski08.pdf Impact of pair programming on thoroughness and fault detection effectiveness of unit test suites.] by L. Madeyski ''Software Process: Improvement and Practice 13(3): 281-295 (2008)''</ref> which are indicators of the thoroughness and the fault detection effectiveness of unit tests, respectively. The effect size of TDD on branch coverage was medium in size and therefore is considered substantive effect.<ref name="Madeyski" /> These findings have been subsequently confirmed by further, smaller experimental evaluations of TDD.<ref name="Pančur">M. Pančur and M. Ciglarič, "Impact of test-driven development on productivity, code and tests: A controlled experiment", Information and Software Technology, 2011, vol. 53, no. 6, pp. 557–573, DOI: 10.1016/j.infsof.2011.02.002</ref><ref name="Fucci">D. Fucci, H. Erdogmus, B. Turhan, M. Oivo, and N. Juristo, "A dissection of the test-driven development process: does it really matter to test-first or to test-last?", IEEE Transactions on Software Engineering, 2017, vol. 43, no. 7, pp. 597–614, DOI: 10.1109/TSE.2016.2616877</ref><ref name="Tosun">A. Tosun, O. Dieste Tubio, D. Fucci, S. Vegas, B. Turhan, H. Erdogmus, A. Santos, M. Oivo, K. Toro, J. Jarvinen, and N. Juristo, "An industry experiment on the effects of test-driven development on external quality and productivity", Empirical Software Engineering, 2016, vol. 22, pp. 1–43, DOI: 10.1007/s10664-016-9490-0</ref><ref name="Papis">B. Papis, K. Grochowski, K. Subzda and K. Sijko, [https://ieeexplore.ieee.org/document/9207972 "Experimental evaluation of test-driven development with interns working on a real industrial project"], IEEE Transactions on Software Engineering, 2020, DOI: 10.1109/TSE.2020.3027522</ref>
=== Psychological benefits to programmer ===
| |||