Как подойти к юнит-тестированию в большом проекте

Question

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

Обновление: чтобы уточнить размер проекта ... Я не совсем уверен, как описать это, кроме как сказать, что есть 8 контроллеров и около 167 файлов с расширением .cs, все сделано за 7 месяцев разработки.

Answer 1

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

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

Одна хорошая книга, которую я рекомендовал мне, - Эффективная работа с устаревшим кодом Майкл С. Перья.Название на самом деле не демонстрирует этого, но работа по тестированию в существующей кодовой базе является основной темой книги.

Answer 2

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

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

Кроме этого, я буду второй рекомендацией для книги Майкла Перса.

Answer 3

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

1. Каждая ошибка, попавшая в среду QA, Release или Production, является кандидатом на написание модульных тестовых примеров вместе с исправлением ошибки.

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

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

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

PS: я добавил книгу Майкла Фезерса в свой список чтения, спасибо за предложение.