Mostrando entradas con la etiqueta Librerias. Mostrar todas las entradas
Mostrando entradas con la etiqueta Librerias. Mostrar todas las entradas

miércoles, 22 de septiembre de 2010

Pruebas de caja negra y caja blanca

Caja Negra

El proceso de una prueba de caja negra es simple, toma una perspectiva externa del objeto de prueba para derivar los casos de prueba. Estas pruebas pueden ser funcionales o no funcionales, ejecutamos la unidad de prueba con datos y se observa la salida, la comparamos con el resulado esperado, tales resultados muchas veces se pueden comprobar usando las condiciones con assert y los errores lógicos que se pueden dar de estas pruebas con excepciones, por ejemplo: throw new AssertionError("el email no existe en la base de datos");

En las cajas negras no se conoce el funcionamiento o la estructura interna del programa en sí sino símplemente el funcionamiento interno de los objetos en prueba.


Caja Blanca

Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas.

Con las pruebas de caja blanca lo que buscamos es encontrar fragmentos del programa que no son ejecutados por los casos de pruebas. Si encontramos que el resultado de estas pruebas es menor al 100%, debemos ejecutar otros casos para intentar llegar al 100%. Si aun así no conseguimos ese 100%, deberíamos preguntarnos si sirve de algo ese trozo de código.

Ejercicio pruebas Caja Negra y Caja Blanca



lunes, 6 de septiembre de 2010

Desarollo Dirigido de Pruebas usando el plugin TestNG

Haremos un ejemplo de este desarrollo de pruebas (TDD - Test Driven Development) siguiendo el ejemplo de la web http://enjava.tiddlyspot.com/ en el apartado EjercicioModuloDesarrolloDirigidoPorPruebas.
En este caso la prueba será en el modo consola de texto, pero también existe un testeador muy potente para las pruebas para el tipo de interfaces gráficas como es Selenium.

El ciclo básico de desarrollo es el siguiente:

1.-Elegir un requerimiento - de la lista de los objetivos a implementar en un proyecto (Ej: añadir un libro a un catalogo)
2.-Escribimos una prueba.
3.-Verificar si la prueba falla.
4.-Escribir la implementación.
5.-Ejecutar las pruebas automatizadaas.
6.-Eliminacion de la duplicación.
7.-Actualizar la lista de requerimientos. (Tachar el requerimiento que ya este implementado y funcionando).

Cuando hacemos el test con TestNG, para no tener problemas con java a la hora de compilar deberemos usar un directorio simétrico de las clases, de esta forma no se solapan las clases puesto que en realidad los archivos se encuentran en el src del proyecto en cuestión.

MI src.es.cea.servicios.ServicioRegistro
PROYECTO test.es.cea.servicios.ServicioRegistroTest


Para ver como funciona el ejercicio de prueba sólo hay que descargándose el proyecto desde el repositorio, desde el número 32 hasta el último para ir viendo paso a paso como se desarrollan estas pruebas. Para descargar la nueva revisión del repositorio sólo hay que pulsar el botón derecho en el proyecto ->Team->Switch->indicar la version a descargar.

Ejemplo básico del funcionamiento de un TDD.

nombre prueba<-| public class ServicioRegistroTest {  @Test nombre metodo     <-| public void existeUsuario Registrado(){  objeto            <-| ServicioRegistro servicio = new ServicioRegistro();  escenario         <-| Usuario pepe = new Usuario("pepe"); a probar  prueba            <-| Usuario manolo = new Usuario("manolo");  invocación        <-| boolean existe = servicio.existeUsuarioRegistrado("pepe)";    comprobación      <-| assert(existe): "debería existir pepe"; y mensaje de error  

domingo, 18 de julio de 2010

Atajos y notas útiles

A lo largo del curso se irá registrando en el blog aquellos datos que puedan ser de utilidad para un trabajo más comodo con el entorno del programa.

Atajos y otras anotaciones para hacer la tarea más sencilla con Eclipse:

  • Cambio de Workspace: File-Switch Workspace. Sólo se puede usar un workspace (directorio de trabajo con eclipse). Es útil por la necesidad que tendremos de ir cambiando de uno dependiendo de los proyectos que tengamos en cada uno de ellos.
  • Configuracion: Windows-Preferences.

Librerias comunes se pueden almacenar en una libreria de usuario, estó se podrá hacer entrando la configuración-> windows-preferences-libraries. Será muy util para añadir librerias como por ejemplo de conexion a bases MySQL.

En este caso lo que hice fue añadir Apache.commons.logging. Existe un archivo Log4j.xml que despues se tendrá que añadir al proyecto que sea en caso de usar esa libreria. Dentro de este archivo hay que variar una línea que dice <>, hay q especificar la carpeta del proyecto para que funcione correctamente.

Configurar proyecto: pulsamos botón derecho encoma del proyecto en properties y lo configuramos como queramos. Añadimos librerías como dijimos anteriormente->pulsamos add library->user library->y elegimos las que previamente hemos añadido a la libreria principal.