Установка/разрушение повреждает тестовую пригодность для обслуживания?
РЕДАКТИРОВАТЬ : Просто " ls -m " Если вы хотите, чтобы ваш разделитель был запятой
Ах, сила и простота !
ls -1 | tr '\n' ','
Поменяйте запятую ", " на любую, какую хотите. Обратите внимание, что это включает "запятую"
9 ответов
Большинство (если не все) из допустимых применений для методов установки и разрыва можно записать как заводские методы, которые позволяют СУХОЙ, не вдаваясь в проблемы, которые кажутся мучительными. с парадигмой setup / teardown.
Если вы реализуете teardown, обычно это означает, что вы выполняете не модульный тест, а скорее интеграционный тест. Многие люди используют это как причину, чтобы не проводить разборку, но IMO должна быть как интеграция, так и модульное тестирование. Я бы лично разделил их на отдельные сборки, но я думаю, что хорошая среда тестирования должна поддерживать оба типа тестирования. Не все хорошее тестирование будет модульным тестированием.
Однако, с настройкой, кажется, есть ряд причин, по которым вам нужно что-то делать до того, как тест действительно будет запущен. Например, построение состояния объекта для подготовки к тесту (например, настройка инфраструктуры внедрения зависимостей). Это веская причина для установки, но ее также легко можно сделать с помощью фабрики.
Кроме того, существует различие между установкой / удалением на уровне класса и метода. Это нужно иметь в виду при рассмотрении того, что вы пытаетесь сделать.
Моя самая большая проблема, с которой я столкнулся при использовании парадигмы установки / удаления, заключается в том, что мои тесты не всегда следуют одному и тому же шаблону. Это заставило меня вместо этого использовать фабричные шаблоны, которые позволяют мне использовать DRY, в то же время читабельный и нисколько не сбивая с толку других разработчиков. Пройдя фабричным маршрутом, я смог съесть свой торт и съесть его.
Это веская причина для установки, но ее также легко можно сделать с помощью фабрики.Кроме того, существует различие между установкой / удалением на уровне класса и метода. Это нужно иметь в виду при рассмотрении того, что вы пытаетесь сделать.
Моя самая большая проблема, с которой я столкнулся при использовании парадигмы установки / удаления, заключается в том, что мои тесты не всегда следуют одному и тому же шаблону. Это заставило меня вместо этого использовать фабричные шаблоны, которые позволяют мне использовать DRY, в то же время читабельный и нисколько не сбивая с толку других разработчиков. Пройдя фабричным маршрутом, я смог съесть свой торт и съесть его.
Это веская причина для установки, но ее также легко можно сделать с помощью фабрики.Кроме того, существует различие между установкой / удалением на уровне класса и метода. Это нужно иметь в виду при рассмотрении того, что вы пытаетесь сделать.
Моя самая большая проблема, с которой я столкнулся при использовании парадигмы установки / удаления, заключается в том, что мои тесты не всегда следуют одному и тому же шаблону. Это заставило меня вместо этого использовать фабричные шаблоны, которые позволяют мне использовать DRY, в то же время читабельный и нисколько не сбивая с толку других разработчиков. Пройдя фабричным маршрутом, я смог съесть свой торт и съесть его.
повторюсь.Моя самая большая проблема, с которой я столкнулся при использовании парадигмы установки / разрыва, заключается в том, что мои тесты не всегда следуют одному и тому же шаблону. Это заставило меня вместо этого использовать фабричные шаблоны, которые позволяют мне использовать DRY, в то же время читабельный и нисколько не сбивая с толку других разработчиков. Пройдя фабричным маршрутом, я смог съесть свой торт и съесть его.
повторюсь.Моя самая большая проблема, с которой я столкнулся при использовании парадигмы установки / разрыва, заключается в том, что мои тесты не всегда следуют одному и тому же шаблону. Это заставило меня вместо этого использовать фабричные шаблоны, которые позволяют мне использовать DRY, в то же время читабельный и нисколько не сбивая с толку других разработчиков. Пройдя фабричным маршрутом, я смог съесть свой торт и съесть его.
Я согласен со всем, что говорит Джозеф, особенно с той частью, что tearDown является признаком написания интеграционных тестов (и в 99% случаев я использовал его для этого), но в дополнение к что я бы сказал, что использование настройки является хорошим индикатором того, когда тесты должны быть логически сгруппированы вместе, а когда они должны быть разделены на несколько тестовых классов.
У меня нет проблем с большими методами настройки при применении тестов к унаследованному коду , но установка должна быть общей для каждого теста в комплекте . Когда вы обнаружите, что метод настройки действительно выполняет несколько этапов настройки, пора разделить ваши тесты на несколько случаев.
Следуя примерам в «Test Driven» , появляется метод настройки из с удалением дублирования в тестовых примерах.
They've really helped with our test maintainability. Our "unit" tests are actually full end-to-end integration tests that write to the DB and check the results. Not my fault, they were like that when I got here, and I'm working to change things.
Anyway, if one test failed, it went on to the next one, trying to enter the same user from the first test in the DB, violating a uniqueness constraint, and the failures just cascaded from there. Moving the user creation/deletion into the [Fixture][SetUp|TearDown] methods allowed us to see the one test that failed without everything going haywire, and made my life a lot easier and less stabby.
У меня не было времени прочитать оба из того, что вы опубликовали, но мне особенно понравился этот комментарий:
каждый тест вынужден выполнять инициализацию того, что ему нужно для запуска.
Установка и удаление - это удобные методы - они не должны пытаться делать что-то большее, чем инициализировать класс, используя его конструктор по умолчанию и т. Д. Общий код, который требуется трем тестам в пяти тестовых классах, не должен там появляться - каждый из три теста должны вызывать этот код напрямую. Это также предохраняет тесты от того, чтобы наступать друг другу на пятки и ломать кучу тестов только потому, что вы изменили общую процедуру инициализации. Основная проблема в том, что это будет вызываться перед всеми тестами, а не только перед конкретными тестами. Большинство тестов должны быть простыми, а для более сложных потребуется код инициализации,
Если вам нужна настройка и разборка, чтобы ваши модульные тесты работали, может быть, вам действительно нужны фиктивные объекты?
У меня нет проблем с тестовой настройкой и методами разборки как таковыми.
Для меня проблема в том, что если у вас есть тестовая настройка и метод разборки, это означает, что тестовый объект повторно используется для каждого теста. Это потенциальный вектор ошибки, так как если вы забудете очистить какой-либо элемент состояния между тестами, результаты ваших тестов могут стать зависимыми от порядка. Что нам действительно нужно, так это тесты, которые не имеют общего состояния.
xUnit.Net избавляется от установки / разрыва, потому что он создает новый объект для каждого запущенного теста. По сути, конструктор становится методом настройки, а финализатор становится методом удаления. Между тестами отсутствует состояние (объектного уровня), что устраняет этот потенциальный вектор ошибки.
Большинство тестов, которые я пишу, имеют некоторую настройку, даже если она ' Я просто создаю нужные мне макеты и подключаю тестируемый объект к ним. Чего они не делают, так это обмена состояниями между тестами. Teardown - это просто убедиться, что я не разделяю это состояние.
Лично я обнаружил, что установка и разборка не всегда являются злом, и что эти рассуждения несколько догматичны. Но у меня нет проблем называть их запах кода для модульных тестов. Я считаю, что их использование должно быть оправдано по нескольким причинам:
- Тестовый код является процедурным по своей природе. В общем, установка / разборка до имеет тенденцию снижать читаемость / фокусировку теста.
- Методы настройки, как правило, инициализируют больше, чем требуется для любого отдельного теста. При злоупотреблении они могут стать громоздкими. Материнские объекты, построители тестовых данных, возможно, такие фреймворки, как FactoryGirl, кажутся лучше при инициализации тестовых данных.
- Они поощряют «раздувание контекста» - чем больше становится тестовый контекст, тем труднее его обслуживать.
В той степени, в которой моя установка / разборка не делает этого, я думаю, их использование оправдано. В тестах всегда будет какое-то дублирование. Нил Форд утверждает это как «Тесты могут быть мокрыми, но не намачиваемыми ...» Кроме того, Я думаю, что их использование более оправдано, когда мы говорим не о модульных тестах конкретно, а о интеграционных тестах в более широком смысле.
Работая самостоятельно, это никогда не было проблемой. Но мне было очень трудно поддерживать наборы тестов в команде, и это, как правило, связано с тем, что мы не сразу понимаем код друг друга или не хотим проходить его, чтобы понять его. С точки зрения тестирования, я обнаружил, что возможность дублирования в тестах облегчает эту нагрузку.
Я бы хотел услышать, что другие думают по этому поводу.
и, как правило, это происходит потому, что мы не сразу понимаем код друг друга или не хотим проходить его, чтобы понять его. С точки зрения тестирования, я обнаружил, что возможность дублирования в тестах облегчает эту нагрузку.Я бы хотел услышать, что другие думают по этому поводу.
и, как правило, это происходит потому, что мы не сразу понимаем код друг друга или не хотим проходить его, чтобы понять его. С точки зрения тестирования, я обнаружил, что возможность дублирования в тестах облегчает эту нагрузку.Я бы хотел услышать, что другие думают по этому поводу.
Я довольно часто использую настройку в Java и Python, часто для настройки соавторов (реальных или тестовых, в зависимости). Если тестируемый объект не имеет конструкторов или только соавторов в качестве конструкторов, я создам объект. Для простого класса значений я обычно не беспокоюсь о них.
Я очень редко использую разборку в Java. В Python он использовался чаще, потому что у меня было больше шансов изменить глобальное состояние (в частности, модули исправления обезьяны, чтобы получить пользователей этих тестируемых модулей). В этом случае я хочу выполнить разборку, которая гарантированно будет вызвана в случае неудачного теста.
Интеграционные тесты и функциональные тесты (которые часто используют платформу xunit), скорее всего, потребуют настройки и разборки.
Важно помнить. думать о светильниках , а не только о DRY.
Я думаю, что принцип DRY применим как для тестов, так и для кода, однако его применение отличается. В коде вы идете намного дальше, чтобы буквально не делать одно и то же в двух разных частях кода. В тестах необходимость делать это (делать много одинаковых настроек), безусловно, является запахом, но решение не обязательно состоит в том, чтобы исключить дублирование в метод настройки. Можно упростить настройку состояния в самом классе или изолировать тестируемый код, чтобы его значимость в меньшей степени зависела от этого количества состояния.
Учитывая общую цель тестирования только одной вещи за тест, в действительности невозможно избежать повторения одного и того же снова и снова в определенных случаях (например, при создании объекта определенного типа). Если вы обнаружите, что у вас их много, возможно, стоит пересмотреть подход к тестированию.