Karate una herramienta de open source que combina la automatización de pruebas de API, pruebas de rendimiento e incluso la automatización de la interfaz de usuario en un marco único y unificado. Utiliza sintaxis BDD popularizada por Cucumber. Genera informes HTML y puede ejecutar sus pruebas en paralelo para aumentar la velocidad.

Ya hemos hablado anteriormente sobre Cucumber lo que viene siendo el TDD, BDD, Gherkin y toda la pesca. En esta ocasión vamos a hablar de Karate.

Esta herramienta de testeo llego a mis manos a raíz de un proyecto en el que estuve inmerso durante los últimos meses. El propio nombre y su curioso logo me dejó un poco estupefacto, pero bueno el tema de los nombres de aplicaciones ya es conocido.

Karate es una herramienta de código abierto para realizar pruebas de BDD sobre nuestra API Rest. Utiliza una sintaxis Gherkin. La diferencia principal entre Karate y Cucumber es que este es por así decirlo como un Cucumber mucho mas simplificado, a continuación enumeramos algunas funcionales que se citan en esta web.

¿Qué nos proporciona Karate?

• Setup inicial sencillo, rápido y directo.
• BDD unificado desde un mismo fichero. No es necesario definir los steps en otras ubicaciones.
• Pruebas simples, concisas, legibles y fáciles de mantener.
• Posibilidad de utilizar clases Java para utilidades complejas o funciones de ayuda que facilita su depuración y mantenibilidad.
• No se requieren conocimientos de programación avanzados. Acciones habituales sobre APIs implementadas mediante lenguaje natural.
• Posibilidad de ejecutar pruebas en paralelo.
• Reutilización de features pudiendo ser usadas como precondiciones o funciones de otros pruebas.
• Implementación sencilla
• Soporte nativo para aserciones sobre JSON y XML.
• Permite lectura de ficheros CSV (Data Driven Testing)
• Motor de JavaScript integrado.
• Importación de archivos csv o json con información. En cucumber, las variables están estáticas en una tabla.
• Documentación y ejemplos completos.
• Soporte websockets.
• Informes en HTML con el resultado de las pruebas

En resumen es un Cucumber mas simplificado y con la posibilidad de incluir javascript para nuestras pruebas. Además de generar unos informes muy completos en html con el resultado de nuestras pruebas.

Para plasmar esta herramienta lo que haremos será coger el mismo ejemplo que realizamos con cucumber anteriormente y hacerlo con Karate.

Prueba de concepto

La prueba que realizaremos será pasar de la anterior prueba de concepto que realizamos en cucumber a realizarla con Karate, haremos una comparativa entre las distintas soluciones para poder mostrar las bondades de Karate.

Recordemos un poco la prueba tenemos dos endpoints simplones, uno devuelve un saludo con el nombre que pasamos por param, y otro recibe dos params y devuelve la suma de ambos.

• Repositorio Cucumber
• Repositorio Karate

Dependencias

El primer paso será incluir las dependencias que necesitamos para lanzar los test en Karate. Sería necesario incluir las siguientes dependencias en nuestro maven.

<properties>	
		<karate.version>0.9.6</karate.version>
</properties>

...
<dependency>
    <groupId>com.intuit.karate</groupId>
    <artifactId>karate-apache</artifactId>
    <version>${karate.version}</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>com.intuit.karate</groupId>
    <artifactId>karate-junit5</artifactId>
    <version>${karate.version}</version>
    <scope>test</scope>
</dependency>

Configuración

Para configurar nuestras pruebas con karate tenemos dos clases por un lado karate-config.js en la que vamos a definir la url (Se podrían definir muchísimas cosas más, os sugiero que consultéis la documentación).

function fn() {
    var config = {
        baseUrl : 'http://localhost:' + karate.properties['port']
    };
    return config;
}

Luego en otra clase vamos a configurar un @SpringBootTest que lanzará nuestra aplicación en un puerto aleatorio, y una vez arrancada se lanzarán los test de Karate que cargarán un fichero feature en el que definiremos las pruebas que queremos hacer.

@SpringBootTest(classes = DemoApplication.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class KarateTest {

    @LocalServerPort
    int port;
    final String directory = "classpath:features/";

    @BeforeEach
    public void setUp(){
        System.setProperty("port", String.valueOf(port));
    }

    @Karate.Test
    @DisplayName("Tests for examples")
    Karate createUserRoleController() {
        return Karate.run(directory + "foo.feature");
    }

}

Si tuviéramos mas ficheros de features, habría que incluir mas métodos con la anotación @Karate.test.

Features

Y ahora vamos con el kit de la cuestión, si recordamos la prueba que teníamos con Cucumber por un lado definíamos el feature en Gherkin y por otro una clase java en la que programábamos cada una de las sentencias Gherkin , por ejemplo dado un Then teníamos que desarrollar la comprobación como podemos ver más abajo, y así con todo

@Then("the client receives status code of 200")
    public void checkStatus200(){

        assertEquals(responseEntity.getStatusCode() , HttpStatus.OK);
    }

Bien, pues aquí es donde esta la magia, lo interesante de Karate. Observemos un momento el fichero de feature de Karate para este ejemplo.

Feature: features of gherkin test

  Background:
    * url baseUrl

  Scenario Outline: client makes call to GET hello
    Given path '/examples/hello'
    And param name = '<name>'
    When method GET
    Then status 200
    And  match response contains '<name>'
    Examples:
      | name |
      | Diego |
      | Sofia |
      | Pepe |

  Scenario Outline: client makes call to GET to sum numbers
    Given path '/examples/sum'
    And param a = '<a>'
    And param b = '<b>'
    When method GET
    Then  status 200
    And  match response == '<result>'
    Examples:
      | a | b | result |
      | 2 | 3 | 5      |
      | 2 | 4 | 6      |
      | 2 | 5 | 7      |

No hay más que codificar, no hay que implementar comprobaciones, preparar la llamada rest, etc. Karate internamente ya se encarga de traducir de Gherkin a la llamada al endpoint, ya se encarga de comprobar la respuesta, de hacer match al response y si consultamos la documentación vemos que se nos abre un amplio abanico de opciones a la hora de diseñar nuestras pruebas sin tener que tocar nada de código java, sino directamente transformando y realizando las pruebas de manera automática este Gherkin a lo que deseamos testear.

El Informe

Y ya para ir cerrando, si accedemos dentro de nuestro proyecto a la path /target/surefire-reports/ podremos observar una web como la que observamos mas arriba con los distintos escenarios de tes que hemos realizado y el resultado de cada uno de los test, así como mediciones de tiempos, etc.