Модул unittest тестват своите програми, Python 3 за начинаещи, така и начинаещи

Представете си, че вие ​​сте написали програма, и искате да проверите дали работи правилно. Какво бихте направили за това? Най-вероятно, ще го изпълним няколко пъти с различни входни данни, и да се осигури правилен отговор издадени.

Сега можете да промени нещо и искат да извършат повторна проверка на коректността на програмата. Пусни още няколко пъти? Но след това отново, ако нещо ще се промени? Възможно ли е по някакъв начин да се автоматизира това?

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

За автоматизиране на теста, unittest поддържа някои важни понятия:

• Стенд (носач) - се получават, необходимо за извършване на тестовете и всички необходими действия за почистване след изпитването. Това може да включва, например, създаването на временна база данни или стартира сървъра процес.
• При тест (тест) - минималната единица тестване. Тя проверява отговорите за различни набори от данни. unittest модул осигурява базов клас TestCase, който може да се използва за създаване на нови случаи на изпитване.
• Наборът от тестове (тестов пакет) - редица случаи от изпитвания, тестове, или и двете от тях. Той се използва за тестове на асоциацията, които трябва да се извършват заедно.
• тест Изпълнител (тест бегач) - компонент, който контролира изпълнението на тестове и предоставя на потребителя с резултата. Изпълнителят може да използва графичен или текстов интерфейс, или да се върне на специална стойност, която отчита резултатите от тест изпълнение.

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

Ето един кратък сценарий за тестване на три метода на линии:

че тест е създаден от унаследяването от unittest.TestCase. 3 отделни тестове, са определени с методите чието име започва с тест. В споразумението се казва изпълнителят на тестове по какви методи са тестове.

Същността на всеки тест - предизвикателство assertEqual (), за да се провери очаквания резултат; assertTrue () или assertFalse (), за да проверите условията; assertRaises (), за да се уверят, че методът хвърля изключение. Тези техники се използват, вместо обичайната отстояват да тестват бегач е в състояние да предприеме всички резултати и да направи доклад.

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

Последните два реда показват тест тече по прост начин. unittest.main () осигурява ред интерфейс команда за програмата за изпитване. Когато стартирате от командния ред, сценарият се показва отчет, като този:

интерфейса на командния ред

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

Можете също да укажете пътя до файла:

С -v флаг може да получи по-подробна справка:

подробен доклад ще бъде така за нашия пример:

-б (--buffer) - изход на програмата, когато теста за неуспех ще бъдат показани, а не скрити, както обикновено.

-в (--catch) - Ctrl + C по време на изпитването очаква приключване на текущия тест и след това да докладва за резултатите до момента. Втори натиснете Ctrl + C е обичайната изключение KeyboardInterrupt.

-F (--failfast) - добив след първия тест недостатъчност.

--местните жители (от Python 3.5) - показват локалните променливи за неуспешен тест.

тестове за откриване

тестове за откриване реализирани в TestLoader.discover (), но могат да се използват от команден ред:

-V (--verbose) - подробния изход.

-ите (--start-директория) directory_name - категория започва тест за откриване (текущата подразбиране).

-р (--pattern) модел - на името на файла на шаблона с тестовете (за тест * .py подразбиране).

-тон (--top ниво-директория) directory_name - директория от първо ниво проект (по подразбиране стартиране директория).

Организация на правила за изпитване

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

че тест е създаден от унаследяването от unittest.TestCase.

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

Най-простият TestCase подклас може просто да приложи метод за изпитване (метод като се започне с тест). Измислен пример:

Имайте предвид, че за да се изпробва нещо, ние използваме една от () методи за тях поддържали \ *.

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

Можем също така да се определи метод демонтиране (), която ще се проведе след всяко изпитване:

Можете да поставите всички тестове в един и същи файл, колкото и самият (като widgets.py) програма, но режима на тест в отделен файл (като test_widget.py) има много предимства:

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

Пропускане на тестове и се очаква грешки

unittest поддържа скачане индивидуални тестове и упражнения за изпитване. В допълнение, марката се поддържа като тест "не работи, но така да бъде."

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

Класове могат също да бъдат пропуснати:

Очаква се използва грешка декоратор expectedFailure ():

Много лесно да направите своя декоратор. Например, след декоратор издържи теста, ако премина обекта има определен признак:

Украси, като прескочите тестове или говорят за очакваната грешка:

@ Unittest.skip (причина) - прескачане на изпитването. причина обяснява защо премине.

@ Unittest.skipIf (условие, причина) - прескачане на изпитването, ако условието е вярно.

@ Unittest.skipUnless (условие, причина) - прескачане на изпитването, ако условието е невярно.

@ Unittest.expectedFailure - отбелязване на теста, както се очаква грешка.

Не стартирайте инсталационната програма () и унищожаване () за пропусната тест. За пропуснатите часове не започват setUpClass () и tearDownClass (). За липсващите модули не се експлоатират setUpModule () и tearDownModule ().

Отличителни изпитване повторения използват подизпитвания

Когато някои тестове имат само малки разлики, например някои параметри, unittest позволява те да бъдат разграничени в рамките на един и същ метод за изпитване с помощта на контекст за управление на под-тестовете ().

Например, следното изпитване:

дава следния доклад:

Без използването на подизпитвания, изпълнението ще спре след първата грешка, и грешката ще бъде по-трудно да се диагностицира, защото стойността на аз няма да се показва:

Проверка на успеха на

unittest модул предоставя набор от функции за различни тестове:

assertTrue (х) - булев (х) е True

assertFalse (х) - булев (х) е False

assertIsNot (а, б) - един не е б

assertIsNone (х) - х е Няма

assertIsNotNone (х) - х не е Няма

assertNotIn (а, б) - един не е в б

assertIsInstance (а, Ь) - isinstance (а, Ь)

assertNotIsInstance (а, б) - не isinstance (а, б)

assertRaises (с изкл, забавно * аргументи, ** kwds) - забавно (* аргументи, ** kwds) хвърля изключение изкл

assertRaisesRegex (с изкл, Г, забавно * аргументи, ** kwds) - забавно (* аргументи, ** kwds) хвърля изключение изкл и съобщение съвпада с регулярен израз R

assertWarns (предупреждавам, забавни, * аргументи, ** kwds) - забавно (* аргументи, ** kwds) генерира предупреждение

assertWarnsRegex (предупреждавам, R, забавни, * аргументи, ** kwds) - забавно (* аргументи, ** kwds) генерира предупреждение и съобщение съвпада с регулярен израз R

assertAlmostEqual (а, Ь) - кръг (а-б, 7) == 0

assertNotAlmostEqual (а, Ь) - кръг (а-б, 7) = 0

assertGreater (а, Ь) - а> б

assertGreaterEqual (а, Ь) - а> = б

assertLessEqual (а, Ь) - а <= b

assertNotRegex (S, R) - не r.search (и)

assertCountEqual (а, Ь) - а и б съдържа същите компоненти в същите количества, но за да не е важно