2013-05-28 4 views
9

Учитель хотел, чтобы мы провели всесторонний единичный тест. Для меня это будет первый раз, когда я использую JUnit. Я смущен насчет тестирования и получения методов. Как вы думаете, следует ли мне их проверять? Если ответ «да»; этот код достаточно для тестирования?модульные испытания сеттеров и геттеров

public void testSetandGet(){ 
    int a = 10; 
    Class firstClass = new Class(); 
    firstClass.setValue(10); 
    int value = firstClass.getValue(); 
    Assert.assertTrue("Error", value==a); 
    } 

В моем коде, я думаю, что если есть ошибка, мы не можем знать, что ошибка вывода из-сеттер или геттер.

+0

Рассмотрите возможность использования Assert.assertEquals (a, value). –

+2

Кроме того, было бы лучше, если вы используете 'firstClass.setValue (a);' вместо hardcoding '10'. –

+3

Спросите своего учителя, должны ли вы их протестировать. Поскольку это оценено, его/ее мнение - единственное, что имеет значение. – thegrinner

ответ

2

Если бы я был вами, я бы сначала set какое-то значение для свойства в классе, который я тестирую, а затем я убеждаюсь, что метод get возвращает то же значение.

public void testSetandGet(){ 
    int a = 10; 
    Class firstClass = new Class(); 
    firstClass.setValue(10); 
    int value = firstClass.getValue(); 
    Assert.assertEquals(value, a); 
} 
3

Рой Osherove в своей знаменитой книге «Искусство модульного тестирования говорит:

Свойства (геттеров/сеттеры в Java) являются хорошими примерами кода, которые обычно не содержат какой-либо логики, и не требует тестирования. Но будьте осторожны: как только вы добавите какую-либо проверку внутри свойства, вы захотите убедиться в том, что тестируется логика.

Вы тестируете, что вы установили, также можете «получить». Изменение Assert заявление:

Assert.assertTrue(a, true);

Кроме того, вы должны пройти a, если вы собираетесь его использовать.

18

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

В реальном проекте у вас будет больше, чем много программной логики для модульного тестирования, не испытывая что-то тривиальное, как сеттеры и геттеры.

+0

Иногда люди просто требуют проверки только в условиях покрытия кода. Конечно, вы можете автоматизировать тестирование для аксессуаров, но ... –

+0

Правда, но на самом деле это может быть плохо. Рассмотрим это: вы написали модульные тесты для геттеров и сеттеров для всех ваших классов, но не для вашей важной логики. Высокий уровень охвата вашего кода, но вероятность ошибок также высока. – cyon

+0

Возможно, действительно. Допустим, что это не помешает коду охватить аксессуры, после того, как вы полностью протестируете логику. :) –

1

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

Если ваши геттеры и сеттеры тривиальны, то они могут потерпеть неудачу только в случае сбоя основного JVM/компилятора - так что вы фактически тестируете JVM/компилятор, а не ваш код.

+0

Они могут потерпеть неудачу, если кто-то прикручивает и делает их непреднамеренно. Конечно, это небольшой шанс, и сеттеры/геттеры не должны быть первыми проверенными вещами, но могут помочь немного предположить, что вы уже проверили всю бизнес-логику. –

3

Я думаю, что это важно, если у вас есть какие-то условия. Например, если он возвращает исключение, если ваш int должен быть положительным или другими условиями. Но если это просто переменная присваивания, я не думаю, что это полезно ... То же самое для геттеров.

1

Если вы хотите, чтобы проверить его можно временно сделать переменную общественности, а затем:

firstClass.setMyInt(5); 
Assert.assertTrue(5, firstClass.myInt); 

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

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