Что бы вы включили в 10-минутный доклад Грока о модульном тестировании?

Question

Я скоро сделаю 10-минутный доклад Грока о модульном тестировании в моей компании. Я сам пробовал и чувствую, что это может принести пользу компании. Мы уже проводим тестирование WebInject в нашей специальной команде QA, но я хочу попробовать продать модульное тестирование разработчикам.

Так что всего за 10 минут, что бы вы покрыли и почему?

• мы веб-приложения Microsoft Shop C #, я использовал NUnit в своем опыте.

Answer 1

Юнит-тестирование - это все о достоверности .

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

Answer 2

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

Модульное тестирование -> Рефакторинг -> Живой код.

Edit: Кстати, я бы не стал приводить цитату «весь код без модульных тестов является устаревшим кодом» от Майкла Фезерса. Это, конечно, заставило меня чувствовать себя защищенным, когда я впервые услышал это. К тому времени, когда люди перестанут чувствовать себя оскорбленными, эти 10 минут закончатся :-) (лично я думаю, что цитата вернее, чем полезна).

Answer 3

Вот хороший формат для короткого разговора о технике X:

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

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

Answer 4

Попытайтесь вкратце рассказать об аспекте разработки, управляемой тестами: сначала пишите тесты и интерфейсы, а затем реализуйте все.

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

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

Answer 5

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

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

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

Answer 6

Я бы продемонстрировал:

• Уверенность, которую он дает в коде, который вы производите
• Уверенность, которую он дает, когда вы меняете код, потому что он проходит модульные тесты
• Преимущества покрытия кода, не более "О, это еще утверждение никогда не проверялось!"
• Преимущества выполнения модульных тестов для каждой сборки на платформе CI, такой как Hudson

FWIW мы проводим дрянное визуальное студийное тестирование через MSTEST на нашей коробке Hudson, и у меня есть xslt, который Hudson использует для преобразования результатов в формат nunit, чтобы Hudson мог их расшифровать. Просто поместите это на тот случай, если они захотят, чтобы вы придерживались платформы тестирования Microsoft.

Answer 7

Ради бога, подчеркните, что юнит-тесты предназначены для проверки "единиц" логики. Ненавижу смотреть на набор тестов QA NUnit, который никто не ожидал поддерживать, где каждый «модульный тест» проверяет действительные выходные данные для 150 (двоичных) входных файлов, а затем выдает себя за неудачу, не сообщая, какой именно. *

Answer 8

Если вы проводите демонстрацию, сделайте это на работающем куске кода из проекта, с которым все знакомы. Избегайте надуманных примеров. Книги по TDD уже заполнены ими, и они на самом деле не продают, как TDD может работать в реальном проекте.

Answer 9

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

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

Кроме того, вы можете выделить, как можно быстрее разрабатывать компоненты, если вы тестируете изолированно (т. Е. Вам не нужно открывать веб-приложение, входить в систему, переходить к своей функциональности, тестировать); Вы можете просто запустить свои тесты.

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

Answer 10

Подотчетность , как подчеркнул Кент Бек, - еще одна черта, которую облегчает юнит-тестирование. Послушайте его подкаст на IT Conversations . (Его точка зрения на ответственность начинается в 30:34.)