Подсказки относительно того, как записать благоприятной для рефакторинга единице тесты TDD

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

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

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

Эта статья мне очень помогла: http://msdn.microsoft.com/en-us/magazine/cc163665.aspx

С другой стороны, чудо нет Способ избежать рефакторинга тестов.

Все поставляется с ценой, и это особенно верно, если вы хотите сделать тестирование подразделения.

Что я думаю, что он означает, что это часть установки, которая довольно утомительна для обслуживания. У нас есть той же проблема, особенно когда мы введем новые зависимости, разделенные зависимости или иным образом изменить, как должен использоваться код.

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

Однако это не очень хорошая вещь, потому что мы все еще должны создавать все эти значения в каждом тесте. Итак, мы сейчас изучаем наши тесты в более подробном стиле спецификации / BDD, что должно помочь уменьшить код установки, и поэтому количество времени, проведенного в поддержании тестов. Несколько ресурсов, которые вы можете проверить, это http://elegantcode.com/2009/12/22/specifications/ и стиль BDD тестирования с MSPEC http://elegantcode.com/2009 / 07/05 / MSPec-Take-2 /

Две площади, на которых я сосредотачиваюсь, когда я начинаю чувствовать, что боль от рефакторов вокруг установки делает мою единицу тесты более конкретными, а мой метод / класс меньше. По сути, я считаю, что я ухожу от Solid / SRP. Или у меня есть тесты, которые пытаются сделать с большим количеством.

Стоит отметить, что я попробую и держусь вдали от BDD / Context Spec, тем дальше от UI, который я получаю. Тестирование поведения отлично, но всегда ведет меня (возможно, я не делаю это правильно?) Для более крупных тестов Мессера, с большим количеством контекстных спецификаций, чем мне нравится.

Еще один способ, которым я видел, чтобы это случилось со мной, - это в качестве дебета кода, ползет в методах, которые растут их бизнес-логику со временем. Конечно, всегда есть большие методы и класс с несколькими зависимостями, но тем меньше у меня меньшее «тестовое переписывание».

Большую часть времени я вижу такие рефакторы, влияющие на настройку модульного теста, часто предполагающие добавление зависимостей или изменение ожиданий от этих зависимостей. Эти зависимости могут быть введены более поздними функциями, но влияют на более ранние тесты. В этих случаях я нашел очень полезным рефакторинг настроенного кода, чтобы его можно было совместно использовать в нескольких тестах (параметризируя таким образом, чтобы его можно было гибко настроить). Затем, когда мне нужно внести изменения для новой функции, которая влияет на настройку, мне нужно рефакторизовать тесты только в одном месте.

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

вместо:

public class A {

   public void foo(B b) {
      String someField = b.getC().getD().getSomeField();
      // ...
   }
} 

измените его на:

public class A {

   public void foo(String someField) {
      // ...
   }
} 

Тогда настройка тестов станет тривиальной.