Отсутствие поддержки базового класса в Junit4 / Jmock2 - PullRequest
1 голос
/ 14 июля 2009

Наконец, мы переносим нашу кодовую базу модульных тестов с JUnit 3 на JUnit 4. Мы также интенсивно используем JMock 2.

В JUnit 3 JMock предоставляет полезный базовый класс для ваших тестов (MockObjectTestCase), который, будучи подклассом TestCase Junit, выполняет различные служебные обязанности, связанные с макетом фреймворка. Это облегчает жизнь тестовому классу.

Теперь с JUnit4 JMock не предоставляет такой поддержки. Ваш тестовый класс должен вручную создать объект Mockery, он должен помнить, что нужно использовать правильную аннотацию для выполнения тестов, и должен делегировать все связанные с имитацией операции над mockery. Короче говоря, это возлагает гораздо большую ответственность на тестовый класс, чем было необходимо для тестов JUnit 3.

Теперь я ценю то, что часть прелести JUnit4 заключается в том, что нет необходимости что-то создавать в подклассе, но эта ситуация с JMock кажется шагом назад и делает перенос с 3 на 4 более трудоемким, чем необходимо.

Я что-то упустил? Есть ли на самом деле хороший способ написать мои тестовые классы JUnit4 / Jmock2, не добавляя вручную всю эту сантехнику в каждый класс? Конечно, я мог бы написать свой собственный базовый класс поддержки, но это кажется таким очевидным упущением в API JMock2, что я должен задаться вопросом, упустил ли я этот момент.


Редактировать: вот исходный код того, как будет выглядеть необязательный класс поддержки:

@RunWith(JMock.class)
public class JMockSupport {

    protected final Mockery mockery = new Mockery();

    protected void checking(ExpectationBuilder expectations) {
        mockery.checking(expectations);
    }

    protected <T> T mock(Class<T> typeToMock) {
        return mockery.mock(typeToMock);
    }

    protected <T> T mock(Class<T> typeToMock, String name) {
        return mockery.mock(typeToMock, name);
    }

    protected Sequence sequence(String name) {
        return mockery.sequence(name);
    }

    protected void setDefaultResultForType(Class<?> type, Object result) {
        mockery.setDefaultResultForType(type, result);
    }

    protected void setImposteriser(Imposteriser imposteriser) {
        mockery.setImposteriser(imposteriser);
    }

    protected void setNamingScheme(MockObjectNamingScheme namingScheme) {
        mockery.setNamingScheme(namingScheme);
    }

    protected States states(String name) {
        return mockery.states(name);
    }
}

Содержит все методы, определенные классом JUnit3 MockObjectTestCase, которые просто отражают насмешку. Также имеется аннотация @RunWith, чтобы избежать возможности забыть добавить ее в свой тестовый класс.

Ответы [ 3 ]

2 голосов
/ 14 июля 2009

Я тоже сделал эту миграцию, и это боль. Я могу понять, почему они создали механизм базового класса - я пытался манипулировать базовыми классами JMock с помощью базовых классов с поддержкой Spring JUnit, и это очевидно не работает.

После того, как я приступил к этой миграции, одна область, которую я нашел для «оптимизации», создавала соответствующие базовые классы Expectation, инкапсулирующие общие операции с вашими фиктивными объектами, вместо создания нового объекта (и экземпляра) Expectation для каждого теста. Это избавит вас от небольшого горя.

1 голос
/ 05 сентября 2009

Есть также проблемы с наличием базовых классов. В предыдущих версиях я страдал от попыток объединить базовые классы из разных тестовых сред. Вот почему мы пошли на композицию по наследству. Будет интересно посмотреть, что мы можем сделать с новой структурой @Rule.

1 голос
/ 14 июля 2009

Нет. Там нет такой поддержки.

Тестовый базовый класс в JMock 1 вызвал много проблем, потому что вы можете расширить только один класс, и поэтому люди не могли использовать JMock с другими тестовыми средами, которые также определяли базовые классы. Вот почему мы пошли с делегированием, а не наследованием в JMock2.

Тем не менее, вы можете использовать класс MockObjectTestCase из библиотеки поддержки JMock2 JMock2, если вы аннотируете свой класс с помощью @RunWith (JMock.class). Но я не пробовал.

Был запрос на "авто-насмешливый" бегун JUnit4, который создаст для вас контекст и будет имитировать объекты с помощью автоматического отражения. Некоторым это нравится, другим действительно не нравится. Если вы хотите эту функцию, проголосуйте за проблему в JMock JIRA .

...