Как покрыть блок While итератором и перехватить метод с помощью mockito и Junit4?

#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: когда вы проводите тесты ПОСЛЕ написания производственного кода, вы рискуете получить трудный для тестирования код. И тогда вам понадобятся всевозможные сложные «обходные пути» в вашем тестовом коде, чтобы компенсировать это. Чрезмерно сложный производственный код приводит к чрезмерно сложному тестовому коду. Это означает, что вы только что удвоили объем трудночитаемого/понятного кода.