Ну тогда ок, почти коллеги )
Мне вот не нравится, что игнорируя все хорошие фишки РНР сообщество пытается создать некую видимость ентерпрайса. Конечно, хорошо, что библиотеки становятся стандартизироваными, чем-то похожими, но плохо, что количество фреймворков до сих пор не дает нужную легкость в разработке.
Да, сам язык такой ентерпрайс… Без много поточности, без нативной поддержки utf, без возможности писать что-либо серьезное помимо веб-приложений. Python и Ruby гораздо больший ентерпрайс, но почему-то вот не пытаются копировать в себе Джаву. При этом, есть и JRuby, IronRubym JPython,… То есть эти языки поддерживаются на ентерпрайс уровне без каких-либо синтаксмических или фреймворковых нововведений.
Если вы считаете, что наличие аннотаций, dependency injection, namespaces делает язык ентерпрайсом вы крайне ошибаетесь. Это просто независимые вещи. А вот то, что PHP в гонитве за статусом и пытается стать недоджавой, это печально.
Ну как бы проблема пока есть. Например, вводишь название класса Command. Он раскрывается в длиннючую малочитабельную строку \Symfony\Component\Console\Command\Command.
Альтернатива — прописовть все используемые классы в начале файла. Но это шаг назад, имхо.
Честно, я не очень, разбирался в DbUnit, но скорее всего, для MySQL там хорошего решения нет. Ибо тут необходимы вложенные транзакции или их эмуляция. Эмулировать транзакции можно, если транзакциями занимается не PDO, а некая обертка над ним. Она может следить, является ли эта транзакция последней, и только тогда делать rollback или commit.
Такие вещи реализованы в Doctrine, Doctrine 2 DBAL. И не реализованы, в том же Zend_Db, хотя там достаточно простой патч и висит у них в багтрекере ещё с 2007го. Почему? Непонятно.
Один из самых важных критериев для юнит-тестов это скорость выполнения. А очистка базы, скорее всего, будет самой медленной операцией. Например, на MageConf упоминали, что в Magento несколько тысяч юнит-тестов, которые выполняются за одну минуту. Такая скорость достигнута только за счет транзакций. Без них, сами понимаете, время выполнения будет гораздо длиннее.
В любом случае, лучше если есть возможность, вообще не заниматься очисткой БД в рамках юнит-тестов. Используйте транзакции. Учитывая, что в MySQL нет вложенных транзакций, то важно, чтобы у вас был какой-то слой абстракции над PDO, который мог бы вести учет транзакций и откатывать только самую последнюю из них.
Вот собственно из-за столь неочевидных методов тестирования БД, я и написал Codeception. В нем тестирование БД проводится всего лишь подключением модуля Db, и указания файла с дампом. При использовании ОРМ в проекте, базу вообще можно не очищать, а выполнять тесты в транзакции, и откатывать их в конце.
Как по мне, то задача тут достаточно проста. А решается в PHPUnit она, как видно даже с этого поста, излишне сложно. И DbUnit это инструмент для усложнения жизни, а не эффективного тестирования. имхо.
Вкратце в чем тут проблема. Много тестов ради самих тестов. Ну вот допустим:
$this->assertTrue($model->saveData()); //записали данные
$this->assertTrue($model->loadData()); //прочитали данные
Если ваша функция loadData не будет ничего загружать тест всё равно пройдет. Ибо данные и так есть в объекте. Как минимум стоит загружать данные для другого объекта.
Мне вот не нравится, что игнорируя все хорошие фишки РНР сообщество пытается создать некую видимость ентерпрайса. Конечно, хорошо, что библиотеки становятся стандартизироваными, чем-то похожими, но плохо, что количество фреймворков до сих пор не дает нужную легкость в разработке.
use \Symfony\Component\Console\Command\Command.
Малозначащая и бессмысленная лишняя строка. И таких будет много.
Я к тому, что, как минимум вариант
use \Symfony\Component\Console\*
нужно было предусмотреть.
Если вы считаете, что наличие аннотаций, dependency injection, namespaces делает язык ентерпрайсом вы крайне ошибаетесь. Это просто независимые вещи. А вот то, что PHP в гонитве за статусом и пытается стать недоджавой, это печально.
Альтернатива — прописовть все используемые классы в начале файла. Но это шаг назад, имхо.
Такие вещи реализованы в Doctrine, Doctrine 2 DBAL. И не реализованы, в том же Zend_Db, хотя там достаточно простой патч и висит у них в багтрекере ещё с 2007го. Почему? Непонятно.
Как по мне, то задача тут достаточно проста. А решается в PHPUnit она, как видно даже с этого поста, излишне сложно. И DbUnit это инструмент для усложнения жизни, а не эффективного тестирования. имхо.
Но подозреваю, что имелось ввиду Sass/Scss.
Подозреваю, что в Netbeans, Eclipse разрабатывать будет так же удобно )
Codeception покрыт тестами. Они через CI-сервер гоняются под линуксом с использованием Selenium, MySQL, Sqlite и в PHP 5.3, 5.4.
вот так пройдет. Также хорошо было б показать, что между тестами данные стоит очищать. Тест не должен «мусорить».
Если ваша функция loadData не будет ничего загружать тест всё равно пройдет. Ибо данные и так есть в объекте. Как минимум стоит загружать данные для другого объекта.