Saltar al contenido

Spock – Prueba de excepciones con tablas de datos

Esta es el arreglo más completa que encomtrarás aportar, pero primero mírala pausadamente y analiza si es compatible a tu trabajo.

Solución:

La solución recomendada es tener dos métodos: uno que pruebe los casos buenos y otro que pruebe los casos malos. Entonces ambos métodos pueden hacer uso de tablas de datos.

Ejemplo:

class SomeSpec extends Specification 

    class User  String userName 

    def 'validate valid user'() 
        when:
        validateUser(user)

        then:
        noExceptionThrown()

        where:
        user << [
                new User(userName: 'tester'),
                new User(userName: 'joe')]
    

    def 'validate invalid user'() 

    private validateUser(User user) 
        if (!user) throw new Exception('no user')
        if (!user.userName) throw new Exception('no userName')
    


Así es como lo hago, modifico el when: cláusula para lanzar siempre una Success excepción, de esa manera no necesita pruebas separadas o lógica para saber si llamar thrown o notThrown, solo llama siempre thrown con la tabla de datos indicando si esperar Success O no.

Podrías cambiar el nombre Success ser - estar None o NoException o lo que prefieras.

class User  String userName 

class SomeSpec extends spock.lang.Specification 

    class Success extends Exception 

    def 'validate user - data table 2 - working'() 
        when:
            validateUser(user)
            throw new Success ()

        then:
            def ex = thrown(expectedException)
            ex.message == expectedMessage

        where:
            user                         

    private validateUser(User user) 
        if (!user) throw new Exception ('no user')
        if (!user.userName) throw new Exception ('no userName')
    

Una cosa adicional que cambiaría, sería usar una subclase para las excepciones de falla también para evitar una Success ser atrapado accidentalmente cuando realmente esperabas un fracaso. No afecta su ejemplo porque tiene una verificación adicional para el mensaje, pero otras pruebas podrían probar el tipo de excepción.

class Failure extends Exception 

y use esa o alguna otra excepción "real" en lugar de la vainilla Exception

Puede envolver su llamada de método con un método que devuelva el mensaje o la clase de excepción, o un mapa de ambos...

  def 'validate user - data table 2 - not working'()  expectedMessage
        new User(userName: 'tester') 

    String getExceptionMessage(Closure c, Object... args)
        try
            return c.call(args)
            //or return null here if you want to check only for exceptions
        catch(Exception e)
            return e.message
        
    

Sección de Reseñas y Valoraciones

Nos puedes añadir valor a nuestro contenido asistiendo con tu veteranía en las explicaciones.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *