Преместих работната си станция от офиса в резиденцията си в четвъртък и сега винаги съм пред екраните си. И четиримата. Първото нещо, което направих, беше да прегледам знанията си за разработка, управлявана от тестове (TDD), да разбера нейните основи и мотиви и най-важното как мога да я използвам в изграждането на софтуер.
Ще опиша част от моите бележки тук и ще споделя връзка към приложението, което създадох, прилагайки TDD.
Да започваме, става ли?
Разработката, управлявана от тестове (TDD) е гъвкава методология за софтуерно инженерство, която набляга на използването на кратки и чести цикли на разработка. Изискванията се превръщат в изключително подробни тестови случаи. Производственият код впоследствие се внедрява за подобряване и преминаване на тестовете.
Единично тестване
Писането на модулни тестове е част от разработката, управлявана от тестове. Единичните тестове изследват най-малките компоненти на по-голяма система. Тези тестове се намират в най-долната част на тестовата йерархия. Те се създават и прилагат възможно най-рано и се изпълняват повторно толкова често, колкото е необходимо.
Червено, зелено, рефактор
Когато става дума за разработка, управлявана от тестове, често се използва терминът „червено, зелено, рефактор“. Моделът на Agile инженерство е червен, зелен, рефактор, което изисква кратка итерация на разработката или цикъл, за да се намалят широките предположения за това как вашият код трябва да функционира спрямо това как работи сега.
ЧЕРВЕНО: Това е първата стъпка в процеса на разработка, дори преди да е написан какъвто и да е код. Създавате тест, който се проваля. Ако нямам код, защо ще пиша тест? Като разработчик това ви насърчава да се съсредоточите върху проблема, който се опитвате да разрешите, а не върху кода. Освен това помага за разделянето на проблема на малки части.
ЗЕЛЕНО: След като сте създали неуспешен тест, втората стъпка е да го оцветите в зелено. Тоест, накарайте неуспешния тест да премине. Трябва да напишете абсолютния минимум код, за да премине този тест. Това води до по-малка кодова база, което означава по-малко код за поддържане през целия живот на приложението.
РЕФАКТОР: Спомняте ли си онзи грозен код, който написахте, за да преминете теста? Това е мястото, където можете да го почистите. Рефакторингът е техника за преструктуриране на код чрез модифициране на неговата вътрешна функционалност, без да се променя външното му поведение. Чувствайте се свободни да преименувате променливи, да извличате логика към функции или дори да въвеждате софтуерен модел, докато кодът узрява. Не забравяйте да изпълните тестовете си, за да се уверите, че случайно не сте нарушили функционалността, докато преработвате до най-красноречивия код.
Тъй като разработчикът прилага своите изисквания, работният процес на разработка, управляван от тестове, обикновено се извършва локално на тяхната работна станция. След като приключат с внедряването на функция, те ще я изпратят в системата за контрол на източника, която ще започне работа за изграждане на CICD. Задачата за изграждане трябва да стартира отново целия тестов пакет, за да гарантира целостта на всички тествани компоненти, включително всички отделни класове и т.н. Това трябва да се случи преди всяка допълнителна интеграция или тестване от край до край.
Използвайки обновените си познания за TDD, създадох библиотека на Java, която преобразува цената на биткойн в ценови еквиваленти в USD, GBP и евро. Можете да намерите изходния код в моя Github, като щракнете върху връзката по-долу.
Препратки
Големи благодарности на Джереми Кук от Cloud Academy за предоставянето на изчерпателен и практичен курс за разработка, управлявана от тестове. Можете да намерите връзка към курса по-долу.
