Порой проще использовать тестовые данные и БД чем создавать моки для классов баз данных.
Ибо там такие моки получатся, которые будут включать в себя парсер SQL. Зачем оно надо?
KISS
Да. Но это значит, что всегда в програмном коде нужно использовать сейвпоинты.
Можно конечно, но лучше исходить из универсального предположения, что мы должны тестировать любой код.
Ну если вам нужна пустая база, возможно truncate помогает. Но лично я решал проблему очистки сразу с наполнением тестовыми данными, и потому что влив дампа, что truncate + заполнение данными занимали примерно одно и то же время.
А решения такие:
— эмулировать вложенные транзакции в приложении. Не так сложно, если не использовать чистый PDO, а какую-то обертку над ним.
— использовать SQLite.
— не использовать транзакции в тестируемом коде.
Вариант с копированием структуры базы напротив, требует много времени на свое выполнение, но зато и выполняется один раз. Т.е. Время его работы не зависит от количества запускаемых тестов.
А у вас не получится тогда ситуация, что тесты периодически что-то меняют в базе данных, и следующий тест может видеть результат предыдущего? Т.е. по-хорошему, тесты должны идти в полной изоляции и не знать о существовании друг друга. И база данных тоже должна очищаться после каждого теста. На этом нельзя халтурить )
Конечно самый удобный по скорости способ это транзакции, но в MySQL нет вложенных транзакций, а значит ваш метод тестирования будет бесполезен, если в самом приложении будет использована транзакция.
Хотелось бы услышать с какими проблемами сталкивались Вы при использовании DbUnit и как их решали.
По отзывам разботчиков на рельсах, их любимая подработка — переводить разросшиеся Sinatra-проекты на Rails… Как вы знаете, Silex похож на Sinatra, потому смею предположить, что вскоре что-то подобное будет в среде симфони2 разработчиков )
Какая-то малость притянутая за уши теория…
Хотя да, схожусь на мысли, что ревность может и должна быть искоренена. Пусть она и заложена на уровне инстинктов, то этот инстинкт как раз можно подавлять.
Короче, вот манифест пакета, который сгенерен вот этой тулзой.
github.com/Codeception/Codeception/blob/master/package.xml
Вручную писать его — никакого смысла.
Скажите, а пиар-агенство окупилось? Ну или есть к этому предпосылки?
Думаю, факт использования фейсбука уже зачисляет человека в ряды «полдитической оппозиции» во многих странах. Так что чистки проводить будет легко )
\+
\=
\-
А тесты в транзакции выполняются максимально быстро. Проверьте.
Ибо там такие моки получатся, которые будут включать в себя парсер SQL. Зачем оно надо?
KISS
Можно конечно, но лучше исходить из универсального предположения, что мы должны тестировать любой код.
А решения такие:
— эмулировать вложенные транзакции в приложении. Не так сложно, если не использовать чистый PDO, а какую-то обертку над ним.
— использовать SQLite.
— не использовать транзакции в тестируемом коде.
Но по скорости альтернативы транзакциям нет.
А у вас не получится тогда ситуация, что тесты периодически что-то меняют в базе данных, и следующий тест может видеть результат предыдущего? Т.е. по-хорошему, тесты должны идти в полной изоляции и не знать о существовании друг друга. И база данных тоже должна очищаться после каждого теста. На этом нельзя халтурить )
Конечно самый удобный по скорости способ это транзакции, но в MySQL нет вложенных транзакций, а значит ваш метод тестирования будет бесполезен, если в самом приложении будет использована транзакция.
Со всеми вышеописанными. Решал так:
codeception.com/docs/08-Data
При этом такой вызов не требует никаких изменений в классе Post или PostQuery.
Итого, РНР может быть компактнее и удобнее. Просто не нужно криво переносить продукты с Ruby (или Java) на PHP, а нужно делать свои ноу-хау.
В первом случае будет искаться класс в текущем неймспейсе, во втором для неймспейса создан алиас и тоже всё ок. Любой аутолоадер с таким справится.
Хотя да, схожусь на мысли, что ревность может и должна быть искоренена. Пусть она и заложена на уровне инстинктов, то этот инстинкт как раз можно подавлять.