Pruebas Unitarias Netbeans Java Maven JUnit Mockito PDF

Title Pruebas Unitarias Netbeans Java Maven JUnit Mockito
Author Sergio Alejandro Gonzalez Segura
Course Construcción de software
Institution Universidad Autónoma de Yucatán
Pages 8
File Size 559.1 KB
File Type PDF
Total Downloads 74
Total Views 132

Summary

Tutorial para usar JUnit y Mockito con Java y Netbeans...


Description

Pruebas Unitarias con NetBeans, Java, Maven, Junit y Mockito Sergio Alejandro González Segura.

En este documento se muestran los pasos para diseñar, implementar y ejecutar una prueba unitaria con NetBeans, Java, Maven, Junit y Mockito.

Creación de un nuevo proyecto en NetBeans Se crea un proyecto de forma tradicional, seleccionando Java y el framework Maven:

En este caso se usará PruMock como nombre del proyecto. Se probará una clase Escritor, la cual se encarga de agregar al final de un archivo, línea por línea, las cadenas que se le pasan. Empecemos con el siguiente diseño para Escritor:

El constructor indicado recibe el nombre del archivo en donde irá agregando las cadenas. Resulta razonable agregar el método que recibirá las cadenas y las agregará al archivo recibido en el constructor. Este método recibirá el nombre de “escribir”:

1

En este caso, se usará un sistema que usará a la clase Escritor a través de la clase Main:

Para la programación se puede empezar con Escritor, ya que no depende de Main. La clase se crea de forma tradicional:

package prumock; import java.util.List; public class Escritor { public Escritor(String nomArchDest) { } public void escribir(List cadenas) { } }

2

Hay varias maneras de implementar la funcionalidad, una de ellas es crear un objeto que almacene el archivo en donde se va a escribir, y escribir en él: package prumock; import import import import import

java.io.File; java.io.FileNotFoundException; java.io.FileOutputStream; java.io.OutputStreamWriter; java.util.List;

public class Escritor { private OutputStreamWriter writer; public Escritor(String nomArchDest) throws FileNotFoundException { File file = new File(nomArchDest); FileOutputStream os = new FileOutputStream(file); this.writer = new OutputStreamWriter(os); } public void escribir(List cadenas) { } }

Sin embargo, esta implementación cambia un poco el diseño, ya que ahora se usan varias clases extras: FileNotFoundException, File, FileOutputStream y OutputStreamWriter. No es necesario anotar todas estas dependencias, es suficiente la clase del objeto que se crea y mantiene:

El siguiente paso es implementar “escribir”: public void escribir(List cadenas) throws IOException { for(String cadena : cadenas) { writer.append(cadena); writer.append(System.lineSeparator()); }

3

writer.flush(); }

Para simular que se tiene un sistema que usa a Escribir, se implementará Main: package prumock; import java.io.FileNotFoundException; import java.io.IOException; import java.util.Arrays; public class Main { public static void main(String[] args) throws FileNotFoundException, IOException { Escritor escr = new Escritor("archivo.txt"); escr.escribir(Arrays.asList(args)); } }

Algunos modelos de programación dicen que se deben programar las pruebas antes de los métodos, en este caso programaremos las pruebas después para notar cómo se modifica el diseño para permitir la “testability”.

Para las pruebas necesitamos agregar JUnit al proyecto, esto se realiza automáticamente al crear una prueba unitaria. Una forma de crear una prueba unitaria es seleccionar a Escritor.java, y en Tools elegir “Crear/Actualizar Pruebas”:

Se pueden generar pruebas unitarias para cada parte de la clase:

4

Esto automáticamente actualiza pom.xml para que agregue Junit 5 al proyecto, y crea el archivo EscritorTest.java, el cual se ejecutará automáticamente al solicitar las pruebas unitarias de Escritor.java. El contenido de dicho archivo es un “esqueleto” para posteriormente escribir las pruebas unitarias. Al momento de escribir esto, hay una pequeña falla al crear el “esqueleto”, pues se duplican algunas anotaciones, sólo hay que borrar las funciones con anotaciones duplicadas. En este momento se descubre un problema: Escritor no devuelve valores que se puedan verificar en las pruebas, sino que directamente escribe en un archivo. Las pruebas unitarias deben ser rápidas, por lo que no deben escribir en archivos. Es necesario modificar a Escritor para que permita realizar las pruebas. La modificación inmediata, es que Escritor ya construya internamente un OutputStreamWriter, sino que se le agregue uno:

5

El código se modifica correspondientemente: public Escritor(OutputStreamWriter osw) { this.writer = osw; }

Ya que ahora el OutputStreamWriter (“writer”) se agrega a Escritor, lo lógico es que se pueda acceder y establecer dinámicamente, con métodos “get” y “set”. Se recomienda hacerlo, para dar mayor libertad a las pruebas, al mismo tiempo que el objeto queda mejor diseñado (se puede expandir su funcionalidad sin cambiar su código). El siguiente paso sería crear una clase dentro del ambiente de pruebas que reemplace los métodos append y flush de OutputStreamWriter por simulaciones que permitan verificar que efectivamente fueron llamados y con los parámetros correctos, sin embargo, existe Mockito, que permite crear clases completas simuladas, con las cuales se pueden verificar que los métodos sean llamados con los parámetros deseados. Para agregar Mockito al proyecto, se puede agregar la dependencia de pruebas:

Los datos para la dependencia son:

NetBeans autocompleta los parámetros, lo que ayuda a recordar y verificar. Otra opción es modificar directamente el archivo pom.xml, y agregarle la dependencia de Mockito:

org.mockito mockito-core 3.9.0 test

6

Notas:  

Versiones anteriores de Mockito tenían “mockito-all” además de “mockito-core”. “mockito-all” incluía sus dependencias, pero actualmente no se usa. Las versiones disponibles se pueden ver en: https://mvnrepository.com/artifact/org.mockito/mockito-core . Al momento de escribir esto la última versión es la 3.10.0.

Una vez declaradas las dependencias, hay que descargarlas de internet. En caso de que ya estén en la caché y no hayan sufrido cambios desde la última vez que se descargaron, no se volverán a descargar. La descarga se realiza con:

Si no se realiza manualmente, se descargarán automáticamente la primera vez que se ejecute el proyecto.

Analizando el código de escritor, descubrimos que, si le pasamos un arreglo con un elemento, debería agregar al archivo o al OutputStreamWriter ese elemento, un salto de línea, y hacer flush. Podemos programar una prueba unitaria que verifique que esto efectivamente suceda: public void testEscribir() throws Exception { System.out.println("Prueba de escribir"); OutputStreamWriter osw = Mockito.mock(OutputStreamWriter.class); Escritor escr = new Escritor(osw); ArrayList palabras = new ArrayList(1); palabras.add("uno"); escr.escribir(palabras); InOrder orden = inOrder(osw); orden.verify(osw).append("uno"); orden.verify(osw).append(System.lineSeparator()); orden.verify(osw).flush(); orden.verifyNoMoreInteractions(); }

Para ejecutar la prueba, seleccionamos Escritor.java y usamos + o presionamos el botón derecho del mouse y elegimos “Probar Archivo”:

7

El resultado es que la prueba pasa.

Si hubiese algún error, la prueba fallaría:

8...


Similar Free PDFs