Как да започнете да пишете тестове за 10-те стъпки на 10 минути
Нека позная: Вие се съгласявате, че тестовете за писане - това е добре. Това увеличава надеждността на системата, ускорява развитието, с проект добро покритие тест за подпомагане лесно и приятно, и TDD - всичко е въпрос на процеса идеалното развитие. Но имате ли в проекта. Това означава, че това е готино, но за съжаление сега толкова много работа - запушване. Куп само задачи критични бъгове - на две дузини плюс спешно се нуждае, за да завършите този модул, а дори и напиши писмо до клиента ... така че тестовете вероятно ще бъдат завинтени в края, ако остане време. Или в следващия проект. Не, добре, просто няма да има по-лесен. Най-вероятно.
Как да разберете ситуацията?
1. Изберете рамка за тестване
2. Писане Здравей, свят!
Напиши Здравей, свят! ни парче от тортата. Например, в C ++.
А сега направи две неща.
На първо място, извършване поколение изход текст на отделни функции. Да, два. Това е да се гарантира, че те след това могат да бъдат тествани.
Здравей, свят! след рефакториране
На второ място, ние ще подават писмена функция някъде във файла. В зависимост от подхода и езикът се използва може да бъде лесно отделни файлове с код библиотека. Това е да се гарантира, че тези функции са тогава наречен от тестовете.
Ние ще бъдем, както следва:
3. Свържете рамка за Здравей, свят!
4. Проект с възможностите на рамката
Първо трябва да разберете:
- Как се пише единица тест
- Как да тече единица тестове
Тези въпроси обикновено се отговаря на всички от същия член, аз говорих за по-горе. Не отивай направо в дивите земи на рамката. Започнете с прости тестове, които проверяват на простите неща. Това ще бъде като в спорта - не просто разкъсване много на тегло, трябва първо да постави правилната техника.
Ето, например, няколко тестове за нашия Здравей, свят! на посочения по-горе тест Google:
5. Свързване на проекта за рамката
Вече знаем как да се свържете рамките на проекта. Не забравяйте да направите №3 стъпка? Всичко се оказа. Сега нека да го направим за борбата на проекта. Сложете всички необходими файлове в рамките момента SVNGitTFSchego-на-ти-там. Направете тест проект. Свържете се с него рамка. Обърнете събрание на проекта за тест в процес на сглобяване на продукта. Проверете монтажа в отстраняване на грешки и освобождаване конфигурации. Komitnite тест стартиране на проекта монтаж върху натрупването сървъра. Всичко ще бъде наред. Не претоварвайте колегите си, докато появата на проекта за тест - на първо място, не е нарушил нищо, и второ, да се покаже и на теб, няма нищо.
6. Тестване за нещо по-просто
Между другото, това е на този етап много често идва на скептиците за осветление. Изведнъж се оказва, че най-прост тест на най-основните функции - изведнъж се срина. Ние се изкачи в кода - и изведнъж се намери нещо подобно
И се оказва, че в основния код просто призовава тази функция, докато такива аргументи, че всичко е ОК, но във всеки един момент това може да се промени.
7. Тестване нещо по-сложно
8. Писане на теста за бъг
Както обикновено, прави работата си бъг ли е? Можете да го вземе от bugtracker, когато се опитвате да играят, ако не можете да - се върнете тестера, ако се окаже, че отстранявате грешки за разбирането на неговото местоположение, да намерите част от код с грешката, да определи, тестване, давате тестера. Отличен. Сега се опитайте по време на работа на следващия бъг между стъпки "намери виновен" и "поправя", за да добавите още една стъпка - напиши тест за тази грешка. Такава, че той падна на текущия код. Това е огромна тръпка, определя кода - а не да отиде да се тества ръцете си, и да започне да пада с преди няколко минути тест и да видим "успешен" на изхода. Освен естетическо удоволствие, този тест може да се дава на тестера и да го използвате по-късно за регресия тестване (и повече - за тестване на странични продукти клони, проектът "в полето" и т.н.). Разбира се, не всички и не винаги е възможно да се провери, може да е трудно с потребителския интерфейс, по-различни браузъри, многонишкова. Да не се притеснява, ако записът на тест ще ви отнеме много, много часове. В крайна сметка, тъй като технологията е проектирана за да направят живота ви по-лесно, а не да се направи танц на песента си.
9. За първи път TDD
Както обикновено, вашата работа е посветен на развитието на нова функционалност? Вероятно, първо мисля. Тогава проектиране, което правиш - Разпространява Имената на интерфейсите, класове, и след това името на методи, попълнете тяхното изпълнение, бягане, отстраняване на грешки. Добре, че не е необходимо да се промени почти нищо. Точно в този момент, когато вече имате интерфейси, класове и имена метод, но все още да ги приложат - пишат тестове за тях. Непретенциозен - наречен метод - проверка на резултатите. Забележете как дори на този етап вие ще забележите липсата на логика на някои имена, липса или излишък на аргументи в методи ненужни или липсващи зависимости и т.н. В това сега, докато тя е вярна - почти безполезен (защото прилагането все още не е написан). Tweaked архитектура, завършени тестове писане стартирани - видяха куп успешно тестовете. Добре, така че трябва да бъде. Писахме на изпълнение стартирате теста - видях повечето от тях да не са успели да поправя грешката, направена успешно приключване на всички тестове - отлично, това е направено. Вие се чувствате, както е какво морално удовлетворение ли? Това е до известна степен напомня на удоволствието от получаване на някои achivki в играта. И защо? И тъй като това може да се измери! "Кодът минава 18-тестове с тест покритие на 90%" - ". Е, бих искал функция се изпълнява, аз мушна малко, изглежда, не попада" звучи охладител, много по-хладна от, Тя дава право да се гордеем. У дома - и ясно да разбере, че някой ден да направи полезен, това "нещо" може да се измери, осезаемо, реално.
10. завинтва текущи тестове за CI-сървър
Тестовете са почти безсмислени, ако не се експлоатират. Пусни ги ръчно - дълго и безсмислено. Със сигурност имате натрупване сървър с някои TeamCity или CruiseControl, което се случва с вашия продукт. Така че, голяма част от добрите изграждане сървъри наведнъж, от подкрепата на кутия текущи тестове, а дори и разбор своите дневници и боядисани красиви отчети. Спазването на това, разбира се, не "всички съвместим с всички", но ако се рамка тест за съвета в началото на статията - шансовете, че ще работят е много висока. Например, аз споменах, и TeamCity Google Тест големи приятели помежду си.
послеслов
Внимателният читател може да забележите, че тези предмети, вариращи навсякъде от седмия и осми най-вероятно няма да се поберат в изявление, озаглавен "10 минути по стъпка." Какво мога да кажа? Имайте предвид, че аз не съм добър човек, вие сте малко нарязан. Въпреки това, ако се упражнявате с праведен гняв премина тези елементи, а след това:
- Имате ли проект, който тестове се завинтват. Те започнаха работа, има повече от нула и те вече ви донесе полза.
- Може да се опита по целия този случай.
- Вторият път, когато стане сериозна скоро.
Тук и да реши, че си заслужава или не.
Някъде точки след 8-ми - добър момент да се въведе тест проект за вашия екип. Обяснете в рамките на 2-3 точки какво и как, показват пример за един прост тест, имайте предвид, че, да речем, «не се колебайте да добавяте свои собствени тестове», но не особено дълги преси. Ако пишете бе взето на тестовете, най-вероятно първото впечатление ще бъде предпазлив скептицизъм и недоразумения. Той бързо се лекува след втората и третата споменато по време на срещата, че се казва, "и ние открихме бъг чрез тестото" или "и тук писмен тест и ние веднага знам дали то ще се счупи отново." Програмисти - хората са рационални, те разбират и годни.