Тестирование светильников при использовании веб-сервисов

Question

Я все еще новичок в TDD, и я также пытаюсь работать с устаревшим приложением, которое не было создано с учетом тестирования.

Одна функция (ошибка), которую я пытаюсь проверить, - это определение того, находится ли заказ в состоянии, позволяющем пользователю планировать доставку.

История такова: при заказе с датой ReadyFrom> 10 дней и <28 дней с сегодняшнего дня, когда [веб-сервис для проверки заказа находится в действительном состоянии для доставки] возвращает true, система должна перечислить 7 доступных дат доставки начиная с даты ReadyFrom </p>

Итак, я определил несколько заказов, подходящих для тестирования этих условий. Я думаю, что я должен также сделать заглушку для веб-службы, поэтому она возвращает true или false в зависимости от теста.

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

Правильно ли я считаю, что я должен поместить тестовые заказы в прибор и динамически изменять соответствующие значения дат для этих заказов во время настройки, прежде чем использовать их в тесте, и динамически изменять свои ожидания от набора дат доставки. система отправляет обратно (даты доставки также возвращаются веб-службой, которая также должна быть проверена)

Или это может вызвать проблемы при разработке приложения?

Спасибо

Answer 1

Я использую шаблон построителя тестовых данных для создания тестовых данных и настраиваю его в самом методе теста. ИМХО это делает очень читаемый тестовый код. Строитель сам по себе выглядит примерно так (C # + Rhinomocks):

public class OrderBuilder 
{
  MockRepository _mockRepository;
  IOrder _order;

  public OrderBuilder()
  {
    _mockRepository = new MockRepository();
    _order = _mockRepository.Stub<IOrder>(); 
  }

  public OrderBuilder WithDate(DateTime date)
  {
    _order.Date = date; 
    return this; 
  }

  public IOrder Build()
  {
    _mockRepository.ReplayAll();
    return _order; 
  }

}

В тестовом методе заказ создается с этим синтаксисом:

DateTime someValidDate = new DateTime(1,2,2012);

IOrder order = new OrderBuilder()
                      .WithDate(someValidDate)
                      .Build();

Разве это не красиво? : о)

Answer 2

Поместите тестовые заказы в прибор

Да.

динамически изменять соответствующие значения даты в этих заказах во время настройки

Вроде.

Не делайте это слишком сложным. Fixture должен иметь несколько тестовых заказов с фиксированными, известными датами. Вам не нужно слишком много менять.

Если - по какой-то причине - даты не могут быть фиксированными, известные даты, тогда setUp делает три вещи.

1. Строит заказы "с нуля" с соответствующими датами.

2. Конфигурирует макет с соответствующими датами.

3. Сохраняет некоторые подсказки «ожидаемых результатов» для фактических тестов, которые будут использоваться.

Снова. Не делайте это звучит сложно. Ты не "динамически меняешь мои ожидания". Вы просто устанавливаете ожидания в настройках.

динамически изменить мои ожидания от набора дат доставки, которые система отправляет обратно (даты доставки также возвращаются веб-службой, которая также должна быть подвергнута насмешке)

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