TDD — разработка через тестирование

TDD, test-driven development или раз­ра­ботка через тести­ро­ва­ние — это мето­до­ло­гия раз­ра­ботки ПО, кото­рая осно­вы­ва­ется на повто­ре­нии корот­ких цик­лов раз­ра­ботки: изна­чально пишется тест, покры­ва­ю­щий жела­е­мое изме­не­ние, затем пишется про­грамм­ный код, кото­рый реа­ли­зует жела­е­мое пове­де­ние системы и поз­во­лит пройти напи­сан­ный тест, а затем про­во­дится рефак­то­ринг напи­сан­ного кода с посто­ян­ной про­вер­кой про­хож­де­ния тестов.

Тести­ро­ва­ние ПО — это про­це­ду­ра, кото­рая поз­во­ляет под­твер­дить или опро­верг­нуть рабо­то­спо­соб­ность кода и кор­рект­ность его работы. ТПри тести­ро­ва­нии при­ло­же­нию пере­да­ются вход­ные дан­ные и запра­ши­ва­ется выпол­не­ние некой коман­ды, после чего про­из­во­дится про­верка полу­чен­ных резуль­та­тов на соот­вет­ствие эта­ло­ну, если резуль­тат соот­вет­ствует ожи­да­е­мому — тест счи­та­ется прой­ден­ным. Эта про­це­дура может быть авто­ма­ти­зи­ро­ва­на, в этом слу­чае про­верка рабо­то­спо­соб­но­сти и пра­виль­но­сти работы при­ло­же­ния осу­ществ­ля­ется гораздо быст­рее, пол­но­цен­нее и чаще (в срав­не­нии с руч­ным тести­ро­ва­нием).

Мето­дика раз­ра­ботки через тести­ро­ва­ние заклю­ча­ется в орга­ни­за­ции авто­ма­ти­че­ского тести­ро­ва­ния раз­ра­ба­ты­ва­е­мых при­ло­же­ний путем напи­са­ния модуль­ных, инте­гра­ци­он­ных и функ­ци­о­наль­ных тестов, опре­де­ля­ю­щих тре­бо­ва­ния к коду непо­сред­ственно перед напи­са­нием этого самого кода. Сна­чала пишется тест, кото­рый про­ве­ряет кор­рект­ность работы еще нена­пи­сан­ного про­грамм­ного кода. Этот тест, разу­ме­ет­ся, не про­хо­дит. После этого раз­ра­бот­чик пишет код, кото­рый выпол­няет дей­ствия, тре­бу­е­мые для про­хож­де­ния теста. После того, как тест успешно прой­ден, по необ­хо­ди­мо­сти осу­ществ­ля­ется рефак­то­ринг (дора­ботка и пере­ра­ботка) напи­сан­ного кода, при­чём рефак­то­ринг осу­ществ­ля­ется под кон­тро­лем про­хож­де­ния тестов.

Эта мето­до­ло­гия поз­во­ляет добиться создания при­год­ного для авто­ма­ти­че­ского тести­ро­ва­ния при­ло­же­ния и очень хоро­шего покры­тия кода теста­ми, так как ТЗ пере­во­дится на язык авто­ма­ти­че­ских тестов, то есть всё, что про­грамма должна делать, про­ве­ряется. Также TDD часто упро­щает про­грамм­ную реа­ли­за­цию: исклю­ча­ется избы­точ­ность реа­ли­за­ции — если ком­по­нент про­хо­дит тест, то он счи­та­ется готовым.

Архи­тек­тура про­грамм­ных про­дук­тов, раз­ра­ба­ты­ва­е­мых таким обра­зом, обычно лучше (в при­ло­же­ниях, кото­рые при­годны для авто­ма­ти­че­ского тести­ро­ва­ния, обычно очень хорошо рас­пре­де­ля­ется ответ­ствен­ность между ком­по­нентами, а выпол­ня­е­мые слож­ные про­це­дуры деком­по­зи­ро­ваны на мно­же­ство про­стых). Ста­биль­ность работы при­ло­же­ния, раз­ра­бо­тан­ного через тести­ро­ва­ние, выше за счёт того, что все основ­ные функ­ци­о­наль­ные воз­мож­носи про­граммы покрыты тестами и их рабо­то­спо­соб­ность посто­янно про­ве­ряется. Сопро­вож­да­е­мость про­ек­тов, где тести­ру­ется всё или прак­ти­че­ски всё, очень высока — раз­ра­бот­чики могут не бояться вно­сить изме­не­ния в код, если что-то пой­дёт не так, то об этом сооб­щат резуль­таты авто­ма­ти­че­ского тести­ро­ва­ния.