Принятие TDD в старом Java-приложении

Question

У меня проблема, и я прошу вас о помощи

Я начал работать над веб-приложением, которое не имеет тестов, основано на Spring 2.5 и Hibernate 3.2, не очень хорошомодульный, с классами, имеющими до 5 тыс. строк, в качестве технологии просмотра JSP используется повсеместно с множеством дубликатов (как и многие подобные формы поиска с очень небольшим количеством различий, но с небольшим количеством общих частей).

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

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

Спасибо за ответы.

Answer 1

Я бы начал с того, что взял бы книгу Майкла Фезерса Эффективная работа с устаревшим кодом - это чистое золото.

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

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

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

Answer 2

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

У меня был такой опыт. В этом случае одним из рекомендуемых методов является разработка тестов для новых функций. Вы не можете сейчас остановиться и разработать тесты для всего приложения. Что вы можете сделать, так это каждый раз, когда вам нужно написать новую функцию, разработайте тесты для этой функции. Если эта функция требует изменений в некоторых уязвимых местах, начните тестирование для этих мест.

Рефакторинг - большая проблема. В идеале, если вы хотите разделить класс из 5k строк на 10 классов нормального размера, вы должны сначала разработать контрольные примеры для большого класса, затем выполнить рефаторинг и затем снова запустить тесты, чтобы убедиться, что вы ничего не сломали. Это очень сложно на практике, потому что, когда вы меняете дизайн, вы меняете интерфейс, и поэтому вы не можете запускать точно такие же тесты. Таким образом, каждый раз вы должны принять трудное решение, каков наилучший способ и каков минимальный тестовый пример, который охватывает вашу задницу.

Например, иногда я выполнял 5-фазный рефаторинг: 1. разработаны тесты для плохого большого класса 2. разработал новый хорошо разработанный код и изменил старый класс, чтобы он стал фасадом для моего нового кода. 3. запустил тестовый пример, разработанный в # 1, чтобы проверить, что все работает 4. разработаны новые тесты, которые проверяют, что каждый новый (маленький) субмодуль работает хорошо 5. рефакторинг кода, то есть удалены все ссылки на большой старый класс (который стал легковесным фасадом) 5. убрал старый класс и его тесты.

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

Вскоре, удачи в вашей тяжелой работе. Подготовьтесь к работе в одночасье, а затем получите 20 отчетов об ошибках от QA и гневное электронное письмо от вашего босса. :( Будь сильным. Ты на правильном пути!

Answer 3

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

Первое правило дырки: если вы застряли в яме, прекратите копать.

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

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

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

Как только вы сбили одно домино, остальные последуют.

Answer 4

Да, определенно есть место для TDD, но это только часть решения.

Вам необходимо refactor это приложение, прежде чем вы сможете внести какие-либо изменения.Рефакторинг требует наличия тестового покрытия.Возьмите небольшие порции явно некачественного кода и напишите characterisation тесты для них.Это означает, что вы тестируете все возможные варианты с помощью этого кода.Вы, вероятно, найдете ошибки, делающие это.Выявляйте ошибки с помощью своей системы обеспечения качества и пока сохраняйте поведение с ошибками (заблокируйте ошибки с помощью тестов характеристик, поскольку другие части системы могут пока полагаться на поведение с ошибками).

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

integration тесты могут быть полезны в этих обстоятельствах для выделения сценариев счастливого дня или нескольких основных ошибок.Но обычно в этих обстоятельствах приложение слишком сложное, чтобы написать полный набор тестов интеграции.Это означает, что вы никогда не будете защищены на 100% от побочных эффектов, используя только интеграционные тесты.Вот почему я предпочитаю «извлечь метод» и охарактеризовать.

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

Answer 5

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

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

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

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - зачеркнуто.

Answer 6

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

Приветствия!