TDD: имеет ли смысл проверять, что конструкторы устанавливают свойства?

Question

[TDD newbie]

У меня есть класс Car со свойствами Color и Brand.

Имеет ли смысл в TDD проверить, что конструктор устанавливает эти свойства?Или я подожду с тестированием (и внедрением) этого, пока мне это не понадобится?

Итак, я собираю тесты, подобные этим:

(c #)

public class CarTests
{
  public void Constructor_Should_Set_Color()
  {
    var car = new Car("Green", "Volvo");

    Assert.Equals(car.Color, "Green");
  }
}

Илиподождать, пока у меня не появится сценарий сценария использования, в котором я должен, например, отфильтровать все зеленые автомобили из списка, построенного с помощью конструктора, что приведет к сбою, поскольку у автомобилей будет нулевой цвет?

Действительно ли имеет смысл напрямую тестировать конструкторы?А как насчет Equals ()?

Answer 1

В идеале, я думаю, у вас не было бы даже свойства Color, пока оно вам не понадобилось бы. В этот момент вы можете просто использовать установщик, или вы можете добавить его в конструктор, или добавить новый конструктор. Второй вариант оставляет вас в состоянии с двумя (или более) конструкторами - и вы можете найти, что это полезно; во многих случаях (как для тестов, так и для «обычного» кода) вы не можете заботиться , какого цвета автомобиль. И , что тестирует ваш дизайн.

Answer 2

Если вы на самом деле делаете TDD, у вас не будет свойств Color и Brand, пока не будет проведен тест, требующий их существования.

Этот тест, вероятно, не должен походить на ваш тест конструктора, а должен проверять что-то еще, что касается цвета или бренда.

Answer 3

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

Хотя пуристы, скорее всего, захотят получить почти 100% тестовое покрытие, есть также разработчики, которые тестируют только нетривиальные вещи.Граница между этими двумя крайностями размыта.

Answer 4

Я обычно не беспокоюсь о тестировании конструкторов и Equals, если они не слишком сложны.Если они усложняются или я сталкиваюсь с ошибкой, я добавляю тесты.Хотя это может быть сигналом того, что ваш класс становится слишком сложным и нуждается в рефакторинге, что можно сделать безопасно только в том случае, если ваш класс защищен сетью тестов безопасности.

Из тест-ориентированногов перспективе вы, вероятно, в любом случае не начнете с тестирования конструктора.Потребность в классе или методе возникнет из-за некоторого сценария, в котором он полезен и должен быть проверен в этом контексте.

Answer 5

Это поднимает интересную загадку для моего в значительной степени пред-TDD мышления.

Условно моя интерпретация ООП предполагает, что класс вашего автомобиля должен представлять реальность.Это означает, что автомобиль должен приобретать свой цвет при создании, и он не может быть изменен после этого, кроме как каким-то «специальным» методом, который перекрашивает автомобиль, и только тогда, когда ваша бизнес-логика позволяет это.

Я полагаюОтвет TDD заключается в том, что вы не можете моделировать реальность, и вместо этого вам следует смоделировать область допустимых поведенческих изменений в вашем приложении.Возможно, автомобиль является гипотетическим будущим автомобилем в онлайн-приложении для заказа или моделью в игре, которая может плавно менять цвет.В любом случае, описанный выше подход Paeleo-OOP недопустим в философии TDD.

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