Какво е разработено чрез тест (TDD)? Урок с пример

Разработване с тест

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

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

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

Тест-управляемото развитие е процес на разработване и стартиране на автоматизиран тест преди реалното развитие на приложението. Следователно TDD понякога се нарича още Test First Development.

В този урок ще научите повече за-

Как се извършва TDD тест
TDD Vs. Традиционно тестване
Какво е TDD за приемане и TDD за разработчици
Мащабиране на TDD чрез Agile Model Driven Development (AMDD)
Тест задвижване разработка (TDD) Vs. Agile Model Driven Development (AMDD)
Пример за TDD
Предимства на TDD

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

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

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

TDD цикъл определя

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

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

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

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

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

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

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

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

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

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

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

По този начин AMDD се използва за по-големи проблеми.

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

В Model-driven Development (MDD) се създават обширни модели преди изписването на изходния код. Кои от своя страна имат подвижен подход?

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

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

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

Итерация 0: Предвиждане

Има две основни суб-активира.

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

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

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

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

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

Тестово задвижване (TDD).

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

Отзиви.

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

Тест задвижване разработка (TDD) Vs. Agile Model Driven Development (AMDD)

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

Пример за TDD

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

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

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

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

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

Ще работим над клас TestPassword ();

Изходът се преминава, както е показано по-долу;

Изход :

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

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

Така че ние рефакторираме (променим кода) както по-долу:

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

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

Изход:

След извършване на промени в клас PassValidator (), ако изпълним теста, изходът ще бъде ПРЕХОДЕН, както е показано по-долу.

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

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

Резюме:

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

Тази статия е предоставена от Kanchan Kulkarni