PHPUnit — Глава 15. Другие использования тестов

Когда вы привыкнете писать тесты, вам будет любопытно найти и другие применения к ним. Ниже приведены несколько примеров.

Документация Agile

Обычно, в проекте, который разрабатывается по методологии agile, таких как Экстремальное программирование, документация не может успевать за частыми изменениями дизайна и кода проекта. Экстремальное программирование требует коллективного владения кодом, таким образом, что все разработчики будут знать как работает вся система. Если вы достаточно дисциплинированы для того чтобы писать "говорящие имена" для тестов, которые описывают то, что должен делать класс, вы можете использовать функциональность TestDox из PHPUnit. Эта документация даёт разработчиками описание того, что делает каждый класс.

Функциональность TestDox PHPUnit'а просматривает классы тестов и преобразует все методы тестового класса из camel case в предложения: testBalanceIsInitiallyZero() становится "Balance is initially zero". Если найдено несколько имен методов, которые отличаются только цифрой на конце, таких как testBalanceCannotBecomeNegative() и testBalanceCannotBecomeNegative2(), то предложение "Balance cannot become negative" появится в документации только один раз, при условии что все из этих тестов прошли.

Давайте взглянем на документацию, созданную для класса BankAccount (из Пример 12.1, «Тесты для класса BankAccount»):

phpunit --testdox BankAccountTest
PHPUnit 3.7.0 by Sebastian Bergmann.

BankAccount
 [x] Balance is initially zero
 [x] Balance cannot become negative

Документация agile также может быть создана в текстовом или HTML формате и записана в файл. Для этого следует использовать аргументы --testdox-html и --testdox-text.

Документация agile может быть использована для документирования предположений, которые делаются относительно внешних пакетов в проекте. Когда вы используете внешние компоненты, вы подвержены риску того что компонент изменит свое поведение, и что будущие версии пакета будут меняться и незаметно ломать ваш код. Вы можете снизить рискаи при написании теста каждый раз когда вы делаете предположение. Если тест проходит - то ваше предположение верно. Если вы будете документировать все предположения в виде тестов, следующие версии компонент не будут причиной для беспокойства: если тесты проходят - значит система может продолжать работать.

Межкомандные тесты

Если вы документируете свои предположения в виде тестов, то вы владеете тестами. Поставщик пакета - тот про кого вы делаете предположения - ничего не знает про выши тесты. Если вам необходимо иметь тесную связь с поставщиком компонента, вы можете использовать тесты для того чтобы управлять вашей деятельностью.

Если вы собираетесь управлять деятельностью с поставщиком компонента - вы можете написать тесты вместе. Сделайте это таки образом, чтобы тесты выявили как можно больше предположений. Скрытые допущения убивают сотрудничество. С помощью тестов вы документируете то, что вы ожидаете от поставщика пакета, и поставщик будет знать что компонент завершён, если проходят все тесты.

При использовании заглушек (см. в главе "Мок объекты", в предыдущей части книги) вы можете ещё больше отойти от связи с поставщиком пакета - поставщику стоит заботиться о том чтобы проходили тесты с реальной системой. Вашей работой будет создание тестов для своего кода. До того момента, пока у вас не будет реальной реализации компонента, вы работаете с заглушками. Следуя этому принципу две команды могут работать независимо друг от друга.

Оцени публикацию:
  • 0,0
Оценили человек: 0

Похожие статьи:

Справочники и учебники:


Предложения и пожелания:
Ваше имя:
Ваш E-mail:
Сколько будет Οдин + Τри
Главная
X

youtube.com/watch?v=7hFivbgIEqk

При полном или частичном использовании материалов данного сайта, ссылка на сайт "yapro.ru" обязательна как на источник информации.
Автоматический импорт материалов и информации с сайта запрещен.
Copyrights © 2007 - 2017 YaPro.Ru

Главная » Веб-мастеру » PHP »