Хочу собрать список наиболее часто встречающихся заблуждений относительно unit testing и примерения принципов TDD/BDD. Поэтому хочу задать вопрос к тем, кто был в ситуации, когда TDD отвергался по каким-либо внутренним причинам (старый проект, нет времени и пр.). Покидайте какие были формулировку против применения TDD и почему? Если получилось вопреки всему убедить использовать TDD тоже было бы интеерсно узнать.

Я тут набросал пока такие утверждения, который сам лично встречал:

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

Здравствуйте, another_coder, Вы писали:

_> Покидайте какие были формулировку против применения TDD и почему?

• Мне 40 лет (почти) и я никогда не использовал юнит тесты.

Здравствуйте, another_coder, Вы писали:

_>Хочу собрать список наиболее часто встречающихся заблуждений относительно unit testing и примерения принципов TDD/BDD. Поэтому хочу задать вопрос к тем, кто был в ситуации, когда TDD отвергался по каким-либо внутренним причинам (старый проект, нет времени и пр.). Покидайте какие были формулировку против применения TDD и почему? Если получилось вопреки всему убедить использовать TDD тоже было бы интеерсно узнать.

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

p.s. только это не заблуждение, а вполне объективная причина

Здравствуйте, another_coder, Вы писали:

_>Хочу собрать список наиболее часто встречающихся заблуждений относительно unit testing и примерения принципов TDD/BDD.

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

Сколько я читал статей/блогов, сколько видел скринкастов/видео по теме TDD, там всегда автор(ы) бойко объяснял азы юнит-тестирования, после чего лихо писал какой-либо тест, а потом — внимание! — копипастил уже готовый код из предыдущего проекта! Ну и прогонял тест на нём.

Невозможно написать тест на ещё не написанный код. Без исключений!

Конечно, я сам могу назвать два случая, когда можно написать сперва тест:

1. Вышеупомянутый случай: имеется ранее написанный проект (написанный, возможно, без TDD), и в новом проекте мы используем наработки из предыдыщего проекта(ов), лишь с небольшими изменениями. В таком случае да, можно сразу писать тест, ибо нам уже известен процентов на 90% рабочий код.
   
   
2. Вариант, когда сначала проводится тщательнейшее проектирование, в UML-диаграммах или прочих CASE-средствах описывается всё поведение и взаимодействие. Ну то есть по сути опять-таки проект пишется полностью, и остаётся лишь механически перевести его в код. Вот тут-то можно, после этой стадии проектирования, написать тесты, а следом код.

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

Здравствуйте, koodeer, Вы писали:

K>Невозможно написать тест на ещё не написанный код. Без исключений!

Насколько я понимаю TDD, тесты пишутся в первую очередь не для проверки правильности написанного кода, а для определения чего мы вообще хотим написать. По мне так это скорее такой практико-ориентированный подход к проектированию. Когда задача есть, а кода нет и не понятно толком, с какого конца начинать его проектировать и писать, то взять и начать использовать еще не написанный код — это как раз неплохой способ определиться (и избежать overarchitecturing).
Другой вопрос, что некоторые адепты TDD советуют писать тест на каждый чих, а не только на мутные места. Это явный перебор.

Здравствуйте, VTT, Вы писали:

VTT>Другой вопрос, что некоторые адепты TDD советуют писать тест на каждый чих, а не только на мутные места. Это явный перебор.

Тут еще такая проблема, что TDD/unit testing — он везде разный. Ну т.е. есть какая-то там классика, но я никогда не видел, что бы она была реализована где-то кроме очередного калькулятора от евангелистов. В результате получаются забавные диалоги:

- Мы не исспользуем TDD/BDD/unit testing, по-моему это чепуха какая-то.
— Да вы что?! В XXI веке, как можно не исспользовать? Это так классно, поверте, это реально работает!
— Что, вы правда практикуете? Уважаю... Нет, ну что, серьёзно test first и вот это вот всё?
— Не, ну не совсем... обычно всё-таки сначала конечно утрясается интерфейс класса, а к этому моменту он, в принципе, уже практически написан...
— А вот эти все бесконечные write-only моки, которые без бутылки не осилишь, заглушки-прокси-интерфейсы... Жуть же как неудобно.
— Да не, это только в пиковых случаях, а так у нас тесты прямо в БД лазят и так далее.
— А вам не лень всё это тестами покрывать? Ну реально же половина кода "достал из базы, перегнал в DTO и отдал". Ну что там тестировать?
— Конечно такое мы тестами не покрываем, только какой-то нетривиальный код... Процетнов 10% наверное.
— А, ну тогда и мы TDD/BDD/unit testing исспользуем.

Здравствуйте, Yoriсk, Вы писали:

Y>Здравствуйте, VTT, Вы писали:

Y>Тут еще такая проблема, что TDD/unit testing — он везде разный. Ну т.е. есть какая-то там классика, но я никогда не видел, что бы она была реализована где-то кроме очередного калькулятора от евангелистов. В результате получаются забавные диалоги:

Y>

Y>- Мы не исспользуем TDD/BDD/unit testing, по-моему это чепуха какая-то.
Y>- Да вы что?! В XXI веке, как можно не исспользовать? Это так классно, поверте, это реально работает!
Y>- Что, вы правда практикуете? Уважаю... Нет, ну что, серьёзно test first и вот это вот всё?
Y>- Не, ну не совсем... обычно всё-таки сначала конечно утрясается интерфейс класса, а к этому моменту он, в принципе, уже практически написан...
Y>- А вот эти все бесконечные write-only моки, которые без бутылки не осилишь, заглушки-прокси-интерфейсы... Жуть же как неудобно.
Y>- Да не, это только в пиковых случаях, а так у нас тесты прямо в БД лазят и так далее.
Y>- А вам не лень всё это тестами покрывать? Ну реально же половина кода "достал из базы, перегнал в DTO и отдал". Ну что там тестировать?
Y>- Конечно такое мы тестами не покрываем, только какой-то нетривиальный код... Процетнов 10% наверное.
Y>- А, ну тогда и мы TDD/BDD/unit testing исспользуем.

Это скорее общая проблема злоупотребления buzzword-ами.

Здравствуйте, another_coder, Вы писали:

_>Хочу собрать список наиболее часто встречающихся заблуждений относительно unit testing и примерения принципов TDD/BDD. Поэтому хочу задать вопрос к тем, кто был в ситуации, когда TDD отвергался по каким-либо внутренним причинам (старый проект, нет времени и пр.). Покидайте какие были формулировку против применения TDD и почему? Если получилось вопреки всему убедить использовать TDD тоже было бы интеерсно узнать.


Нестабильная кодовая база, мало разработчиков.

Здравствуйте, VTT, Вы писали:

VTT>Здравствуйте, koodeer, Вы писали:

K>>Невозможно написать тест на ещё не написанный код. Без исключений!

VTT>Насколько я понимаю TDD, тесты пишутся в первую очередь не для проверки правильности написанного кода, а для определения чего мы вообще хотим написать. По мне так это скорее такой практико-ориентированный подход к проектированию. Когда задача есть, а кода нет и не понятно толком, с какого конца начинать его проектировать и писать, то взять и начать использовать еще не написанный код — это как раз неплохой способ определиться (и избежать overarchitecturing).
VTT>Другой вопрос, что некоторые адепты TDD советуют писать тест на каждый чих, а не только на мутные места. Это явный перебор.

Именно к этому заключению и пришёл в итоге, после чтения всех этих "test first" и раздумий "а оно мне надо?". Т.е. тестируем не методы, а сценарии использования. Создали чистый объект, при необходимости перевели его в нужное состояние (через SetUp), прогнали сценарий с контролем точек состояния. Осетры не упали? Тест пройден. Упал какой-то осётр? Делаем разбор полётов. Потребность в моках автоматически приводит к необходимости Dependency Injection, что для большого проекта тоже окупится сторицей (нет этих уродливых singleton<t>.getInstance, намазанных на код как икра на бутерброд).

А вся эта катавасия с тестированием вплоть до геттеров-сеттеров и приватных методов — оверкил, нужный ровно в одном случае: если логика геттера/сеттера предполагает вариативность, исходя из внутреннего состояния объекта. Тогда да, пишем на каждый стейт по тесту (ибо это и есть сценарий "прочитать данные, если объект в состоянии X"). Что ещё хорошо — если состояний известное число, то можно для создания тест-кейсов сделать кодогенерацию (которую я очень люблю), любым способом вплоть до T4 (который я очень не люблю по причине его студенческой наивности а-ля "сперва грузим всё в память" и вытекающих отсюда глюков на промышленных объёмах).

Здравствуйте, VTT, Вы писали:

VTT>Это скорее общая проблема злоупотребления buzzword-ами.

Проблема злоупотребления buzzword-ами возможна если buzzword не имеет чётких признаков.
С ТDD ситуация ровно обратная, чёткие определения, методики, схемы и так далее. Так что проблема тут в другом.

Здравствуйте, another_coder, Вы писали:

_>Хочу собрать список наиболее часто встречающихся заблуждений

А ты с каких пор считаешь, что утверждаешь здесь истину? Для тебя Земля — плоская, и ты решил подсобрать побольше доказательств? Ну-ну, "герой", видимо слился ты в других спорах — прибежал за новыми аргументами?

Здравствуйте, btn1, Вы писали:

B>Здравствуйте, another_coder, Вы писали:

_>>Хочу собрать список наиболее часто встречающихся заблуждений

B>А ты с каких пор считаешь, что утверждаешь здесь истину? Для тебя Земля — плоская, и ты решил подсобрать побольше доказательств? Ну-ну, "герой", видимо слился ты в других спорах — прибежал за новыми аргументами?
Анонировать идите в другое место.

Спасибо всем откликнувшимся. Я собираю эту информацию для своей лекции по TDD. Мне еще предстоит изучить все ответы. Пока, если несложно, можете ответить еще в этой Гугл форме клик

Здравствуйте, another_coder, Вы писали:

По TDD вам похоже написали уже. Касательно BDD я заметил следующие несколько заблуждений:

1. Specflow сценарии предназначены исключительно для упрощения читаемости тестов. Это утверждение содержит в себе долю истины. Читать specflow сценарии действительно проще. Все таки это одна из причин их появления. Но если мы чисто механически начнем писать наши тесты на естественном языке это не даст большого положительного результата. Скорее наоборот, команда будет разочарована и забросит Specflow. На практике этим страдают в первую очередь программисты. Сценарии превращаются в набор "инструкций" на естественном языке, причем прочитать его может кто угодно — аналитик, тестировщик, заказчик, но понять и вникнуть только программисты.

2. Specflow сценарии как замена тестировщиков. Здесь сценарии становятся слишком подробными и не имеют единой цели, единого бизнес правила. Например, вы хотите проверить что при удалении файла в Windows он попадает в корзину. А сценарий у вас проверяет еще, что после удаления файла меню Пуск на месте, системные часы не перевелись, цвет рабочего стола остался таким же каким и был, иконки с рабочего стола не исчезли, программы не удалились и т.д. и т.п. Т.е. вместо небольшого и емкого бизнес правила вы получаете огромный сценарий, который сложно понять и вникнуть что же именно это такое. Страдают этим в первую очередь тестировщики.

3. Specflow сценарии как замена требований. Часто говорят, а зачем нам требования? Напишем ключевые сценарии, реализуем их, и не будем писать требования вовсе. На самом деле требования необходимы, а сценарии выступают лишь как иллюстрация к требованиям. Они позволяют с одной стороны найти логические ошибки в требованиях на ранней стадии, а с другой стороны получить acceptance criteria.