La prueba es el proceso de verificar la funcionalidad de la aplicación si está funcionando según los requisitos.

La prueba unitaria es la prueba de una sola entidad (clase o método). Las pruebas unitarias son muy esenciales para que todas las empresas de software brinden un producto de calidad a sus clientes.

La ejecución de los casos de prueba manualmente sin ningún soporte de herramientas se conoce como prueba manual.

Tomar el soporte de la herramienta y ejecutar los casos de prueba mediante el uso de la herramienta de automatización se conoce como prueba de automatización.

Las siguientes son las desventajas de las pruebas manuales:

• Consume mucho tiempo y es tedioso: dado que los casos de prueba los ejecutan recursos humanos, es muy lento y tedioso.

• Gran inversión en recursos humanos: dado que los casos de prueba deben ejecutarse manualmente, se requieren más probadores en las pruebas manuales.

• Menos confiable: las pruebas manuales son menos confiables, ya que es posible que las pruebas no se realicen con precisión cada vez debido a errores humanos.

• No programable: no se puede realizar ninguna programación para escribir pruebas sofisticadas que obtengan información oculta.

Las siguientes son las ventajas de las pruebas automatizadas:

• Fast - La automatización ejecuta casos de prueba significativamente más rápido que los recursos humanos.

• Less investment in human resources - Los casos de prueba se ejecutan utilizando la herramienta de automatización, por lo que se requieren menos tester en las pruebas de automatización.

• More reliable - Las pruebas de automatización realizan exactamente la misma operación cada vez que se ejecutan.

• Programmable - Los probadores pueden programar pruebas sofisticadas para sacar información oculta.

JUnit es un marco de pruebas de regresión utilizado por los desarrolladores para implementar pruebas unitarias en Java y acelerar la velocidad de programación y aumentar la calidad del código.

Las siguientes son las características importantes de JUnit:

• Es un marco de código abierto.

• Proporciona anotación para identificar los métodos de prueba.

• Proporciona afirmaciones para probar los resultados esperados.

• Proporciona corredores de prueba para ejecutar pruebas.

• Las pruebas JUnit se pueden ejecutar automáticamente y verifican sus propios resultados y brindan retroalimentación inmediata.

• Las pruebas de JUnit se pueden organizar en conjuntos de pruebas que contienen casos de prueba e incluso otros conjuntos de pruebas.

• JUnit muestra el progreso de la prueba en una barra que es verde si la prueba va bien y se vuelve roja cuando falla una prueba.

Un caso de prueba unitario es una parte del código que garantiza que la otra parte del código (método) funcione como se espera. Para lograr los resultados deseados rápidamente, se requiere un marco de prueba. JUnit es el marco de prueba unitario perfecto para el lenguaje de programación Java.

Un caso de prueba unitario escrito formal se caracteriza por una entrada conocida y por una salida esperada, que se resuelve antes de ejecutar la prueba. La entrada conocida debe probar una condición previa y la salida esperada debe probar una condición posterior.

Debe haber al menos dos casos de prueba unitarios para cada requisito: una prueba positiva y una prueba negativa. Si un requisito tiene subrequisitos, cada subrequisito debe tener al menos dos casos de prueba como positivos y negativos.

Las pruebas se escriben antes del código durante el desarrollo para ayudar a los programadores a escribir el mejor código.

La depuración del código usando system.out.println () conducirá a un escaneo manual de toda la salida cada vez que se ejecute el programa para garantizar que el código esté realizando las operaciones esperadas. Además, a largo plazo, se necesita menos tiempo para codificar métodos JUnit y probarlos en archivos de clase.

Siga los pasos a continuación:

• Descargue la última versión de JUnit, a la que se hace referencia a continuación como junit.zip.

• Descomprima el archivo de distribución junit.zip en un directorio denominado% JUNIT_HOME%.

• Agregue JUnit al classpath -

set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%\junit.jar

• Pruebe la instalación ejecutando las pruebas de muestra distribuidas con JUnit (las pruebas de muestra se encuentran en el directorio de instalación directamente, no en el archivo junit.jar). Luego simplemente escriba -

java org.junit.runner.JUnitCore org.junit.tests.AllTests

• Todas las pruebas deben aprobarse con un mensaje "OK". Si las pruebas no pasan, verifique que junit.jar esté en CLASSPATH.

Informar múltiples fallas en una sola prueba es generalmente una señal de que la prueba hace demasiado y es una prueba unitaria demasiado grande. JUnit está diseñado para funcionar mejor con una serie de pequeñas pruebas. Ejecuta cada prueba dentro de una instancia separada de la clase de prueba. Informa fallas en cada prueba.

JUnit 3.7 desaprobó assert () y lo reemplazó con assertTrue (), que funciona exactamente de la misma manera. JUnit 4 es compatible con la palabra clave assert. Si ejecuta con el modificador -ea JVM, JUnit informará de las afirmaciones que fallan.

La refactorización de componentes J2EE para delegar la funcionalidad a otros objetos que no tienen que ejecutarse en un contenedor J2EE mejorará el diseño y la capacidad de prueba del software. Cactus es una extensión JUnit de código abierto que se puede utilizar para realizar pruebas unitarias de código java del lado del servidor.

JUnit Framework se puede integrar fácilmente con cualquiera de los siguientes:

• Eclipse
• Ant
• Maven

El marco de prueba JUnit proporciona las siguientes características importantes:

• Fixtures
• Suites de prueba
• Corredores de prueba
• Clases de JUnit

Fixture es un estado fijo de un conjunto de objetos que se utiliza como línea de base para ejecutar pruebas. El propósito de un dispositivo de prueba es garantizar que exista un entorno bien conocido y fijo en el que se ejecuten las pruebas para que los resultados sean repetibles. Incluye los siguientes métodos:

• método setUp () que se ejecuta antes de cada invocación de prueba.

• tearDown () método que se ejecuta después de cada método de prueba.

El conjunto de pruebas significa agrupar algunos casos de prueba unitarios y ejecutarlos juntos. En JUnit, las anotaciones @RunWith y @Suite se utilizan para ejecutar la prueba de la suite.

El corredor de pruebas se utiliza para ejecutar los casos de prueba.

Las clases de JUnit son clases importantes que se utilizan para escribir y probar JUnits. Algunas de las clases importantes son:

• Assert - Contiene un conjunto de métodos de aserción.

• TestCase - Contiene un caso de prueba que define el dispositivo para ejecutar múltiples pruebas.

• TestResult - Contiene métodos para recopilar los resultados de la ejecución de un caso de prueba.

• TestSuite - Es un compuesto de pruebas.

Las anotaciones son como metaetiquetas que puede agregar a su código y aplicarlas a métodos o en clase. La anotación en JUnit nos da información sobre los métodos de prueba, qué métodos se ejecutarán antes y después de los métodos de prueba, qué métodos se ejecutarán antes y después de todos los métodos, qué métodos o clases se ignorarán durante la ejecución.

Siga los pasos a continuación:

• Establecer el CLASSPATH

• Invocar al corredor -

java org.junit.runner.JUnitCore

Esta clase proporciona un conjunto de métodos de afirmación útiles para escribir pruebas. Solo se registran las afirmaciones fallidas.

Un TestResult recopila los resultados de la ejecución de un caso de prueba. Es una instancia del patrón Collecting Parameter. El marco de prueba distingue entre fallas y errores. Una falla se anticipa y se verifica con afirmaciones. Los errores son problemas imprevistos como una excepción ArrayIndexOutOfBoundsException.

Un TestSuite es un compuesto de pruebas. Ejecuta una colección de casos de prueba.

La anotación Test le dice a JUnit que el método public void al que está adjunto se puede ejecutar como un caso de prueba.

Varias pruebas necesitan objetos similares creados antes de que puedan ejecutarse. Anotar un método de vacío público con @Before hace que ese método se ejecute antes de cada método de prueba.

Si asigna recursos externos en un método Antes, debe liberarlos después de que se ejecute la prueba. Anotar un método de vacío público con @After hace que ese método se ejecute después del método de prueba.

Anotar un método void estático público con @BeforeClass hace que se ejecute una vez antes que cualquiera de los métodos de prueba de la clase.

Esto ejecutará el método después de que hayan finalizado todas las pruebas. Esto se puede utilizar para realizar actividades de limpieza.

A continuación se muestran algunas de las utilidades de la anotación @Ignore:

Puede identificar fácilmente todas las anotaciones @Ignore en el código fuente, mientras que las pruebas sin anotaciones o comentadas no son tan fáciles de encontrar.

Hay casos en los que no puede arreglar un código que falla, pero aún desea que el método esté presente, precisamente para que no se olvide. En tales casos, @Ignore tiene sentido.

A continuación se muestra cómo funciona el procedimiento de ejecución de JUnit:

• En primer lugar, el método anotado como @BeforeClass se ejecuta solo una vez.

• Por último, el método anotado como @AfterClass se ejecuta solo una vez.

• El método anotado como @Before se ejecuta para cada caso de prueba pero antes de ejecutar el caso de prueba.

• El método anotado como @After se ejecuta para cada caso de prueba pero después de la ejecución del caso de prueba.

• Entre el método anotado como @Before y el método anotado como @After se ejecuta cada caso de prueba.

Los casos de prueba se ejecutan utilizando la clase JUnitCore. JUnitCore es una fachada para ejecutar pruebas. Admite la ejecución de pruebas JUnit 4, pruebas JUnit 3.8.x y mezclas.

Junit ofrece una práctica opción de tiempo de espera. Si un caso de prueba lleva más tiempo que el número especificado de milisegundos, Junit lo marcará automáticamente como fallido. El parámetro de tiempo de espera se usa junto con la anotación @Test.

JUnit proporciona una opción para rastrear el manejo de excepciones del código. Puede probar si un código arroja la excepción deseada o no. El parámetro esperado se usa junto con la anotación @Test de la siguiente manera: @Test (esperado)

Junit 4 ha introducido una nueva función de pruebas parametrizadas. Las pruebas parametrizadas permiten al desarrollador ejecutar la misma prueba una y otra vez usando diferentes valores.

Hay cinco pasos que debe seguir para crear pruebas parametrizadas

• Anote la clase de prueba con @RunWith (Parameterized.class).

• Cree un método estático público anotado con @Parameters que devuelva una colección de objetos (como matriz) como conjunto de datos de prueba.

• Cree un constructor público que tome lo que es equivalente a una "fila" de datos de prueba.

• Cree una variable de instancia para cada "columna" de datos de prueba.

• Cree sus casos de prueba utilizando las variables de instancia como fuente de los datos de prueba.

• El caso de prueba se invocará una vez por cada fila de datos. Veamos las pruebas parametrizadas en acción.

Accesorios es un estado fijo de un conjunto de objetos que se utiliza como línea de base para ejecutar pruebas. El propósito de un dispositivo de prueba es garantizar que exista un entorno bien conocido y fijo en el que se ejecuten las pruebas para que los resultados sean repetibles. Incluye -

• método setUp () que se ejecuta antes de cada invocación de prueba.

• tearDown () método que se ejecuta después de cada método de prueba.

Compilar una clase de prueba JUnit es como compilar cualquier otra clase de Java. Lo único que debe tener en cuenta es que el archivo JUnit JAR debe incluirse en la ruta de clase.

Si un método de prueba JUnit se declara como "privado", se compilará correctamente. Pero la ejecución fallará. Esto se debe a que JUnit requiere que todos los métodos de prueba se declaren como "públicos".

Cuando un método se declara como "protegido", solo se puede acceder a él dentro del mismo paquete donde se define la clase. Por lo tanto, para probar un método "protegido" de una clase de destino, defina su clase de prueba en el mismo paquete que la clase de destino.

Cuando un método se declara como "privado", solo se puede acceder a él dentro de la misma clase. Por tanto, no hay forma de probar un método "privado" de una clase de destino desde cualquier clase de prueba. Por lo tanto, debe realizar pruebas unitarias manualmente. O tienes que cambiar tu método de "privado" a "protegido".

Si se declara que un método de prueba JUnit devuelve "String", la compilación pasará correctamente. Pero la ejecución fallará. Esto se debe a que JUnit requiere que todos los métodos de prueba se declaren para devolver "void".

Sí, puedes probar usando el método main (). Una ventaja obvia parece ser que puede probar la clase en una caja blanca. Es decir, puede probar sus partes internas (métodos privados, por ejemplo). No puedes hacer eso con pruebas unitarias. Pero principalmente el marco de prueba prueba la interfaz y el comportamiento desde la perspectiva del usuario.

No. No necesitamos escribir una clase de prueba independiente para cada clase que necesite ser probada. Si hay un pequeño grupo de pruebas que comparten un dispositivo de prueba común, puede mover esas pruebas a una nueva clase de prueba.

El ejecutor de la prueba tiene fuertes referencias a todas las instancias de prueba durante la ejecución de la prueba. Esto significa que para una ejecución de prueba muy larga con muchas instancias de prueba, ninguna de las pruebas puede ser recolectada como basura hasta el final de toda la ejecución de la prueba. Establecer explícitamente un objeto como nulo en el método tearDown (), por ejemplo, permite que se recolecte la basura antes del final de toda la ejecución de prueba.

En una prueba unitaria, los objetos simulados pueden simular el comportamiento de objetos complejos, reales (no simulados) y, por lo tanto, son útiles cuando un objeto real es impráctico o imposible de incorporar en una prueba unitaria.

El estilo de codificación común para probar con objetos simulados es:

• Crea instancias de objetos simulados.
• Establezca el estado y las expectativas en los objetos simulados.
• Invocar código de dominio con objetos simulados como parámetros.
• Verifique la coherencia en los objetos simulados.

Las siguientes son las extensiones de JUnit:

• Cactus

• JWebUnit

• XMLUnit

• MockObject

Cactus es un marco de prueba simple para pruebas unitarias de código java del lado del servidor (Servlets, EJB, Tag Libs, Filtros). La intención de Cactus es reducir el costo de escribir pruebas para el código del lado del servidor. Utiliza JUnit y lo amplía. Cactus implementa una estrategia en el contenedor, lo que significa que las pruebas se ejecutan dentro del contenedor.

El ecosistema de cactus está formado por varios componentes:

• Cactus Framework es el corazón de Cactus. Es el motor que proporciona la API para escribir pruebas de Cactus.

• Los módulos de integración de Cactus son interfaces y marcos que proporcionan formas fáciles de usar el marco de Cactus (scripts Ant, complemento Eclipse, complemento Maven).

WebUnit es un marco de prueba basado en Java para aplicaciones web. Envuelve los marcos de prueba existentes, como HtmlUnit y Selenium, con una interfaz de prueba unificada y simple para permitirle probar rápidamente la exactitud de sus aplicaciones web.

JWebUnit proporciona una API de Java de alto nivel para navegar por una aplicación web combinada con un conjunto de afirmaciones para verificar la exactitud de la aplicación. Esto incluye navegación a través de enlaces, ingreso y envío de formularios, validación del contenido de la tabla y otras características típicas de aplicaciones web comerciales.

Los métodos de navegación simples y las aserciones listas para usar permiten una creación de pruebas más rápida que usar solo JUnit o HtmlUnit. Y si desea cambiar de HtmlUnit a otros complementos como Selenium (disponible pronto), no es necesario que vuelva a escribir sus pruebas.

XMLUnit proporciona una única clase de extensión JUnit, XMLTestCase y un conjunto de clases de soporte.

Las clases de apoyo permiten hacer afirmaciones sobre -

• Las diferencias entre dos piezas de XML (a través de las clases Diff y DetailDiff).

• La validez de una pieza de XML (a través de la clase Validator).

• El resultado de transformar un fragmento de XML utilizando XSLT (a través de la clase Transform).

• La evaluación de una expresión XPath en una pieza de XML (a través de clases que implementan la interfaz XpathEngine).

• Nodos individuales en una pieza de XML que son expuestos por DOM Traversal (a través de la clase NodeTest).