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

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

  • "Это задача QA, просто сосредоточиться на особенностях и развитии"
  • "Приложение не критично, если есть некоторые ошибки, а не конец света"
  • "Мы не можем позволить себе потратить время на модульное тестирование"
  • "Старайтесь не слишком причудливо"

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Прибыль:

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

Ответ 2

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

  • Применить модульные тесты к повторяющимся ошибкам. Это лучший пример использования доказательств ценности модульных тестов. Когда у вас есть ошибки, которые только появляются и появляются снова в каждой другой сборке, unit test позволит разработчикам увидеть, какие изменения вызвали ошибки, кроме предупреждения о том, что исправление в порядке. Это также легко продемонстрировать руководству.
  • Применить модульные тесты к регулярным ошибкам. С учетом полезности модульных тестов, которые теперь ясно продемонстрированы, несколько случаев повторяющихся ошибок, исчезающих в долгосрочной перспективе, должны быть достаточными, чтобы побудить всех использовать модульные тесты для оценки всех ошибок, чтобы они не становились повторяющимися ошибками.
  • Применить модульные тесты к новым функциям. С модульными тестами, чтобы убедиться, что старые ошибки не повторяются, и убедитесь, что они исправлены в первую очередь, следующим шагом было бы применить его к новые функции для обеспечения минимизации ошибок. Проясните, что невозможно полностью устранить ошибки.
  • Применить полноразмерный TDD. Последним шагом будет применение модульного тестирования еще до кодирования, в качестве инструмента разработки, который помогает в разработке кода и минимизации ошибок.

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

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

Ответ 3

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

Ответ 5

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

если вы не можете практиковать unit test в своем реальном проекте из-за проблем с управлением, я бы предпочел практиковать на небольшом игрушечном проекте, просто чтобы заставить себя получить способ написания тестового кода, даже если есть NO unit test.

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

В этой теме много советов (Jon Limjap answer), попробуйте!

Ответ 9

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

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

Ответ 10

Еще одна мысль добавить к другим замечательным комментариям к этой теме (многие из которых я поддержал): убедитесь, что ваше руководство знает, что модульное тестирование на данный момент очень автоматизировано. Я нахожу очень впечатляющим, чтобы поп-шоу NUnit на экране, нажал кнопку "Запустить все" и увидел, что десятки зеленых светодиодов проходят через секунды. Сделайте это один раз, сказав: "это подтверждает, что все мои старые работы все еще правильные, несмотря на все мои новые изменения", и вы можете выиграть несколько конвертируемых. В любом случае, они будут доверять вам - с вашим видимым доказательством качества - больше, чем доверять другим. Это может быть только полезно для вашей карьеры.

Ответ 11

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

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

Ответ 12

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

Вам нужно убедить своего босса или товарищей по команде в том, что TDD используется? Что это не какая-то теория? Что это не просто наследник?

Теперь вы можете проверить WeDoTDD.com, список компаний, которые TDD и истории за этими командами.

Именно поэтому я создал этот сайт, чтобы поместить аргументы вокруг "TDD proof" и "Работает ли TDD" и "Кто делает TDD".

Вы также можете много узнать о самой теме там, читая истории, стоящие за этими компаниями и командами, практикующими ее.