#mockito #junit4 #powermockito #java-ee-7
Вопрос:
Я должен охватить блок Junit4 и Mockito/PowerMockito, блок While и блок catch. Исключение StateException запускается методом getHrest
public class Fstate{
….
private Date selectedDate;
private Date dateYes;
private Collection<State> sStateList;
private boolean statePlus;
private String stateVisibility;
@EJB
private Muller mull;
….
public void methodState(){
final Calendar calendar=new GregorianCalendar();
this.dateYes=calendar.getTime();
this.selectedDate = this.dateYes;
Collection<State> allState=null;
try{
allState=this.mull.getHrest(this.p, this.b, this.ba, this.so);
Iterator<State> iter=allState.iterator();
while(iter.hasNext()){
State s=iter.next();
String s_string=s.getSfielString();
this.sStateList.add(s_string);
}
} catch (StateException stateException){
WebLogger.fatal(stateException.getMessage(), LOGGER_OUT);
}
this.statePlus=loadStatePlus(this.dateYes);
this.stateVisibility=STATE_PLUS;
}
}
Ниже, в первом методе я хочу описать выполнение while, в то время как во втором методе я хочу описать улов.
Однако это не дает ожидаемого результата, в то время как блокировка и перехват не покрываются!
@Test
public void state_Test(){
try {
Fstate spyFstate = Mockito.spy(Fstate.class);
State mockState=Mockito.mock(Muller.class);
Mockito.when(mockState.getHrest(anyString(), anyString(), anyString(), anyString())).thenReturn(createCollectionOfStates());
Whitebox.setInternalState(spyFstate, "mull",mockState);
spyFstate.methodState();
Mockito.verify(spyFstate, Mockito.times(1)).methodState();
} catch (StateException e) {
System.out.println("StateException in state_Test method!");
}
}
@Test
public void stateException_Test(){
try {
Fstate spyFstate = Mockito.spy(Fstate.class);
State mockState=Mockito.mock(Muller.class);
Mockito.when(mockState.getHrest(anyString(), anyString(), anyString(), anyString())).thenThrow(new StateException("StateException Exception"));
Whitebox.setInternalState(spyFstate, "mull",mockState);
spyFstate.methodState();
Mockito.verify(spyFstate, Mockito.times(1)).methodState();
} catch (DealAnagException e) {
e.printStackTrace();
}
}
Комментарии:
1. Примечание: реальный ответ может заключаться в дальнейшем анализе вашего кода. Вместо определения списка в методе, чтобы затем повторить список в этом методе и обновить внутренний список … почему бы не иметь вспомогательный метод, который просто берет список и возвращает список? Вы можете проверить это полностью самостоятельно, без каких-либо насмешек? И не связанные: соглашения об именовании java flow.
s_string
это ооочень неправильно, и ничего не говорит. Используйте имена, которые следуют условностям и которые рассказывают читателю, о чем идет речь в названии.2. Итак, короче говоря: ваш производственный код слишком сложен, и если бы вы следовали принципам «чистого кода»… в итоге вы получите код, который также будет намного проще протестировать. Вот почему люди в TDD: когда вы проводите тесты ПОСЛЕ того, как написали свой рабочий код, вы рискуете получить трудный для тестирования код. И тогда вам понадобятся всевозможные сложные «обходные пути» в вашем тестовом коде, чтобы компенсировать это. Чрезмерно сложный производственный код приводит к чрезмерно сложному тестовому коду. Это означает, что вы просто удвоили объем трудного для чтения / понимания кода.
Ответ №1:
Я думаю, что вам просто нужно создать экземпляр своего состояния, прежде чем создавать своего шпиона таким образом :
Fstate fstate = new Fstate();
Fstate spyFstate = Mockito.spy(fstate);
Ответ №2:
Я решил эту проблему с помощью комментариев GhostCat.
Цитата:
Примечание: Реальный ответ может заключаться в дальнейшем анализе вашего кода. Вместо определения списка в методе, чтобы затем повторить список в этом методе и обновить внутренний список, почему бы не использовать вспомогательный метод, который просто берет список и возвращает список? Вы можете проверить это полностью самостоятельно, без каких-либо насмешек?
И не связанные: соглашения об именовании java потока. s_string ооочень ошибочен и ничего не говорит о том, для чего предназначена переменная. Используйте имена, соответствующие условностям и рассказывающие читателю, о чем они.
Итак, короче говоря: ваш производственный код слишком сложен, и если бы вы следовали принципам «чистого кода», вы получили бы код, который также было бы намного проще протестировать. Вот почему люди в TDD: когда вы проводите тесты ПОСЛЕ написания производственного кода, вы рискуете получить трудный для тестирования код. И тогда вам понадобятся всевозможные сложные «обходные пути» в вашем тестовом коде, чтобы компенсировать это. Чрезмерно сложный производственный код приводит к чрезмерно сложному тестовому коду. Это означает, что вы только что удвоили объем трудночитаемого/понятного кода.