Tests de unidad en Rails, ¿qué testear?
4 Dic 06
El otro día lanzaba una pregunta al aire que nadie ha contestado, así que me contesto yo mismo y amplio la reflexión, a ver si alguien se anima a participar en el debate.
Mi pregunta era algo así como: cuando realizáis un test de unidad en Rails, ¿qué testeais? Pregunta justificada, tanto en cuanto el testing en general y en Rails en particular no es una ciencia exacta: nunca sabes cuánto testear, qué testear y si has hecho los suficientes tests.
Cuando Rabble estuvo en La Gran Corporación hablando sobre Testing en Rails alguien le preguntó cómo organizaba sus tests de unidad. Y si no recuerdo mal ni entendí mal (aunque por aquel entonces estaba yo aún un poco verde con el tema del testing) él contestó algo así como:
un test por cada validación realizada en el modelo
Pero claro, tú puedes testear para cada validación los valores que son válidos y aquellos que no lo son.
Sin embargo un test de unidad es algo más, pues se supone que al ser un test del modelo deberíamos también comprobar que las operaciones CRUD (creación, lectura, modificación y borrado también se llevan a cabo). Por tanto, cobra bastante sentido un test tal que así:
def test_crud
m = MyClass.new
m.att1 = value1
m.att2 = value2
...
m.attN = valueN
assert m.save
assert m.update_attribute(:attI, valueI)
assert m.destroy
endY por otro lado, cuando comienzas a escribir tests antes incluso de haber escrito el código de tu aplicación te das cuenta que tienes que escribir las fixtures a mano, lo cuál parece que sea lo normal, ya que existe una tarea de Rails que carga las fixtures en la base de datos de desarrollo.
Una vez has escrito dos, tres, cinco o veinte fixtures resulta bastante útil validarlas.
Esto se puede hacer también de forma bastante fácil con un simple test de unidad, que podéis incluir para clase testeada:
def test_fixtures
MyClass.find(:all).each do |p|
assert p.valid?
end
endAdemás, aumentas tus estadísticas (rake stats) en tantos asserts como fixturas de la clase tengas.
En resumen, que para mi un test de unidad debe de tener, como mínimo:
- un test por cada validación, tanto positivo como negativo
- un test de las operaciones CRUD
- un test de las fixtures
Dejo aquí un fichero con los tests de unidad de una clase Project perteneciente a un proyecto que tengo a medias con Ale (aunque él no lo sabe) en el que se ve todo lo que he ido explicando en el post y no se ha entendido.
¿Qué pensáis? ¿Demasiado exagerado o mejor cuanto más estricto y más encorsetado esté el modelo?
5 comentarios