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

Тестването на поведение за разлика от внедряването означава, че трябва да тествам публичния интерфейс на приложението и да оставя вътрешните последици скрити от теста. Ползата от това прави тестването поддържано. Промените е по-вероятно да настъпят в действителното внедряване на кода, за разлика от поведението. Чрез отделяне на реализацията на кода от тестването, няма да се налага да пренаписвам теста си, ако реализацията се промени. Освен това тестването на действителното поведение на кода служи като жива документация за кода.

Това каза, когато се натъквам на това как мога да тествам определен аспект от моята програма. Трябва да имам предвид, че трябва да тествам за конкретно поведение. Ако моят код се придържа към принципите на SOLID, тестването трябва да е осъществимо. Ако е трудно да се тества, вероятно е кодова миризма. Важно е да имате предвид тази перспектива, но разполагането с инструментите, за да можете да го направите, е моментът, в който магията започва да се случва. Тази публикация от чичо Боб подчертава различни инструменти, които мога да използвам за тестване на поведението на моето приложение

  1. Dummies: позволява ми да тествам функция, която обаче изисква параметър; ако този параметър никога няма да бъде използван. Мога просто да предам фиктивен параметър и да го задам на всичко.
  2. Stubs: Това е полезно, когато искам да тествам функционалност на моето приложение, която може да разчита на друга функция. Ако знам, че зависимата функция вече работи, мога да предефинирам тази функция до желана от мен стойност и да я инжектирам в основната функция, която искам да тествам.
  3. Шпионин: Това ми позволява да проверя дали дадена функция е била извикана от приложението ми.
  4. Истински подигравки: Бих използвал истински подигравки, за да тествам какви функции са били извиквани, с какви аргументи, кога са били извиквани и колко често са били извиквани. Това е начин за тестване на поведението.
  5. Фалшификати: Не съм напълно сигурен какво представляват фалшификатите, но моето разбиране е, че може да се усложни и е напълно различно животно в сравнение с първите четири, които бяха въведени. Определено ще трябва да се върна към това, когато разбера по-добре фалшификатите.

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