Comments 10
Как удачно! У меня как раз есть задачи по написанию тестов для Symfony. Спасибо за статью.
Прогон функциональных тестов может занимать немало времени. Например, полный прогон набора из 77 тестов и 524 предположений может занять 3-4 минут.
Только вот зачем прогонять полный набор функциональных тестов локально. Для этого есть ci. А с phpunit можно и по одному нужные во время разработки тесты запускать.
Я обнаружил, что прекрасный способ очистки БД — загрузить пустые фикстуры в особый метод setUp в PHPUnit.
Есть куда более практичный способ. Пакет dama/doctrine-test-bundle предоставляет удобный апи для оборачивания тестов в бд транзакцию. Которую после его выполнения откатывается. Просто, быстро, удобно. Чаще всего даже отдельная бд для тестов не нужна.
Этого достигли с помощью многочисленных функциональных тестов Symfony и некоторых модульных тестов, которые заполнили некоторые пустоты.
Тоже был такой опыт на нескольких проектах. Это и правда хорошо работает. Но на текущем мы используем tdd. И это работает еще лучше. Вопрос, по сути, лишь в том, как много заказчик готов платить за тесты. Если мало — можно ограничиться функциональными. А если надежность системы для него важнее — можно и нормальную пирамиду тестирования наладить.
UFO just landed and posted this here
Есть куда более практичный способ. Пакет dama/doctrine-test-bundle предоставляет удобный апи для оборачивания тестов в бд транзакцию. Которую после его выполнения откатывается. Просто, быстро, удобно. Чаще всего даже отдельная бд для тестов не нужна.
Но есть проблема в этом способе — транзвакции не откатывают счетчик автоинкремента. И если есть привязка теста к IDs — возникнет проблема.
Еще одна проблема — если код приложения сам внутри открывает транзакцию и коммитит (или откатывает) ее. Тогда у нас получаются вложенные транзации. Не БД хорошо такое поддерживают.
Как с этим у sqlite?
За этим обычно следит сама доктрина, у нее есть счетчик вложенности транзакций и реально закрывает\открывает она только внешнюю
www.doctrine-project.org/projects/doctrine-dbal/en/2.10/reference/transactions.html#transaction-nesting
www.doctrine-project.org/projects/doctrine-dbal/en/2.10/reference/transactions.html#transaction-nesting
Позвольте узнать, а что именно вы проверяете такое, где нужна привязка к генерируемым автоинкрементом айдишникам? На моей практике такие вещи сигнализируют об очень хрупких тестах которые дорого обслуживать и от которых мало профита.
Не исключаю, что это не верный путь. Но, например, я заполняю базу данными и заполняю так, что для тестируемого запроса — результат сущность с ID =5. Конечно есть вариант проверять по другому полю. Но вроде как id — точно будет идентифицировать сущность.
Вопрос в том, зачем вам проверять айдишник? Важно ли что он именно 5? Будет ли проблема, если 6? Может важно лишь то, что по айдишнику, который в ответ был возвращен системой лежат данные, которые вы этим запросом отправили, а какой именно айдишник вам выдали — не важно?
Представьте себе, что вместо ваших тестов сидит тестировщик и у него есть какое — то состояние приложение — он не знает какие данные туда заливали раньше. Как он будет проверять этот запрос?
Представьте себе, что вместо ваших тестов сидит тестировщик и у него есть какое — то состояние приложение — он не знает какие данные туда заливали раньше. Как он будет проверять этот запрос?
Для заполнения тестовой базы данными придумали фикстуры
Sign up to leave a comment.
10 советов по тестированию в Symfony