Ценность модульного тестирования

Question

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

1. «Это работа QA, просто сосредоточьтесь на возможностях и разработке»
2. «Приложение не является критически важным, если есть ошибки, это не конец света»
3. «Мы не можем позволить себе тратить время на юнит-тестирование»
4. "Постарайся не слишком придумывать"

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

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

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

ОБНОВЛЕНИЕ: Спасибо всем за много проницательных советов. Есть несколько ответов, которые я бы хотел выбрать в качестве правильного.

Answer 1

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

Например: Инвестиции:

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

Прибыль:

• ошибка не появляется снова без знака;
• без прохождения модульных тестов никакие основные функции не выдаются;
• цикл ошибок разработки-qa-fix сокращается пополам для большинства ошибок: ошибок тест-исправления модуля разработки;
• и т.д.

Answer 2

Большинство менеджеров не увидят преимуществ модульного тестирования, пока не увидят его в действии, где оно имеет смысл, поэтому мой совет, исходя из опыта, состоит в том, чтобы предпринять шаги ff:

1. Применение модульных тестов к повторяющимся ошибкам - Это лучший вариант использования, чтобы доказать ценность модульных тестов. Если у вас есть ошибки, которые появляются и появляются при каждой другой сборке, модульное тестирование позволит разработчикам увидеть, какие изменения вызвали ошибки, кроме того, чтобы заранее предупредить их, что исправление исправно. Это довольно легко продемонстрировать руководству.
2. Применение модульных тестов к обычным ошибкам - Теперь, когда наглядно продемонстрирована полезность модульных тестов, нескольких случаев повторяющихся ошибок, исчезающих в долгосрочной перспективе, должно быть достаточно, чтобы каждый мог использовать модульные тесты для оценки все ошибки, чтобы они не становились повторяющимися.
3. Применение модульных тестов к новой функциональности - С помощью модульных тестов убедитесь, что старые ошибки не повторяются, и подтвердите, что они исправлены в первую очередь, следующим шагом будет применение их к новым функциональность, чтобы гарантировать, что ошибки будут минимизированы. Дайте понять, что невозможно полностью устранить ошибки.
4. Применение полнофункционального TDD - Заключительным этапом будет применение модульного тестирования еще до кодирования, как инструмента проектирования, который одновременно помогает в разработке кода и минимизации ошибок.

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

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

Answer 3

Люди слушают свои кошельки. Покажите, сколько времени вы можете сэкономить, обнаруживая ошибки на ранней стадии. Переведите это в доллары-сбережения.

Answer 4

Что касается # 3, то время, потраченное на юнит-тестирование, скорее всего, уменьшит общее время выхода на рынок. Отличная статья - http://blog.scottbellware.com/2008/12/does-test-driven-development-speed-up.html

Answer 5

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

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

Мои собственные 2 цента.

Answer 6

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

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

Пока ваши менеджеры не поймут, что TDD НЕ исключительно для предотвращения ошибок или «тестирования», они НИКОГДА не получат его. TDD - это дизайн и общее качество кода.

Вы должны показать им. Если их невозможно убедить, я бы начал искать. Тихо;)

Answer 7

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

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

Answer 8

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

Не думаю, что проблема в технике или стоимости сервера интеграции. Проблема заключается в отношении руководства к юнит-тестированию. Поэтому убедите их всех разработчиков.

В этой теме много подсказок ( ответ Джона Лимджапа ), попробуйте!

Answer 9

Мой короткий и неполный совет:

• Просто поменяйте работу. Компания, чьи менеджеры дают такие ответы, в любом случае обанкротится и скоро. Убирайся, пока не стало слишком поздно.

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

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

Answer 10

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

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