si ... tema else en la prueba Mockito en la primavera de arranque

Pajaro hambriento :

cómo escribir un caso de prueba para Mockito si ... else que también incluye prueba de excepción, estoy bastante confundido acerca de esto. UserService es una interfaz

UserFactory.java

public class UserFactory {
    @Autowired
    private List<UserService> UserList;

    private final Map<String, UserService> UserMap = new HashMap<>();

    @PostConstruct
    public void initUserMap() {
        for (final UserService user : UserList) {
            UserMap.put(user.getUserId(), user);
        }
    }

    public UserService getUser(String userId) {
        final UserService userService = UserMap.get(userlId);
        if (null == userService) {
            throw new IllegalArgumentException("user are not in the group");
        }
        return userService;
    }
}

UserService (Interface)

public interface UserService{
  String getUserName();
  String getUserId();
}

aquí está mi prueba, pero no es correcto ...

@RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {

    @Mock
    private UserService userService;

    @InjectMocks
    private UserFactory UserFactory;

    private Map<String, User> UserMap;

    private String userId = "123";

    @Before
    public void set_up(){
        UserMap = new HashMap<>();
        UserMap.put(userId, userService);
    }

    @Test
    public void getUser(){
        when(UserMap.get(userId)).thenReturn(userService);
        userService actual = userServiceFactory.getUser(userId);
        assertEquals(UserMap.get(userId), actual);
    }
}

davidxxx:

1) Usted escribe una prueba de unidad, no una prueba cortada o una prueba de integración. Así que aquí la primavera de arranque no importa ya que no es necesario cargar un contenedor a prueba la lógica de su componente.
Usted puede leer mi pregunta / respuesta sobre este campo si está interesado.

2) Una rama ( if/else) en los medios de lógica que tiene múltiples escenarios.
Escenarios distintos significan métodos de ensayo generalmente distintas y nombres significativos.
También puede depender de lo dado / cuando / entonces idioma.

3) Dado que en la prueba de la información de entrada para la rama es proporcionada por el simulacro, también significa que va a registrar comportamientos distintos para el simulacro en cada método de ensayo.

4) UserServiceno tiene por qué ser burlado. Tiene que ser un valor devuelto por la maqueta no el simulacro de sí mismo. Aquí hay que burlarse de la Map.

5) Se prueba UserFactory, así que hay que nombrarlo UserFactoryTest.

Por ejemplo :

@RunWith(MockitoJUnitRunner.class)
public class UserFactoryTest {

    @Mock
    private Map<String, User> UserMap;

    @InjectMocks
    private UserFactory UserFactory;

    private String userId = "123";


    @Test
    public void getUser(){
       when(UserMap.get(userId)).thenReturn(userService);
       userService actual = userServiceFactory.getUser(userId);
       assertEquals(UserMap.get(userId), actual);
    }


    @Test
    public void getUser_with_unknown_userId(){
        Assertions.assertThrows(IllegalArgumentException.class, 
                            ()->  userServiceFactory.getUser(userId));
    }

}

Se nota que en el segundo caso no registro ningún comportamiento de la maqueta.
Por defecto Mockito volverá nully, de hecho, es lo que necesito para provocar la excepción. Por lo que está muy bien.
Tenga en cuenta también que escribí la afirmación apoyándose en la biblioteca JUnit 5 y no la biblioteca JUnit 4 que parecen utilizar según el corredor usado.
Usted debe considerar cambiar a JUnit 5 para nuevas pruebas.