Каковы ощутимые преимущества для правильных юнит-тестов по сравнению с функциональными тестами, называемыми юнит-тестами

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

Мои вопросы: каковы НАСТОЯЩИЕ мировые ощутимые преимущества надлежащего модульного тестирования, которые я могу использовать, чтобы отодвинуть? Есть ли такие? Я просто сторонник того, что плохие юнит-тесты (даже если они работают) плохие? Является ли покрытие кода таким же эффективным?

• Ресурсы

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

• надежность

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

• Дополнительное обслуживание

  Тесты можно запускать в любом порядке. Добавление или удаление теста не должно привести к сбою набора тестов. Работа с базой данных означает, что где-то есть состояние (в базе данных). Как правило, эти тесты требуют дополнительного обслуживания, чтобы гарантировать, что база данных поддерживает надлежащее состояние для запуска следующего теста.

• совпадение

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

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

Мои вопросы: каковы НАСТОЯЩИЕ мировые ощутимые преимущества надлежащего модульного тестирования, которые я могу использовать, чтобы отодвинуть?

Хорошие юнит-тесты (согласно Чистому коду и в других местах):

• Быстрый
• независимый
• Повторяется
• Не подлежащий ратификации
• своевременно

Отсутствие настоящих юнит-тестов нарушает первые три (и обычно последний). Это приводит к некоторым довольно существенным проблемам:

1. Ваши тесты медленные. Медленные тесты запускаются нечасто. Тесты, которые не запускаются, почти бесполезны.
2. Ваши тесты могут провалиться по причинам, не связанным с кодом, который вы тестируете. Это значительно усложняет выяснение причин, по которым тесты проваливаются, тратя время и заставляя людей обвинять не код, а среду.
3. По мере изменения базы данных ваши результаты меняются. Получение некоторой базы данных в известном исправном, поддерживаемом состоянии для тестов утомительно, раздражает и подвержено ошибкам.

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

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

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

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

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

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

Хорошие юнит-тесты обеспечивают локализацию. Функциональные тесты могут сказать вам «функция добавления пользователя не работает», но хороший модульный тест скажет вам, что он сломан, потому что кто-то изменил поле USER.LAST_NAME в базе данных на ненулевое. Также возможно тестировать небольшие изменения напрямую, вместо того, чтобы нуждаться в сложной тестовой среде (которая может потребоваться повторная инициализация или очистка для некоторых тестов).