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

Question

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

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

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

• Определение написанных модульных тестов
• Идентификация тестовых данных (или их описание)
• Написание этих тестов
• Отслеживание этих тестов (и повторное использование при необходимости)
• Предоставление результатов

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Извлечение соответствующих точек -

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

1. Изменение требований к программному обеспечению
2. Программное обеспечение изменяется в соответствии с требованиями

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

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

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

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

Answer 7

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

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

Answer 8

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

https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html

Answer 9

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

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

Answer 10

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