Как проверить, что объекты обновляются с использованием поддельного хранилища - PullRequest
Новая
       19

Как проверить, что объекты обновляются с использованием поддельного хранилища

1 голос
/ 23 сентября 2010

Скажите, у меня есть следующая бизнес-логика: 

    foreach (var item in repository.GetAll())
    {
        if (SomeConditition)
        {
            item.Status = Status.Completed;
            repository.Update(item);
        }
    }

Теперь я пишу следующий юнит-тест: 

    public void Test()
    {
        var repository = new FakeRepository();
        repository.Add(new Item());

        RunBusinessLogic(repository);

        Assert.AreEqual(Status.Completed, repository[0].Status);
    }

FakeRepository реализован поверх List, а GetAll () просто возвращает список.

Хотя я могу протестировать большую часть логики, связанной с использованием этого подхода, я не могу проверить, что я запомнил вызов repository.Update () в бизнес-коде. Поскольку FakeRepository.GetAll () возвращает фактические объекты, объекты репозитория уже будут изменены бизнес-кодом, прежде чем я вызову Update (). Фактически, FakeRepository.Update () ничего не делает.

Я понимаю, что могу использовать FakeRepository.Update, чтобы записать, что он был вызван, и подтвердить это в тесте. Но если я забуду позвонить в «Обновление», мне тоже нельзя будет доверять «Утвердить обновление», верно? Я бы предпочел, чтобы тест просто провалился, если вызов Update пропущен.

Есть идеи?

Ответы [ 5 ]

3 голосов
/ 23 сентября 2010

Здесь может быть полезен фальшивый фреймворк, поскольку он позволяет вам проверить, какие методы на самом деле вызываются. Чтобы назвать несколько:

А вот хорошее сравнение между этими тремя популярными фреймворками.

1 голос
/ 24 сентября 2010

Есть несколько вещей, которые можно отдельно протестировать здесь: методы Repository.getAll() и Repository.update(), а также оценка условия завершения для каждого предмета или каждого вида предмета.Я не уверен, что здесь я буду использовать FakeRepository.

Как и предполагалось, другой вариант - записать и / или подсчитать количество обновлений метода FakeRepository.update().

Но если я забуду позвонить в «Обновление», мне нельзя будет доверять «Утвердить обновление», верно?

Правильно, но когда вы следуете процессу TDD, вы сначала провалите свой тест - красным, а затем напишите код, который сделает его успешным - зеленым.Сначала вы напишите утверждение, в результате чего тест не пройден, а затем вызовите метод update (), чтобы выполнить тест.

1 голос
/ 23 сентября 2010

Я понимаю, что могу использовать FakeRepository.Update, чтобы записать это это называется, утверждают, что в тест. Но если я забуду позвонить Обновление, мне нельзя доверять не забудьте утверждать обновление либо, право? Я бы предпочел тест просто потерпите неудачу, если вызов обновления опущено.

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

0 голосов
/ 06 сентября 2011

Лучшим способом является использование Dev Magic Fake, так что вы можете смоделировать базу данных и быть постоянными, вы также можете смоделировать пользовательский интерфейс

Просто добавьте ссылку на DevMagicFake.dll

И вы можете кодировать следующее: 

[HttpPost]
public ActionResult Create(VendorForm vendorForm)
{
   var repoistory = new FakeRepository<VendorForm>();
   repoistory.Save(vendorForm);
   return View("Page", repoistory.GetAll());
}

Это сохранит перманент VendorForm в памяти, и вы можете получить его в любое время. Вы также можете сгенерировать данные для этого объекта или любого другого объекта в вашей модели, для получения дополнительной информации.информацию о Dev Magic Fake смотрите по следующей ссылке на CodePlex:

http://devmagicfake.codeplex.com

Спасибо

M.Radwan

0 голосов
/ 13 декабря 2010

Учитывая, что ответ еще не был принят, и что ответы верны (по моему скромному мнению!), Я могу предположить, что Тор Ховланд может задавать немного другой вопрос:

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

Если это так, то нужно сказать две вещи:

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

Если есть код приложения, который не вызывает Update () правильно, и код просто полагается на это (Кто знает, почему ... Возможно, в коде есть ошибка, которая просто работает, потому что она не ' не вызывать Update?), и разработчик изменяет библиотеки так, что некоторые свойства изменяются так, что Update () либо вызывается автоматически, либо вызывающий ошибку код вызывает его, теперь у вас есть изменение в функциональности, которое делают ваши модульные тесты не тестировать, потому что они всегда вызывают обновление.

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

Чтобы повторить и перефразировать мой несколько многословный ответ, не проверяйте тесты .

...