Diferencia entre revisiones de «SoapUI Con JUnit»

De Dos Ideas.
Saltar a: navegación, buscar
(Componentes)
(Ver también)
Línea 58: Línea 58:
 
You're on top of the game. Thanks for sahring.
 
You're on top of the game. Thanks for sahring.
  
== Ver también  ==
+
Ah yes, nicely put, eervyone.
 
 
*[[Mock de un web service con Jetty|Alternativa a SoapUI utilizando Jetty]]
 
*[http://www.soapui.org/userguide/commandline/functional.html SoapUITestCaseRunner ]
 
 
 
[[Category:Web_Service]] [[Category:JUnit]]
 

Revisión del 17:24 7 sep 2011

Integración

Es muy fácil incorporar la suite de test JUnit generada por SoapUI a nuestro proyecto y poder así sumar estos test a los test de integración de nuestra aplicación.

Librerias a incluir en el modulo de test de nuestro proyecto

  • bcprov-jdk15-138.jar
  • commons-beanutils.jar
  • commons-beanutils-1.7.0.jar
  • commons-cli.jar
  • commons-codec.jar
  • commons-httpclient.jar
  • not-yet-commons-ssl.jar
  • saxon-dom-9.1.0.8j.jar
  • saxon-9.1.0.8j.jar
  • soapui.jar
  • soapui-xmlbeans.jar
  • soap-xmlbeans.jar
  • xbean-fixed.jar
  • xmlpublic.jar
  • xbean_xpath-2.4.0.jar


Al incluir las librerias propuesta arriba podremos correr los tests con Junit y fucionarán los siguientes asserts de SoapUI:

  • Contains
  • SOAP response
  • Soap fault
  • Schema Compliance
  • not soap fault

Si se desean otras validaciones sobre la respuesta deberán agregar otros JARs que see encuentran dentro del directorio donde se instalo SoapUI.

Great haemmr of Thor, that is powerfully helpful!

Problemas con Assertions

Se presentan ciertos problemas al correr los test SoapUi con JUnit.

Soapui propone muchas formas para realizar assert sobre el response de un ws, a continuación un breve explicación de cada una:

  • WS-security status : Chequea que el reponse tenga un encabezado ws-security válido.
  • not soap fault : Chequea que el response no sea un fault.
  • Response SLA : Chequea que el response haya tardado menos del tiempo configurado.
  • SOAP response: Chequea que el response sea un mensaje soap.
  • Script assertion: Permite hacer scrips de groovy para realizar assert con el response.
  • WS adressing response: Chequea que el encabezado del resopnse tenga propiedades válidas.
  • Contains: Chequea que el response contenga un valor o un tag con un valor determinado.
  • Not Contains: Chequea que el response no contenga un valor o un tag con un valor determinado.
  • xQuery math: Permite chequear el contenido del response con expresiones de xquery 2.0.
  • Schema Compliance: Chequea que el response sea compatible con un shema dado.
  • xPath match: Permite chquear el contenido del response con expresiones de xPath.
  • Soap fault: Chequea que el response sea un fault.


Estos assert son muy completos y muy fáciles de usar con SoapUI. En principio con los contains se pueden hacer asserts sobre todo el response, pero tienen una serie de limitaciones: solo permite hacer assert por tag, es decir, que no se puede hacer un assert del xml completo, con lo cual si el xml del response tiene 20 tag, habrá que hacer 20 assert distintos. Otro punto en contra es que no hay un forma con las assertions para testeas los tags en el caso de que nuestro WebServices retorne una colección de datos, ya que es estos casos hace un assert sobre todo el xml, sin controlar la cantidad.

You're on top of the game. Thanks for sahring.

Ah yes, nicely put, eervyone.