Diferencia entre revisiones de «SoapUI Con JUnit»
| Línea 70: | Línea 70: | ||
'''SOAP response''': Chequea que el response sea un mensaje soap. | '''SOAP response''': Chequea que el response sea un mensaje soap. | ||
'''Script assertion''': Permite hacer scrips de groovy para realizar assert con el response. | '''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. | + | '''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. | '''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. | '''Not Contains''': Chequea que el response no contenga un valor o un tag con un valor determinado. | ||
Revisión del 14:23 24 jun 2010
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-cli.jar
- commons-codec.jar
- commons-httpclient.jar
- not-yet-commons-ssl.jar
- soapui.jar
- soapui-xmlbeans.jar
- soap-xmlbeans.jar
- xbean-fixed.jar
- xmlpublic.jar
De esta manera corremos la batería completa de test de un proyecto. Hay que tener en cuenta que al tener un solo test para toda la batería, cuando surge un error no se continúa con el resto de los test.
@Test
public void holaMundo() throws Exception
{
SoapUITestCaseRunner runner = new SoapUITestCaseRunner();
runner.setProjectFile( "src/dist/HolaMundo-soapui-project.xml" );
runner.run();
}
También existe la posibilidad de correr individualmente cada uno de los test.
WsdlProject wsdlProject = null; TestSuite testSuite = null;
@Before public void setUp() throws Exception {
wsdlProject = new WsdlProject("src/dist/HolaMundo-soapui-project.xml");
testSuite = wsdlProject.getTestSuiteByName("HolaMundo");
}
@Test public void holaMundoOk() {
TestCase testCase = testSuite.getTestCaseByName("HolaMundoOk");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}
@Test public void holaMundoError() {
TestCase testCase = testSuite.getTestCaseByName("HolaMundoError");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}
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 el sopUI, pero una vez que guardamos un proyecto y lo importamos para correr los test de junit, los mismos fallan (retorna status FAILD). Entonces, para que los test corran automáticamente, vía junit, los únicos assert que se pueden hacer son los del tipo “contains” y “soap response”, cualquier otro tipo de assert falla. 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.
