java - pruebas - junit tutorial español
Reemplazar frijoles en pruebas de integración (2)
1. Puedes usar la anotación @Primary
:
@Configuration
public class MockRestTemplateConfiguration {
@Bean
@Primary
public RestTemplate restTemplate() {
return Mockito.mock(RestTemplate.class)
}
}
Por cierto, escribí una publicación en el blog sobre cómo falsificar Spring Bean
2. Pero sugeriría echar un vistazo al soporte de prueba de Spring RestTemplate . Este sería un ejemplo simple: MockRestServiceServer mockServer privado;
@Autowired
private RestTemplate restTemplate;
@Autowired
private UsersClient usersClient;
@BeforeMethod
public void init() {
mockServer = MockRestServiceServer.createServer(restTemplate);
}
@Test
public void testSingleGet() throws Exception {
// GIVEN
int testingIdentifier = 0;
mockServer.expect(requestTo(USERS_URL + "/" + testingIdentifier))
.andExpect(method(HttpMethod.GET))
.andRespond(withSuccess(TEST_RECORD0, MediaType.APPLICATION_JSON));
// WHEN
User user = usersClient.getUser(testingIdentifier);
// THEN
mockServer.verify();
assertEquals(user.getName(), USER0_NAME);
assertEquals(user.getEmail(), USER0_EMAIL);
}
Más ejemplos se pueden encontrar en mi repositorio Github aquí
Para mi aplicación Spring-Boot proporciono una RestTemplate a través de un archivo @Configuration para poder agregar valores predeterminados razonables (ex Timeout). Para mis pruebas de integración, me gustaría burlarme de RestTemplate ya que no quiero conectarme a servicios externos. Sé qué respuestas esperar. Traté de proporcionar una implementación diferente en el paquete de prueba de integración con la esperanza de que este último anule la implementación real, pero revisar los registros es al revés: la implementación real prevalece sobre la versión de prueba.
¿Cómo puedo asegurarme de que el de TestConfig es el que se usa?
Este es mi archivo de configuración:
@Configuration
public class RestTemplateProvider {
private static final int DEFAULT_SERVICE_TIMEOUT = 5_000;
@Bean
public RestTemplate restTemplate(){
return new RestTemplate(buildClientConfigurationFactory());
}
private ClientHttpRequestFactory buildClientConfigurationFactory() {
HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
factory.setReadTimeout(DEFAULT_SERVICE_TIMEOUT);
factory.setConnectTimeout(DEFAULT_SERVICE_TIMEOUT);
return factory;
}
}
Examen de integración:
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = TestConfiguration.class)
@WebAppConfiguration
@ActiveProfiles("it")
public abstract class IntegrationTest {}
Clase TestConfiguration:
@Configuration
@Import({Application.class, MockRestTemplateConfiguration.class})
public class TestConfiguration {}
Y finalmente MockRestTemplateConfiguration
@Configuration
public class MockRestTemplateConfiguration {
@Bean
public RestTemplate restTemplate() {
return Mockito.mock(RestTemplate.class)
}
}
Desde Spring Boot 1.4.x hay una opción para usar la anotación @MockBean
para falsificar Spring beans.
Reacción al comentar:
Para mantener el contexto en la memoria caché, no use @DirtiesContext
, pero use @ContextConfiguration(name = "contextWithFakeBean")
y creará un contexto separado, mientras que mantendrá el contexto predeterminado en la memoria caché. Spring mantendrá ambos (o la cantidad de contextos que tiene) en la memoria caché.
Nuestra compilación es de esta manera, donde la mayoría de las pruebas usan configuración predeterminada no contaminada, pero tenemos 4-5 pruebas que falsifican beans. El contexto predeterminado está muy bien reutilizado