Простой список из 10 правил, которым нужно следовать при написании модульных тестов, представленный в формате постера.
Контрольные списки — отличный инструмент для проверки применения конкретного процесса. Они предназначены для быстрого чтения и уменьшения количества человеческих ошибок при применении процесса. Контрольные списки широко используются, например, в здравоохранении и авиационных системах, где ошибки имеют решающее значение.
Когда дело доходит до модульных тестов программного обеспечения, хотя ошибки обычно менее критичны, тесты все же могут выиграть от контрольного списка, чтобы гарантировать, что стандарт всегда применяется. Контрольный список для модульных тестов представляет собой набор из 10 поправок, которым должен соответствовать каждый тест. Я представляю 10 правил модульного тестирования на плакате, который можно использовать в качестве ссылки, чтобы всегда проверять перед отправкой модульных тестов в строку кода.
Вы также можете скачать: Постер формата А3 в натуральную величину | полноразмерный постер формата А4
Выразительные имена
Написание хороших имен тестов является ключом к тому, чтобы помочь будущим читателям кода понять, что делает тест. Они также служат документацией по коду для понимания его функциональности. Существует множество соглашений о написании модульных тестов. Соглашение, которое я рекомендую, исходит из дисциплины разработки, управляемой поведением (BDD), и заключается в следующем.
Given <a current state> When <something happen> Then <a specific result is expected> // example of a test name: given_valid_passport_when_ticket_is_paid_then_check_in_to_flight
Это соглашение поможет писать тесты, обеспечивающие ценность для бизнеса.
Офлайн
Тесты не должны зависеть от внешних ресурсов, таких как доступность базы данных или службы REST для выполнения и прохождения. Если такие зависимости присутствуют, то тесты будут выполняться дольше, и они завершатся ошибкой, если во внешней службе возникнет ошибка. Вместо того, чтобы зависеть от внешних ресурсов, рекомендуется имитировать такие ресурсы в модульных тестах.
Независимый от заказа
Несколько тестов в тестовом классе не должны зависеть друг от друга. Тесты должны быть автономными и всегда проходить независимо от порядка их запуска. Многие тестировщики выполняют тесты в случайном порядке, поэтому наличие зависимостей между тестами приведет к случайным сбоям.
Не зависит от платформы
Тесты должны проходить при выполнении на всех поддерживаемых платформах. Например, тот же модульный тест, который проходит на компьютере разработчика с Windows, должен пройти на компьютере с Linux, когда сервер непрерывной интеграции запускает тесты.
Последовательно проходит
В заданном состоянии кода тест должен либо всегда проходить, либо всегда терпеть неудачу. Не должно быть случайности, которая затрудняет выявление и отладку проблем. Например, основной причиной случайности в модульных тестах является использование тайм-аутов для тестирования асинхронного кода. Библиотеки асинхронных тестов могут быть очень полезны, чтобы избежать таких ситуаций.
Быстро
Кодовые базы будут содержать тысячи и тысячи модульных тестов. Эти тесты также будут запускаться тысячи раз в процессе разработки. Таким образом, даже выигрыш в миллисекундах в каждом тесте может иметь огромное значение для времени обратной связи в нашем наборе тестов. По этой причине рекомендуется, чтобы выполнение модульного теста выполнялось в миллисекундах, чтобы сделать набор тестов масштабируемым.
Высокое покрытие
Хотя покрытие кода не является полным показателем качества наших модульных тестов, это хорошая отправная точка. Обычно, когда покрытие кода составляет около 80%, а тесты соответствуют остальным принципам, мы можем гарантировать более высокое качество модульных тестов.
Осторожно имитируйте
Макеты и заглушки — отличный инструмент, который должен быть в наборе инструментов каждого разработчика при написании модульных тестов. Это может помочь изолировать модули от их зависимостей и протестировать определенное поведение приложения, предполагающего определенное стабильное состояние. Но если ими злоупотреблять, в конечном итоге придется тестировать детали реализации, что в конечном итоге создаст технический долг тестирования. Рефакторинг будет намного сложнее, потому что каждый рефакторинг будет ломать множество модульных тестов, которые нелегко исправить.
Заметив создание множества макетов и деталей реализации тестирования, следует подумать о рефакторинге и применении принципа единой ответственности к тестируемому классу, и это должно помочь решить эту проблему.
Проверка поведения
У каждого производственного класса есть цель. Следует проверять только цель класса, а не то, как цель достигается. Другими словами, мы должны тестировать API класса, а не детали реализации. Чтобы убедиться, что это применяется, никогда не следует изменять видимость методов и полей только для того, чтобы иметь доступ к ним внутри тестов.
Когда вы замечаете, что невозможно протестировать без изменения видимости, это признак того, что в дизайне класса что-то не так. Следует рассмотреть возможность рефакторинга кода вместо предоставления дополнительных методов и полей.
Воспроизведение ошибок
При исправлении обнаруженной ошибки первое, что нужно сделать, это написать ошибочный модульный тест, который воспроизводит ошибку. Это гарантирует, что ошибка больше никогда не повторится. Затем после написания теста исправьте ошибку в производственном коде.
Это сообщение изначально появилось на моем личном сайте. Посмотрите похожие статьи
