2013-11-19 5 views
0

У меня есть класс обслуживания MyBusinessService с 2 методами doABC() и doXYX(). Метод doABC() делегирует работу ABCHandler.do(), а метод doXYX() делегирует работу XYZHandler.do(). Методы класса MyBusinessService просто делегируют работы соответствующим обработчикам.Java - модульные тестовые примеры для делегирования класса

У меня есть вопрос здесь. Когда я пишу Unit для этого, я должен написать модульные тесты для методов в обработчиках. Должен ли я писать UT для методов класса MyBusinessService. Я задаю этот вопрос по двум причинам.

a. В тестах UT одна функциональность не должна тестироваться в двух местах. Моя фактическая логика находится в классах обработчиков, и я не должен тестировать одну и ту же логику как в классе обработчика, так и в классе обслуживания

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

Пожалуйста, дайте мне знать, следует ли мне писать UT для делегирования класса (класс MyBusinessService) или я должен оставить его в тестовых случаях интеграции для его решения.

+0

Используйте шпиона или макет (см 'Mockito.spy()' или 'Mockito.mock()', например) и тест для правильного делегация? –

+1

Где вы получили правило a? На мой взгляд, всегда ошибаться на стороне слишком много тестирования, а не на недостаточном уровне. Если это означает дублирование некоторых тестов, пусть так и будет. – DanK

+0

@RC, я хочу знать, действительно ли нужно писать UT для проверки делегирования? Потому что он автоматически проверяется. – javalearner

ответ

0

Испытание на единицу измерения должно проверять только один класс. Если вы тестируете взаимодействие более чем одного экземпляра класса, чтобы вы проводили интеграционное тестирование. Вы должны рассмотреть возможность использования какой-либо макетной библиотеки, такой как jmock или mockito, первая из которых лучше подходит для моих целей.

Если вы используете JMock вы можете сделать, как описано выше:

@Test 
public void someTestMethod(){ 
MyBusinessService instance = new MyBusinessService() 

Mockery context = new Mockery(); 
ABCHandler mock1 = context.mock(ABCHandler.class); //creating a mock object 

instance.setABCHandler(mock1); 

context.checking(new Expectations(){{ 
    oneOf(mock1).do(); //creating a expectation wich expects exactly on call of method do. 
}}); 

instance.doABC(); 

context.assertIsSatisfied(); //check if the expectation is met 

} 
+0

Я думаю, что это определение модульного тестирования слишком ограничительно. Там, где я работаю, мы ссылаемся на модульное тестирование как на все тесты, выполненные программистом, чтобы проверить, что новый введенный звук является правильным. Таким образом, это включает тесты в различных классах. С другой стороны, тестирование интеграции - это серия тестов, которые работают против остальной системы (также как и другие модульные тесты программиста), чтобы убедиться, что что-то новое не нарушило функциональность в другом месте. – DanK

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