¿Cómo se automatiza integration testing? Yo uso JUnit para algunas de estas pruebas. Esta es una de las soluciones o es totalmente incorrecta? ¿Que sugieres?¿Podemos usar JUNIT para Pruebas de integración automatizada?
JUnit funciona. No hay limitaciones que lo restrinjan a pruebas unitarias solamente. Usamos JUnit, Maven y CruiseControl para hacer CI.
Puede haber herramientas que sean específicas para las pruebas de integración, pero creo que su utilidad depende del tipo de componentes del sistema que está integrando. JUnit funcionará bien para pruebas de tipo no UI.
Definitivamente! Utilizamos una combinación de tareas JUnit, ANT para ejecutarlas, y Hudson para pruebas de integración continuas. Funciona de maravilla.
Cuando uso Maven para construir un proyecto, he tenido un poco más de suerte con TestNG porque tiene operaciones @BeforeSuite y @AfterSuite. Que son útiles porque Maven no ejecutará la 'prueba de integración posterior' si falla cualquiera de las pruebas de integración. No es un problema con Ant, así que solo uso jUnit fuera de preferencia con él.
En cualquier caso, segmentar las pruebas como TestNG y jUnit también es útil con las pruebas de integración.
Sí, puede usar junit para las pruebas de integración, pero depende del tipo de prueba de integración que necesite.
Prueba de un servlet:
Prueba de una aplicación de primavera:
Pero el junit puro tiene su límite. La prueba de las interfaces de usuario es un caso típico. Puede usar selenio para aplicaciones web, soapui para servicios web u otras herramientas apropiadas.
Pero sea lo que sea que use, debería ser posible integrarlo en su construcción continua (control de crucero, ciudad de equipo o lo que sea).
Hola, ¿podría aconsejarme sobre dónde podría encontrar más información sobre el uso de Spring para simular un servlet? –
@Ben: Spring tiene soporte para probar un servlet con clases de respuesta y solicitud de servlet falso, no para simular un servlet. –
En nuestro trabajo, nuestra solución de pruebas de integración tiene tres partes principales:
El resultado final es que la mayoría de la gente aquí nunca se preocupa por las pruebas de integración: simplemente sucede. Las pruebas unitarias, por otro lado, son la prioridad de todos. JUnit hace que sea fácil construir pruebas, aunque buenas pruebas siempre requerirán tiempo de reflexión y desarrollo.
He usado JUnit para hacer muchas pruebas de integración. Las pruebas de integración pueden, por supuesto, significar muchas cosas diferentes. Para más pruebas de integración de nivel de sistema, prefiero dejar que las secuencias de comandos dirijan mi proceso de prueba desde el exterior.
He aquí un método que funciona bien para mí para aplicaciones que utilizan HTTP y bases de datos y quiero para verificar toda la pila:
Hypersonic or H2 en el modo en memoria como un reemplazo para la base de datos (esto funciona mejor para ORM)@BeforeSuite o equivalente (de nuevo: más fácil con ORM)@Before cada prueba, borrar la base de datos e inicializar los datos necesariosJWebUnit para ejecutar peticiones HTTP hacia el embarcaderoEsto le da pruebas de integración que puedan funcionar sin ningún tipo de configuración de base de datos o servidor de aplicaciones y que ejercita la pila desde http hacia abajo. Como no tiene dependencias con recursos externos, esta prueba funciona bien en el servidor de compilación.
Aquí una parte del código que utilizo:
@BeforeClass
public static void startServer() throws Exception {
System.setProperty("hibernate.hbm2ddl.auto", "create");
System.setProperty("hibernate.dialect", "...");
DriverManagerDataSource dataSource = new DriverManagerDataSource();
dataSource.setJdbcUrl("jdbc:hsqldb:mem:mytest");
new org.mortbay.jetty.plus.naming.Resource(
"jdbc/primaryDs", dataSource);
Server server = new Server(0);
WebAppContext webAppContext = new WebAppContext("src/main/webapp", "/");
server.addHandler(webAppContext);
server.start();
webServerPort = server.getConnectors()[0].getLocalPort();
}
// From JWebUnit
private WebTestCase tester = new WebTestCase();
@Before
public void createTestContext() {
tester.getTestContext().setBaseUrl("http://localhost:" + webServerPort + "/");
dao.deleteAll(dao.find(Product.class));
dao.flushChanges();
}
@Test
public void createNewProduct() throws Exception {
String productName = uniqueName("product");
int price = 54222;
tester.beginAt("/products/new.html");
tester.setTextField("productName", productName);
tester.setTextField("price", Integer.toString(price));
tester.submit("Create");
Collection<Product> products = dao.find(Product.class);
assertEquals(1, products.size());
Product product = products.iterator().next();
assertEquals(productName, product.getProductName());
assertEquals(price, product.getPrice());
}
Para aquellos que quieren saber más, he escrito un article about Embedded Integration Tests with Jetty and JWebUnit en Java.net.
¿Qué es el campo "probador" en el código de ejemplo? – Nicolai
Si está probando la integración con su base de datos, debe probar la integración con esa base de datos y no con un sustituto. Si está probando la integración con algún otro sistema, entonces tiene sentido usar una base de datos sustituta si eso disminuye las posibilidades de errores "falsos". – kc2001
@ kc2001 Cierto, cuanto más realista sea su configuración de prueba, más podrá confiar en sus pruebas. Para mí, usar un DB sustituto se ha sentido suficiente (y es más rápido), pero usar el DB real daría más confianza. –
La sugerencia depende de su aplicación y su objetivo.
He escrito pruebas de integración en JUnit, pero también he visto personas usar HtmlUnit (extensión JUnit), Selenium, Watir, Fit/Fitness e incluso herramientas comerciales como WinRunner y Silk.
Cuéntanos un poco más acerca de tu dominio y los objetivos de tus pruebas y probablemente puedas obtener una mejor respuesta.
Espero haber aclarado la pregunta. –
Hay una muy buena extensión para JUnit llamada Jitr.
Jitr es un JUnit Integration Test Runner y permite que las pruebas de integración de aplicaciones web se ejecuten fácilmente contra un contenedor web liviano en la misma JVM que sus pruebas.
ver a su sitio para más detalles: http://www.jitr.org/
Actualización para 2012: Mientras JUnit se puede utilizar (y se beneficia de apoyo CI) JWebUnit y selenio parecen estar comiendo el reconocimiento de marca para pruebas de integración.
Creo que las pruebas de automatización e integración no funcionan bien juntas. El problema más básico es configuración de entorno antes de cada prueba. Cuanto más prueba de tipo de integración se necesita una configuración más grande.
Mis pensamientos sobre la automatización de pruebas sobre la capa de integración: http://blog.aplikacja.info/2012/03/whats-wrong-with-automated-integration-tests/
con respecto a "No hay limitaciones que restringen a ser pruebas de unidad única," por favor ver http://stackoverflow.com/questions/3144887/passing-junit -data-between-tests. Algunas respuestas interesantes y sugerencias allí. – orbfish