Как да започнете да се учите как да пишете TDD тестове
Има мнение, че за да подобрите наистина уменията и знанията си на програмист, трябва да пишете TDD тестове.
Какво е това като цяло и какво да напиша? Моля, дайте пример за тези тестове, както са написани.
трябва да напишете TDD тестове. Не, няма такова нещо като „TDD тестове“. TDD е една от техниките за екстремно програмиране (XP). Вече ви беше дадена връзка към книга на Кент Бек по тази тема (между другото силно я препоръчвам)
Същността на тази методология е да раздели работата върху кода на три етапа, които се наричат цикъл на червено-зелено рефакторинг.
-Червено- преди да напишем код, трябва да напишем тест, който се поврежда (обикновено неработещите тестове се маркират в червено в конзолата). Според тази методология трябва да пишете код стриктно, когато имате счупени тестове. Ако няма счупени тестове, тогава няма нужда да пишете код. -Зелен- когато получите червени тестове, трябва да завършите кода възможно най-бързо. така че тестовете да са зелени. Да кажем, че ако сте написали тест, който очаква функция да върне низа "foo", тогава във вашия код не трябва да имате повече от самата функция и изхода на низа "foo". Веднага след като постигнем това, ние или преработваме, или добавяме още червени тестове, за да завършим кода по-късно. Разбира се, правенето на такива примитивни неща в такъв цикъл е излишно и Кент Бек описва концепцията за „дължина на стъпката“, тоест колко работа можем да извършим на всеки етап. Винаги трябва да свързвате здравия разум с една дума. -Рефакторинг- в предишните фази не се притеснявахме колко красив е кодът ни, доколко следвахме принципите DRY и т.н. така че това е фазата на почистване на кода. Можем да го правим на всяка итерация или можем да го правим на всеки два часа, но е важноправете го възможно най-често. На този етап премахваме дублирането както в кода на приложението, така и в тестовете. Важно е да се отбележи, че е добра идея да не преработвате кода и тестовете едновременно, защото трябва да имаме източник на истина. Ако изчистим тестовете и в същото време те започнат да се провалят, значи сме счупили нещо, докато сме броили. И обратно. И ако промените това и това между тестовете, не е ясно кой е виновен.
Обикновено TDD се практикува с модулни тестове (което е логично, тъй като те се изпълняват достатъчно бързо, така че изпълнението на тестовете да не ни кара да си правим чай), което предполага, че тестваме една единица (един клас или обект) и всички нейни зависимости трябва да бъдат заменени с фалшиви обекти (фалшиви обекти, които са необходими, за да проверим как нашият обект взаимодейства с други, за това също е писано много). Но никой не забранява използването на интеграционни / функционални тестове и в същото време практикуване на TDD (например пичове, практикуващи BDD, го правят), а Kent Back нарича този бизнес ATDD.
Всъщност TDD ни дава следните предимства: - не губите време за проектиране на система в микроскопичен мащаб, това е еволюционен подход, архитектурата на приложението непрекъснато се променя и развива заедно с изискванията. Всички изисквания са формализирани под формата на тестове. - кодът винаги е покрит с тестове (макар и не 100%, обикновено 20% са достатъчни, за да живеете, всичко зависи от живота на проекта и необходимото ниво на надеждност) - ако ви стане трудно да пишете тестове (например много зависимости, трудни за подиграване) - тогава това трябва да ви накара да мислите за грешната архитектура и да започнете по-задълбочено преработване. И ако има тестове, не е толкова страшно. - необходимостта от покриване на тестове увеличава необходимостта от придържане към всеки тип принципиТВЪРД и др. защото в противен случай започваме да пишем тестове много неефективно и отново се връщаме към факта, че нещо не е наред с архитектурата.
Недостатъците на TDD идват от положителни страни. Това е еволюционен подход, който работи добре, когато правим промени в системата на малки парчета и винаги преработваме нашия код, така че да е красив и лесен за разширяване през повечето време. Ако са ви дали наследен проект в ръцете ви и са ви казали да преработите, тогава TDD не пасва тук или не пасва добре. Но отново, такава задача се поставя доста рядко, по-често - добавяне на функционалност. И в този случай се връщаме към извършване на промени на малки порции и еволюционен подход. Просто ще отнеме доста време, но ако го сравним с „рефакторинг + добавяне на функционалност + регресионно тестване“, тогава в зависимост от ситуацията TDD може или да даде печалба, или не. Всичко зависи от сложността на системата. При прости системи това няма смисъл.
Относно обхвата. Тук има няколко гледни точки. Най-малкото TDD е за дизайн на архитектура, а не за дизайн на алгоритми. Това правим с тестовете. Но отново е доста неудобно да се разработват определени типове проекти чрез тестване на единици: компилатори, преводачи, различни решения, базирани на сложни алгоритми (например алгоритми за компресиране, криптиране и т.н.), неща, свързани с мрежово взаимодействие, например клиенти за протоколи. За тези неща функционалните тестове са по-подходящи, или те са напълно трудни за покриване с тестове.