> А изменится ли что-нибудь при этом в базе, эти тесты не обязательно должны тестировать.
Я бы даже сказал, что они обязательно НЕ должны это тестировать :) И тесты скорее эмулируют не систему, а поведение пользователя системы, ожидая на производимые действия описанных в требованиях реакций.
Контроллеры, как и любой другой класс, отлично «тестируются» модульными тестами. Функциональные тесты — это тестирование черного ящика, т.е. вы взаимодействуете с системой как ее конечный пользователь и ассерты должны быть соответствующие.
Вы хотите просто писать модульные тесты, или практиковать TDD? Если последнее, алгоритм простой:
1. Придумываете фичу.
2. Создаете тест — красная полоска.
3. Пишете минимум кода, чтоб тест прошел.
4. Рефакторинг.
Сначала тест — потом код, как следствие, нет сломанного теста — нет нового кода. И, конечно же, нет требования — нет теста :)
В вашем случае: пишете testSetSomeValue, допустите, что в случае успешной установки значения сеттер должен вернуть истину. Реализуйте метод setSomeValue { return true }, тест пройдет. Пишите тест testGetSomeValue. Т.к. в нем используется сеттер, последний придется изменить, ровно настолько, чтоб прошел новый тест. В итоге у вас два теста, оба нужные т.к. описывают поведение тестируемых методов: сеттер должен вернуть истину после установки значения, значение должно быть доступно через геттер после установки сеттером.
Рекомендую попробовать несколько принципов, в том числе из BDD, которые существенно упрощают написание тестов до кода:
1. Should вместо test — название теста отражает поведение.
2. Один тест — один ассерт.
3. AAA (Arrange — Act — Assert).
P.S. В комментариях обсуждается все что угодно, но только не TDD :)
Правильный ресурс читаете, хотел написать комментарий с ссылкой на него :)
Кстати, Павел и Сергей, основатели эджайлдева, еще в 2005 году читали отменные доклады по XP и TDD на phpconf, лично я очень многое узнал именно благодаря им. Жаль, что у них поменялись интересы в жизни :(
Я писал о моках в контексте проблем, описанных в первом комментарии ветки (т.е. не следует читать «мы у себя отказались от моков» как «мы у себя вообще отказались от моков» :)
Что касается сквозного функционала, вроде упомянутого вами логгера, декораторов, цепочек фильтров и т.д. — тут использование моков, конечно, более чем разумно. Ну и если с помощью инверсии зависимостей пытаться устранить излишнюю связанность в коде, то и в тестах следует придерживаться этого же принципа и, как верно было подмечено, использовать моки.
Мы у себя отказались от моков, а так же от от «дамповых» фикстур т.е. когда данные тем или иным образом напрямую добавляются в БД. Тестовые данные создаем при помощи реальных объектов. Например, в тестах хозяйственной операции проводки создаются просто через класс проводок.
Если вам для какого-нибудь калькулятора или процессора нужен платеж, отправитель, счет — создайте в сетапе эти объекты да используйте в тестах. Чтоб избежать дублирования, связанного с инициализацией тестовых данных, воспользуйтесь паттерном Mother Object либо базовым тестом для группы тестов.
В общем, попробуйте в тестах абстрагировать от БД и работать с данными через классы модели. Интерфейсы довольно постоянны, а реализация меняется очень часто. Поэтому тесты, которые завязаны на реализацию, очень хрупкие. Кстати, когда мы активно использовали моки, они часто хотя бы немного знали о реализации настоящих классов, что тоже только добавляло хрупкости тестам. Насколько мне известно, это проблема, с которой сталкивались не только мы.
Если у вас класс работает с 10 таблицами — это проблема, и решать стоит ее. Любой проект, разрабатываемый по TDD, отличается от остальных большим количеством маленьких классов (до 200 строк) с миниатюрными методами. И вполне очевидно, почему так.
Моки разумно использовать на начальной стадии разработки, когда вам еще нечего предложить классу, кроме мока: интерфейс есть, а реализации нет. Чрезмерное увлечение моками, особенно в отсутствии функциональных тестов, обычно ничем хорошим не заканчивается.
Что касается БД: зачем тестам знать, где и как ваш класс хранит данные? Способ хранения — это детали реализации, а в тестах они раскрываться не должны. Именно поэтому тесты у вас получаются хрупкими.
Практика показывает, что в 90% случаев, если возникают сложности с написанием теста — проблема в архитектуре. Часто решить проблему помогает выделение класса.
BDD — это, фактически, эволюция TDD. В современном понимании (Rspec + Cucumber) с внешним и внутренним циклами пользовать не пробовали, но вот некоторые практики очень успешно применяем в xUnit среде. Хорошая статья на тему.
Если серьезно, на практике это работает следующим образом: аудитор смотрит логи веб-сервера и если не видит там критичных данных (обычно это действительно критичные данные, вроде номера карты, cvv кода, паспортных данных) — все окей. А попадетесь вы, скорее всего, когда будут тестировать на Broken Authentication and Session Management.
В правоохранительных органах считают, что личные данные были выложены в Интернет намеренно. "Очевидно, это делалось специально, кто-то писал скрипты, чтобы достать эти данные из «Яндекса». С какой целью это было сделано — пока не ясно, но вызывает некоторые подозрения тот факт, что это произошло накануне подписания президентом РФ поправок к закону «О персональных данных»
Я бы даже сказал, что они обязательно НЕ должны это тестировать :) И тесты скорее эмулируют не систему, а поведение пользователя системы, ожидая на производимые действия описанных в требованиях реакций.
1. Придумываете фичу.
2. Создаете тест — красная полоска.
3. Пишете минимум кода, чтоб тест прошел.
4. Рефакторинг.
Сначала тест — потом код, как следствие, нет сломанного теста — нет нового кода. И, конечно же, нет требования — нет теста :)
В вашем случае: пишете testSetSomeValue, допустите, что в случае успешной установки значения сеттер должен вернуть истину. Реализуйте метод setSomeValue { return true }, тест пройдет. Пишите тест testGetSomeValue. Т.к. в нем используется сеттер, последний придется изменить, ровно настолько, чтоб прошел новый тест. В итоге у вас два теста, оба нужные т.к. описывают поведение тестируемых методов: сеттер должен вернуть истину после установки значения, значение должно быть доступно через геттер после установки сеттером.
Рекомендую попробовать несколько принципов, в том числе из BDD, которые существенно упрощают написание тестов до кода:
1. Should вместо test — название теста отражает поведение.
2. Один тест — один ассерт.
3. AAA (Arrange — Act — Assert).
P.S. В комментариях обсуждается все что угодно, но только не TDD :)
Кстати, Павел и Сергей, основатели эджайлдева, еще в 2005 году читали отменные доклады по XP и TDD на phpconf, лично я очень многое узнал именно благодаря им. Жаль, что у них поменялись интересы в жизни :(
По делу: если вы нашли время для теории, почитайте там же статьи "Запахи тестового кода" (Чрезмерное доверие мокам, Недостаточное доверие мокам) и "Мок-объекты в модульном тестировании. Как избежать проблем". Там, в принципе, более детально описано все то, что вам писали в комментариях.
Что касается сквозного функционала, вроде упомянутого вами логгера, декораторов, цепочек фильтров и т.д. — тут использование моков, конечно, более чем разумно. Ну и если с помощью инверсии зависимостей пытаться устранить излишнюю связанность в коде, то и в тестах следует придерживаться этого же принципа и, как верно было подмечено, использовать моки.
Если вам для какого-нибудь калькулятора или процессора нужен платеж, отправитель, счет — создайте в сетапе эти объекты да используйте в тестах. Чтоб избежать дублирования, связанного с инициализацией тестовых данных, воспользуйтесь паттерном Mother Object либо базовым тестом для группы тестов.
В общем, попробуйте в тестах абстрагировать от БД и работать с данными через классы модели. Интерфейсы довольно постоянны, а реализация меняется очень часто. Поэтому тесты, которые завязаны на реализацию, очень хрупкие. Кстати, когда мы активно использовали моки, они часто хотя бы немного знали о реализации настоящих классов, что тоже только добавляло хрупкости тестам. Насколько мне известно, это проблема, с которой сталкивались не только мы.
Моки разумно использовать на начальной стадии разработки, когда вам еще нечего предложить классу, кроме мока: интерфейс есть, а реализации нет. Чрезмерное увлечение моками, особенно в отсутствии функциональных тестов, обычно ничем хорошим не заканчивается.
Что касается БД: зачем тестам знать, где и как ваш класс хранит данные? Способ хранения — это детали реализации, а в тестах они раскрываться не должны. Именно поэтому тесты у вас получаются хрупкими.
Если серьезно, на практике это работает следующим образом: аудитор смотрит логи веб-сервера и если не видит там критичных данных (обычно это действительно критичные данные, вроде номера карты, cvv кода, паспортных данных) — все окей. А попадетесь вы, скорее всего, когда будут тестировать на Broken Authentication and Session Management.
О_о