2015-06-11 3 views
1

Допустим, у меня есть класс JUnit под названием Test.class. Test.class имеет около 50 тестов JUnit и на 30 тестов JUnit, всегда появляется эта строка кода:Является ли мой способ повторного использования в тестах JUnit плохой?

Примечание: Я использую Mockito/PowerMock

when(ConnectionHandler().getConnection()).thenReturn(connection);

Я планирую создать служебный класс называется TestUtils.class и создать частный метод для линии выше, как:

public static stubConnection(Connection connection) { 
    when(ConnectionHandler().getConnection()).thenReturn(connection); 
} 

Таким образом, вместо того, чтобы писать вниз when(ConnectionHandler().getConnection()).thenReturn(connection); каждый раз, когда я мог бы просто пойти на TestUtils.stubConnection(connection);

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

+0

Если это имеет смысл для вас и экономит ваше время, то да, это хорошая идея. – ChrisStillwell

+0

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

+0

@Savagewood. После небольшого рефакторинга у меня есть частный метод в 'Test.class' с именем' stubConnection() ', который в основном делает то же самое, что и 'TestUtils # stubConnection'. Тем не менее, я уверен, что этот метод также будет использоваться в других тестовых случаях JUnit - вот почему я планирую переместить его в другом месте:/ – mpmp

ответ

1

Это рекомендуется? Я просто вижу много повторяющихся кодов в тестах JUnit .

Абсолютно. Тот факт, что это единичный тест (почти) не имеет отношения к делу, это все еще код, который вы или кто-то еще должны поддерживать. Инкапсулирование его в утилиту или класс обслуживания - это, безусловно, шаг в правильном направлении.

+0

Я обеспокоен читабельностью, хотя - есть ли лучший способ сделать мои модульные тесты читаемый, предполагая, что мне нужно создавать классы утилит для инкапсуляции? – mpmp

+1

Я думаю, что метод, который вы создали ('TestUtils.stubConnection (connection)'), отлично читается; он точно описывает, что он делает. Существует определенная сложность, требуемая при использовании насмешливых фреймворков, скрывая эту сложность, может сделать код более читаемым, но это также сделает его намного более загадочным! – StuPointerException

+0

Хорошо! Для проблем с читабельностью я решил просто импортировать его статически, поэтому он просто будет выглядеть как «stubConnection()» в моем коде. Спасибо за ваш вклад! – mpmp

Смежные вопросы