Меню

Phpunit как запустить конкретный тест

PHPUnit тестирование – проще простого

Насколько часто вы попадаете в замкнутый цикл из ошибок при разработке приложения в PHP? Ошибка исчезает, а потом появляется в другом блоке кода, или баги постоянно сменяют друг друга. Самое неприятное обстоятельство — вернуться к багу, который был исправлен несколько часов назад. Когда отлаживание алгоритма начинает приносить раздражение — о конструктивном подходе к задаче можно забыть. Именно для того, чтобы не дать вам забросить перспективную разработку или просто выполнить поставленную задачу, существует возможность использовать PHPUnit тестирование.

Что такое PHPUnit тестирование?

С Unit или же «модулем» плотно связано понимание процесса тестирования. Модуль — это работающая часть кода, функционал которой можно протестировать автономно. Соответственно, PHPUnit тестирование представляет собой последовательную проверку всех модулей приложения на корректность выполнения их алгоритмов.

Тесты можно прописать один раз и впоследствии использовать после внесения любых изменений.

Преимущества модульного тестирования

Вот несколько неоспоримых преимуществ Unit-тестирования:

  1. Оперативная проверка правок. Довольно удобно проверять работоспособность модуля немедленно после его изменения. Операция займет несколько секунд.
  2. Облегченная передача кода другому разработчику. Если вы прекратили разработку продукта и ее продолжит другой специалист, то процесс передачи пройдет намного легче.
  3. Безопасное редактирование. Если вы боитесь, что изменения модулей могут повлечь за собой глобальную проблему для системы в целом, то без предложенного Unit-тестирования обойтись будет очень сложно.

Источник



Часть 7: PHPUnit (Тестирование ПО)

Записная книжка рассеянного [в пространстве и времени] программиста

Часть 7: PHPUnit (Тестирование ПО)

Оглавление

Продолжаем цикл статей по разработке веб-приложений с использованием методологии TDD.

Ранее утверждалось, что для понимания того, как функционирует тот или иной фреймворк или технология нужно сначала попытаться реализовать похожий функционал самостоятельно. И только затем пытаться использовать уже существующие наработки.

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

Это немного удивительно, но предыдущие наработки можно легко использовать лишь изменив родительский класс для UserTest с \common\tests\TestCase на \PHPUnit\Framework\TestCase и несколько изменив порядок запуска тестов.

Помимо изменения родительского класса мы еще и убрали подключение файла _bootstrap.php. Запуск тестов будет выглядеть так, как показано ниже.

Примечание : кавычки нужны из-за неправильной обработки передаваемых в команду аргументов. Эта ошибка уже исправлена, но ее портирование в composer будет выполнено только после того как разработчики проекта откажутся от поддержки версий php ниже 5.5.

Здесь мы вызываем исполняемый скрипт phpunit, который расположен в каталоге vendor/bin и передаем ему несколько аргументов.

  • –bootstrap common/tests/_bootstrap.php — указывает, что перед запуском тестов фреймворк обязан запустить файл, переданный как часть опции. В нашем случае он отвечает за инициализацию окружения так же, как и в случае с unitSuite.php.
  • common/tests/unit — этот аргумент обозначает каталог, в котором phpunit будет искать тесты

Результат выполнения это восемь точек, каждая из которых обозначает успешно выполненный тест. Если тест не выполнен, то вместо точки мы увидим букву F, а ниже будет следовать расшифровка, в которой написано, какой тест упал (во втором примере поломан первый тест).

Конечно же каждый раз писать подобную командную строку не очень удобно. И PHPUnit предусмотрена возможность конфигурирования. Один из этих способов — использование xml-файла настроек, с которым мы работали в рамках предыдущей лекции. О средствах интеграции phpunit и yii, которые существую мы поговорим на одной из следующих лекций. Создадим файл настроек phpunit.xml и разместим его в каталоге с конфигурацией тестового окружения environments/dev/. После этого нужно выполнить провизию машины или скопировать файл phpunit.xml в корень проекта (как описывалось ранее).

phpunit.xml

Файл конфигурации — это xml файл, который содержит в себе несколько секций, описывающих определенные аспекты тестирования. Атрибуты тега phpunit xmlns:xsi и xsi:noNamespaceSchemaLocation являются обязательными. Все остальные — это настройки. Самая важная настройка — bootstrap. Она показывает, что за файл нужно выполнить перед запуском тестов. Это тот самый _bootstrap.php, который мы писали выше.

Внутри phpunit вкладываются элементы testsuites и filter. Первый описывает группы тестов, а второй — список файлов и каталогов, на которых будет проводится анализ покрытия кода тестами. Не будем подробно на них останавливаться поскольку данные теги очень хорошо описаны в официальной документации.

Таким образом мы говорим фреймворку, что у нас есть только одна группа тестов, которая расположена в каталоге common/tests/unit, и файлы в только этом каталоге нужно анализировать на процент покрытия тестами (если указана соответствующая опция запуска).

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

Строго говоря, все возможные опции, которые доступны через аргументы командной строки (посмотреть, какие опции вам доступны можно либо на официальном сайте проекта, либо выполнив composer exec -v – “phpunit –help”) мы можем указывать в конфигурационном файле. Никто не запрещает нам иметь несколько файлов конфигурации в одном проекте и использовать их поочередно, но делать так не стоит.

Отличия интеграционных и модульных тестов

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

Читайте также:  Эли висцеро тест 24 что показывает

Смотрите, первый же вызываемый метод setUp() работает с базой, очищая ее и наполняя данными. Дальше идут тесты сохранения пользователя в базу и т.д. Если следовать букве определения, то мы должны разместить тесты модели не в подкаталоге unit, а в подкаталоге integration например, но, увы, это не будет отражать суть того, что же мы тестируем. Поэтому порой приходится идти на некоторые уступки.

Правильны же модульный тест тестирует только один класс в отрыве от всей остальной инфраструктуры, подменяя все внешние зависимости своими заглушками. Интеграционный же тест проверяет некоторую единицу, которая взаимодействует с различными частями системы.

Интеграционные тесты

Исторически сложилось, что интеграционное и блочное тестирование не разделяется в yii на два отдельных процесса и запускается одновременно (одна из причин описана в предыдущем разделе — их просто невозможно отделить). Изолировать их запуск можно самостоятельно. В раздел testsuites конфигурационного файла phpunit.xml мы добавим запись еще об одной группе тестов — интеграционной.

С помощью ключа –testsuite название_группы можно запустить конкретную группу тестов.

Первая команда запустит все тестовые группы. Вторая и третья только группы с соответствующем именем.

Mock-объекты

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

Например, у нас есть \Yii::$app->user, который является текущим пользователем системы и содержит в себе процедуры авторизации (процедуры аутентификации происходят в модели LoginForm).

При тестировании формы одним из аспектов, который обязательно требуется проверить, является наличие вызова метода авторизации из объекта user (чаще всего используется \yii\web\user). Как мы можем это проверить простым способом?
Никак. Но что если мы сможем подменить объект user на свой? И эта сущность сможет сообщить о том был ли вызов нужно процедуры или нет. Кратко это и есть вся суть mock-объектов — объектов, которые подменяют оригинальный класс на специфический, подконтрольный разработчику. Историю появления и больше сведений можно прочесть в википедии.

Первое, что мы сделаем для тестирования LoginForm — создадим класс тестов.

03-create_class

common/tests/unit/LoginFormTest.php

Разберем этот код подробно. Метод setUpBeforeClass() выполняется единожды при инициализации класса (аналогично setUp(), который выполняется перед каждым тестом), в нем мы создаем в базе тестового пользователя. tearDownAfterClass() запускается после прохождения всех тестов и в нем мы очищаем за собой базу. Для проверки того, что все идет хорошо мы используем testOne(). Он покажет все ли идет хорошо.

обратите внимание на то, что мы используем константный хеш. Это нужно для повторяемости тестов. Не используйте рандомные данные в своих кейсах — воспроизвести ошибку будет практически невозможно.

Запускаем через phpunit способом, который мы изучили ранее и убеждаемся, что ни один тест не упал.

Первый реальный тест, который мы напишем будет проверять валидаторы полей формы.

Тест не проходит и показывает, что есть ошибка. Это очевидно поскольку все шаблоны приложений Yii ориентируются на username, а мы в предыдущих частях условились использовать email как уникальный идентификатор пользователя.
Вашей задачей будет модифицировать LoginForm так, чтобы данный кейс прошел. Да, в процессе работы над проектом у вас будут самостоятельные задания ответы на которые вы сможете подсмотреть в исходном коде прилагаемой к статье.
А теперь мы хотим проверить, что после успешной аутентификации запускается механизм авторизации. Для этого нужно убедиться, что запускается метод \Yii\web\User::login(). Но как? Здесь нам помогут mock-объекты. На время теста мы подменим актуальный класс на наш, который укажет на то, выполнялся конкретный метод или нет.

Рассмотрим метод testAuthorizationCall().

Создается mock на базе класса \Yii\web\user. Это значит, что будет использоваться оригинальный класс с сохранением всех его методов.

Указываем какие методы будут заменены на новые.

Отключаем конструктор (так как оригинальный выполняет слишком много действий, которые нам для этого теста не нужны.

Получаем итоговый объект.

Указываем, что метод login() будучи вызванный с любыми параметрами всегда вернет true.

Подменяем оригинального пользователя на нашего.

А дальше идет простой тест, который будет искать ошибки кейса. И конечно же не стоит забывать о сохранении и восстановлении оригинальных значений. Это делают методы setUpBeforeClass() и teadDown() соответственно.

На этом мы заканчиваем знакомство с PHPUnit и дальше будем применять его на практике (конечно же заглядывая в документацию).

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

Источник

PHPUnit с нуля для начинающих: основы использования модульного тестирования в проектах на PHP

Если вы в очередной раз находите себя в ситуации, когда пишете скрипт примерно такого вида:

И если вы уже начинаете забывать, где какой скрипт для тестирования чего (не говоря уж о ваших коллегах), то это означает что пришло время вам внести структуру в ваши тесты. Поможет вам в этом PHPUnit — фреймворк для написания юнит-тестов.

Установка

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

Проверим корректность установки PHPUnit, запросив версию:

Инструкции приводятся для версий 7.4, 8.5 и 9.0.

Настройка

Понятно, что вы не хотите каждый раз вручную указывать всевозможные аргументы типа —bootstrap при запуске phpunit , а потому лучше всего будет сразу же, до начала работы, указать все необходимые параметры для системного запуска тестов. Настроил — и забыл!

Настройки PHPUnit хранятся в XML-файле в корне вашего проекта. Лучше сразу использовать phpunit.xml.dist , а не phpunit.xml , чтобы у ваших коллег была возможность переопределить свои настройки для тестов или свою подборку тестов.

Что мы делаем

Пример минимального файла phpunit.xml.dist , который подразумевает, что автозагрузчик и всё необходимо для работы наших классов инициализируется в vendor/autoload.php , и что все тесты лежат в каталоге tests в корне проекта, и в подкаталогах этого каталога. Также мы просим PHPUnit проводить тесты в случайном порядке для исключения возможных скрытых зависимостей между тестами.

Читайте также:  Тематический апперцептивный тест протокол

Если нужна какая-то ещё инициализация кроме автозагрузчика, то вместо vendor/autoload.php , который генерирует Composer, можно и нужно использовать app/common.php или подобный.

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

Подход с включением всего подряд в область поиска тестов ведет к некоторым неудобствами в том, что касается оценки покрытия кода тестами, но не будем пока на этом останавливаться — нам важно начать хоть что-то.

Проверить корректность конфигурации можно следующей командой:

Должно вывести что-то вроде phpunit.xml.dist validates .

Что мы получили

С указанным выше минимальным phpunit.xml.dist будут просмотрены все файлы, заканчивающиеся на *Test.php , и использованы все найденные в этих файлах классы, названия которых заканчиваются на *Test .

Примерно оценить список классов, которые будут задействованы, можно так:

Конфигурационный файл позволяет вам (и вашим коллегам) забыть о том, где находятся тесты, как подключать настройки, и тому подобные детали, тем самым позволяя нам сконцентрироваться на том, для чего вам собственно и нужны тесты:

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

Применение

Самый простой вид теста представляет собой.

  • Метод класса, начинающийся на test ,
  • в классе, заканчивающемся на Test ,
  • и наследующем от \PHPUnit\Framework\TestCase .

Понимаю, сложно и запутанно. Но посмотрим на пример такого класса:

Как видите, ничего особенно сложного.

Достаточно будет определить этот класс в tests/ExampleTest.php и мы сможем испытать PHPUnit:

Эта команда сообщит нам об успешном прохождении всех тестов:

Практический пример

Чтобы не ходить далеко, перепишем скрипт из начала этой заметки.

Здесь вы можете видеть пример применения аннотаций, которые позволяют, в числе прочего, указать какой тест от какого зависит, и какие исключения являются ожидаемым поведением.

Вот так могло бы выглядеть определение для тестируемого класса ExampleClass и исключения SpecificException :

Оценка тестов

Предположим, написали вы десяток-другой тестов, запускаете их одной командой, всё прекрасно. Так ли прекрасно. Чем ещё может помочь нам PHPUnit?

PHPUnit может помочь нам с метриками, которые могут использоваться для первичной оценки качества тестов в части покрытия кода тестами. Покрытие рассчитывается как отношение числа строк, файлов, классов, методов, которые были задействованы в тестах, к число строк и т.д., которые никак не задействованы в тестах. Оценка покрытием не даёт гарантий качества тестов (с чем может помочь мутационное тестирование), но, по крайней, вы будете знать что для какого-то класса и какой-то функции у вас есть тест, и что для чего-то теста ещё нет.

Можно попросить PHPUnit давать такие отчеты при каждом запуске директивами конфигурации, но замедлит работу тестов, и чем больше проект, тем существенней будет задержка на сбор покрытия и запись отчётов. Будет лучше запрашивать такие отчёты по необходимости, при регулярной оценке покрытия или при CI.

Получить простой текстовый отчёт можно с ключем —coverage-text :

В случае выше видно что у нас 100% покрытие всего кода тестами.

Понятно что из одной метрики покрытия меньшей 100%, например, 85%, сложно сделать вывод о том, какие именно части кода не покрыты тестами. В этом нам поможет отчёт о покрытии в формате HTML, получить и изучить который можно в две команды:

Открываем http://localhost:8000 и видим код проекта, размеченный согласно покрытия тестами.

Кроме текстового и HTML отчётов PHPUnit может выдать отчёты в других форматах, более пригодных для программной обработки.

Что дальше?

За дальнейшим вдохновением можно обратиться как к официальной документации, так и к примерам тестов, которые за много лет существования PHPUnit написало всё сообщество программистов.

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

Вот бы у меня-из-прошлого была такая статья! Тогда внедрение PHPUnit не потребовало бы от меня ни чтения всей документации, ни долгого и мучительного изучения форумов и блогов в поисках крупиц смысла. Ведь всё просто.

Источник

PHPUnit тестирование – проще простого

Насколько часто вы попадаете в замкнутый цикл из ошибок при разработке приложения в PHP? Ошибка исчезает, а потом появляется в другом блоке кода, или баги постоянно сменяют друг друга. Самое неприятное обстоятельство — вернуться к багу, который был исправлен несколько часов назад. Когда отлаживание алгоритма начинает приносить раздражение — о конструктивном подходе к задаче можно забыть. Именно для того, чтобы не дать вам забросить перспективную разработку или просто выполнить поставленную задачу, существует возможность использовать PHPUnit тестирование.

Что такое PHPUnit тестирование?

С Unit или же «модулем» плотно связано понимание процесса тестирования. Модуль — это работающая часть кода, функционал которой можно протестировать автономно. Соответственно, PHPUnit тестирование представляет собой последовательную проверку всех модулей приложения на корректность выполнения их алгоритмов.

Тесты можно прописать один раз и впоследствии использовать после внесения любых изменений.

Преимущества модульного тестирования

Вот несколько неоспоримых преимуществ Unit-тестирования:

  1. Оперативная проверка правок. Довольно удобно проверять работоспособность модуля немедленно после его изменения. Операция займет несколько секунд.
  2. Облегченная передача кода другому разработчику. Если вы прекратили разработку продукта и ее продолжит другой специалист, то процесс передачи пройдет намного легче.
  3. Безопасное редактирование. Если вы боитесь, что изменения модулей могут повлечь за собой глобальную проблему для системы в целом, то без предложенного Unit-тестирования обойтись будет очень сложно.

Источник

3. Исполнитель тестов командной строки

Исполнитель тестов командной строки PHPUnit можно запустить с помощью команды phpunit . Следующий пример показывает, как запускать тесты с помощью этого инструмента командной строки PHPUnit:

Читайте также:  Для обнаружения микобактерий туберкулеза применяется тест

При вводе команды, как показано выше, исполнитель тестов командной строки PHPUnit будет искать исходный файл ArrayTest.php в текущей рабочей директории, загрузит его с целью найти в нём класс теста ArrayTest . Затем он выполнит тесты этого класса.

Для каждого тестового запуска инструмент командной строки PHPUnit выведет один символ для обозначения прогресса:

PHPUnit различает неудачные выполнения (failures) и ошибки (errors). Неудачное выполнение — это непройденное утверждение PHPUnit, например вызов assertSame() . Ошибка — необработанное исключение или ошибка PHP. Иногда это различие оказывается полезным, поскольку ошибки гораздо легче исправить, чем неудачные выполнения. В случае большого списка проблем, лучше всего сначала устранить ошибки и посмотреть, остались ли ещё какие-либо неудачные выполнения, когда ошибки исправлены.

Опции командной строки

Давайте посмотрим на опции командной строки исполнителя тестов в следующем коде:

Запускает тесты, представленные в классе UnitTest . Ожидается, что этот класс будет объявлен в исходном файле UnitTest.php .

UnitTest должен быть либо классом, который наследуется от PHPUnit\Framework\TestCase , либо классом с методом public static suite() , возвращающим объект типа PHPUnit\Framework\Test , например, экземпляр класса PHPUnit\Framework\TestSuite .

phpunit UnitTest UnitTest.php

Генерирует файл логов в формате XML с информацией о покрытии кода тестами для выполненных тестов. См. Логирование для получения более подробной информации.

Обратите внимание, что данная функциональность доступна только в случае установленных расширений tokenizer и Xdebug.

Генерирует отчёт о покрытии кода тестами в формате Crap4j. См. Анализ покрытия кода для получения более подробной информации.

Обратите внимание, что данная функциональность доступна только в случае установленных расширений tokenizer и Xdebug.

Генерирует отчёт о покрытии кода тестами в формате HTML. См. Анализ покрытия кода для получения более подробной информации.

Обратите внимание, что данная функциональность доступна только в случае установленных расширений tokenizer и Xdebug.

Генерирует сериализованный объект класса PHP_CodeCoverage с информацией о покрытии кода тестами.

Обратите внимание, что данная функциональность доступна только в случае установленных расширений tokenizer и Xdebug.

Генерирует файл логов или вывод командной строки в человекочитаемом формате с информацией о покрытии кода тестами для запуска тестов. См. Логирование для получения более подробной информации.

Обратите внимание, что данная функциональность доступна только в случае установленных расширений tokenizer и Xdebug.

—testdox-html и —testdox-text

Выполняются только те тесты, названия которых совпадают с регулярным выражением. Если регулярное выражение не заключёно в разделители, PHPUnit будет автоматически заключать его в разделители / .

Имена тестов для совпадения может быть в одном из следующих форматов:

TestNamespace\TestCaseClass::testMethod

TestNamespace\TestCaseClass::testMethod with data set #0

TestNamespace\TestCaseClass::testMethod with data set «my named data»

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

См. Пример 3.2 для примеров корректных шаблонов фильтров.

См. Пример 3.3 для некоторых дополнительных сокращений, доступных для сопоставления с провайдерами данных.

Выполняются только тесты из указанных групп. Тест можно добавить в группу, используя аннотацию @group .

Аннотации @author и @ticket — это псевдонимы для @group , позволяющие фильтровать тесты по их авторам или по номерам связанных тикетов соответственно.

Использовать цвета в выводе. В Windows используйте ANSICON или ConEmu.

Существует три возможных значения этой опции:

  • never : никогда не отображать цвета в выводе. Это значение по умолчанию, когда не используется опция —colors .
  • auto : отображает цвета в выводе, за исключением, если текущий терминал не поддерживает цвета, либо если вывод не был передан в другую команду или не перенаправлен в файл.
  • always : всегда отображать цвета в выводе, даже если текущий терминал не поддерживает цвета, или когда вывод передаётся в команду или перенаправляется в файл.

Когда опция —colors используется без значения, используется auto .

Указывает используемую реализацию загрузчика PHPUnit\Runner\TestSuiteLoader

Стандартный загрузчик тестового набора будет искать исходный файл теста в текущей рабочей директории и в каждой директории, указанной в конфигурационной PHP-директиве include_path . Имя класса, такое как Project_Package_Class , сопоставляется с исходным файлом Project/Package/Class.php .

Прочитать конфигурацию из XML-файла. См. Конфигурационный XML-файл для получения более подробной информации.

Если файл phpunit.xml или phpunit.xml.dist (в таком порядке) существует в текущей рабочей директории, а опция —configuration не используется, конфигурация будет автоматически прочитана из этого файла.

Если директория указана и файл phpunit.xml или phpunit.xml.dist (в таком порядке) существует в этой директории, конфигурация будет автоматически загружена из этого файла.

Обратите внимание, что с версии 4.8 параметры могут быть указаны после аргументов.

TestDox

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

Давайте посмотрим aglie-документацию, сгенерированную для класса BankAccount :

В качестве альтернативы, aglie-документация может быть сгенерирована в HTML или текстовом формате и записана в файл, используя аргументы —testdox-html и —testdox-text .

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

© Copyright 2019, Sebastian Bergmann. Revision 124cbafd .

Источник