Diferencia entre revisiones de «ObjectMother»
(→Ver también) |
(→Ver también) |
||
| Línea 28: | Línea 28: | ||
==Ver también== | ==Ver también== | ||
| + | * [[Test Driven Development]] | ||
* [[TestDataBuilder]] | * [[TestDataBuilder]] | ||
* [[CreationMethod]] | * [[CreationMethod]] | ||
Revisión del 19:14 17 feb 2009
Cuando se crean tests para probar una clase, por lo general, es necesario instanciar una serie de objetos que funcionarán de ejemplo al ejercitar el SUT (System Under Test). Estos objetos, que suelen ser entidades, ValueObjects o DTOs, son inicializados con valores y combinados entre sí para producir un set de objetos de ejemplo en un estado consistente.
El problema en los tests es que el código para instanciar y preparar los objetos de muestra comienza a repetirse una y otra vez con sólo alguna variación a medida que crece el número de tests.
La primer reacción frente a esto es extraer la creación de estos objetos a CreationMethods dentro de la misma clase. Pero cuando comienzan a utilizarse desde diferentes clases es necesario hacer su acceso público para poder reutilizarlos.
Esto comienza a tener los síntomas de MysteryGuest y TestDependency. Las clases de test se vuelven frágiles y comienzan a perder claridad.
Para ordenar la creación de objetos de muestra se agrupan bajo una misma clase ObjectMother. Se puede tener un ObjectMother por proyecto o varios, esto depende únicamente del tamaño del proyecto, aunque en la práctica, el ObjectMother crece tan rápidamente que conviene plantearlo desde un inicio como varias clases.
Es importante mantener algún tipo de convención respecto de la nomenclatura y ubicación de los ObjectMothers y el nombre de los métodos de creación para ayudar a expresar intención en el código de los tests.
Las atribuciones que se le dan al ObjectMother es la de administrar el ciclo de vida completo de los objetos creados:
- crear
- configurar
- alterar
- limpiar
Una desventaja de los ObjectMothers con CreationMethods es la dificultad en expresar las diferentes variaciones de los objetos de muestra. Por ejemplo:
- crearFactura()
- crearFacturaVacia()
- crearFacturaConClienteInexistente()
- crearFacturaConClienteRegionSur()
- crearFacturaConClienteCalidadARegionSur()
Finalmente comienza a existir un método de creación para cada vez que se necesita un ejemplo en un test y es difícil expresar en el nombre del método cuál es la variación de la muestra. Una solución a esto es utilizar TestDataBuilders.
