Archivo

Archivos de marzo, 2012

Sobre los test unitarios y la capa de acceso a datos

Lunes, 5 de marzo de 2012

Este viernes, durante una cena con integrantes de Gusenet y con Javier Torrecilla, que muy amablemente vino a darnos una charla sobre EF, saltó el comentario de que si decidía no hacer test unitarios a mi capa de datos el resto de tests de mi aplicación no serviría para nada, la casa se me caería sobre los cimientos y acabaría siendo víctima de la moda programando tests que no aportan nada a mi aplicación.

De buenas a primeras yo no estaba muy de acuerdo con la afirmación, pero hay que ser prudente, así que me he dado un par de días para pensarlo bien… y la verdad es que sigo sin pensar que sea cierto.

Por supuesto, hacer test unitarios a la DAL es algo deseable si se cuenta con el tiempo y los recursos (aunque hay que reconocer que es un grano en el culo). Si pudiera haría test unitarios hasta al desayuno de por las mañanas, pero hay que pensar que no siempre se cuenta con los recursos necesarios para hacer todo lo que queremos.

Unos buenos test unitarios deben tener unas características de sobra conocidas: Automatizables, completos (con respecto a lo que se está probando), independientes, repetibles, sencillos, etc. Si tenemos una buena separación en capas, y hemos cumplido estos principios le habremos dado un valor añadido al código de esa capa, independientemente de que otras capas carezcan de ese valor, porque los test deben ser UNITARIOS ¡Es su principal característica! No pasa nada si un test en la capa de negocio no me detecta un mal funcionamiento en la DAL. No solo no pasa nada, sino que es normal, porque lo deseable es que un test pruebe solo una cosa, y por eso usamos mocks y stubs: Para que aislandolo de sus dependencias nuestro test pruebe “una sola unidad de código”, y estar seguros en la medida de lo posible de que esa unidad en concreto funciona como esperamos.

No debemos esperar que los test nos detecten todos los errores porque sabemos que eso no va a pasar, pero sí es importante que las clases con lógica de negocio funcionen como nosotros pensamos que van a funcionar y que los bugs arreglados no vuelvan nunca a repetirse.

Lo que realmente me gustaría es probarlo todo, pero si no lo hago así, creo que un 20% de buena cobertura es mejor que un 0%, independientemente de las capas sobre las que esté hecho. ¿Y qué pasa entonces con los errores de la DAL? ¿Nos los comemos? No, por supuesto que no. ¿O acaso solo probamos nuestras aplicaciones con test unitarios? Tener una buena cobertura no es excusa ni de lejos para seguir haciendo las pruebas manuales de toda la vida.

Como diría Steven Sanderson, no es cierto que cualquier test unitario sea mejor que ninguno, pero sí que un buen test unitario es mejor que ninguno. A lo que yo añadiría “No importa en la capa que esté”.

Llegados a este punto corro el peligro de comenzar a repetirme y ponerme pesado, pero nunca podrán decir que me asusto del peligro: Voy a poner un par de ejemplos prácticos donde se clarifica mi postura:

–          Nos toca desarrollar una capa de negocio sobre una capa DAL que ya está hecha, tengo dos opciones:

a) No hacer pruebas unitarias a la nueva capa porque… total, la DAL no las tiene así que las que yo haga no aportan nada.

b) Hacer pruebas unitarias a la nueva capa conforme la estoy desarrollando.

En este caso, mi opción es la B.

–          Me toca mantener una aplicación que no tiene test unitarios, encuentro y arreglo un bug, tengo 2 opciones:

a)      Hago un test unitario que pruebe ese caso, para que el error no vuelva a repetirse misteriosamente.

b)      No hago un test unitario, porque cubrir solo ese 0.001% del código no me aporta nada, son solo modas.

 Esta vez… mi opción es la A.

Tests Unitarios ,