Внедрение модульного тестирования в существующий проект

Какие-нибудь инструменты для создания причудливых результатов для менеджеров проектов?

Будь осторожен. Причудливый инструмент для отображения метрик по количеству модульных тестов, покрытию, метрикам качества кода, количеству строк, количеству чекинов и т. д. может быть опасным в руках некоторых менеджеров проектов. Менеджер проекта (который не знаком с реалиями разработки программного обеспечения) может быть одержим метриками и не понимать, что:

• они не дают реальной картины состояния и прогресса проекта, и

• они могут дать совершенно ложную картину производительности отдельных членов команды.

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

Любые правила, которые должны быть установлены — покрытие кода или обеспечение того, чтобы это были модульные, а не интеграционные тесты.

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

• Модульные тесты по сравнению с интеграционными тестами зависят от характера и сложности системы, которую вы создаете.

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

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

Что касается фреймворка модульного тестирования, то в основном их две: jUnit и TestNG. Оба имеют свои преимущества, и оба одинаково эффективны. Основным преимуществом jUnit является (на мой взгляд) включение по умолчанию плагина Eclipse, позволяющего легко вызывать тесты.

Что касается насмешливой структуры, я не считаю их обязательной частью вашего подхода к тестированию. Конечно, они полезны, но они решают конкретную задачу: тестирование поведения (в отличие от тестирования интерфейса, что позволяет jUnit. С помощью фиктивных фреймворков вы можете проверить, как конкретный класс реализует конкретный интерфейс. Будете ли вы? Вам это нужно? Очевидно. Вам это понадобится в первую очередь? Я не знаю.

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

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

Это сложный вопрос, поэтому несколько заметок о нашей практике в $work:

• JUnit действительно по-прежнему является стандартом. Большая часть документации и литературы относится к JUnit.
• Mockito кажется новой звездой насмешек Java, хотя мы все еще используем JMock и думаем, что он подходит для наших нужд.
• Мы используем подключаемый модуль Eclipse EclEmma для проверки нашего тестового покрытия, и он нам нравится.

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

Я модифицировал модульные тесты для проекта C++, и это неприятно.

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

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

Не ожидайте быстрого исправления — потребовалось 3 недели (6 часов в день, 5 дней в неделю), чтобы получить 20% покрытие, но код тратит 80% времени в этом коде, поэтому я думаю, что это было потраченное время с пользой и раскрыто. довольно много ошибок.

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