Как выполнить модульное тестирование функции, которая вставляет запись в базу данных RIA Services? - PullRequest
3 голосов
/ 13 октября 2009

Это пример функции, которая работает с сущностью, сохраняет ее в БД, а затем вызывает проблемы, потому что мы не можем написать для нее модульный тест. Проверьте это:

// this class exists in a Silverlight Class Library
public class EmployeeSaver
{
    ....

    public void Go()
    {
        Employee e = new Employee();

        e.Name="Jeremiah";

        ... // Other stuff that really needs to be tested

        _DataContext.Employees.Add(e);
        _DataContext.SubmitChanges();

    }
}

Поскольку службы RIA по своей природе не работают, DomainService не работает внутри инфраструктуры модульного тестирования Silverlight. Это означает, что у меня нет доступа к RIA, когда я выполняю свои модульные тесты.

Мы думали о фиктивных базах данных, но этот класс фактически создает Entity (Employee) для добавления в БД. Это проблематично, поскольку базы данных Mock используют не эту сущность, а класс MockEntity, который похож на исходную сущность.

Мы не пытаемся протестировать саму RIA, но как мы используем сущности, созданные RIA.

Моя конечная цель - написать функцию, подобную этой:

[TestMethod]
public void Test()
{
    EmployeeSaver s = new EmployeeSaver();
    s.Go();

    Assert.IsEqual( DataContext.Employees.Last().Name, "Jeremiah" );
}

Как я могу проверить эту функцию? Какие рамки тестирования мне следует использовать? Могу ли я использовать платформу тестирования Silverlight?

Ответы [ 2 ]

2 голосов
/ 14 октября 2009

В вашем модульном тесте экземпляры s должны иметь заглушенную реализацию _DataContext. Когда вызывается метод Go и он вызывает: _DataContext.Employees.Add (е); _DataContext.SubmitChanges (); это вызовет в твою заглушку. Затем заглушка должна записать факт добавления сотрудника и отправки изменений.

После вызова Go вы должны запросить заглушку, чтобы убедиться, что новый сотрудник был добавлен, и произошел вызов SubmitChanges.

В качестве вторичной ноты: Я не совсем согласен с последней частью другого ответа в том, что вас не должно волновать, вызывает ли Go различные методы _DataContext. Это правда, что вы не беспокоитесь о тестировании методов _DataContext здесь, но модульный тест для Go должен убедиться, что метод Go правильно вызывает методы _DataContext. Обоснование заключается в том, что каждая строка метода Go должна быть тестируемой. Если вы не сделали эту проверку, вы можете удалить вызовы метода _DataContext, нарушив код, но модульный тест не поймает его. Это нарушило бы принцип «трех правил TDD» Боба Мартина.

1 голос
/ 14 октября 2009

Ручная свернутая база данных может хранить ваш объект как есть. Мы используем такую ​​систему, где хранилища хранятся в словарях.

Тебе даже не нужно заходить так далеко. Вы можете просто использовать фиктивный интерфейс для _DataContext с чем-то вроде RhinoMocks, чтобы убедиться, что методы, которые вы ожидаете вызывать, были (это не ваше беспокойство о том, что _DataContext.SubmitChanges () работает (это будет работать, если это модульный тест) Вы заботитесь только о том, чтобы Go установил объект и вызвал save.

...