Каковы пределы TDD? [закрытый]

Мне интересно, какой фреймворк / язык вы используете для своего TDD, если вы еще не достигли самых очевидных мест, где это сложно:

• GUI - Определенные среды и платформы в частности, веб-формы Windows Forms и ASP.NET страдают от практической нестабильности, поскольку нет простого способа изолировать или высмеять их поведение. В этом отношении это одна из главных движущих сил ASP.NET MVC.

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

• Принятие - Даже если вы хорошо разбираетесь в TDD, это непростая попытка заставить других разработчиков - гораздо меньше целых цехов разработки - использовать его. , Многие просто не видят пользы; они легко отключаются при начальных крутых кривых обучения и производительности. Вы столкнетесь со случаями, когда вы будете единственным, кто практикует TDD в своем проекте, и даже если вы будете применять его, другие разработчики будут вводить некачественные, бессмысленные тесты. Эта нетехническая причина - самое большое препятствие для использования TDD в реальных производственных системах, с которым я столкнулся, и это болезненное осознание, когда вы хорошо осведомлены о преимуществах.

У вас есть некоторые затраты на выполнение TDD:

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

Мне нравится TDD для многих вещей. Имейте в виду, что приведенная выше стоимость обслуживания для поддержания рабочих модульных тестов может означать, что, хотя ваш код стал более модульным, выбранную модульную организацию сложнее изменить. Вы не можете реорганизовать свой код без дополнительных затрат на переписывание всех ваших модульных тестов. Это действительно большой предел, который я нашел с TDD. Позже, когда вы поймете, что совершили ошибку, теперь у вас есть все эти накладные расходы, которые вы должны пройти, чтобы реорганизовать вещи, тогда как раньше эти изменения могли произойти гораздо более плавно. Итак, чтобы правильно использовать TDD, я бы сказал, что вам нужно принимать правильные решения при первой разработке модуля. Не всегда легко в изменяющемся, гибком мире, в котором мы живем;).

Также подумайте:

• Не все может быть чисто проверено с помощью методов классов. То есть метод, результат которого зависит от того, сколько именно микросекунд прошло с момента его последнего вызова. Вам нужно добавить хуки, чтобы контролировать, сколько времени прошло, и посмотреть, получите ли вы правильный ответ.
• Модульное тестирование действительно не подходит для всего. Проверка того, пригоден ли GUI для использования людьми, на самом деле никогда не может быть проверена с помощью unittest.

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

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

Попробовать заводную графику Вы получаете автоматически сгенерированные тесты.

Каждый раз, когда вы автоматически создаете класс контроллера, генерируется класс модульных тестов.

Из книги «Полное руководство к Grails»:

Grails разделяет тесты на «юнит» и «Интеграционные» тесты. Интеграционные тесты Вся среда, включая базу данных и, следовательно, имеет тенденцию работать медленнее. К тому же, интеграционные тесты, как правило, предназначены для проверки взаимодействия между несколькими классами и поэтому требуется более полное приложение, прежде чем вы сможете запустить их. Модульные тесты, с другой стороны, являются быстрыми тестами, но они требуют от вас использование издевательств и окурков. Заглушки - это классы, используемые в тестировании, которые имитируют реальное поведение методы, возвращающие произвольные жестко закодированные значения. По сути, издевательства делают то же самое, но проявлять немного больше интеллекта, имея «ожидания». Например, макет может указать, что он «ожидает», что данный метод будет вызван по крайней мере один раз или даже десять раз, если потребуется.