Я тоже считаю, что в написании тестов для геттеров и сеттеров есть смысл, ибо тесты — это документация. Тот тривиальный тест, который я сейчас напишу на геттер или сеттер явным образом укажет, что именно такое поведение ожидается от этих геттеров и сеттеров. Если не написать такой\такие тест\тесты, то пришедший на смену меня программист изменит их поведение, усложнив их, и тесты могут и не провалиться (которые, якобы, должны их косвенно тестировать).
А за что мне минусы? Ещё и в карму? Вы почитайте, хоть, я не знаю, Википедию. Лучше наших жили только рабочие Америки.
Или из-за жидов? Так жиды — не евреи, если кто не в курсе.
Я вообще вот что скажу. TDD, ИМХО, это не формализованный механизим разработки ПО от А до Я. Это свод рекомендаций, принципов и практик, которые могут быть иногда нарушены, если того требует ситуация. Если есть кусок, тесты под который поддерживать сложнее и дороже, чем просто тупо протыкать кнопки в рантайме, то зачем такие тесты?
Над их библиотеками у меня есть фасад со своим интерфейсом. Мне придётся изменить только фасад.
Ну, разумеется, если только они вообще не перекроят полностью свои интерфейсы. Но такие вещи — от лукавого. TDD не предполагает изменений всего и вся. При TDD нужно пользоваться головой. Опять же, TDD не предполагает, что посредь разработки будут доменный уровень изменять. И так далее, какие-то вещи должны быть железобетонными.
Менять доменный уровень — это полностью другое приложение. Если приходится менять доменный уровень — то либо были допущены ошибки при анализе предметной области, либо надо писать другое приложение (новое).
Есть случаи, когда доменная область является нестабильной, как в банковской сфере, где может быть 1001 «особый клиент» не удовлетворяющий общей бизнес-логике домена. Но это особый случай. Как с этим бороться у меня опыта нет.
Для меня сложный сетап — это интеграционный сетап. А для моков я не встречал сложного сетапа (ну, это просто лично мой опыт).
Сложный сетап — это когда я прошу прицепить к серверу реально работающее устройство, чтобы тесты интеграционные проходили. Для такого сетапа мне официальный запрос в организации писать надо :)
Хм, странно. Нет, я пишу тесты, используя моки (но не везде!). Ну, вот, например, мой последний проект: старт приложения проходит n-е количество этапов. Эти этапы зависят от библиотек моих коллег, которые общаются с устройствами. Для того, чтобы протестировать всю логику запуска приложения мне пришлось сконфигурировать моки как надо, но после того как я их сконфигурил — я их больше не трогаю.
Кстати, не всегда удобно использовать моки, иногда удобнее написать действительно интеграционный тест, зависящий от внешней среды. Бывает так, что настроить такую интеграционность проще, чем настроить моки.
Для юнит-тестов не надо ничего сетапить. Как только речь заходит о сетапах — это уже не юнит-тест.
Юнит-тест — это не функция, покрытая атрибутом [Test] или [TestMethod] (в .NET).
Юнит-тест — это тест, обладающий рядом характеристик:
1. Повторяемость
2. Независимость
3. Полнота
4. Поддерживаемость
5. Быстрота
6. Читаемость
Как только появляется полносью не замокнутое внешнее окружение, то тест — уже не юнит-тест.
Кстати, сейчас прочитал ваш комментарий ещё раз. Хотелось бы уточнить, что вы имели ввиду под «актуализировать мокнутое окружение тестируемого класса»?
Почему все считают TDD тяжёлой практикой? Это обычное написание кода. Просто более надёжного. Больше писать? Ну, да, писать больше, но разве кого-то пугает количество писанины при наличии таких инструментов, которыми мы обладаем? (например, VS+R#) А раз количество писанины это больше не проблема, то проблема в качестве. А чтобы достичь хорошего уровня качества мы применяем TDD.
TDD тормозит только если ваша кодовая база пару тысяч строк, т.е крайне небольшой проект. Там можно и без тестов обойтись, в крайнем случае, потом тестов накидать. Если у вас большой проект (over 30k строк), то TDD не тормозит, выбросьте этот миф из головы.
Совсем другое дело, что люди не понимают как применять TDD на больших проектах. А всё потому, что кроме TDD надо разбираться как минимум в Agile Modeling. Без Agile Modeling, TDD может привести к тяжёлым дефектам, начиная с середины проекта.
Дядя действительно очень крут. Но я согласен насчёт пиара. Действительно, нужно включать свою голову и смотреть на свою ситуацию, а не слепо следовать всему, что скажет Дядя Боб или Рой Ошероув. Абсолютных истин в программировании катастрофически мало (если они вообще есть в программировании).
Или из-за жидов? Так жиды — не евреи, если кто не в курсе.
Ну, разумеется, если только они вообще не перекроят полностью свои интерфейсы. Но такие вещи — от лукавого. TDD не предполагает изменений всего и вся. При TDD нужно пользоваться головой. Опять же, TDD не предполагает, что посредь разработки будут доменный уровень изменять. И так далее, какие-то вещи должны быть железобетонными.
Менять доменный уровень — это полностью другое приложение. Если приходится менять доменный уровень — то либо были допущены ошибки при анализе предметной области, либо надо писать другое приложение (новое).
Есть случаи, когда доменная область является нестабильной, как в банковской сфере, где может быть 1001 «особый клиент» не удовлетворяющий общей бизнес-логике домена. Но это особый случай. Как с этим бороться у меня опыта нет.
Сложный сетап — это когда я прошу прицепить к серверу реально работающее устройство, чтобы тесты интеграционные проходили. Для такого сетапа мне официальный запрос в организации писать надо :)
Кстати, не всегда удобно использовать моки, иногда удобнее написать действительно интеграционный тест, зависящий от внешней среды. Бывает так, что настроить такую интеграционность проще, чем настроить моки.
Юнит-тест — это не функция, покрытая атрибутом [Test] или [TestMethod] (в .NET).
Юнит-тест — это тест, обладающий рядом характеристик:
1. Повторяемость
2. Независимость
3. Полнота
4. Поддерживаемость
5. Быстрота
6. Читаемость
Как только появляется полносью не замокнутое внешнее окружение, то тест — уже не юнит-тест.
Кстати, сейчас прочитал ваш комментарий ещё раз. Хотелось бы уточнить, что вы имели ввиду под «актуализировать мокнутое окружение тестируемого класса»?
Совсем другое дело, что люди не понимают как применять TDD на больших проектах. А всё потому, что кроме TDD надо разбираться как минимум в Agile Modeling. Без Agile Modeling, TDD может привести к тяжёлым дефектам, начиная с середины проекта.