PDF de programación - Curso .NET con C# - Pruebas unitarias

Curso .NET con C#
Servicio de Informática

Pruebas unitarias

Índice de contenido
Características de una buena prueba unitaria.................................................................................1
Beneficios de las pruebas unitarias.................................................................................................2
Mitos de las pruebas unitarias.........................................................................................................3
Prueba de método...........................................................................................................................4
Métodos de inicialización..............................................................................................................10
Pruebas unitarias en web..............................................................................................................12
Configurar una prueba unitaria de ASP.NET ............................................................................14
Atributos de una prueba ASP.NET.........................................................................................14
Configurar pruebas unitarias de ASP.NET utilizando configuraciones de ejecución ....................15
Orígenes de datos para alimentar las pruebas..............................................................................16

Si es un programador que utiliza Visual Studio Professional Edition, puede crear y ejecutar dos
tipos de pruebas: unitarias y por orden. Una prueba unitaria se utiliza para comprobar que un
método concreto del código de producción funciona correctamente, probar las regresiones o
realizar pruebas relacionadas (buddy) o de humo. Una prueba por orden se utiliza para ejecutar
otras pruebas en un orden especificado.

Visual Studio nos proporciona un sistema sencillo para poder crear nuestras pruebas unitarias.
Nos facilita la creación de los proyectos de pruebas y nos genera la estructura básica que tiene
que tener la prueba

Los evaluadores del equipo pueden utilizar Herramientas para pruebas Team System para crear
y ejecutar pruebas. Si ejecutan una prueba unitaria en la que se produce un error, almacenan un
error y se lo asignan a usted. A continuación, usted puede utilizar Visual Studio para reproducir el
error ejecutando la prueba unitaria que no se ha superado.

Características de una buena prueba unitaria

Las pruebas unitarias se tienen que poder ejecutar sin necesidad de intervención manual. Esta
característica posibilita que podamos automatizar su ejecución.

Las pruebas unitarias tienen que poder repetirse tantas veces como uno quiera. Por este
motivo, la rapidez de las pruebas tiene un factor clave. Si pasar las pruebas es un proceso lento
no se pasarán de forma habitual, por lo que se perderán los beneficios que éstas nos ofrecen.

Las pruebas unitarias deben poder cubrir casi la totalidad del código de nuestra aplicación.
Una prueba unitaria será tan buena como su cobertura de código. La cobertura de código marca
la cantidad de código de la aplicación que está sometido a una prueba. Por tanto, si la cobertura
es baja, significará que gran parte de nuestro código está sin probar.

Tema 7 / Página 1

Curso .NET con C#
Servicio de Informática

Las pruebas unitarias tienen que poder ejecutarse independientemente del estado del entorno.
Las pruebas tienen que pasar en cualquier ordenador del equipo de desarrollo.

La ejecución de una prueba no puede afectar la ejecución de otra. Después de la ejecución de
una prueba el entorno debería quedar igual que estaba antes de realizar la prueba.

Las diferentes relaciones que puedan existir entre módulos deben ser simulada para evitar
dependencias entre módulos.

Es importante conocer claramente cuál es el objetivo del test. Cualquier desarrollador debería
poder conocer claramente cuál es el objetivo de la prueba y su funcionamiento. Esto sólo se
consigue si se trata el código de pruebas como el código de la aplicación.

Es importante tener en cuenta que aunque estas son las características de una buena prueba, no
siempre será posible ni necesario cumplir con todas estas reglas y será la experiencia la que nos
guiará en la realización de las mismas

Beneficios de las pruebas unitarias

Con las pruebas unitarias todos ganan. La vida de desarrollador será mucho más fácil, ya que
la calidad de su código mejorará, se reducirán los tiempos de depuración y la corrección de
incidencias y por tanto el cliente estará mucho más contento porque la aplicación hace lo que él
quiere que haga, por lo que ha pagado.

Las pruebas fomentan el cambio y la refactorización. Si consideremos que nuestro código es
mejorable podemos cambiarlo sin ningún problema. Si el cambio no estuviera realizado
correctamente las pruebas nos avisarán de ello. Seguramente la frase “si funciona no lo toques” a
más de uno familiar les resultará familiar. Si hubiera pruebas unitarias, no sería necesario
pronunciarla.

Se reducen drásticamente los problemas y tiempos dedicados a la integración. En las
pruebas se simulan las dependencias lo que nos permite que podemos probar nuestro código sin
disponer del resto de módulos. Por experiencia puede decir que los procesos de integración son
más de una vez traumáticos, dejándolos habitualmente para el final del proyecto. La frase “sólo
queda integrar” haciendo referencia a que el proyecto está cerca de terminar suele ser engañosa,
ya que el periodo de integración suele estar lleno de curvas.

Las pruebas nos ayudan a entender mejor el código, ya que sirven de documentación. A
través de las pruebas podemos comprender mejor qué hace un módulo y que se espera de él.

Nos permite poder probar o depurar un módulo sin necesidad de disponer del sistema
completo. Aunque seamos los propietarios de toda la aplicación, en algunas situaciones montar
un entorno para poder probar una incidencia es más costoso que corregir la incidencia
propiamente dicha. Si partimos de la prueba unitaria podemos centrarnos en corregir el error de
una forma más rápida y lógicamente, asegurándonos posteriormente que todo funciona según lo
esperado.

Tema 7 / Página 2

Curso .NET con C#
Servicio de Informática

Mitos de las pruebas unitarias

Aunque los beneficios de las pruebas unitarias puedan parecer claros, no es más cierto que a día
de hoy se usan en muy pocos proyectos. Pero sin son tan buenas,¿por qué no se usan?

Pues la razón principal es que existen bastante desconocimiento en esta materia, poca tradición y
algunos falsos mitos.

Uno de los mitos es creer que escribir pruebas unitarias es escribir el doble de código;
escribir el código de la aplicación y escribir el código de pruebas. Escribir una prueba nunca es
escribir el doble de código, aunque lógicamente sí es escribir más código. El mito es totalmente
falso.

Las pruebas siempre se deben ir escribiendo a medida que se desarrolla el software. A medida
de desarrollamos vamos probando nuestro código lo que nos permite asegurar que el módulo
queda terminado correctamente, libre de incidencias.

La realización de pruebas unitarias debe ser un proceso obligatorio en nuestros desarrollos y que
no queden a la voluntad del desarrollador. Si el desarrollador no está habituado a su uso diario es
muy fácil que tienda a evitar realizar este tipo de pruebas.

Si no estás familiarizado con el uso de pruebas unitarias la perseverancia debe ser tu gran aliado.
Debes estar convencido de que el uso de pruebas unitarias es el enfoque correcto y no ser
flexible; las pruebas unitarias no son opcionales y deben realizarse a medida que se desarrolla.

Dejar la implementación de pruebas para el final no es realista, ya que las pruebas nunca se
llegarán a implementar y si lo hacen, serán de una baja calidad, ya que la persona que las realiza
considerará que es una pérdida de tiempo, considerando que su tarea ya estaba terminada sin
realizar estas pruebas.

¿Y si no escribiéramos este código cómo probamos? Hay diferentes situaciones.

La primera situación es que no se prueba. Se implementa el módulo pero no se prueba, dando
por hecho que nuestra experiencia como desarrolladores hará que las incidencias sean mínimas.
Cuando tenemos todos los módulos lo probamos de forma integrada a través de pruebas
funcionales.

Esta situación es la situación peor con la que podemos encontrarnos, pero desgraciadamente es
la más habitual. Los tiempos de integración, depuración y corrección de incidencias se
multiplican. El tiempo que va desde que consideramos que el producto está terminado hasta que
realmente está terminado puede llegar a ser superior al tiempo invertido en el desarrollo, y lo digo
por experiencia, por mala experiencia.

Otra situación algo mejor, es el uso de aplicaciones de pruebas de usar y tirar. Todos hemos
implementado aplicaciones tontas, generalmente de consola, para probar el módulo que estamos
desarrollando y que posteriormente integraremos en un sistema mayor.

La situación no es la ideal pero realmente el desarrollo de pruebas unitarias puede tener una
semejanza con este tipo de aplicaciones, siendo éste último concepto más avanzado y mejorado
para que pueda ser reutilizable, independientes y completas.

Tema 7 / Página 3

Curso .NET con C#
Servicio de Informática

Estas aplicaciones de usar y tirar nos valen para la primera vez y si somos exhaustivos nos
permitirá probar bien nuestro módulo. La realidad nos dice que esta aplicación se tira y que ante
cualquier modificación en el módulo nos comportamos como en la situación primera, en las
pruebas con sistema completa y pruebas funcionales.

Otro mito, unido al anterior, es que desarrollar pruebas unitarias hace que los tiempos de
desarrollo se incrementen, incrementando los costes del proyecto.

Entre desarrollar y no probar y desarrollar haciendo pruebas unitarias, reconoceré que es más
rápido desarrollar sin probar…..pero creo que esto no nos vale….así que entre desar