Каков наиболее убедительный способ потребовать формализованного модульного тестирования?

Question

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

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

По формализованных модульных тестов, я просто говорю о

• Определение модульных тестов должны быть записаны
• Определение тестовых данных (или описать)
• Запись этих тестов
• Tracking эти испытания (и повторное использование по мере необходимости)
• Выполнение имеющихся результатов

Answer 1

Итак, через два года после того, как я задал этот вопрос, я обнаружил, что один неожиданный ответ заключался в том, что, перейдя на новый SDLC, это было необходимо. Пять лет назад мы создали нашу первую формальную SDLC. Это улучшило нашу ситуацию, но оставило некоторые важные вещи, такие как автоматизация. Сейчас мы находимся в процессе создания новой SDLC (под новым управлением), где одним из арендаторов является автоматизация. Не только автоматические модульные тесты, но и автоматические функциональные тесты.

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

Answer 2

Напомните вашей команде или другим разработчикам, что они профессионалы, а не любители. Работал для меня!

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

Answer 3

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

Answer 4

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

Answer 5

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

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

После того, как вы убедите своих коллег-разработчиков, убедите руководство вместе.

Answer 6

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

Answer 7

Образование и/или сертификация.

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

Answer 8

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

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

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

1. Программные требования изменить
2. изменения программного обеспечения в соответствии с требованиями

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

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

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

Надеюсь, это поможет.

Answer 9

Я использую Maven с плагинами Surefire и Cobertura для всех моих сборщиков. Фактические тестовые примеры создаются с помощью JUnit, DbUnit и EasyMock.

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

Идентификация данных испытаний DbUnit отлично подходит для загрузки тестовых данных для ваших модульных тестов.

Письменные тестовые случаи Я использую JUnit для создания тестовых примеров. Я пытаюсь написать самостоятельное документирование тестовых примеров, но я буду использовать Javadocs, чтобы комментировать что-то, что не очевидно.

Отслеживание & Изготовление Результаты Доступные Я интегрировать модульное тестирование в моей Maven сборки цикла, используя Surefire плагин, и я использую плагин Corbertura для измерения охвата, достигнутый этими тестами. Я всегда создаю и публикую веб-сайт, в том числе отчеты Surefire и Cobertura, как часть моей ежедневной сборки, поэтому я могу видеть, какие тесты не выполнялись/проходили.

Answer 10

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

Как и в большинстве мейнфреймов, у нас было три сферы, разработка, обеспечение качества и производство. Программисты, разработанные в разработке и модуле, прошли тестирование там, и как только они подписались и были счастливы, подразделение было перенесено в среду QA (с документами тестирования и результатов), где она была протестирована системой выделенным персоналом ОК. Развитие миграции QA было формальным шагом, который произошел в одночасье. Как только QA'ed, код был перенесен в Production - и у нас было очень мало ошибок.

Мотивация для проведения модульного тестирования была выполнена правильно, так это то, что если вы этого не сделали, а сотрудники QA обнаружили ошибку, было очевидно, что вы не выполнили эту работу. Следовательно, ваша репутация зависела от того, насколько вы были строги. Конечно, большинство людей получат случайную ошибку, но кодеры, производящие проверенный код, все время скоро получили звездную репутацию, и те, кто произвел ошибку, тоже заметили. Толчок всегда будет поднимать вашу игру, и, следовательно, культура, созданная, была той, которая была направлена ​​на бесплатный код ошибки, который был доставлен в первый раз.

Добывающие соответствующие точки -

1. Coder репутация связана с поставкой ошибка свободного протестированного кода
2. Значительные накладные расходы, связанные с перемещением блока протестированного кода на новый уровень, поэтому мотивация не повторить это и получить его правый первый раз.
3. Тестирование системы, проводимое различными людьми для модульного тестирования - в идеале - другая команда.

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

Answer 11

Как руководитель команды, я обязан гарантировать, что мои программисты проводят модульное тестирование на всех модулях, над которыми они работают. Полагаю, на данный момент, это даже не вопрос о том, как убедить их, это необходимо. Не иногда, а не по довольно крупным проектам, все время. Единичное тестирование - это первая линия защиты от сдачи чего-то в производстве, которую вам нужно будет поддерживать. Если что-то вводится в производство, которое не было полностью проверено на единицу и систему, тогда оно вернется, чтобы укусить вас. Я полагаю, что одна из политик, которые мы здесь имеем, чтобы поддержать это, заключается в том, что если он вступает в производство или создает проблемы, то программист, ответственный за кодирование и тестирование этого модуля, будет тем, кто должен заботиться о проблемах, выполнить очистку и т. д. Это само по себе является довольно хорошим мотиватором.
Другое дело, что речь идет о гордости. Я работаю в магазине около 75 кодеров, хотя это по ряду стандартов, но это действительно достаточно мало, чтобы мы все знали друг друга. Он также достаточно мал, чтобы мы знали, над чем работает один человек, и когда он переходит к производству, мы знаем о любых нарушениях, сбоях и т. Д. Если вы будете осторожны, выполните тестирование единицы и системы, шансы чего-то переместить к производству без возникновения сбоев значительно возрастает. Потребуется время или два, чтобы что-то переделать в производство и не осознать этого, но есть большие награды, которые не возились.Очень приятно слышать поздравления в коридоре, когда вы перемещаете проект, и он не испортит.

Answer 12

Существует большая разница между убедительными и , требующими.

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

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

Answer 13

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