Implementación de pruebas unitarias

Taller de Programación Orientada a Objetos 
Semana 11 

Implementación de las pruebas unitarias en código documentado y un reporte de los resultados de su ejecución.

Diseño de pruebas unitarias

Programación Orientada a Objetos 
Semana 11 

Esta entrada es referente a las pruebas unitarias que estamos por aplicar a nuestro proyecto. Primeramente tenemos que conocer que es una prueba unitaria en la materia de programación, y es que esta es una manera de probar si una parte de nuestro código funciona correctamente. Con esto nos podemos asegurar que cada una de los métodos de una clase funcionen correctamente individualmente.

La principal razón por la que se escriben pruebas para cada función o método en una clase, es para que su buen funcionamiento sea independiente de las otras.

Con lo que debe cumplir una prueba unitaria para considerase buena debe seguir por lo menos los siguientes requisitos:

Automatizable: No debería requerirse una intervención manual.

Completas: Deben cubrir la mayor cantidad de código.

Reutilizables: No se deben crear pruebas que sólo puedan ser ejecutadas una sola vez.

Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra.

El objetivo de una prueba unitaria es comprobar que partes individuales del código funcionan correctamente.

Las ventajas que nos brindan las pruebas unitarias son:

Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura, puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.

Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente.

Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.

Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro.

Los errores están más acotados y son más fáciles de localizar: Dado que tenemos pruebas unitarias que pueden desenmascararlos.

Otra ventaja de las pruebas unitarias es que nos da más confianza para modificar código ya que se pierde el miedo a hacer modificaciones y volver inconsistente el sistema.

Según el tipo de componente, podemos probar varios aspectos del código:
Funciones individuales o métodos de objeto: Probar las entradas y las salidas y comprobar que los valores obtenidos son los esperados.

Clases de objetos: Hacer pruebas aisladas de operaciones o probar también las secuencias de las operaciones.

Componentes: Hay que tener en cuenta si son distribuidos, en este caso es recomendable pasarle al componente pruebas de estrés.

¿Donde ejecutamos las pruebas unitarias?

En java podemos usar JUnit para las pruebas unitarias y JMeter para pruebas de rendimiento. Para otros lenguajes existen herramientas similares.

JUnit es un conjunto de clases que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente.

Yo descargue JUnit desde el siguiente enlace:

Descargas

En la página hay varios paquetes, yo recomiendo bajar el más reciente que hasta el momento es el credo el 18 de enero de este año.

Crear nuestros propios Tests

En el enlace anterior esta una página de ayuda con un ejemplo simple de como empezar con JUnit y la creación de tests.

¿Cuándo implementamos las pruebas unitarias?

De forma paralela a la codificación o antes de la codificación siguiendo un desarrollo guiado por pruebas.

Referencias:
Prueba unitaria
Pruebas en el Software

Implementación de eventos, excepciones y errores

Taller de Programación Orientada a Objetos 
Semana 10 

Incorporación de eventos, excepciones y errores particulares del software.

Excepciones

Pequeños bloques de try y catch de mi código.

Con el manejo de archivos:

try {
  out = new FileOutputStream("Datos01.dat");
  p = new PrintStream(out);
  p.println("Tabla nueva");
  p.close();
} catch (Exception e) {
  System.err.println("Error con el archivo");
}

try {
  FileInputStream fstream = new FileInputStream(project/01.dat);
  DataInputStream in = new DataInputStream(fstream);

  while (in.available() !=0) {
    System.out.println(in.readLine());
  }
  in.close();
} catch (Exception e) {
  System.err.println("Error al crear");
}

En la entrada de datos:

public EntradaDatos() {
  InputStreamReader entrada = new InputStreamReader(System.in);
  BufferedReader br = new BufferedReader(entrada);
  try {
    System.out.println("Dime tu nombre:");
    nombre = br.readLine();
    System.out.println("Dime cuanto daras:");
    valor = Double.parseDouble(br.readLine());
  } catch(Exception e)  {
    e.printStackTrace();
  }
}

Identificación de eventos, excepciones y errores

Programación Orientada a Objetos 
Semana 10 

Texto con diagramas que explica los eventos, excepciones y errores particulares al software que está diseñando.

Eventos

En Java, los eventos representan toda la actividad que tiene lugar entre el usuario y la aplicación. Abstract Windowing Toolkit (AWT) comunica estas acciones a los programas de uso de eventos. Cuando el usuario interactúa con un programa digamos haciendo clic en un botón de comando, el sistema crea un evento que representa la acción y delega en el código de control de eventos dentro del programa. Este código determina la forma de controlar el evento por lo que el usuario obtiene la respuesta adecuada.

Existen varios grupos de eventos comunes en programas creados en Java, como pueden ser:
Eventos de la ventana.
Eventos del teclado.
Eventos del ratón.
Eventos de las barras de desplazamiento.

Para que un evento logre hacer la acción para la cual se le programo, es necesario tener un escuchador que este al pendiente de las acciones del usuario, y este responda inmediatamente de alguna forma.

> Como todo programa que incluye una interfaz gráfica como eventos de mi proyecto tendré una ventana que responderá a los botones de la esquina superior y marcan el cierre o la acción de minimizar la ventana.

> Como en mi programa se necesita que el usuario llene algunos campos se tiene que tener un escuchador para el teclado, que este recibiendo datos del teclado.

> Y el escuchador para los botones de la ventana principal, también requiere del escuchador.

Estos será los eventos que tendría tomados en cuenta en mi programa.

Excepciones

Una excepción es un evento, que se produce durante la ejecución de un programa, que interrumpe el flujo normal de las instrucciones del programa.

Cuando se produce un error dentro de un método, el método crea un objeto y lo entrega al sistema en el tiempo de ejecución. El objeto, llamado un Objeto de Excepción, contiene información sobre el error, incluyendo su tipo y el estado del programa cuando se produjo el error. A la creación de un objeto de excepción y la entrega al sistema en el tiempo de ejecución se denomina una excepción.

El sistema de ejecución busca en la pila de llamadas de un método que contiene un bloque de código que puede controlar la excepción. Este bloque de código que se llama un controlador de excepciones. La búsqueda se inicia con el método en el que se produjo el error y procede a través de la pila de llamadas en el orden inverso en el que los métodos fueron llamados.

Existen tres tipos de excepciones:
El primer tipo de excepción es la excepción comprobada. Estas son condiciones excepcionales que una aplicación bien escrita debe anticipar y recuperarse. Por ejemplo, si se le pide al usuario indicar el nombre de un archivo que se desea abrir, y se comete un error en la escritura del archivo y este no existe, entonces el programa deberá lanzar un aviso de error en la escritura del nombre del archivo.

El segundo tipo de excepción es el error. Estas son condiciones excepcionales que son externos a la demanda, y que la aplicación por lo general no puede anticipar o recuperarse. Por ejemplo, si es necesario abrir un archivo para que el programa haga determinada acción y por fallas en el sistema o hardware este archivo no se puede abrir, estaríamos enfrentando este tipo de error.

El tercer tipo de excepción es la excepción en tiempo de ejecución. Estas son condiciones excepcionales que son internos a la demanda, y que la aplicación por lo general no puede anticipar o recuperarse. Estos por lo general indican errores de programación, tales como errores de lógica o el uso indebido de una API.

El primer paso en la construcción de un controlador de excepciones es encerrar el código que podría lanzar una excepción dentro de un try.

Para asociar controladores de excepciones con try al proporcionar una o más bloques catch inmediatamente después de la try de bloque. Ningún código puede estar entre el final de las try de bloque y el comienzo de la primera catch de bloque.

try {

} catch (ExceptionType name) {

} catch (ExceptionType name) {

}

Errores

EL error es un tipo de excepción que no se puede anticipar y por lo general termina cerrando el programa. Lo ideal es avisar al usuario que se deberá cerrar el programa por completo, y evitar que el programa se cierre frente a los ojos del usuario sin darle previo aviso.

> En mi caso, si al abrir el programa se detecta un error que impide abrir correctamente el programa, este deberá cerrarse inmediatamente.

> También se puede esperar a que en el momento de la ejecución del programa un evento deje de escuchar las peticiones por falla en el sistema mismo, este deberá mandar el error y avisar del cierre próximo del programa.

Referencias:
Java Exceptions
Eventos en Java