какие функции и / или классы нельзя тестировать и почему

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

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

Некоторые примеры кода, которые, вероятно, будет сложно протестировать:

• Функция 1000-LOC,
• Код, который сильно зависит от глобального состояния,
• Код, который требует конкретного, усложняет создание объектов, таких как контекст базы данных, вместо того, чтобы полагаться на интерфейсы и Dependency Injection,
• Код, который выполняет медленно ,
• Код спагетти,
• Устаревший код, который изменялся годами, не заботясь о удобочитаемости или удобстве обслуживания,
• Трудно понять код, который не имеет комментариев или подсказок об исходном намерении автора (например, код, который использует имена переменных, такие как function pGetDp_U(int i, int i2, string sText).

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

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

• Нарушение закона Деметры .
• Создание объектов внутри метода вместо введения зависимостей .
• Тесная связь.
• Плохая сплоченность
• Полностью зависит от побочных эффектов.
• Полностью полагается на глобалы или синглтоны.
• Не дает много промежуточных результатов. (Однажды мне пришлось провести модульное тестирование десятистраничной математической функции с одним выходом и без доступных промежуточных результатов. Мои предшественники в основном жестко запрограммировали любой ответ, который дал код).
• Зависит в большой степени и напрямую от служб, которые трудно подделать, таких как базы данных.
• Среда выполнения значительно отличается от среды разработки, как встроенная цель.
• Единицы доступны только в скомпилированном виде (например, сторонние библиотеки DLL).

Типичные примеры кода, которые люди не хотят тестировать:

• Код, который напрямую взаимодействует с вводом / выводом (чтение файлов, прямые сетевые вызовы,…).
• Код, который напрямую обновляет интерфейс.
• Код, который напрямую ссылается на синглтоны или глобальные объекты.
• Код, который неявно изменяет состояние объекта или подобъекта.

Используя макет фреймворка, все эти примеры могут быть проверены модулем. Это просто работа по настройке фиктивных замен для внутренних зависимостей.

Вещи, которые действительно не могут быть проверены модулем:

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

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

Плохо написан разработанный код

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

Уверенность государства в другой сфере

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

• Одиночки
• Глобалы
• Затворы

Внешнее / состояние системы

• Аппаратные / аппаратные зависимости
• Сетевые зависимости
• Зависимости файловой системы
• Межпроцессные зависимости
• Другие зависимости системных вызовов

совпадение

• Потоки (блокировки, критические секции и т. Д.)
• fork'ing
• Сопрограммы
• Обратные звонки
• Обработчики сигналов (не все, но некоторые)

Нет такого понятия, как код, который нельзя протестировать. Однако есть несколько примеров кода, который ДЕЙСТВИТЕЛЬНО, ДЕЙСТВИТЕЛЬНО трудно протестировать (возможно, не стоит затраченных усилий):

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

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

Мои основные три группы для этого:

• код, который опирается на внешние сервисы

• системы, которые не позволяют тестерам изменять состояние независимо от приложения.

• тестовые среды, которые не повторяют производственную настройку.

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