conceptos basicos de las pruebas de unidad
























LOS CONCEPTOS BÁSICOS DE LAS PRUEBAS DE UNIDAD
Siempre hay un primer paso: la primera vez que escribiste un programa, la primera vez que fracasaste en un proyecto, y la primera vez que tuviste éxito al tratar de compilar. Nunca olvidas la primera vez, y yo espero que no olvides tu primera prueba. Quizás estás listo para escribir algunas pruebas, yquizás recuerdas qué está comenzando mal, lento o inmantenible (mucha gente lo hace). Por otra parte puede que quizás tengas una gran experiencia con las pruebas unitarias, y estas leyendo esto para mirar que más puedes estarte perdiendo.
A lo largo de este ensayo mostraremos definiciones de pruebas unitarias, que pueden resultar confusas. Pero hay que ver los pros y contras del desarrollo eintegración de las pruebas unitarias
Definiendo pruebas unitarias, paso a paso.
Las pruebas unitarias no son algo nuevo en el desarrollo de software, ya que existen desde hace mucho tiempo; desde los lenguajes de programación de los años 70’s, y éstas han ido mejorando con el tiempo. Las pruebas de unidad se han convertido en una las mejores formas de desarrollo que pueden otorgar calidad de código,mientras van ganando mayor entendimiento.
Se introdujo el concepto de las pruebas unitarias en Smalltalk, y éstas se han integrado en muchos otros lenguajes de programación, haciendo pruebas unitarias extremadamente para prácticas en la programación de software. Una de las definiciones de pruebas de unidad, es la siguiente:
Una prueba unitaria es una pieza de un código (generalmente un método)que invoca otro pedazo de código y comprueba la corrección de alguna hipótesis después. Si el supuesto resulta ser erróneo, la prueba de unidad ha fallado. Una "unidad" es un método o función”.
Otra definición más clara sería:
Una prueba unitaria es una pieza de código que llama a una unidad de trabajo y verifica un resultado final específico de dicha unidad de trabajo. Si las hipótesis sobre elresultado final llegar a ser malo, la prueba de la unidad ha fallado. El ámbito de una prueba de unidad puede abarcar tan poco como un método o tanto como varias clases.
No importa qué lenguaje de programación esté usando, uno de los más difíciles aspectos, al realizar una prueba unitaria es definir si ésta es “buena”.
Es por eso, que ser capaz de entender lo que es una unidad de trabajo, no essuficiente, y la mayoría de las personas que intentan examinar su código mediante pruebas unitarias, renuncian en algún momento o simplemente no las realizan. En cambio, se basan en las pruebas del sistema y pruebas de integración y son que no son muy eficaces.
Por ejemplo, que importancia tendría escribir mal una prueba unitaria, si no se sabe cómo escribir una buena. Y es que se sabrá si unaprueba es buena, si podemos estar seguros que no empiezan con la idea equivocada de lo que estamos tratando de escribir. Para ello, hay que entender, primeramente, lo que es una prueba de unidad; por lo que tenemos que mirar lo que hacen los desarrolladores cuando están probando algo.
Es por ello, que una prueba unitaria debe tener las siguientes propiedades:
Debe ser automatizado y repetible.Debe ser fácil de implementar.
Debe ser relevante después.
Cualquier persona debe ser capaz de ejecutarla con sólo pulsar un botón.
Debe ejecutarse rápidamente.
Debe ser coherente en sus resultados (que siempre devuelve el mismo resultado y si no cambia no hizo nada entre ejecuciones).
Se debe tener control total bajo las pruebas unitarias.
Está completamente aislado (se ejecutaindependientemente de otras pruebas).
Cuando falla, debe ser fácil de detectar lo que se esperaba, y cómo determinar el problema.

Pruebas de Integración
Las pruebas de integración no se pueden considerar fáciles y consistentes, además utilizan una o más dependencias reales. Algunos ejemplos son probar un sistema en tiempo real, unos archivos del sistema o una base de datos.
Se realiza una prueba de...