Con la ayuda del libro de @CarlosBle “Diseño ágil con TDD”, hemos creado este esquema con todos los conceptos, artefactos y algoritmos referentes a la programación dirigida por test.
1.- NUEVO TEST
Cuando creamos un nuevo test debemos tener en cuenta que debe ser:
FIRST
- Rápido: No debe tardar mucho, sino, en cada ejecución de test perderemos mucho tiempo y debemos tener en cuenta que la ejecución del test la hacemos dos veces mínimo antes de finalizar el test.
- Independiente: No debe depender de otros test.
- Repetible: Se puede repetir la veces que queramos sin que el resultado cambie.
- Pequeño: No debe ser excesivo en líneas de código.
Regla de la AAA
Arrange: Preparar las expectativas.
Actuar: Llamar a la funcionalidad que queremos probar.
Assert: Comprobar que el resultado coincide con la expectativa.
- Transparente: No altera el sistema. Cuando nuestros test dependan de sistemas externos tendremos que ayudarnos de objetos que se hagan pasar por ellos. Estos objetos pueden ser:
- Mocks: Objetos que imitan el comportamiento de su original.
- Stubs: Objetos que devuelven los mismos resultados que su original.
- Fakes: Objetos que imitan el comportamiento, pero no tienen algún atajo en su comportamiento para devolver el resultado.
- Dummies: Se pasa como argumento pero no se usa.
2.- CODIGO MÍNIMO VIABLE
Principios SOLID
- Un objeto solo debe tener una única responsabilidad.
- Una entidad debe estar abierta a implementación pero cerrada a la modificación.
- Una clase B debe cumplir todas las especificaciones de A siendo B una clase heredada de A.
- Una Interface no debe tener más métodos de los que necesita.
- Cada Interface tiene que cumplir el principio de única responsabilidad.
- Nunca debemos pasar de las especificaciones a la plataforma tecnológica en un solo paso (Inyección de dependencia).
3.- REFACTORIZACIÓN
BAD SMELLS
- Código duplicado: No debe existir código duplicado en ningún caso. Ni en la propia clase ni entre clases.
- Métodos Largos: Lo métodos no deben tener mas de 40 líneas se deben leer enteros sin hacer scroll.
- Clase Grande: Al igual que los métodos, las clases no deben ser demasiado largas. (150 líneas aprox.)
- Muchos Parámetros: Los métodos no deben tener muchos parámetros. (5 max), sino extraer a una clase.
- Envidia de funcionalidades: Si desde el método de una clase realizamos muchas llamadas a propiedad y métodos de otra clase, debemos replantearnos si ese método debe ir en esa clase o la utilización de patrones.
- Switch: El uso excesivo de estructuras switch o similares, se hace muy pesado y alarga el código, se puede reemplazar por patrones.
- Obsesión con datos primitivos: Sustituir el uso abusivo de datos primitivos, se pueden sustituir por enum o clases.
- Alinear/Extraer Clases: Si dos clases tienen la misma funcionalidad se pueden unir, hacer que una herede de otra o definir una clase abstracta que as relacione o una interface.
Este es el esquema que hemos decido seguir para aplicar TDD en nuestro desarrollo esperamos que os sea útil.
Hola Kiko!
Gracias por compartir este conocimiento, estoy seguro de que será realmente útil para mucha gente. Sí creo que ayudaría un poco más una breve explicación de los porqués de cada punto (por qué no código duplicado, por qué no métodos largos, por qué máximo 5 parámetros, etc.).
Un abrazo amigo!
Gracias por el comentario Juanma,
Esa explicación tenemos pensada hacerla en próximos post, que a medida que vayamos teniendo tiempo iremos publicando.
Excelente resumen en un solo vistazo, enhorabuena por ello.
Por puntualizar un poquito, la definicion de stub no es muy buena. No devuelve lo mismo que el objeto original sino lo que uno quiere que devuelva. Es un doble que responde con lo que se le programe, y ademas no tiene memoria sobre lo que ha ocurrido.
Seguid asi
Excelente resumen, pero… ¿5 parámetros para un método? A mí me parece excesivo.
Según el Clean Code, el número ideal es 0. 1 es asumible. 2, si no queda más remedio. 3 es para pensárselo otra vez.
Sinceramente, si te hacen falta 5 parámetros en un método, es para plantearte crear una clase sólo para pasar los parámetros a ese método. Yo, personalmente, admito hasta 3 parámetros.
Pingback: COMO COMENTAR CÓDIGO (CCC) | Aprendiendo TDD