Возможно ли провести тестирование этого метода?

Question

У меня есть следующий метод, для которого я пытаюсь написать модульный тест:

using StaticClass;   // writen by some one else, have a dll 

namespace Test 
{ 
    Class TestClass 
    { 
     public void DoSomething(string param1) 
     { 
     List<string> = StaticClass.GetList(param1) 

     // sort the list and do other studd here 
     } 
    } 
} 

Когда я не знаю, как написать тест для метода DoSomething, который зависит от статического метода в другом классе. Результат этого метода зависит от таких вещей, как база данных на этой машине, окружающая среда и несколько других факторов. Поэтому, если базы данных на двух машинах отличаются друг от друга, тот же метод даст разные результаты. Все, что я знаю, это то, что GetList возвращает некоторое значение, и этот метод может или не может быть проверен модулем создателем этого класса.

Как проверить такой метод? Можно ли что-то сказать, когда метод StaticClass.Getlist называется возвратом пользовательского List<String>, который я создал в своей программе? Я пишу тесты на C#.

Спасибо,

Answer 1

Статические типы с методами, которые имеют побочные эффекты, являются хлопотными.

У вас есть два варианта:

• Кратковременных Написать интерфейс, который имеет метод GetList с правой подписью. Затем напишите адаптер - класс, который реализует этот интерфейс и делегирует StaticClass внутренне. Передайте экземпляр этого типа адаптера в ваш класс как ctor arg или метод arg. Вызовите GetList. Теперь вы можете использовать фальшивую фреймворк для создания макетного объекта и передать его в свои тесты и настроить его для возврата сохраненных значений.
• Долгосрочный: преобразовать StaticClass в нестатический. Передайте его (вместо объекта адаптера); но для этого требуется доступ к исходному коду для StaticClass.

Answer 2

Вы должны будете использовать Mock объекты для проверки такого рода вещи. См. Эту замечательную статью: http://gamesfromwithin.com/mock-objects-friends-or-foes

В основном вы создадите объект, который эмулирует объекты, с которыми он взаимодействует, и затем проверит ваши ожидания.

Answer 3

Если я вижу это право, этот метод не будет компилироваться. Но если вам нравится тестировать метод в статическом классе, это может быть проверено отдельно.

Метод в вашем классе ничего не возвращает. Если в системе есть только входы, которые вам не нужны, чтобы реализовать их.

Answer 4

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

что-то вроде

Class StaticClassWrapper { 
    public List<string> GetList(string param1) { 
    return StaticClass.GetList(param1); 
    } 
} 

, а затем использовать обертку вместо статического класса в вашем TestClass

Answer 5

Сделать StaticClass зависимостях, что вы можете издеваться с Moq, Rhino и т.д. Затем Вы свободны либо изматывать StaticClass, чтобы вернуть известный List<string> или просто проверить, что он вызван через макет.

Answer 6

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

Один из подходов - отвлечь работу этого класса на что-то другое.

Например, вы могли бы объявить

public interface ISomeonesDllService 
{ 
    IList<string> GetList(string param1); 
} 

Теперь создаст реализацию, которая использует StaticClass:

public class SomeonesDllService : ISomeonesDllService 
{ 
    public IList<string> GetList(string param1) 
    { 
     return StaticClass.GetList(param1); 
    } 
} 

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

public class TestClass 
{ 
    ISomeonesDllService dllService; 

    public TestClass(ISomeonesDllService dllService) 
    { 
     this.dllService = dllService; 
    } 

    public void DoSomething(string param1) 
    { 
     IList<string> strings = dllService.GetList(param1); 
     // do work 
    } 
} 

Теперь вы может очень легко протестировать метод DoSomething(), потому что в вашем тестовом устройстве вы можете создать экземпляр TestClass, используя другую реализацию ISomeonesDllService. Вы можете вручную скрыть заглушку, которая просто возвращает статический список строк, или вы можете использовать фальшивую фреймворк, например Rhino.Mocks, чтобы настроить это для вас (что я рекомендую).

Таким образом вы можете изолировать DoSomething() от работы внешних зависимостей.