Какво е разработка, управлявана от тестове (TDD)? Пример

Какво е разработка, управлявана от тестове (TDD)?

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

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

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

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

Как да извършите TDD тест

Следните стъпки определят как да се извърши TDD тест,

Добавяне на тест.
Изпълнете всички тестове и вижте дали някой нов тест е неуспешен.
Напишете някакъв код.
Изпълнете тестове и преработете код.
Повторете.

Извършете TDD тест — Пет стъпки на разработка, управлявана от тестове

TDD цикъл дефинира

Напишете тест
Накарайте го да работи.
Променете кода, за да го направите правилен, т.е. Refactor.
Повторете процеса.

Някои пояснения относно TDD:

TDD подходът не е нито за „тестване“, нито за „дизайн“.
TDD не означава „напишете някои от тестовете, след което изградете система, която преминава тестовете.
TDD не означава „да правите много тестове“.

TDD Vs. Традиционно тестване

По-долу е основната разлика между разработката, управлявана от тестове, и традиционното тестване:

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

При традиционното тестване успешният тест открива един или повече дефекти. Същото е като TDD. Когато тестът е неуспешен, вие сте постигнали напредък, защото знаете, че трябва да разрешите проблема.
TDD гарантира, че вашата система наистина отговаря на изискванията, определени за нея. Помага да изградите увереност във вашата система.
В TDD по-голям фокус е върху производствения код, който проверява дали тестването ще работи правилно. При традиционното тестване по-голям фокус е върху дизайна на тестови случаи. Дали тестът ще покаже правилното/неправилното изпълнение на приложението, за да изпълни изискванията.
В TDD постигате 100% тест за покритие. Всеки един ред код се тества, за разлика от традиционното тестване.
Комбинацията както от традиционното тестване, така и от TDD води до важността на тестването на системата, а не на съвършенството на системата.
In Гъвкаво моделиране (AM), трябва да „тествате с цел“. Трябва да знаете защо тествате нещо и на какво ниво трябва да бъде тествано.

Какво е TDD за приемане и TDD за разработчици

Има две нива на TDD

TDD за приемане (ATDD): С ATDD пишете един тест за приемане. Този тест изпълнява изискванията на спецификацията или удовлетворява поведението на системата. След това напишете достатъчно производствен/функционален код, за да изпълните този тест за приемане. Тестът за приемане се фокусира върху цялостното поведение на системата. ATDD също е известен като Поведенческо развитие (BDD).
Разработчик TDD: С Developer TDD вие пишете един тест за разработчици, т.е. единичен тест и след това точно достатъчно производствен код, за да изпълните този тест. Единичният тест се фокусира върху всяка малка функционалност на системата. Разработчикът TDD се нарича просто as TDD.Основната цел на ATDD и TDD е да се уточнят подробни, изпълними изисквания за вашето решение на база точно навреме (JIT). JIT означава вземане под внимание само на онези изисквания, които са необходими в системата. Така че увеличете ефективността.

Мащабиране на TDD чрез Agile Model Driven Development (AMDD)

TDD е много добър в детайлната спецификация и валидиране. Не успява да обмисли по-големи проблеми като цялостен дизайн, използване на системата или потребителски интерфейс. AMDD адресира проблемите с Agile мащабирането, които TDD не прави.

Така AMDD се използва за по-големи проблеми.

Жизненият цикъл на AMDD

При разработката, управлявана от модели (MDD), се създават обширни модели, преди да бъде написан изходният код. Кои от своя страна имат гъвкав подход?

На горната фигура всяко поле представлява дейност за разработка.

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

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

Итерация 0: Визуализация

Има две основни подактиви.

Предвидени първоначални изисквания.Може да отнеме няколко дни, за да се идентифицират изискванията на високо ниво и обхвата на системата. Основният фокус е да се проучи моделът на използване, моделът на първоначалния домейн и моделът на потребителския интерфейс (UI).
Първоначален Archiтектурно предвиждане. Освен това са необходими няколко дни за идентифициране на архитектурата на системата. Позволява задаване на технически указания за проекта. Основният фокус е да се изследват технологични диаграми, поток на потребителския интерфейс (UI), модели на домейни и случаи на промяна.

Итерационно моделиране

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

Agile процесът се използва за всяка итерация, т.е. по време на всяка итерация ще се добавя нов работен елемент с приоритет.
Първата работа с по-висок приоритет ще бъде взета под внимание. Добавените работни елементи могат да бъдат повторно приоритизирани или премахнати от стека с елементи по всяко време.
Екипът обсъжда как ще изпълни всяко изискване. За тази цел се използва моделиране.
Анализът и дизайнът на моделиране се извършват за всяко изискване, което ще се приложи за тази итерация.

Модел щурмуване

Това също е известно като Моделиране точно навреме.

Тук сесията за моделиране включва екип от 2/3 членове, които обсъждат проблеми на хартия или бяла дъска.
Един член на екипа ще помоли друг да моделира с тях. Тази сесия за моделиране ще отнеме приблизително 5 до 10 минути. Където членовете на екипа се събират, за да споделят бяла дъска/хартия.
Те изследват проблемите, докато не намерят основната причина за проблема. Точно навреме, ако един член на екипа идентифицира проблема, който иска да разреши, тогава той/тя ще потърси бърза помощ от други членове на екипа.
След това другите членове на групата проучват проблема и след това всеки продължава както преди. Нарича се още моделиране в изправено положение или сесии за QA на клиенти.

Разработка, управлявана от тестове (TDD)

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

Reviews

Това не е задължително. Включва проверки на кодове и прегледи на модели.
Това може да се направи за всяка итерация или за целия проект.
Това е добра възможност да дадете обратна връзка за проекта.

Разработка, управлявана от тестове (TDD) Vs. Разработка, управлявана от гъвкав модел (AMDD)

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

TDD рамки

Ето списъка с най-добрите рамки за разработка, управлявани от тестове (TDD).

Джунит
TestNG
csUnit и NUnit
Rspec

Сега нека научим разработката, управлявана от тестове, чрез пример.

Пример за TDD

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

Условие за приемане на паролата:

Паролата трябва да бъде между 5 и 10 знака.

Първо в този TDD пример ние пишем кода, който отговаря на всички горепосочени изисквания.

Сценарий 1: За да изпълним теста, създаваме клас PasswordValidator ();

Ще изпълним над клас TestPassword ();

Изходът е ПРЕМИНАТ, както е показано по-долу;

Продукция:

Сценарий 2: Тук можем да видим в метода TestPasswordLength () няма нужда от създаване на екземпляр на клас PasswordValidator. Инстанция означава създаване на обект на класа за препращане към членовете (променливи/методи) на този клас.

Ще премахнем класа PasswordValidator pv = new PasswordValidator () от кода. Можем да се обадим на еВалиден () метод директно от PasswordValidator. IsValid („Abc123“). (Вижте изображението по-долу)

Така че ние преработваме (променяме кода), както е показано по-долу:

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

Така че трябва да променим този метод, като добавим „статична“ дума преди Boolean като public static boolean isValid (парола за низ). Рефакторинг на Class PasswordValidator () за премахване на горната грешка, за да премине теста.

Изход:

След като направим промени в класа PassValidator (), ако стартираме теста, изходът ще бъде ПРЕМИНАТ, както е показано по-долу.

Предимства на TDD

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

Ранно известяване за грешки.

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

По-добре проектиран, по-чист и по-разширяем код.

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

Доверие за преструктуриране

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

Добър за работа в екип

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

Добър за разработчици

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

Oбобщение

TDD означава Разработка, управлявана от тестове.
Значение на TDD: Това е процес на модифициране на кода, за да премине тест, проектиран преди това.
Той акцентира повече върху производствения код, отколкото върху дизайна на тестови случаи.
Разработката, управлявана от тестове, е процес на модифициране на кода, за да премине тест, проектиран преди това.
In Софтуерно инженерство, Понякога е известен като „Първо тестване на разработката.“
TDD тестването включва рефакторинг на код, т.е. промяна/добавяне на известно количество код към съществуващия код, без да се засяга поведението на кода.
Когато се използва TDD програмиране, кодът става по-ясен и лесен за разбиране.