В първата част сме създали среда за развитието, прилагана няколко правила, взети от PHP лига. и създаде две прости, но безполезен клас - Diffbot и DiffbotException. В тази част ще се занимава с разработка чрез тестове (разработка чрез тестове, TDD)
Ако искате да продължите - Прочетете първата част на статията. или skloniruyte хранилище с код проба.
Може би вече сте чули нещо за на PHPUnit, но е време да го прилагат в реалната практика. Първата стъпка е да се провери, ако е инсталиран:
Изпълнението на тази команда трябва да даде информация за доклада за един преминал тест. Този тест, който по подразбиране идва с заявление по образец, а в действителност това потвърждава твърдението, че вярно е равно вярно. Доклад на корицата ще бъде генериран и се поставя в директорията на проекта.
Ако отворите капака на доклада на браузъра, трябва да се види, че процентът на покритие на тестовете в проекта е много малък.
Сега, след като видяхме, че ние PHPUnit работи, нека да се тества всичко. В момента не разполагаме с прекалено много код, освен привличат и инкубатори, които, като цяло, а не да се тества. Така че да можем да тестваме в сегашната ни код? Ами ... Какво ще кажете за валидността премина при създаването на инстанция на обект токен?
Първо да разгледаме PHPUnit конфигурационния файл, phpunit.xml.dist. След като смените думата "Лига" на "Diffbot" тя трябва да изглежда така:
Атрибути е основният елемент на PHPUnit се каже, че неговият доклад трябва да бъде възможно най-подробно, че е необходимо да конвертирате всички видове предупреждения и грешки в изключение, и с останалата част от настройките, които можете да намерите в PHPUnit на документация. След това, ние се определи набор от тестове, които се отнасят до указаното приложението или скрипт. Един такъв комплект - комплект за основното приложение (единственият, който ние ще използваме) и призовал своя "Diffbot Tesat Suite", установявайки, че директорията на тестове съдържа всички наши тестове - може да забележите, че тестът за проба на Лигата вече е в тази директория. ние също се говори за PHPUnit, е да се игнорира файловете намиращи се в SRC / директория. тъй като ние искаме да прави изследвания, само, а не за нашите класове. И накрая, ние се създаде сеч - какво, къде и как да се включат в доклада.
Нека да напише първата ни тест. При тестове DiffbotTest.php директория създайте файл. Ако използвате PhpStorm - този процес е почти автоматично:
Не забравяйте да проверите, че пространството от имена в composer.json файл съответства на това:
Сега можете да премахнете примерен тест ExampleTest (както и клас SkeletonClass) и замените съдържанието DiffbotTest клас до следното:
В този прост пример, ние тестваме статичен метод Diffbot :: setToken. Ние използваме доставчика на данни на синтактичните (DataProviders) за набори от данни цикличен тестване. Той също така ни дава възможност да се знае кои ключове не са валидни, вместо да се проверява освобождаването на изключения. Ако сега стартирате теста и погледнете корицата, ние трябва да видите нещо подобно:
Виждам постигането и се събужда в мен желанието да видите, колкото е възможно в зелено. Нека да проверим за създаване на инстанция на класа.
Тези методи включват всички случаи на автора - на инстанция, без знак сет и не в световен мащаб на инстанция с глобално определен знак и само чрез параметър на инстанция. Но изпълнението на теста ние можем да видим, че тя се провали. Това е така, защото Diffbot клас все още пази статичен имот, разположен в предишния тест, затова ние нямаме статичен знак подразбиране във втория тест. Това е често срещан проблем за изпитване глобални и статични свойства. За да получите около него, за да се уверите, че всеки тест DiffbotTest клас работи в отделен процес. Това ще забави изпълнението, но ние сме сигурни, че във всеки случай ние имаме чиста и не е застлан среда.
Сега, когато стартирате теста, погледнете корицата - ще видите, че всичко е зелено!
В действителност, това е един вид анти-модел - необходимостта да се прави изследвания в различни процеси - което обикновено означава, че класът на архитектурата нещо не е наред, но аз все още се намира най-добрият подход за тестване в този случай. Статично имот в клас Diffbot трябва да бъде променлива, за по-лесна употреба. Ако имате някакви предложения за това как тя може да се подобри - аз съм в слух. Един алтернативен подход към решаването на този проблем - да се създаде метод за нулиране. или допълнително сетер, който може да се използва за ръчно клас връщане към първоначалното си състояние, но стоят настрана от тези подходи, така че да не се претрупва вашите логически класове, предназначени да проверят. Всъщност, това може да бъде решен чрез backupStaticAttributes. но не можех да го да работи.
TDD (Test Driven развитие)
В TDD, трябва първо да се мисли за планираната функционалност, след това да напишете тест за него (да ги управляват, и да получите съобщение за грешка), а след това работи за изпълнение функционалност, която тестовете разработени, както би трябвало. Това е, когато тестването кара развитие, т.е. развитие чрез тестване. Това е точно това, което ние ще направим в този раздел.
Diffbot, като услуга, предвижда няколко подразбиране API:
Според документацията, всеки API връща подобен отговор (всички се върне валиден JSON), но на снимачната площадка на полета върнати обикновено е по-различно. Ето как виждам Diffbot клас етап на крайния продукт: той има методи за достъп до API за всеки вид, както и всеки вид API - това е отделен клас, че ние все още трябва да се развива. Всички класове API наследяват от един абстрактен клас API, която предоставя набор от общи-инкубатори за областта, и всеки клас API допълнително прави свои собствени потребителски полета. Като цяло, в края искам да получа тази възможност за ползване:
Тестване на абстрактни класове
Ние идентифицирахме няколко доставчици на данни, както и в първия тест. Също така ние имаме метод, който създава нашия макет обект, така че можем да се обади, ако е необходимо. Тогава ние се създаде метод за изпитване за всички сценарии - не argumanta изчакване невалиден аргумент стойност и истинската стойност на аргумента. Изключение, очакваме само в случай на неправилна стойност на аргумента.
Ако стартирате теста - ние ще получавате съобщение за грешка:
Работещи теста вече генерира нова грешка:
Уау! Разделихме PHPUnit! Всъщност, аз съм се шегувам, че е добре. Тук се казва, че ние имаме в класната стая не е метод setTimeout (). който се нуждае от тестото - приема се, че тя трябва да бъде в моделната обекта. Нека vnesom променя Api.php.
Рестартирането на теста получаваме:
Сега ние ще се някъде. Сега добавете крайната реализация на функционалността имахме нужда. Редактирайте setTimeout на метод на тялото по този начин:
Заедно с логиката сме добавили документиране на блока и направи този метод, за да се върнете на инстанция на класа се използва, така че можем да направим верига от методи. Рестартирайте тестовете, всички трябва да премине. Търси за покриване трябва да видите 100%.
заключение
Във втората част, ние започнахме да се запознаят с въвеждането на TDD PHPUnit и да я използват за разработване на някои функционални на нашия пакет. Можете да опровергавам пълния код за втора част на статията от този бранш. В следващата част ще продължим да разработи пакет с помощта на методите, описани в тази статия, и да добавите още един аспект - заместване на данни. Останете на линия!
5 урока последната колона "PHP"
Когато става въпрос за сигурността на уеб сайт, фразата "Да се филтрират всички, избяга всичко" винаги ще бъде от значение. Днес нека да поговорим за филтриране на данните.
Изразителен 2 поддържа връзка с други компоненти за специален режим на ZF. Не всеки харесва решението. В тази статия ще обсъдим как да се подобри процесът на свързване на няколко модула.
Да предположим, че трябва да изпратите информация за Google Анализ от страна на сървъра скрипт. Как да го направя. Отговорът в тази статия.
Селекция от няколко вида PHP пясък. На някои ви в онлайн режим ще бъде в състояние да тествате вашия код, но има и решения, които могат да бъдат приложени в сайта си.
До получаване на информация от два канала (зрение и слух) на ефективността на обучението далеч по-добър живот от книги. А домашните задачи и онлайн тестове ще ви позволи да мисля постоянно в целевия език и веднага провери знанията си!
Ако искате по-дълго време, за да проучи как да се HTML, че ме има, за което трябва добра новина!
Ако вече сте се научили HTML и искат да се движи напред, следващата стъпка ще бъде да се проучи CSS технологията.
Ако искате да се разбере концепцията на домейн и хостинг, да научат как да се създаде база данни, да качвате файлове към уеб сайт чрез FTP сървър, създаване на поддомейни, да конфигурирате пощенските кутии за сайта и мониторинг на посещаемостта, този курс е разработен специално за вас!
Свързани статии