TestCase
В простите тестове твърденията могат да следват едно след друго. Понякога обаче е полезно да се затворят твърденията в тестови клас и да се структурират по този начин.
Класът трябва да бъде потомък на Tester\TestCase
, а ние го наричаме
просто testcase.
Можем да обогатим тестовия пример с методите setUp()
и
tearDown()
. Те се извикват преди/след всеки метод за изпитване:
Ако се появи грешка във фазата setUp()
или tearDown()
, тестът ще
се провали. Ако в тестовия метод възникне грешка, методът tearDown()
се извиква въпреки това, но с потиснати в него грешки.
Препоръчваме анотацията @testCase да се запише в началото на теста, след което програмата за стартиране на тестове от командния ред ще изпълнява отделните методи на тестовия случай в отделни процеси и паралелно в няколко нишки. Това може значително да ускори целия процес на тестване.
Анотиране на методи
Има няколко анотации, които ни помагат при тестването на методите. Записваме ги в посока на метода за изпитване.
@throws
Това е същото използване на Assert::exception()
в рамките на метод за
изпитване. Но обозначението е по-четивно:
@dataProvider
Тази анотация е подходяща, когато искаме да стартираме даден тестови метод многократно, но с различни аргументи. (Да не се бърка с анотацията на файла със същото име).
Като аргумент записваме името на метода, който връща параметрите на тестовия метод. Методът трябва да връща масив или Traversable. Един прост пример:
Друга разновидност на анотацията @dataProvider приема като аргумент
пътя до файла INI (относително към тестовия файл). Методът се извиква
толкова пъти, колкото секции има в INI файла. Файл loop-args.ini
:
и метода, използващ файла INI:
По същия начин можем да предадем път до PHP скрипт вместо INI. Тя трябва
да връща масив или Traversable. Файл loop-args.php
: