Бях попадал на TDD (Test Driven Development) няколко пъти преди кандидатстването ми в Andela, но никога не съм го приемал достатъчно сериозно, за да отделя време, за да науча какво представлява или как работи. Всичко, което наистина ме интересуваше тогава, беше фактът, че кодът ми работи добре. Искам да кажа защо някой трябва да се тревожи за нещо друго.

Но както щях да разбера по-късно, когато пишем код професионално или работим върху огромни кодови бази, ръчното тестване на отделни единици или модули от код може да бъде изненадващо досадна работа и понякога е много по-трудно от писането на самия код за внедряване.

Странно, аз си представях TDD като някакъв вид софтуер, който просто инсталирате на вашата система, стартирате и след това щракнете върху няколко бутона и готово, целият ви код е магически тестван и след това получавате куп сложни резултати. Чудех се и какви ще са критериите за тестовете. Дали това беше структурирането или изрядността на кода, или придържането на кода към най-добрите практики или вероятно наличието или отсъствието на синтактични грешки. Честно казано, нямах представа, но едно нещо беше сигурно в този момент, бях достатъчно любопитен.

Така че се потопих в Homestudy на Andela и започнах да чета всички статии, изброени в раздела TDD. След няколко минути получих отговора на първия си въпрос, TDD определено не беше приложение, предназначено да свърши цялата мръсна работа вместо вас за няколко секунди, но вместо това тестовете бяха самият код и беше ръчно написан и стартиран. Така че, по същество, ние основно пишем код, за да тестваме друг код.

След като прегледах една-две статии, разбрах, че TDD е просто метод за разработка, при който първо са написани единични тестове, преди да бъде написан действителният код за внедряване. Можете да пишете тестове, които използват част от код, сякаш вече са имплементирани.

Следва цикъл на червено, зелено рефакториране, с други думи, тестът се проваля в началото (всъщност те трябва да се провалят в този момент, защото тепърва ще пишете код), следващата стъпка ще бъде да напишете най-малкото количество код, необходим за преминаването на този тест, и след като премине, кодът се рефакторира.

Бях буквално изумен от начина, по който бяха изпълнени тестовете. Използвайки рамки за тестване като Jasmine или Mocha, можете да напишете модулни тестове, които извикват функции, предоставят аргументи и след това проверяват дали получените резултати всъщност са очакваните резултати. Някои библиотеки за твърдения като Chai позволяват да се правят HTTP заявки към крайни точки. С две думи, TDD служи като осезаем начин за измерване на ефективността на вашия код.

След няколко дни изучаване и практикуване на TDD, бях открил някои конкретни причини, поради които TDD е толкова важен инструмент в разработката на софтуер.

  • Това прави сътрудничеството много по-лесно и ефективно, членовете на екипа могат да правят промени в кодова база с пълната увереност, че модулните тестове ще ги информират, ако промените, които правят, се отразяват негативно на кода.
  • TDD прави кода по-лесен за поддръжка и рефакторинг. Той осигурява яснота по време на действителното внедряване на кода.
  • Помага да се изяснят и изолират изискванията на конкретна функция, защото трябва да разберете конкретно какви входове трябва да подадете в програма и какви резултати да очаквате.
  • Той също така насърчава разработчиците да пишат само най-малкото/минималното количество код, необходимо за преминаване на тестовете, следователно може да направи процеса на кодиране по-рационализиран и обективно ориентиран.
  • И тъй като пишете малки тестове наведнъж, това принуждава вашия код да бъде по-модулен и абстрактен.

В крайна сметка бях щастлив, защото бях натрупал жизненоважен опит за един от най-популярните методи за разработка на софтуер и си заслужаваше.