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

Question

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

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

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

Answer 1

Эффективная работа с устаревшим кодом от Michael Feathers

Трудно понять, пойдет ли на пользу реализация фабричного шаблона, зависит от того, что делает код :)

Answer 2

Эффективная работа с устаревшим кодом от Michael Feathers (также доступна в Safari, если у вас есть подписка) - отличный ресурс для вашей задачи. Автор определяет унаследованный код как код без юнит-тестов и дает практические пошаговые руководства по лотам консервативных методов, необходимых, потому что вы работаете без сети безопасности, для тестирования кода. Оглавление:

• Часть: I Механика перемен
  • Глава 1. Изменение программного обеспечения
    • Четыре причины для изменения программного обеспечения
    • Рискованное изменение
  • Глава 2. Работа с обратной связью
    • Что такое модульное тестирование?
    • Тестирование на более высоком уровне
    • Тестовые покрытия
    • Устаревший алгоритм изменения кода
  • Глава 3. Ощущение и разделение
    • Поддельные соавторы
  • Глава 4. Модель шва
    • Огромный лист текста
    • пласты
    • Типы швов
  • Глава 5. Инструменты
    • Инструменты автоматического рефакторинга
    • Макет объектов
    • Жгуты для юнит-тестирования
    • Жгуты общего теста
• Часть: II Изменение программного обеспечения
  • Глава 6. У меня мало времени, и я должен его изменить
    • Способ прорастания
    • Росток класса
    • Метод обтекания
    • Класс упаковки
    • Резюме
  • Глава 7. Внесение изменений навсегда
    • Понимание
    • Время задержки
    • Нарушение зависимости
    • Резюме
  • Глава 8. Как добавить функцию?
    • Разработка через тестирование (TDD)
    • Программирование по разнице
    • Резюме
  • Глава 9. Я не могу получить этот класс в тестовом жгуте
    • Случай раздражающего параметра
    • Дело о скрытой зависимости
    • Дело о Строительном Блобе
    • случай раздражающей глобальной зависимости
    • Случай ужасного включения зависимостей
    • Случай Лукового параметра
    • Случай с псевдонимом параметра
  • Глава 10. Я не могу запустить этот метод в тестовом жгуте
    • Дело о скрытом методе
    • Дело о «полезной» языковой функции
    • Случай неопределяемого побочного эффекта
  • Глава 11. Мне нужно внести изменения. Какие методы я должен проверить?
    • Рассуждение об эффектах
    • Аргументация вперед
    • Эффект распространения
    • Инструменты для рассуждения об эффекте
    • Изучение эффекта анализа
    • Упрощенные эскизы эффектов
  • Глава 12. Мне нужно сделать много изменений в одной области. Должен ли я нарушать зависимости для всех участвующих классов?
    • точки перехвата
    • Оценка дизайна с точками защемления
    • Ловушки с точечными точками
  • Глава 13. Мне нужно внести изменения, но я не знаю, какие тесты писать Тесты характеристик
    • Характеризующие классы
    • Целевое тестирование
    • Эвристика для написания тестов характеристик
  • Глава 14. Зависимости от библиотек убивают меня
  • Глава 15. Мое приложение - это все вызовы API
  • Глава 16. Я недостаточно понимаю код, чтобы изменить его
    • Примечания / Sketching
    • Разметка списка
    • Рефакторинг нуля
    • Удалить неиспользуемый код
  • Глава 17. Мое приложение не имеет структуры
    • Рассказ об истории системы
    • Голый CRC
    • Проверка разговора
  • Глава 18. Мой тестовый код в пути
    • Соглашения об именах классов
    • Место проведения теста
  • Глава 19. Мой проект не является объектно-ориентированным. Как мне сделать безопасные изменения?
    • Легкий чехол
    • Твердый футляр
    • Добавление нового поведения
    • Использование преимуществ ориентации объекта
    • Все ориентировано на объект
  • Глава 20. Этот класс слишком велик, и я не хочу, чтобы он стал больше
    • Видя обязанности
    • Другие техники
    • Движение вперед
    • После извлечения класса
  • Глава 21. Я меняю один и тот же код повсюду
    • Первые шаги
  • Глава 22. Мне нужно изменить метод монстров, и я не могу написать для него тесты
    • Разновидности монстров
    • Борьба с монстрами с поддержкой автоматического рефакторинга
    • Задача ручного рефакторинга
    • Стратегия
  • Глава 23. Откуда мне знать, что я ничего не ломаю?
    • Редактирование Hyperaware
    • Редактирование одной цели
    • Сохранить подписи
    • Опираться на компилятор
  • Глава 24. Мы чувствуем себя подавленными. Лучше не станет
• Часть: III Техники, нарушающие зависимость
  • Глава 25. Техники нарушения зависимости
    • Адаптировать параметр
    • Объект метода Break Out
    • Определение завершения
    • Инкапсулировать глобальные ссылки
    • Открытый статический метод
    • Извлечение и переопределение вызова
    • Метод фабрики извлечения и переопределения
    • Извлечение и переопределение получателя
    • Извлечение экстрактора
    • Извлечение интерфейса
    • Представьте делегат экземпляра
    • Введение статического сеттера
    • Замена ссылок
    • Конструктор Параметризации
    • Метод параметризации
    • Примитивизировать параметр
    • Функция подтягивания
    • Зависимость нажатия вниз
    • Заменить функцию с помощью указателя функции
    • Заменить глобальную ссылку на Getter
    • Подкласс и метод переопределения
    • Заменить переменную экземпляра
    • Переопределение шаблона
    • Переопределение текста
• Приложение: Рефакторинг
  • Метод извлечения

Answer 3

Как насчет написания серии тестов «черного ящика» вокруг основных частей функциональности вашего кода? Поскольку вы упоминаете, что это проект ASP.NET, вы можете использовать такую ​​среду, как WaitN или Selenium для автоматизации веб-браузера. Это дает вам базовый набор функций, который должен оставаться постоянным независимо от того, насколько сильно изменяется код.

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

Answer 4

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

Конечно, даже это сложно, когда структура проекта не подходит для тестируемости.

Моя лучшая рекомендация - делать это небольшими шагами.

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

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

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