Применение тест-ориентированной разработки в тесно связанной архитектуре

Question

Я недавно изучал TDD, посетил конференцию и несколько раз пробовал пройти тесты, и я уже на 100% продан, мне очень нравится TDD.

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

Проблема в том, что наша система развивалась со времен VB6 до .NET и реализует много устаревших технологий и некоторые далекие от лучших методов разработки, то есть много бизнес-логики в коде ASP.NET и клиентском скрипте. Однако самая большая проблема заключается в том, как наши классы тесно связаны с доступом к базе данных; свойства, методы, конструкторы - обычно имеет доступ к базе данных в той или иной форме.

Мы используем собственный генератор кода доступа к данным, который создает sqlDataAdapters, который дает нам весь доступ к базе данных, который мы когда-либо хотели, что помогает нам разрабатывать очень быстро, однако классы на нашем бизнес-уровне очень тесно связаны с этими данными слой - мы даже не близки к реализации какой-либо формы дизайна хранилища. Это и вышеперечисленные проблемы создали мне всевозможные проблемы.

Я пытался разработать некоторые модульные тесты для некоторых существующих классов, которые я уже написал, но тесты занимают ОЧЕНЬ больше времени, так как требуется доступ к БД, не говоря уже о том, что мы используем инфраструктуру MS Enterprise Caching, которую я вынужден подделать httpcontext для успешного выполнения моих тестов, что непрактично. Кроме того, я не понимаю, как использовать TDD для разработки новых классов, которые я пишу, поскольку они должны быть так тесно связаны с базой данных ... помогите!

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

У кого-нибудь есть предложения, как мне реализовать TDD с ограничениями, с которыми я связан? Или мне нужно протолкнуть шаблон проектирования репозитория до глубины души и сказать им, что мы либо изменим нашу методологию архитектуры / разработки, либо вообще забудем о TDD? :)

Спасибо

Answer 1

Просто чтобы прояснить, разработка через тестирование и модульное тестирование - это не одно и то же.

• TDD = Напишите ваши тесты перед вашим кодом.
• Юнит-тестирование = Написание тестов, подтверждающих работу небольшого блока кода.
• Интеграционное тестирование = Написание тестов, подтверждающих совместную работу блоков кода.

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

Вы можете написать модульные тесты для существующего кода, но это не то же самое, что делать TDD.

Тесты, которые вы описали (доступ к базе данных и т. Д.), Являются технически интеграционными тестами. Интеграционные тесты обычно занимают много времени. Настоящий модульный тест будет просто проверять код уровня DA без фактического доступа к базе данных. Истинное модульное тестирование требует интерфейсов для тестирования, чтобы вы могли изолировать блоки от окружающих блоков.

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

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

Короче говоря - не пытайтесь изменить методологию для существующего кода. Просто сделайте новый код лучше.

Answer 2

Nitpick: вы не можете выполнить Test- Driven Проектирование существующего кода, но я понимаю, что вы хотите использовать TDD против новых функций, которые вы реализуете на существующей кодовой базе.

Лучшее, что вы можете сделать, - это постепенно ввести швы в базу кода, защищая вас от тесно связанного кода, уже существующего.

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

Answer 3

Я думаю, что тот факт, что вы используете ASP.NET Web Forms, поставит под сомнение ваш путь к TDD. Это просто кошмар для насмешки над Session / ViewState / HTTPContext в веб-формах, поэтому тестирование является почти помехой. Конечно, существует альтернатива ASP.NET MVC, но вы, кажется, уже далеко. Другой многообещающий вариант для парадигмы веб-форм - ASP.NET Web Forms MVP , но этот проект еще не полностью завершен. Я перевожу все, что могу, в MVC; Другой вариант для TDD с веб-формами, Selenium , на самом деле не является TDD, как должно быть.

Answer 4

Для добавления тестов в существующий код вы можете проверить Эффективная работа с устаревшим кодом . «Устаревший код» определяется как код, в котором нет тестов.