Код модульного тестирования, использующий API - PullRequest
1 голос
/ 25 ноября 2010

У меня есть этот простой метод, который вызывает API TFS (сервер Team Foundation) для получения объекта WorkItemCollection.Я только что преобразовал в класс сущности, а также добавил его в кеш.Как видите, это очень просто.

Как мне провести модульное тестирование этого метода.Единственное, что важно, это вызов API TFS.Стоит ли тестировать такие методы?Если да, то как мы должны это проверить?

Один из способов, которым я могу подумать, - это смоделировать вызов Query.QueryWorkItemStore (query) и вернуть объект типа «WorkItemCollection» и посмотреть, наконец, этот метод преобразует «WorkItemCollection».к списку.И проверьте, был ли он добавлен в кеш или нет.

Кроме того, поскольку я использую шаблон внедрения зависимостей, она вводит зависимость для

  • кеш
  • Запрос

Должен ли я передавать только зависимость по ложному типу (используя MOQ) или я должен передавать правильный тип класса.

public virtual List<Sprint> Sprint(string query)
{
    List<Sprint> sprints = 
        Cache.Get<List<Sprint>>(query);

    if (sprints == null)
    {
        WorkItemCollection items = 
            Query.QueryWorkItemStore(query);
        sprints = new List<Sprint>();

        foreach (WorkItem i in items)
        {
            Sprint sprint = new Sprint
            {
                ID = i.Id,
                IterationPath = i.IterationPath,
                AreaPath = i.AreaPath,
                Title = i.Title,
                State = i.State,
                Goal = i.Description,
            };

            sprints.Add(sprint);
        }

        Cache.Add(sprints, query, 
            this.CacheExpiryInterval);
    }

    return sprints;
}

1 Ответ

3 голосов
/ 25 ноября 2010

Должен ли я передавать только зависимость по ложному типу (используя MOQ), или я должен передавать правильный тип класса.

В ваших модульных тестах вы должны передать имитацию.Есть несколько причин:

  • Макет прозрачный : он позволяет проверить, что тестируемый код правильно работал с макетом.
  • Aмакет дает вам полный контроль , что позволяет вам тестировать сценарии, которые трудно или невозможно создать на реальном сервере (например, throw IOException)
  • Макет предсказуемый .Реального сервера нет - он может быть недоступен даже при запуске ваших тестов.
  • То, что вы делаете на макете , не влияет на внешний мир .Вы не хотите изменять данные или приводить к сбою сервера, выполняя ваши тесты.
  • Тест с имитаторами * на 1025 * быстрее .Нет необходимости подключаться к серверу или выполнять запросы к реальной базе данных.

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

edit: некоторые объекты соавторов, такие как ваш объект Cache, также могут быть очень дружественными к юнит-тестам.Если у них те же преимущества, что и у макета, который я перечислю выше, вам не нужно создавать макет.Например, обычно не нужно издеваться над коллекцией .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...