Ние започнете да пишете тестове (вдясно) - Блог

Как да започнем? Колко време трябва да пишат тестове? Какво трябва да пишат тестове? Какво не трябва да пишат тестовете? Трябва ли винаги да прилага TDD?

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

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

Основната цел на тази статия - за да ви даде цялостно разбиране на смисъла на теста. Разбиране на същността, вие ще бъдете по-способни да мислят критично и да се разбере къде да отида. И, разбира се, ще бъде малко по-практични съвети.

Да започнем с най-важния въпрос: защо ние трябва да се тества?

За да бъдат сигурни в изпълнението на нашия продукт. Забележете, че не съм написал "функции", "модул", "код" или "проект". В крайна сметка, единствено има значение, че крайният продукт, който се използва (не непременно потребители), работи и го прави добре. Въпреки, че в момента тя може да изглежда като капитанската лента, но както ще видим по-късно, ориентацията на целта ще ни позволи да вземат правилни решения.

Следваща ключова теза не е функция на процеса на тестване. Задачите могат да се разделят на два вида: те или са завършени или не, както и завършване на задачата на втория вид - това е скалата, където 0 - е "нищо не е направено", и 1 - тя е направена от 100%. И в справянето с тези проблеми, 100% разтвор често е недостижим, защото на ултра-високо над главата.

Тук е идеален пример. В продължение на много услуги, такова нещо като критична SLA или по-просто, наличието на услугата. Например, на хостинг сайтове пишат нещо в духа на "ние предоставяме достъп до 99.9% от нашите сървъри." Нека да брои до колко часа годишно хостинг могат да бъдат на разположение като част от своята SLA: 0,001 * 365 * 24 = 8,7. По принцип е добра идея.

Да приемем, че предоставянето на такова ниво на наличност струва на компанията $ 1000. И колко ще струва да се добавят всеки нови деветки в края? Това означава, че предоставянето на 99.99. 99 999 и така нататък. Доколкото ми е известно, на това ниво осигуряват експоненциална (експлозив) нарастване на разходите. Аз не говоря за това, че 100% наличност е фантастично.

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

Сега обратно към нашия тест и ние откриваме, че тестовете са от този тип проблеми. Добавянето на първия тест в проекта, дава невероятен ефект. Покриване на 50% (половината от кода се извиква в теста) може да се получи почти веднага, а в сравнение с никой тест - ние две жилища отпред. Тогава ситуацията започва да се променя, и някъде на нивото на 70-90% започва рязко забавяне в растежа на покритието, тестове стават все по точка, скъпа. Увеличава сложността на тяхната подкрепа, рефакториране.

Този процес е безкраен. За да се постигне 100% покритие е много скъпо и, най-вече, ненужно (вж. По-горе пример). Освен това не тестовете не ви дават пълна гаранция за изпълнение.

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

• звено тестване
• интеграционно тестване
• тестване на системата (приемане)

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

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

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

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

Основната ми наблюдава анти-модел в развитието на тези библиотеки - тя проверява за вътрешни малки компоненти. Същите тези тестове единица. Защо този подход не е продуктивен? Може би това не е очевидно, но такова изследване, обаче, и е модулна, но това не е евтино и добро качество. Но как ...?

Ние вече заяви, че архитектурата на проекта все още не е известна, и, като правило, вътрешното разделение в файлове / модули / класове / функции, се променя с космическа скорост. В рамките на един час, всички по няколко пъти може да бъде пренаписана. Но сега с кода трябва постоянно да редактирате тестове, че става досадно. Програмистът започва да се съмнява, че те са всичко, което той се нуждае, а не рядко просто ги спира да пише. Други продължават да страдат и да ги пренапише, въпреки че често има повече. Писмени тестове започват да закрепите, и мозъкът изпраща команда "Ти прекарва известно време, оставете всичко както си е." Постепенно Преструктуриране на все по-трудно и по-мързелив. Това е много подобно на ситуацията, когато бизнесменът е инвестирала пари в нова посока, дори ако бизнесът вече потъва, а след това, че ще бъде трудно да се откаже, защото е прекарал толкова много усилия и пари (в икономиката се нарича загубите, -. Ед ..).

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

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

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

Описаната техника работи особено добре, във връзка с подхода, когато тестовете са написани преди кода (с кода).

Съществува мит, че само най-необходимите за регресията тестовете, това е да се уверите, че новият кодекс не се е разпаднала възраст. Далеч от нея. Освен това, тя е следствие от тестове за писане като такива. В някои ситуации, основната цел на тестове за писане - ускорява разработването. Да, ти чу добре, пишат тестове преди код / ​​код в същото време, това води до сериозно ускоряване на развитието. Повечето от тези ситуации, които са включват въвеждане на сложни данни, които по някакъв начин се трансформират и prokidyval допълнително. Тествайте ръцете (по време на разработка), този код е много трудно, трябва да се подготвят данните, трябва да се провери, че резултатът е, както се очаква.

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

Второто основно предимство на TDD е, че дизайнът на кода, ние започваме да не мисля за това как готино е сега nasozdaem файлове и да ги на разстояние функция чрез създаване на десетки абстракции и да започне да се мисли за наистина важните неща. За какво ще се използва моята библиотека. Изненадващо, започнете да търсите под ъгъл (както се преподава на всички стартиращи фирми, разработване на клиентите във всички области) не е лесно, ние винаги искаме да се потопите в чудния свят на архитектурата.

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