Напомнете им, че всичко това е вашата «Test-Drive-развитие»?
Тя е такава техника за разработка на софтуер, в който всичко развитие се разделя на множество по-малки цикли: първо писмени тестове, които обхващат желаната промяна, и след това да напишете кода, който минава тези тестове. Това е последвано от преработка на код, нови тестове са написани, ако е необходимо. Ако някой тест част от кода не го давате право.
Това звучи като странен начин. И това е точно ефективност?
Очевидно е, да. На първо място, тя позволява да се разбере по-ясно какво точно трябва да се напише. Там е състояние, което трябва да се извърши след работещ код - и най-важното. Тестове самите трябва да се формира въз основа на задание. Ако в резултат на тест писане те започват да си противоречат - това е повод да се направи преглед на техническото задание.
На второ място, в резултат на разпределение на задачите в най-малко обемисти подзадачи, кодът става много по-прости и по-разбираемо. В идеалния случай, трябва да се тества твърдение (поддържали). В допълнение, на бедните в кода за дизайн (например, с помощта на глобални променливи и singletons) обикновено е също толкова трудно да се тества, което стимулира разработчиците й не е писал.
Но ми се струва, че да пиша, както обикновено много по-бързо
Да, наистина, за първото използване на TDD ще отнеме повече време. Въпреки това, той е по-скоро въпрос на навик - с времето свикваш да пише първите тестове, и едва след това кода и може би дори ще спечели във времето, тъй като процеса на развитие е ясно структурирана, трябва първо да реши въпроса: "Какво да пиша?" И едва тогава "Как се пише?". Също така, че отделихте време, сега, вие ще спечелите време в бъдеще, което значително ще улесни подкрепата на продукта.
Тя винаги има смисъл да се използва TDD?
Разбира се, не. TDD не е панацея. Например, ако развитието е поредица от експерименти, когато няма ясна сигурност, че това е необходимо, в резултат на тест писане ще бъде по-товар, който дърпа назад отбора.
Откъде да започнете?
Свързани статии