ДЕН 3! Научих много неща, които изглеждаха странни в началото, но нищо не се доближава до Test Driven Development (TDD). TDD е процес на разработка на софтуер, който разчита на повторението на много кратък цикъл на разработка: изискванията се превръщат в много специфични тестови случаи, след което софтуерът се подобрява, за да премине само новите тестове. Нормалното тестване на единици основно означава, че пишете някакъв код, за да тествате кода за приложението, което изграждате, но TDD отива крачка напред. TDD има същите елементи, но обръща процеса. Всъщност първо трябва да напишете тестовете, преди да напишете своя код. Странно е, знам! На мен ми се стори като ходене назад.
Идеята за TDD изглежда луда за много хора в началото, включително и за мен, но ако се успокоите, поемете дълбоко въздух, ще започнете да разбирате многото предимства. И така, как е възможно да тествате код, който не съществува? тестът няма ли да се провали? Да, възможно е и да, ще се провали и това всъщност следва идеята на TDD. Първият път, когато стартирате теста си, той трябва да се провали или може дори да не се компилира в зависимост от използвания език и ние искаме това да се случи. Това е основната разлика между TDD и вашето средно тестване на единица. Така че отново първо пишем неуспешен тест и след това пишем код, който преминава само теста и не прави нищо повече.
Много хора може би се чудят защо това е добро? какво е предимството? Вземете, например, пишем код или проектираме приложение, прекарваме толкова много време в мислене за всички възможни „пропуски“, които нашият код, клас, функция не удовлетворяват. Може дори никога да не покрием всички пропуски, които нашият код има. Разработката, управлявана от тестове, разрешава този проблем, тъй като ние удовлетворяваме всяко едно изискване, преди да преминем към следващото. Тестовете движат нашето развитие. Много разработчици на софтуер всъщност не са съгласни с TDD, смятат, че добавя сложност, тъй като някои тестови случаи са по-трудни за изчисляване. Някои разработчици казват, че някои дизайни, които искате да направите, се развиват, докато вървите напред и това ви принуждава да продължите да повтаряте тестовете си. Всичко това са валидни точки, но смятам, че предимствата на TDD са твърде големи, за да бъдат игнорирани. Някои твърдят, че TDD може да се използва само за малки проекти, а не за реални приложения и това просто не е вярно. Кент Бек, автор на книга, озаглавена„Разработка, управлявана от тестове: чрез пример“ твърди, че е използвал напълно подход за тестово шофиране върху проект, който отне 4 години и имаше около 250 000 реда функционален код и 250 000 реда тестов код.
Сега, като отворен софтуерен разработчик с мислене за растеж :), мога смело да кажа, че започнах да използвам процеса TDD и не е лош. Все още не съм го използвал за нещо твърде сложно, но вече ми харесва. За мен най-голямото предимство е спестеното време. След като вашите тестове преминат, продължавате напред и не е нужно да продължавате да размишлявате върху грешките, които вашият код може да има. Определено отне известно време, за да свикна, но свиквам. Също така е полезно да знаете, че TDD не замества традиционното тестване, а вместо това дефинира доказан начин за осигуряване на ефективно тестване на единици. Ще кажа, че всеки разработчик трябва да разгледа TDD, не затваряйте ума си от него напълно. Бъдете отворени към учене и отказване от учене.
