Защо разработката на тестово управление (TDD) е най-добрият начин за устойчиво кодиране.

Първо напишете единични тестове, след което напишете кода.

Имидж кредити: Pexels.com

Преди няколко години, когато за първи път чух за „Тестово задвижвано развитие“, бях скептично настроен.

Самата идея за „първо тест за писане на единици, а след това за писане на кода“ беше мнима.

Защо не би било? Напишете първо своите тестове за единица? Кой би направил подобно глупаво нещо?

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

Затова се консултирах с мой приятел, който ми показа основен пример.

Този основен пример има клас LCL_SUM с метод SUM. Отговорността на този метод е да се добавят числата. Той приема число като параметър за импортиране и след това го добавя към себе си, за да извлече резултата. Нека наречем този метод като производствен метод.

Кодът за класа беше следният:

КЛАС lcl_sum ОПРЕДЕЛЕНИЕ.
ОБЩЕСТВЕН РАЗДЕЛ.
МЕТОДИ: ИЗНОСНО ВНОСКАНЕ iv_1 ТИП i
ВРЪЩАЩА СТОЙНОСТ (rv_sum) ТИП i.
ENDCLASS. „Lcl_sum ОПРЕДЕЛЕНИЕ
*
Начало на подбор.
* Все още нищо тук
*
*
КЛАС lcl_sum ИЗПЪЛНЕНИЕ.
МЕТОД СЪМ.
rv_sum = iv_1 * iv_1. „Умишлена грешка (умножавам вместо да добавям)
ENDMETHOD. "сума
ENDCLASS. „ИЗПЪЛНЕНИЕ lcl_sum.

Настройка на тестовия клас

Сега създайте клас, който действа като тестов клас. В SAP трябва да добавите ключовата дума FOR TESTING, когато дефинирате класа. Това допълнение отделя този клас от производствения код.

КЛАС lcl_test ОПРЕДЕЛЕНИЕ ЗА ИЗПИТВАНЕ
ОБЩЕСТВЕН РАЗДЕЛ.
МЕТОДИ: m_sum ЗА ИЗПИТВАНЕ.
ENDCLASS. „Lcl_test ОПРЕДЕЛЕНИЕ
*
КЛАС lcl_test ИЗПЪЛНЕНИЕ.
METHOD m_sum.
ENDMETHOD. "m_sum
ENDCLASS. „Lcl_test ИЗПЪЛНЕНИЕ

Въвеждане на метод за изпитване

В този метод за тестване, което трябва да направите е - да тествате производствения код. Така че, за да можете да тествате метода SUM на LCL_SUM, ще трябва да създадете позоваване на обект към LCL_SUM, извикайте метода SUM, изпращащ стойката на манекена.

Въз основа на стойността на Dummy, методът ще ви изпрати резултата - действителния резултат от метода. Въз основа на стойността на Dummy знаете каква би била очакваната стойност. Например Ако преминете номер 3 към метода SUM, това ще ви даде резултата от 6, тъй като се добавя към 3.

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

КЛАС lcl_test ИЗПЪЛНЕНИЕ.
METHOD m_sum.
ДАННИ: o_cut ТИП REF TO lcl_sum.
ДАННИ: lv_result ТИП i.
*
СЪЗДАВАНЕ НА ОБЕКТ o_cut.
lv_result = o_cut-> сума (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
act = lv_result
msg = 'нещо не е наред в изхода'
).
ENDMETHOD. "m_sum
ENDCLASS. „Lcl_test ИЗПЪЛНЕНИЕ

Резултати от тест на единица

Това ми казва, че има нещо нередно в прилагането на производствения метод.

Да, ако погледнете отблизо метода на изпълнение на SUM, аз имам печатна грешка - вместо да използвам сумирането, използвах умножение. Така че, аз бих го коригирал и отново пуснах теста, за да го изпълня успешно.

Бях закачен за TDD. Flabbergasted би била точната дума.

Удивителното беше силно намаленото време за цикъл на разработка и тестване.

Бях свикнал да пиша код през по-голямата част от час, преди да се опитам да го компилирам или стартирам. Но тук кодът се изпълняваше и тестваше на всеки 2 минути.

Така накратко, TDD се реализира чрез кратки цикли на развитие, които следват правилото „първо напишете тестовете на единици, след това напишете кода, след това рефактор, след това повторете.“ Тестовете на единици са автоматизирани тестове, които проверяват дали функциите работят както се очаква. Вашият първи тест за единица трябва да се провали, тъй като е написан преди дори да имате кодова база.

Добавяте малко към кода на тестовия случай. Добавяте малко към производствения код. Двата кодови потока нарастват едновременно в допълнителни компоненти. Тестовете отговарят на производствения код, като антитяло пасва на антиген.

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

И целият този интегриран подход предлага пълна полза за разработчика.

Поправяте лош код, без да нарушавате нищо.

Всеки път, когато видите лош код, търкаляте очи, молете се на Бог и изричате едно от двете твърдения.

· „Това е каша. Предполагам, че трябва някак да го поправя ”.

· „Не го пипам.“

И в двата случая има елемент на страх. Всъщност несигурността.

Какво става, ако кодът ми наруши съществуващата функционалност?

TDD ви помага точно да преодолеете тази несигурност.

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

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

TDD насилства документацията.

Дик Брандън го удари с нок, когато го забеляза.

„Документацията е като секса; когато е добро, много е много, а когато е лошо, е по-добре от нищо. "

Документацията е рициново масло на програмирането. Мениджърите смятат, че е добре програмистите, а програмистите го мразят!

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

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

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

TDD помага за по-добър дизайн

Основната предпоставка в TDD е, че трябва да напишете своите тестови случаи, преди да напишете кода.

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

Това създава по-добър, отделен дизайн, при който имате по-добър контрол върху нещата, докато кодът се развива.

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

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

А самият факт на писане на тестови случаи предварително предотвратява появата на грешки, които могат да изскочат по-късно, като по този начин спестяват време, усилия и киселини.

И накрая, TDD следва най-добрите практики за кодиране.

TDD насърчава добрите принципи на кодиране, включително DRY, KISS, YAGNI и SOLID.

Принципът DRY (Don’t Repeat Yourself) казва на разработчиците да избягват да повтарят един и същ код в различни части на една и съща система, поради което понякога се наричат ​​DIE принцип (дублирането е зло). DRY препоръчва на разработчиците да използват класове и функции, за да капсулират функционалността на системата и да поддържат последователна кодова база.

Принципът на KISS (Keep it Simple, Stupid!) Съветва разработчиците да не преоткриват колелото, а да изграждат прости и ясни архитектури. Същността на KISS е да избягва прекомерно разработени решения.

Принципът YAGNI (You Ainth Gonna Need) се бори срещу позлатяването. Покриването със злато може да изглежда безобидно, особено ако разработчикът има желание да подобри съществуващата функционалност, за да зарадва клиента. Това обаче води до допълнително време за разработка, което може да причини забавяне на проекта или недоволен клиент. YAGNI пояснява: разработчикът трябва да изпълнява само зададени задачи и да избягва добавянето на прекомерна функционалност.

SOLID се състои от пет принципа в едно: единична отговорност, отворено затворено, заместване на Лисков, сегрегация на интерфейса и инверсия на зависимост. Накратко, SOLID заявява, че следването на тези принципи прави приложенията по-лесни за поддръжка и тестване.

С две думи, TDD помага за създаването на елегантен и прост код, който се поддържа лесно.

Както умело каза Робърт Мартин.

„Чистият код винаги изглежда, че е написан от някой, който се интересува.“

Препратки

Екстремно програмиране: Кент Бек.

Agile Софтуерна разработка: Робърт Мартин

Рефакторинг: Мартин Фаулър

За автора-:

Ravi Rajan е глобален мениджър на информационни програми, базиран в Мумбай, Индия. Освен това е запален блогър, писател на поезия Хайку, ентусиаст по археология и маниак по история. Свържете се с Рави в LinkedIn, Medium и Twitter.

Тази история е публикувана в най-голямото предприемаческо издание The Startup, последвано от +438 678 души.

Абонирайте се, за да получавате нашите топ истории тук.