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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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