Spring Testing. Mostrar información de las peticiones

Cuando usamos MockMvc para testear controladores de Spring, es muy útil disponer del máximo de información referente a la petición realizada desde el test. Una forma muy sencilla es indicarle al “builder” que queremos que muestre en la salida del test dicha información.

import org.junit.Before;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;

@RunWith(MockitoJUnitRunner.class)
public abstract class MyTestClass {

    MockMvc mvc;

    @Mock
    MyRepository myRepository;

    @Before
    public void initialize() {

        mvc = MockMvcBuilders.standaloneSetup(new MyController(new MyService(myRepository)));
                .alwaysDo(print()) // Esta es la línea importante
                .build();
    }
}

Esto hace que para cada petición se se hace desde un test unitario via MockMvc muestre una información detallada de la misma:

MockHttpServletRequest:
      HTTP Method = GET
      Request URI = /my-request-path
       Parameters = {my-request-param=[my-request-param-value]}
          Headers = {my-header=[my-header-value]}

Handler:
             Type = com.example.MyController
           Method = public org.springframework.http.ResponseEntity<java.util.List<com.example.MyResponseClass>> com.example.MyController.myMethod(com.example.MyRequestBodyClass)

Async:
    Async started = false
     Async result = null

Resolved Exception:
             Type = null

ModelAndView:
        View name = null
             View = null
            Model = null

FlashMap:
       Attributes = null

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = {Content-Type=[application/json;charset=UTF-8]}
     Content type = application/json;charset=UTF-8
             Body = [{"field":"value"}]
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

Tener en cuenta que hasta versión 5.0 de Spring Framework no se muestra el contenido de la request tal y como se puede leer en el siguiente jira:

https://jira.spring.io/browse/SPR-14717

Mejorar la salida de los tests de una aplicación Spring Boot

Cuando hago aplicaciones con SpringBoot abruma un poco la cantidad de información que este muestra en el log cuando está activado el debug.

El tema es que el nivel de log lo suelo configurar a través del fichero application.properties pero cuando se ejecutan tests de JUnit donde no interviene Spring para nada este valor no se recoje y por defecto muestra todo a nivel DEBUG.

Añadiendo este fichero logback-test.xml en la ruta src/test/resources conseguiremos que los mensajes del framework Spring se muestren con nivel WARN mientras que los del paquete de mi aplicación (en el ejemplo: com.my.package) se muestren con el nivel más alto TRACE.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml" />
    <logger name="org.springframework" level="WARN"/>
    <logger name="com.my.package level="TRACE"/>
</configuration>

De esta forma la salida (standard output) de los tests queda muchísimo más limpia y prácticamente se limita a los mensajes própios de mi aplicación.

Failed to instantiate Pageable: Specified class is an interface

Al añadir los parámetros de paginación a un controlador de spring. Unos tests que estaba haciendo con MockMvc y Mockito me comenzaron a fallar con el siguiente error:

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.data.domain.Pageable]: Specified class is an interface

La solución consiste en proporcionar una clase que resuelva los argumentos en tiempo de test (setCustomArgumentResolvers). Esta clase solo atiende al parámetro de tipo Pageable.

public class TestUtils {
    public static MockMvcBuilder prepareMockMvcForPageableArguments(Object... controllers) {
        return MockMvcBuilders.standaloneSetup(controllers)
                .setCustomArgumentResolvers(
                        new HandlerMethodArgumentResolver() {
                            @Override
                            public boolean supportsParameter(MethodParameter parameter) {
                                return parameter.getParameterType().equals(Pageable.class);
                            }

                            @Override
                            public Object resolveArgument(MethodParameter parameter,
                                    ModelAndViewContainer container,
                                    NativeWebRequest request,
                                    WebDataBinderFactory binderFactory) throws Exception {
                                return new PageRequest(0, 50);
                            }
                        });

    }
}

Para utilizarlo:

MockMvc mvc = TestUtils.prepareMockMvcForPageableArguments(controller).build();

Fuente:

https://github.com/terasolunaorg/terasoluna-tourreservation/blob/master/terasoluna-tourreservation-web/src/test/java/org/terasoluna/tourreservation/app/searchtour/SearchTourControllerTest.java

Mockito InOrder y ArgumentCaptor

InOrder

Uso de InOrder permite validar el orden en el que se ejecutan las llamadas a los distintos objetos doble (mock).

@Mock
Repository someRepository;

@Mock
Repository someOtherRepository;

@Test
public void testSomething() {

	InOrder order = Mockito.inOrder(someRepository, someOtherRepository);

	order.verify(someRepository).save(anyString());
	order.verify(someOtherRepository).findByName(anyString());
	order.verify(repository).update(anyString());
	order.verifyNoMoreInteractions();
}

ArgumentCaptor

Uso de ArgumentCaptor permite capturar los argumentos que recibe una llamada a una objeto doble (mock).

@Mock
Repository mockRepository;

@Test
public void testSomething() {

	service.useCase("some_string");
	
	ArgumentCaptor<String> argument = ArgumentCaptor.forClass(String.class);
	verify(mockRepository).findByName(argument.capture());
	assertEquals("some_string", argument.getValue());
}

Gradle, Sonar e Informes de cobertura (Jacoco)

Para un proyecto java simple.

El análisis estático de SonarQube se lanza desde Jenkins.

sonar-project.properties:

sonar.projectKey=com.sourcerebels:some_project
sonar.projectName=SomeProject
sonar.projectVersion=1.0
sonar.language=java
sonar.sources=src/main/java
sonar.tests=src/test/java
sonar.java.binaries=build/classes/main
sonar.jacoco.reportPaths=build/jacoco/test.exec

build.gradle

apply plugin: 'java'
apply plugin: 'application'
apply plugin: 'jacoco'

mainClassName = "SomeProject"
sourceCompatibility = 1.8
targetCompatibility = 1.8

repositories {
    jcenter()
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.12'
    testCompile 'org.mockito:mockito-core:2.7.16'
}

Mostrar el resultado de los test unitarios al ejecutar Gradle

Una de las cosas que me confunde cuando ejecuto el Gradle desde la línea de comandos es que si los tests se ejecutan sin fallos, no muestra ningún tipo de detalle acerca de que tests fueron ejecutados. Con lo que no acabo de tener la certeza de que todo haya ido bien.

Al añadir estas líneas en el fichero build.gradle de nuestro módulo mostrará la información de qué test ha ejecutado y cual ha sido el resultado, además de la salida standard y error si la hubiese.

android {
  ...
  testOptions.unitTests.all {
    ignoreFailures false
    testLogging {
      events "passed", "skipped", "failed", "standardOut", "standardError"
    }
  }
}

Por supuesto, yo no he inventado nada. Lo saqué de esta respuesta en Stackoverflow.

Tema relacionado: Test from the Command Line

Configuración Checkstyle Google Checks

Instalar plugin “CheckStyle-IDEA”

  • En Android Studio o IntelliJ abrir la opción de menú “File” -> “Settings”.
  • Allí, localizar el apartado “plugins”.
  • Buscar e instalar el plugin “CheckStyle-IDEA”.
  • Reiniciar el IDE cuando lo solicite.

Configurar Google Checks

  • Volver a abrir la vista de “Settings”.
  • Allí, localizar el apartado “Other Settings -> Checkstyle”.
  • Añadir un nuevo fichero de configuración haciendo click en el botón con el símbolo “+” correspondiente.
  • Seleccionar el checkbox correspondiente para activar la configuración.

Captura de pantalla de 2016-04-09 21-00-04

Finalmente, el fichero se puede localizar on-line en las direcciones.

Fichero para la última versión de checkstyle (no recomendable instalar ya que puede ser que tengas una versión anterior)

https://raw.githubusercontent.com/checkstyle/checkstyle/master/src/main/resources/google_checks.xml

Fichero para una versión en concreto de checkstyle (6.17)

https://github.com/checkstyle/checkstyle/blob/checkstyle-6.17/src/main/resources/google_checks.xml

Las diferentes versiones se pueden encontrar marcadas con tags en el repositorio de Checkstyle.

SonarQube

Para poder analizar un proyecto Android con la herramienta sonarqube tuve que modificar el fichero build.gradle añadiendo las siguientes líneas:

buildscript {
  repositories {
    ...
    maven { url "https://plugins.gradle.org/m2/" } 
  }
  dependencies {
    ...
    classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2"
  }
}

apply plugin: 'org.sonarqube'

sonarqube {
  properties {
    ...
    property "sonar.projectName", "Mi aplicación"
    property "sonar.host.url", "http://url_de_sonarqube"
    properties["sonar.sources"] += "src"
  }
}