SoapUI Generación de propiedades

Hay varias formas de generar datos dinámicos en SoapUI que posteriormente podremos usar en nuestras peticiones WS.

Propiedades auto-generadas.

SoapUI permite declarar propiedades cuyo valor es interpretado, generando un valor cada vez que se consulta.

En la imagen se genera un bloque TestSuite, pero también se puede generar en un bloque TestCase.

Propiedad del test-suite autogenerada

Propiedad auto-generada

Como ya supondréis la cadena ${=Math.random()*100} generará un valor numérico aleatorio con una parte entera <= 100.

Para acceder a este valor usaremos la cadena ${#TestSuite#autogenerado} en el nodo donde queremos que se inserte.

<cur:amount>${#TestSuite#autogenerado}</cur:amount>

Si hemos generado el valor en un bloque TestCase la cadena será similar ${#TestCase#autogenerado}

Propiedades auto-generadas 2

Existe otra forma de generar las propiedades, que los hace una vez en cada ejecución. Esta forma de generación es mas útil si pretendemos usar estos valores de forma repetida a lo largo del test. Esta generación la realizaremos con ayuda de un script. En este ejemplo usaremos la pestaña “SetupScript” del TestCase que nos permite introducir este script.

SoapUI TestCase SetupScript

SoapUI TestCase SetupScript

Las sentencias de Setup Script se ejecutan antes de iniciar el test, por lo que tendremos al inicio de cada ejecución un nuevo valor en la propiedad autogenerado2.

Si usamos el botón play (en la imagen el botón verde al lado de Edit ) se ejecutará el script y podremos ver la propiedad generada en la pestaña Properties que ya hemos visto en la imagen anterior.

Si queremos tener mas visible en qué lugares se generan valores podemos añadir un paso del tipo Groovy Script y añadir ahí el mismo script que acabos de usar.

Groovy Script

Groovy Script

 

Anuncios

Eclipse + JUnit + java.lang.NoSuchFieldError: NULL

Estos días me he vuelto a tropezar con un error que me costó bastante tiempo resolver, no por la complejidad, sino por encontrar el motivo:

Antecedentes:

Tengo un proyecto A en eclipse que depende de otro B. El proyecto A tiene dependencias con JUnit 4.10 y la ejecución con “mvn test” funciona correctamente, aun así, Eclipse me devuelve este elocuente error:

java.lang.NoSuchFieldError: NULL
at org.junit.runners.ParentRunner.(ParentRunner.java:54)
at org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.(SpringJUnit4ClassRunner.java:104)

Reviso las dependencias con “mvn dependency:tree” para ver las librerías que se están incluyendo y efectivamente está presente la librería  junit-4.10.jar

¿Cómo es posible que mvn funcione y Eclipse no?  Pues algo extraño tiene que pasar con Eclipse. Reviso las dependencias que importa el proyecto, bloque Referenced Library usando la vista Package Explorer y la entrada sobre JUnit que tengo es junit-4.10.jar ¡Todo correcto! Entonces… ¿Qué está pasando?

Reviso el lanzamiento del Junit: Run As -> Run Preferences y compruebo que el Test Runner es JUnit4 ¿Entones? Entonces es cuando me doy cuenta que en el Classpath se está importando librerías del proyecto B, entre ellas la junit-3.8.jar

¿Por qué no prevalece la librería importada por el proyecto principal A? No lo sé.

Para solucionar el error anterior hay que eliminar esta incoherencia de librerías. Esto ya depende de como estén montado el proyecto A y el B. En mi caso, para solucionarlo e eliminado la referencia directa al proyecto B y hago la referencia al B.jar que se genera a partir de él y que no contiene la librería problemática.

Si tienes el proyecto B referenciado desde el pom como un jar, en vez de hacer “mvn eclipse:eclipse”  puedes hacer

mvn eclipse:clean eclipse:eclipse -Declipse.useProjectReferences=false

para que no se haga referencia a los proyectos del classpath.

Espero que esto os sirva de ayuda.