Cómo hacer pruebas automáticas sin xUnit

Hace un tiempo en un webcast de la comunidad ágil de Venezuela mencioné la importancia de que todo programador sea responsable de escribir las pruebas unitarias de su código, lo cual es absolutamente independiente del lenguaje de programación utilizado ya que para hacer pruebas no es necesario contar con ninguna herramienta particular. Ante esta afirmación una persona de la audiencia consulto ¿afirmas que es posible escribir pruebas unitarias sin usar un framework de pruebas unitarias? La respuesta es si. Veamos un ejemplo.

Básicamente una prueba unitaria consta de 3 pasos conocidos como las 3A.

  • Arrange: es la preparación de todo lo necesario para realizar la prueba
  • Act: es la ejecutación de la prueba
  • Assert: es verificación de que el resultado obtenido es acorde a lo esperado

De estos tres pasos el único que depende del framework de pruebas unitarias es el assert. Generalmente el framework de pruebas unitarias provee uno o varios métodos del tipo assertXXXX que verifican el valor de verdad de una expresión y en base a ello arrojan un resultado.
Esta funcionalidad del assert de framework de pruebas unitarias bien podría ser reemplazada por una función similar a la siguiente

public void verificar(boolean expresion){
  if(!expresion)
    throw new RuntimeException();
}

Vemos cómo podríamos utilizar esta función para hacer un prueba de la clase ArrayList.

public void deberiaCrearseVacio(){
  // arrange & act
  ArrayList array = new ArrayList();
  // assert
  verificar(array.size()==0);
}

Para aquellos interesados en profundizar, aquí les dejo un ejemplo completo en Java que muestra como codificar y ejecutar las pruebas.

2 thoughts on “Cómo hacer pruebas automáticas sin xUnit

  1. Si bien es verdad que las 3A son los tres elementos de una prueba unitaria y “en teoría” se podría prescindir de un Framework, la familia xUnit (y sus vecinos) provee bastantes más cosas, con las que escribir pruebas unitarias es posible, pero poco más que una tortura. Por nombrar algunas:

    – Reporte de fallas y errores
    – Ejecución de tests parametrizados (para poder correr el mismo test con distintos tipos de entrada)
    – Integración con IDEs
    – Integración con frameworks de mocking, stubbing, etc.

    Por otro lado, estos Frameworks presentan, en general, unas interfaces con muy buen diseño, por lo que son una excelente manera de aprender sobre el diseño de buenas APIs.

    1. Estoy de acuerdo con tus observaciones. Este ejemplo no apuntaba a no usar un framework de pruebas unitarias, sino a mostrar que no es necesario el framework, pues hay gente que ve el no tener un framework como un impedimento para hacer las pruebas, lo cual es falso.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.