10 марта 2020

Тесты слишком «сухие»? Сделайте их «мокрыми»!

Всегда ли нужно придерживаться принципа DRY? Одна из возможных точек зрения — в переводе QA Division Manager Noveo Анастасии!

Noveo testing

Тест ниже следует принципу DRY («Don’t Repeat Yourself»), который говорит, что переиспользовать код лучше, чем повторять, — например, вынося отдельно методы-помощники или используя циклы. Но можно ли назвать тест ниже хорошо написанным?

DRY test

Хотя тест выше достаточно лаконичен, читателю необходимо приложить некоторые мысленные усилия, чтобы понять его, например, следуя за self.users из setUp() через _RegisterAllUsers(). Так как не существует тестов на эти тесты, людям не должно быть трудно вручную проверить их на правильность, даже ценой некоторого повторения в коде. Это значит, что принцип DRY часто не очень подходит для юнит-тестов, несмотря на то, что это одна из лучших практик для кода в продакшене.

Мы можем использовать для тестов другой принцип — DAMP («Descriptive and Meaningful Phrases»), который отдает предпочтение читаемости над уникальностью. Применение этого принципа может привести к избыточности кода (к примеру, за счет повторений), но оно увеличивает простоту проверки тестов на правильность. Давайте добавим немного «воды» (ориг. «DAMP-ness», «влажность») в пример выше:

DAMP test

Обратите внимание, что принцип DRY всё ещё важен для тестов; например, использование метода-помощника для создания объектов-значений может добавить понятности за счет сокращения избыточных частей в теле теста. В идеале код тестов должен быть и понятным, и неповторяющимся, но иногда приходится идти на сделку с совестью. Создавая юнит-тесты и выбирая между принципами DRY и DAMP, постарайтесь больше придерживаться принципа DAMP.

Оригинал: https://testing.googleblog.com/2019/12/testing-on-toilet-tests-too-dry-make.html

Наше мнение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: