Возможно ли внедрить разработку через тестирование (TDD) в зрелом проекте?[закрыто]

Question

• Допустим, мы слишком поздно осознали ценность TDD.Проект уже сформировался, им начали пользоваться многие клиенты.
• Скажем, используемое автоматизированное тестирование в основном представляет собой функциональное/системное тестирование, и существует много автоматизированного тестирования графического пользовательского интерфейса.
• Допустим, у нас есть запросы на новые функции и новые отчеты об ошибках (!).Так что хорошее развитие все еще продолжается.
• Обратите внимание, что уже будет много бизнес-объектов без модульного тестирования или с небольшим его количеством.
• Слишком тесное сотрудничество/отношения между ними, что опять-таки проверяется только посредством функционального/системного тестирования более высокого уровня.Никакого интеграционного тестирования как такового.
• Большие базы данных с множеством таблиц, представлений и т. д.Просто для создания экземпляра одного бизнес-объекта уже приходится совершать множество обходов базы данных.

Как мы можем внедрить TDD на данном этапе?

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

Означает ли это, что TDD — подходящая методология только для начала с нуля?Мне интересно услышать о возможных стратегиях внедрения TDD в уже зрелый продукт.

Answer 1

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

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

Answer 2

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

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

Если у вас есть ошибка, напишите модульный тест, чтобы воспроизвести ее, рефакторируя код по мере необходимости (если только усилия действительно не стоят того).

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

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

Answer 3

Да, ты можешь.Судя по вашему описанию, проект находится в хорошей форме - большое количество автоматизации функциональных тестов - это путь!В некоторых аспектах это даже более полезно, чем модульное тестирование.Помните, что TDD != модульное тестирование — это короткие итерации и четкие критерии приемки.

Помните, что наличие существующего и принятого проекта на самом деле упрощает тестирование: работающее приложение — это лучшая спецификация требований.Таким образом, вы находитесь в лучшем положении, чем тот, у кого есть просто клочок бумаги для работы.

Просто начните работать над новыми требованиями/исправлениями ошибок с помощью TDD.Помните, что смена методологии потребует дополнительных затрат (убедитесь, что ваши клиенты знают об этом!), и, вероятно, ожидайте значительного сопротивления со стороны членов команды, которые привыкли к «старым добрым методам».

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

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

Answer 4

Одним из инструментов, который может помочь вам протестировать устаревший код (при условии, что у вас нет/не будет времени на его рефакторинг), является Typemock Isolator:TypeMock.com он позволяет вводить зависимости в существующий код без необходимости извлечения интерфейсов и тому подобного, поскольку он не использует стандартные методы отражения (динамический прокси и т. Д.), но вместо этого использует API Profiler.Он использовался для тестирования приложений, использующих SharePoint, HTTPContext и другие проблемные области.Рекомендую вам посмотреть.(Я работаю в качестве разработчика в этой компании, но это единственный инструмент, который не заставляет вас рефакторировать существующий устаревший код, экономя время и деньги), я также настоятельно рекомендую «эффективно работать с устаревшим кодом» для получения дополнительных методов.

Рой

Answer 5

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

Вы также можете начать с приемочных тестов более высокого уровня и двигаться дальше (см. Фитнес для этого).

Answer 6

Я бы начал с некоторых базовых интеграционных тестов.Это получит поддержку со стороны остального персонала.Затем начните отделять части вашего кода, которые имеют зависимости.Работайте над использованием внедрения зависимостей, поскольку это сделает ваш код более тестируемым.Относитесь к ошибкам как к возможности написать тестируемый код.