Каковы ключевые моменты, чтобы объяснить модульное тестирование

Question

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

На какие ключевые моменты следует обратить внимание при представлении?

Answer 1

Для краткости: модульное тестирование - это две вещи

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

Очевидно, что это намного больше, но для меня это в значительной степени подводит итог.

Answer 2

Юнит-тесты по мелочам

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

Модульные тесты должны выполняться быстро и часто запускаться

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

Юнит-тесты лучше всего работают при высоком охвате

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

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

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

Модульное тестирование существующего кода ставит особые задачи

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

Answer 3

Здесь вы тоже можете получить вдохновение https://stackoverflow.com/questions/581589/introducing-unit-testing-to-a-wary-team/581610#581610

Answer 4

Модульные испытания должны быть ЧЕСТНЫМИ.

• F Fast
• A Может быть легко Автоматизировано
• I Может быть запущен Независимо
• R Повторяется

Answer 5

Основные баллы:

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

Answer 6

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

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

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