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

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

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

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

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

Я попытался разработать некоторые модульные тесты для некоторых существующих классов, которые я уже написал, но тесты требуют LOT дольше, чем нужно, поскольку требуется доступ к db, не говоря уже о том, что мы используем структуру кэширования MS Enterprise. Я вынужден подделать httpcontext для моих тестов, чтобы успешно работать, что нецелесообразно. Кроме того, я не вижу, как использовать TDD для управления дизайном любых новых классов, которые я пишу, поскольку они должны быть так тесно связаны с базой данных... help!

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

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

Спасибо

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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