Применение Разработки через тестирование к сильно связанной архитектуре
Я недавно изучал TDD, присутствовал на конференции и баловался немногими тестами, и уже я - проданных 100%, я абсолютно люблю его TDD.
В результате я повысил это со своими старшими, и они готовы дать ему шанс, таким образом, они определили задачу для меня с предложением способа реализовать TDD в разработке нашего корпоративного продукта.
Проблемой является наша система, развился со дней VB6 к.NET и реализует большую технологию прежней версии и некоторых далеко от методов разработки лучшей практики т.е. большой бизнес-логики в коде ASP.NET позади и клиентском сценарии. Самая большая проблема однако состоит в том, как наши классы сильно связываются с доступом к базе данных; у свойств, методов, конструкторов - обычно есть некоторый доступ к базе данных в некоторой форме или другом.
Мы используем внутренний инструмент генератора кода доступа к данным, который создает sqlDataAdapters, который дает нам весь доступ к базе данных, который мы могли когда-либо хотеть, который помогает нам разработать чрезвычайно быстро, однако, классы в нашем бизнес-слое очень сильно связаны с этим слоем данных - мы даже не близко к реализации некоторой формы дизайна репозитория. Это и проблемы выше создали меня все виды проблем.
Я попытался разработать некоторые модульные тесты на некоторые существующие классы, которые я уже записал, но тесты берут НАМНОГО дольше для выполнения, так как доступ дб требуется, не говоря уже о том, так как мы используем MS Enterprise, Кэширующую платформу, которую я вынужден фальсифицировать httpcontext для своих тестов для выполнения успешно, который не практичен. Кроме того, я не вижу, как использовать TDD для управления дизайном любых новых классов, которые я пишу, так как они должны быть так сильно связаны к базе данных... на помощь!
Из-за архитектуры системы кажется, что я не могу реализовать TDD без некоторого реального взлома, который в моих глазах просто побеждает цель TDD и огромных преимуществ, которые идут.
У кого-либо есть какие-либо предложения, как я мог реализовать TDD с ограничениями, с которыми я связываюсь? Или я должен продвинуть шаблон разработки репозитория вниз мои горла старших и сказать им нас или изменить нашу архитектуру/методологию разработки или забыть о TDD в целом?:)
Спасибо
4 ответа
Просто для уточнения: разработка на основе тестирования и модульное тестирование - это не одно и то же.
- TDD = писать тесты до кода.
- Unit Testing = написание тестов, которые подтверждают работоспособность небольшой части кода.
- Интеграционное тестирование = Написание тестов, подтверждающих, что блоки кода работают вместе.
TDD, по определению, не может быть выполнено на существующем коде. Вы уже разработали код, поэтому вы не собираетесь разрабатывать его снова. TDD означает, что вы сначала пишете неудачный тест, а затем пишете достаточно кода, чтобы пройти тест. Вы уже написали код, поэтому вы не можете заниматься TDD.
Вы можете написать модульные тесты для существующего кода, но это не то же самое, что TDD.
Тесты, которые вы описали (доступ к базе данных и т.д.), технически являются интеграционными тестами. Интеграционные тесты обычно занимают много времени. Настоящий модульный тест будет проверять только код уровня DA без фактического доступа к базе данных. Настоящее модульное тестирование требует интерфейсов для тестирования, чтобы вы могли изолировать модули от окружающих модулей.
Очень трудно правильно протестировать существующий код, если только он не был хорошо разработан с учетом интерфейсов и абстракции.
Я знаю, что немного придираюсь к терминологии, но это важно, когда речь идет о том, какой подход вы можете использовать. Мой совет заключается в том, что для существующего кода, который не очень хорошо абстрагирован, вы должны постепенно создавать набор автоматизированных интеграционных тестов. Когда вы придете к написанию чего-то нового (это может быть не целый проект, а просто новая часть существующего приложения), подумайте о том, чтобы подойти к этому в стиле TDD. Для этого вам понадобится написать некоторые интерфейсы и абстракции, которые позволят вам проводить TDD на новом коде, не затрагивая слишком много существующего кода. Затем вы сможете написать несколько интеграционных тестов, которые проверят работу вашего нового кода со старым.
Короче говоря, не пытайтесь изменить методологию для существующего кода. Просто делайте новый код лучше.
Я думаю, что сам факт использования веб-форм ASP.NET, ваш путь к TDD будет затруднен. Это просто кошмар - издеваться над Session / ViewState / HTTPContext в веб-формах, поэтому тестирование на основе тестирования - это почти помеха. Конечно, есть альтернатива ASP.NET MVC, но, похоже, вы уже в пути. Другой многообещающий вариант парадигмы веб-форм - это ASP.NET Web Forms MVP , но этот проект еще не полностью сформирован. Я перемещаю все, что могу, в MVC; другой вариант для TDD с веб-формами, Selenium , на самом деле не TDD, каким он должен быть.
Nitpick: вы не можете делать Test- Driven Design на существующем коде, но я понимаю, что вы хотите использовать TDD против новые функции, которые вы реализуете на существующей кодовой базе.
Лучшее, что вы можете сделать, - это постепенно ввести стыков в кодовую базу, защищая вас от уже существующего тесно связанного кода.
Книга Эффективная работа с унаследованным кодом содержит много полезных советов о том, как превратить унаследованное приложение в тестируемое.
Для добавления тестов в существующий код, вы можете посмотреть Working Effectively With Legacy Code. Под "устаревшим кодом" понимается код, в котором нет тестов.