Я слышал, как кто-то сказал, что модульные тесты (например, nUnit, jUnit, xUnit) должны быть
(Например, модульные тесты должны содержать "влажный код", а не "сухой код" )
О чем они говорят?
Что означает "DAMP not DRY", когда речь идет об модульных тестах?
Ответ 1
Это баланс, а не противоречие
DAMP и DRY не противоречат друг другу, скорее они балансируют два разных аспекта ремонтопригодности кода. Полезный код (код, который легко изменить) является конечной целью здесь.
DAMP (описательные и значащие фразы) способствует читабельности кода.
Чтобы поддерживать код, вам сначала нужно понять код. Чтобы понять это, вы должны прочитать его. Подумайте, сколько времени вы тратите на чтение кода. Это много. DAMP повышает ремонтопригодность за счет сокращения времени, необходимого для чтения и понимания кода.
DRY (не повторяйте себя) способствует ортогональности кода.
Удаление дублирования гарантирует, что каждое понятие в системе имеет единое авторитетное представление в коде. Изменение единой бизнес-концепции приводит к единому изменению кода. DRY увеличивает ремонтопригодность, изолируя изменения (риск) только к тем частям системы, которые должны измениться.
Итак, почему дублирование более приемлемо в тестах?
Тесты часто содержат присущее дублирование, потому что они тестируют одно и то же снова и снова, только с немного разными входными значениями или кодом настройки. Однако, в отличие от производственного кода, это дублирование обычно изолируется только для сценариев в рамках одного тестового прибора/файла. Из-за этого дублирование является минимальным и очевидным, что означает, что он представляет меньший риск для проекта, чем другие типы дублирования.
Кроме того, удаление такого рода дублирования снижает читаемость тестов. Детали, которые ранее были дублированы в каждом тесте, теперь скрыты в каком-то новом методе или классе. Чтобы получить полную картину теста, вы должны мысленно вернуть все эти части вместе.
Поэтому, поскольку дублирование тестового кода часто несет меньший риск и повышает читаемость, его легко увидеть, как он считается приемлемым.
Как принцип, предпочитайте DRY в производственном коде, пользуйтесь DAMP в тестовом коде. Хотя оба они одинаково важны, с небольшой мудростью вы можете опрокинуть баланс в свою пользу.
Ответ 2
DAMP - описательные и значащие фразы.
"DAMP not DRY" читает значения при повторном использовании кода. Идея DAMP не DRY в тестовых случаях заключается в том, что тесты должны быть легко понятны, даже если это означает, что в случае тестов иногда повторяется код.
См. также Является ли дублированный код более переносимым в модульных тестах? для некоторого обсуждения достоинств этой точки зрения.
Возможно, это было придумано Jay Fields в отношении доменных языков.
Ответ 3
"DRY" - "Не повторяйте себя"
Это термин, который используется для того, чтобы заставить людей писать код, который можно повторно использовать, чтобы вы не повторяли снова и снова с помощью подобного кода.
"DAMP" - "Описательные и значащие фразы".
Этот термин предназначен для того, чтобы сообщить вам написать код, который легко понять кто-то, кто смотрит на него. Если вы следуете этому принципу, у вас будут длинные и описательные имена переменных и функций и т.д.
Ответ 4
Damp = "Описательные и значащие фразы" - ваши модульные тесты должны быть "прочитаны":
Ответ 5
DAMP означает "описательные и содержательные фразы" и является противоположностью DRY, а не в том смысле, что в нем говорится, что "все должно выглядеть как куча мусора и быть невозможным для чтения", поскольку эта читаемость важнее, чем избегать избыточных код.
Ответ 6
Здесь уже есть несколько ответов, но я хотел добавить еще один, поскольку я не думал, что они обязательно объяснят это так, как могли.
Идея DRY (Не повторяйте себя) заключается в том, что в коде приложения вы хотите избежать избыточного или повторного кода. Если у вас есть что-то, что ваш код должен делать несколько раз, у вас должна быть функция или класс, а не повторять аналогичный код в нескольких местах.
Это довольно известная концепция программирования.
DAMP (описательные и значащие фразы) для ваших модульных тестов. Идея здесь в том, что ваши имена методов unit test должны быть длинными и описательными - эффективно короткие предложения, которые описывают то, что вы тестируете.
например: testWhenIAddOneAndOneIShouldGetTwo() { .... }
Когда вы читаете имя метода DAMP, подобное этому, вы должны точно понимать, что пытался создать тестовый писатель, даже не имея необходимости читать тестовый код (хотя тестовый код также может следовать этой концепции, а также, конечно, с многословным имена переменных и т.д.).
Это возможно, потому что метод unit test имеет очень специфический вход и ожидаемый результат, поэтому принцип DAMP хорошо подходит для них. Методы в вашем основном коде приложения вряд ли будут достаточно конкретными, чтобы оправдать такие имена, особенно если вы написали его с использованием принципа DRY.
DAMP и DRY не противоречат друг другу - они охватывают различные аспекты написания вашего кода, но тем не менее они обычно не используются вместе, потому что методы, написанные с использованием принципа DRY, будут универсальными и маловероятными чтобы соответствовать высокоспецифическому имени метода. В общем случае, как объяснялось выше, ваш код приложения должен быть сухим и вашим unit test кодом DAMP.
Я надеюсь, что это поможет немного улучшить его.
Ответ 7
Я согласен с Крисом Эдвардсом в том, что вам нужно найти баланс между ними. Еще одна вещь, которую следует отметить, заключается в том, что если вы попытаетесь удалить дублирование, вы добавите много дополнительной структуры в свой код unit test (т.е. При переходе с DRY в крайности), вы рискуете внедрить там ошибки. В такой ситуации вам придется либо unit test тестировать ваш блок, либо оставлять бит структуры непроверенной.
Ответ 8
Я не хочу дублировать усилия здесь, но вы можете иметь тесты, которые являются DAMP, но имеют преимущество DRY. С другой стороны, тесты DRY в некоторых случаях не будут удовлетворять испытаниям DAMP.
Я писал о DRY vs DAMP, который содержит некоторые примеры.
Ни один из подходов не должен быть вашим единственным решением, иногда DAMP является излишним, а иногда очень приятным дополнением.
Как правило, вы должны применять правило из трех. Если вы обнаружите дублирование в третий раз, возможно, стоит посмотреть на тесты стиля DAMP, но даже тогда не все дублирование плохое. Контекст имеет значение.