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.

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.

image

Las diferentes relaciones que puedan existir entre módulos deben ser simulada para evitar dependencias entre módulos. La simulación suele hacerse en base a interfaces usando stubs o mocks.

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.

Published 18/2/2009 15:48 por Ibon Landa
Archivado en: ,,
Comparte este post:
http://geeks.ms/blogs/ilanda/archive/2009/02/18/caracter-237-sticas-de-una-buena-prueba-unitaria.aspx

Comentarios

# re: Características de una buena prueba unitaria

Una consulta, si tienes un procedimiento a modo de metodo de una clase que quieres probar, y tienes una lectura de una BD que te saltas con un mock,en el mock puedes simular el retorno para los fields de la tabla que debrías haber leído?

Gracias

Wednesday, February 18, 2009 4:42 PM por Julio Trujillo Leon

# re: Características de una buena prueba unitaria

Hola Julio,

Con un mock lo que simulas es un objeto al que llama tu clase. Si tu clase utiliza un método de acceso a datos seguro se puede simular con mocks.

Usando mocks tú configuras el comportamiento que va a tener tu objeto falso; Si al método A se le pasa 1 y 3 entonces devuelve 4....Si luego le pasas 1y 4 el mock no sabe lo que tiene que hacer.

Eso sí, usar mocks puede resultar un poco pesado en algunas ocasiones y aunque siendo purista deberían simularse los acceso a datos con mocks, hay ocasiones en que los test podrían usar la base de datos.

En mi caso no suelo simular el acceso a datos con mocks.

Utizo Database Edition para mantener mi esquema de base de datos y tener datos de pruebas, lo que me posibilidad que todos los miembros del equipo siempre tengamos el última esquema y así poder pasar los test contra la última versión de la base de datos.

Te recomiendo que eches un ojo a este post de Rodrigo Corral que habla sobre pruebas unitarias con base de datos.

geeks.ms/.../191-deben-los-test-unitarios-usar-la-base-de-datos.aspx

Un saludo,

Wednesday, February 18, 2009 5:07 PM por Ibon Landa

# re: Características de una buena prueba unitaria

Creo q el caso q expones es mas bien un stub q un mock :)

Public class PesonService

{

     public PersonService(IRepository repo,INotification n)

public void Save(Person p)

{

   try

      {

       repo.Save(p);

      }

  catch(DataBaseException ex)

     {

      service.Send(p);

     }

}

}

Para poder hacer un prueba unitaria sobre este  codigo se podria crear un stub del repositorio, lanzar una exception DataBaseException  y comprobar q el metodo Send se ejectuta.

La verdad q es un test un "poco ridiculo"...

MockNotification mock = new MockNotification(); //implementa el interfaz INotification

IRepository repo = new StubRepo();

Person p = new Person("lorem@lorem.com);

PesonService servicio = new PesonService(repo,mock);

servicio.Save(p);

Assert.AreEqual(mock.Email); // al mock se le pueden añadir propiedades o metodos.

Puede q este confundido. Bajo mi punto de vista los unicos test q deben usar la BBDD son los de la capa de datos. Este ejemplo q puse no lo deberia hacer ya q si tirase de un BBDD como lanzas la exception?

Saludos! :)

Thursday, February 19, 2009 2:04 PM por Carlos

# re: Características de una buena prueba unitaria

Hola Carlos,

La delgada linea entre mock y stub...yo hablaba de mocks o al menos eso intentaba :-) Suelo emplear RhinoMock.

Ambos son dos recursos que usamos en nuestras pruebas unitarias que nos permiten simular objetos con los que interactua el módulo de que está sometido a la prueba.

Los stubs proporcionas respuestas fijas a las llamadas hechas durante los test normalmente sin responder en absoluto a otra cosa fuera de lo que han sido programados.

Los mocks son objetos preprogramados con expectativas que conforman la especificación de cómo se espera que se reciban las llamadas.

Los stubs se basan más en el estado y los mocks permiten comprobar en detalle las llamadas realizadas entre ellos, en el comporamiento.

No sé si me habré explicado pero veo que sería un buen tema para otro post, diferencias entre stubs/mocks y con algún ejemplito :-)

En cuanto al tema de si deben o no usar la base de datos, en general suelo seguir lo que comentas. Los test que prueban la capa de acceso a datos usan las DDBB mientras que en el resto de los módulos intento simular las dependencias.

Lo que intentaba decir es que aunque las reglas de una buena prueba unitaria digan unas cosas, hay que tener cuidado con aplicarlas al 100% al pie de la letra. Si se conoce bien la teoría y bien las herrameintas podemos tomar decisiones sobre qué enfoque puede ser el adecuado para nuestras pruebas unitarias.

Un saludo!

Thursday, February 19, 2009 10:04 PM por Ibon Landa

# re: Características de una buena prueba unitaria

Eso eso, espero con ganas ese futuro post!

Friday, February 20, 2009 9:31 AM por Carlos

# re: Características de una buena prueba unitaria

Apuntado queda!

De todas maneras, si alguno está subscrito a la revista dotNetMania, el número de febrero de ha salido un artículo mio que habla sobre mocks y pone un ejemplo.

Un saludo!

Monday, February 23, 2009 12:52 PM por Ibon Landa