Лучшая практика Symfony unit test - PullRequest
Новая
       13

Лучшая практика Symfony unit test

4 голосов
/ 25 февраля 2011

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

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

Теперь я ищу способ написать один прибор на единицу теста.

Теоретически, я думаю, что нет никаких проблем.Скажите, если я ошибаюсь.

Моя проблема в том, как я могу гарантировать, что приборы будут обновлены.Я не хочу менять все приборы, если я изменяю схему базы данных.Это должно быть возможно, если какие-либо изменения схемы вносятся с помощью Migration.

Есть ли для этого какие-либо инструменты?

1 Ответ

5 голосов
/ 26 февраля 2011

Я считаю, что лучше использовать отдельный файл фикстуры для каждого тестового файла.Этот подход имеет несколько преимуществ:

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

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

Добавление нового поля не должно нарушать ваши существующие тесты ИМХО.Вы должны сделать так, чтобы все тесты все еще проходили.Если вам нужно изменить поведение, сначала обновите тесты, сделайте их неудачными, а затем пропустите их.

...