Método de réplica de Mockito ya anotado con thenthrow

Question

Me encontré con un problema con mockito. Estoy desarrollando una aplicación web. En mis pruebas, se burla de la administración de usuarios. Hay algunos casos en los que tengo que modificar el usuario devuelto por el método getLoggedInUser().

El problema es que mi método getLoggedInUser() también arroja un AuthenticationException.

Así que cuando trato de cambiar de ningún usuario a algún usuario, la llamada a

when(userProvider.getLoggedInUser()).thenReturn(user); 

se produce una excepción, ya que userProvider.getLoggedInUser() ya se apagó con thenTrow()

¿Hay alguna manera de decirle al when método para no preocuparse por las excepciones?

Gracias de antemano - István

Answer 1

Mi primera reacción a su pregunta es que parece que está tratando de hacer demasiado en una prueba.

Para facilitar la prueba y la simplicidad, cada prueba debe probar una sola cosa. Esto es lo mismo que Single Responsibility Principle. A menudo encuentro que los programadores intentan probar varias cosas en una prueba y tienen todo tipo de problemas debido a eso. Así que cada uno de sus métodos de prueba de la unidad debe seguir este flujo:

1. instalación de un único escenario de la prueba.
2. Realice una llamada a la clase que se está probando para activar el código que se está probando.
3. Verifica el comportamiento.

En su caso, esperaría ver al menos dos pruebas. Uno donde getLoggedInUser() devuelve un usuario, y otro donde getLoggedInUser() arroja una excepción. De esta forma, no tendrás problemas para simular un comportamiento diferente en el simulacro.

El segundo pensamiento que me viene a la mente es no resbalar. Considere el uso de esperar en su lugar porque puede configurar una serie de expectativas. Es decir. la primera llamada devuelve un usuario, la segunda llamada arroja una excepción, la tercera llamada devuelve un usuario diferente, etc.

Answer 2

Parece que usted puede tener que utilizar una respuesta personalizada. Here is an example.

Answer 3

En las nuevas versiones de Mockito, puede usar el troceo de llamadas consecutivas para lanzar una excepción en la primera lata y devolver un valor en una segunda llamada.

when(mock.someMethod("some arg")) 
    .thenThrow(new RuntimeException()) 
    .thenReturn("foo"); 

http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mockito.html#stubbing_consecutive_calls

Answer 4

¿Hay alguna manera de decirle al método cuando no a la atención acerca de las excepciones?

Para responder a esta pregunta en realidad:

import static org.hamcrest.Matchers.equalTo; 
import static org.hamcrest.Matchers.is; 
import static org.junit.Assert.assertThat; 
import static org.mockito.ArgumentMatchers.any; 
import static org.powermock.api.mockito.PowerMockito.mock; 
import static org.powermock.api.mockito.PowerMockito.when; 

import org.junit.Test; 
import org.mockito.Mockito; 

import java.util.ArrayList; 

public class MyTest { 

    @Test 
    public void testA() { 

     // setup 
     ArrayList<Object> list = mock(ObjectArrayList.class); 
     when(list.indexOf(any())).thenReturn(6); 
     when(list.indexOf(any())).thenReturn(12); 

     // execute 
     int index = list.indexOf(new Object()); 

     // verify 
     assertThat(index, is(equalTo(12))); 
    } 

    @Test 
    public void testB() { 

     // setup 
     ArrayList<Object> list = mock(ObjectArrayList.class); 
     when(list.add(any())).thenThrow(new AssertionError("can't get rid of me!")); 
     when(list.add(any())).thenReturn(true); 

     // execute 
     list.add(new Object()); 
    } 

    @Test 
    public void testC() { 

     // setup 
     ArrayList<Object> list = mock(ObjectArrayList.class); 
     when(list.add(any())).thenThrow(new AssertionError("can't get rid of me!")); 
     Mockito.reset(list); 
     when(list.add(any())).thenReturn(true); 

     // execute 
     list.add(new Object()); 
    } 

    /** 
    * Exists to work around the fact that mocking an ArrayList<Object> 
    * requires a cast, which causes "unchecked" warnings, that can only be suppressed... 
    */ 
    class ObjectArrayList extends ArrayList<Object> { 

    } 
} 

TestB falla debido a la aserción de que no puede deshacerse de.TestC muestra cómo se puede utilizar el método reset para restablecer el simulacro y eliminar el comando thenThrow en él.

Tenga en cuenta que el reinicio no siempre parece funcionar en algunos ejemplos más complicados que tengo. Sospecho que podría ser porque están usando PowerMockito.mock en lugar de Mockito.mock?