Как правильно выполнить юнит-тестирование с помощью макетов - PullRequest
Новая
       15

Как правильно выполнить юнит-тестирование с помощью макетов

0 голосов
/ 10 ноября 2011

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

Class A {
    public A() {}
}

Class B {
    private A a1;
    public A a2;

    public B(A a3) {}
    public A m1(A a4) {
        A a5 = new A();
        return a5;
    } 

}

Я хочу провести модульное тестирование в классе B. Я хочу, чтобы он тестировал только класс B, независимо от A. Как я узнал, мне нужно создать фиктивный класс для A. После этого я должен использовать его вместо A . Но как мне это сделать без изменения кода?

Я видел пример, когда A и макет A реализуют общий интерфейс, а затем в классе B интерфейс является формальным типом параметров вызова метода. Это правильный способ сделать это? Это поможет только a2, a3 и a4, но что мне делать с остальными?

2) Как мне могут помочь такие фреймворки, как mokito? Стоит ли усилий, чтобы научиться с ними работать?

Ответы [ 2 ]

2 голосов
/ 10 ноября 2011

Моты по определению имеют тот же тип, что и аргумент или зависимость, которые они заменяют.Таким образом, они являются либо подклассом A (если A является конкретным классом), либо реализацией A (если A является интерфейсом).

Моделирование интерфейсов, как правило, проще, чем моделирование конкретных классов, и выражение зависимостей в терминах интерфейсов, а не конкретных классов, уменьшает сцепление и позволяет упростить моделирование и, следовательно, тестирование.

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

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

2 голосов
/ 10 ноября 2011

В этом случае вы этого не сделаете, потому что вы напрямую создаете экземпляр A. Моксы предназначены для внедрения реализаций - одна из причин, по которой DI / IoC - хорошая идея.

Чем больше привязан кРеализации, где бы вы ни находились, тем более трудным будет тестирование, имитирует или нет.

Имитация IMO - это фантастический инструмент, и разработчики должны быть знакомы с его использованием.Они не подходят в любой ситуации, но когда вы разрабатываете с учетом тестирования, они действительно полезны.

...