java - tutorial - pruebas unitarias pdf

¿Podemos usar JUNIT para Pruebas de Integración Automatizada?

Question

¿Cómo automatizas las pruebas de integración ? Yo uso JUnit para algunas de estas pruebas. Esta es una de las soluciones o es totalmente incorrecta? ¿Que sugieres?

Answer 1

Actualización para 2012: si bien JUnit se puede usar (y los beneficios del soporte de CI), JWebUnit y Selenium parecen estar consumiendo el interés en las pruebas de integración.

Answer 2

Hay una muy buena extensión para JUnit llamada Jitr.

Jitr es un JUnit Integration Test Runner y permite que sus pruebas de integración de aplicaciones web se ejecuten fácilmente contra un contenedor web liviano en la misma JVM que sus pruebas.

Vea su sitio para más detalles: http://www.jitr.org/

Answer 3

¡Seguro! Usamos una combinación de tareas JUnit, ANT para ejecutarlas, y Hudson para pruebas de integración continuas. Funciona de maravilla.

Answer 4

Cuando uso Maven para construir un proyecto, he tenido un poco más de suerte con TestNG porque tiene las 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.

Answer 5

En nuestro trabajo aquí, nuestra solución de prueba de integración tiene tres partes principales:

1. CruiseControl es la base de nuestra metodología de integración continua.
2. Nuestra configuración de CruiseControl inicia una construcción de prueba rápida en 3 minutos desde el momento en que alguien se registra en Subversion . Las pruebas que ocurren aquí son "¿todo sigue compilando?" y "¿aún pasan las pruebas unitarias?". JUnit es obviamente el principal facilitador al responder las segundas preguntas.
3. Cada hora, se inicia una construcción más grande que construye la ayuda en línea y los instaladores que utilizamos en nuestras diversas plataformas de implementación. Este paso verifica las preguntas más importantes de "¿todavía tenemos un producto desplegable para cada una de nuestras plataformas de destino?"

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 las buenas pruebas siempre requerirán tiempo de pensamiento y desarrollo.

Answer 6

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.

Answer 7

Sí, puede usar junit para las pruebas de integración, pero depende del tipo de prueba de integración que necesite.

Probando un servlet:

• configurar el contexto y la configuración del servlet
• hacer las pruebas utilizando solicitudes de servlet simuladas (Spring tiene soporte para esto, pero también puedes usar EasyMock o tus propios simulacros)

Prueba de una aplicación de primavera:

• use AbstractDependencyInjectionSpringContextTests para configurar el contexto
• prueba los granos alámbricos
• también hay subclases de AbstractDependencyInjectionSpringContextTests que admiten la gestión de transacciones cuando se prueban con una base de datos.

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).

Answer 8

La sugerencia depende de su aplicación y su objetivo.

He escrito pruebas de integración en JUnit, pero también he visto a personas usar HtmlUnit (extensión JUnit), Selenium, Watir, Fit / Fitness e incluso herramientas comerciales como WinRunner y Silk.

Cuéntanos un poco más sobre tu dominio y los objetivos de tus pruebas, y probablemente puedas obtener una mejor respuesta.

Answer 9

Creo que las pruebas de automatización e integración no funcionan bien juntas . El problema más básico es la configuración del entorno antes de cada prueba. Cuanto más prueba de tipo de integración se necesita una configuración más grande.

Mi opinión sobre la automatización de pruebas en la capa de integración: http://blog.aplikacja.info/2012/03/whats-wrong-with-automated-integration-tests/

Answer 10

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.

Este es un enfoque que funciona bien para las aplicaciones que usan http y bases de datos y quiero verificar toda la pila:

1. Use Hypersonic or H2 en modo de memoria como reemplazo de la base de datos (esto funciona mejor para ORM)
2. Inicialice la base de datos en @BeforeSuite o equivalente (de nuevo: más fácil con ORM)
3. Use Jetty para iniciar un servidor web en proceso.
4. @Before cada prueba, borre la base de datos e inicialícese con los datos necesarios
5. Use JWebUnit para ejecutar solicitudes HTTP hacia Jetty

Esto le proporciona pruebas de integración que pueden ejecutarse sin ninguna configuración de base de datos o servidor de aplicaciones y que ejercitan la pila desde http hacia abajo. Como no tiene dependencias con recursos externos, esta prueba funciona bien en el servidor de compilación.

Aquí parte del código que uso:

@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 quieran saber más, he escrito un artículo sobre pruebas de integración incrustadas con Jetty y JWebUnit en Java.net.