2016-11-09 2 views
0

Я пытаюсь написать несколько тестов junit для класса Student. В принципе, у каждого ученика есть studentNum, который устанавливается на итератор, который является частным статическим int. Каждый раз, когда создается новый ученик, studentNum увеличивается.Сброс частного статического int из тестового класса junit

У меня есть несколько тестов для функции, которая получает ученика со студентомNum 1 из прошедшего в arraylist студентов. Тем не менее, каждый раз, когда я делаю нового арраиста студентов в новом тесте, studentNum начинается там, где студент предыдущего теста отказался. Таким образом, первый тест заставит учащихся с учениками с 0 по 5, а второй тест сделает студентов с studentNums с 6 по 11.

Мне было интересно, есть ли способ сбросить личное статическое целое studentNum из моего теста класс, чтобы я мог начать с нуля для каждого теста? Любая помощь была бы очень восприимчивой.

+0

Возможно, вам нужен метод '@ Before', который вызывается перед каждым тестом. –

+0

где ваш код? –

+0

Просто создайте новый прибор «Студент» перед каждым методом тестирования. – eckes

ответ

2

каждый студент имеет studentNum, который является частным статического INT

Это утверждение не имеет никакого смысла. Если каждый экземпляр вашего объекта Student должен иметь свой собственный идентификатор, поле id должно быть не быть статическим по определению.

+0

Извините, вы правы. Фактически есть частный статический итератор в классе Student, в котором устанавливается studentNum в конструкторе. – ThatOneGuy

0

Посмотрите на @Before/@After аннотации. Методы, аннотированные таким образом, вызываются до/после каждого тестового примера. Вы можете сбросить свои данные там.

@Before 
public void setup(){ 

} 
3

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

Если вы разделите логику генерации идентификатора (даже если это так же просто, как приращение отдельного счетчика), в отдельный класс, вы сможете издеваться над этим классом во время тестирования Student и вернуть ему идентификатор вы хотите в своих тестах.

+1

Или вы просто создаете экземпляр 'Student' с идентификатором, выбранным в тесте. – chrylis

+1

@chrylis Да, есть много способов передать идентификатор в объект-ученик, если это необходимо. Но важным является принцип единой ответственности: класс «Студент» не должен нести ответственность за создание идентификатора (или вести список экземпляров или что-то подобное). – biziclop

-2

У вас может быть @Before или @After (или оба), в котором вы сбросите личное статическое поле на любое значение, которое вы хотите (например, 0), используя Java Reflection API.

Способ сделать это было бы:

@Before 
public void setup() throws Exception { 
    Field studentNum = Student.class.getDeclaredField("studentNum"); 
    studentNum.setAccessible(true); //to overcome the visibility issue 
    studentNum.setInt(null, 0); //null since it's static 
} 
+2

Хотя этот подход возможен, вы не должны его использовать. доступ к частному члену объекта (даже для теста) нарушает самый важный принцип в ООП: * скрытие информации *! Также: если вы начнете тестировать детали реализации (вместо поведения ob), ваши тесты укусят вас, если вы захотите реорганизовать свой код. –

+0

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

+0

* ", в то время как OP хотел сохранить код как есть, но преодолел проблему проверки" * Когда самое лучшее время для начала лучшего кодирования? Для меня есть * сейчас *. Предоставление OP решения отражений позволяет ей болеть за сломанный стиль кодирования/тестирования. Вы * хотите, чтобы сотрудник делал то, что пытается сделать ОП? *Я не! –

-1

Просто подумайте о том, что означает, что статические decalration ... Для настоящих целей studentNum не должно быть статическим, если он имеет студенческий отличительный номер. со статическими все ваши объекты Student будут иметь последний studentNum.

Но если это требование (не могу себе представить, для чего ...), просто для junit с несколькими методами @Test (и только с) R O M A N I A верен. Сделайте это:

@Before 
public void setUp() throws Exception { 
    Student.studentNum =0; 
} 

Он сбрасывает статический studentNum перед выполнением каждого вызова метода @Test.

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