Как повторно использовать методы тестирования JUnit для разных контекстов тестирования?

Question

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

В настоящее время я использую JUnit 4 под JavaEE 8.

Моя ситуация выглядит примерно так.Учитывая тест, подобный следующему:

class TestExample {
    Context context;

    @Before
    public void setUp() {
        context = new ContextA();
    }

    @After
    public void terminate() {
        context.dispose();
    }

    @Test
    public void test1() {
        context....
    }
}

abstract class Context {
    @Override
    public void dispose() {
        ...
    }
}

class ContextA extends Context {
}

class ContextB extends Context {
}

Я хотел бы иметь возможность выполнить тест один раз для ContextA, а затем для ContextB.

Answer 1

Как повторно использовать методы тестирования JUnit для различных контекстов тестирования?

Как правило, вы делаете , а не .

Один из ключевых моментов модульных тестов: они помогают вам быстро выявлять ошибки, когда вы позже вносили изменения в производственный код.Значение: основное требование для модульных тестов - вы можете быстро прочитать и понять .Все, что делает это сложнее, например, «сложные» решения, позволяющие избежать дублирования кода, проблематично.

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

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

Сказав это, одно из возможных решений: если вы действительно хотите выполнить одни и те же тесты на нескольких «входах», то я предлагаю вам взглянуть на параметризованные тесты, например.Вместо жесткого кодирования вашего экземпляра context в коде @Before, вы можете просто иметь несколько различных context объектов и запускать все тесты для каждого из них.

Answer 2

Другим подходом может быть улучшение вашего дизайна :

В вашем случае оба проекта используют один и тот же базовый класс.Вы можете применить подход Favor Composition к наследованию , превратив Context в обычный класс (удалив ключевое слово abstract) и переместив его в общий базовый проект.Таким образом, у вас есть единственная точка, в которой вы тестируете поведение Context.

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

interface Context {
   public void dispose();
}

class ContextImpl implements Context {
    @Override
    public void dispose() {
        ...
    }
}

class ContextA implements Context {
    private final Context common;
    ContextA(@Inject Context common){
       this.common = common;
     @Override
    public void dispose() {
        common.dispose();
    }
}

class ContextB implements Context {
    private final Context common;
    ContextB(@Inject Context common){
       this.common = common;
     @Override
    public void dispose() {
        common.dispose();
    }
}

Затем вы проверяете (наряду со специальным поведением ContextA и ContextB соответственно), что ожидаемые методы в переданном экземпляре Context вызываются.

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

---

иногда это может быть даже лучшесделать это наоборот и внедрить специализированные реализации в класс, содержащий общее поведение ...