Karteikarten
TDD-RESUMEN
Karten in diesem Stapel (15)
- 1Desarrollo Dirigido por Test 2. (TDD) Técnica de diseño e implementación de software incluida dentro de la metodología XPSe centra en tres pilares fundamentales:
* La implementación de las funciones justas que el cliente necesita y no más.
* La minimización del número de defectos que llegan al software en fase de producción.
* La producción de software modular, altamente re utilizable y preparado para el cambio. - 2TDD es la respuesta a las grandes preguntas de: *¿Cómo lo hago? *¿Por dónde empiezo? *¿Cómo sé qué es lo que hay que implementar y lo que no? *¿Cómo escribir un código que se pueda modificar sin romper funcionalidad existente?RAZONES que da Kent junto con otras destacadas figuras de la industria:
* La calidad del software aumenta (y veremos por qué).
* Conseguimos código altamente re utilizable.
* El trabajo en equipo se hace más fácil, une a las personas.
* Nos permite confiar en nuestros compañeros aunque tengan menos experiencia.
* Multiplica la comunicación entre los miembros del equipo.
* Las personas encargadas de la garantía de calidad adquieren un rol más inteligente e interesante.
* Incrementa la productividad.
* Nos hace descubrir y afrontar más casos de uso en tiempo de diseño - 3El algoritmo TDD Tiene 3 pasos: * Escribir la especificación del requisito (el ejemplo, el test). * Implementar el código según dicho ejemplo. * Refactorizar para eliminar duplicidad y hacer mejoras.- Escribir la especificación primero
1- Tener claro el requisito
2- Expresarlo en forma de código
( Por eso, un test no es inicialmente un test sino un ejemplo o especificación ) - 4- Implementar el código que hace funcionar el ejemplo Teniendo el ejemplo escrito, codificamos lo mínimo necesario para que se cumpla, para que el test pase- Refactorizar
Es modificar el diseño sin alterar su comportamiento. A ser posible, sin alterar su API pública. (* Refactorizar no significa reescribir el código; reescribir es más general que refactorizar).
Fases del ciclo:
1- Rojo
2- Verde
3- Refactorizar - 5¿Y TDD sirve para proyectos grandes?Un proyecto grande no es sino la agrupación de pequeños subproyectos y es ahora cuando toca aplicar aquello de “divide y vencerás”. El tamaño del proyecto no guarda relación con la aplicabilidad de TDD
- 63. Desarrollo Dirigido por Test de Aceptación (ATDD) Es igualmente TDD pero a un nivel diferente. Los test de aceptación o de cliente son el criterio escrito de que el software cumple los requisitos de negocio que el cliente demanda. Son ejemplos escritos por los dueños de producto.Las Historias De Usuario
* El título de la historia se corresponde con el del caso de uso tradicional. Sin embargo, la historia no pretende definir el requisito.
* cada historia de usuario contiene una lista de ejemplos que cuentan lo que el cliente quiere, con total claridad y ninguna ambigüedad.
* Están escritas con el vocabulario del negocio del cliente, no con vocabulario técnico.
* Las preguntas surgidas de una historia de usuario pueden incluso dar lugar a otras historias que pasan a engrosar el backlog o lista de requisitos - 7Que y no Como Aprovechamos los frameworks tipo Concordion para desarrollar nuestra habilidad de preguntar al cliente qué quiere y no cómo lo quiere. Evitamos a toda costa ejemplos que se meten en el cómo hacer, más allá del qué hacer¿Está hecho o no?
Se puede comprobar muy rápido si el programa está cumpliendo los objetivos o no. Conocemos en qué punto estamos y cómo vamos progresando - 84. Tipos de test y su importancia * Aspecto visibilidad (si se sabe lo que hay dentro del SUT o no) * Aspecto potestad (a quién pertenece el test) * Un mismo test puede ser de varios tipos, incluso mirándolo desde la perspectiva de un solo equipo de desarrollo ya que su clasificación dependerá del aspecto a considerar.Terminología en la comunidad TDD
*Desde el aspecto potestad,es decir,mirando los test según a quién le pertenecen.
* Lo ideal es que el analista de negocio ayude al cliente a escribir los test para asegurarse de que las afirmaciones están totalmente libres de ambigüedad.
* Los test que pertenecen al Dueño del Producto se llaman test de cliente o de aceptación. - 9Test de AceptaciónEs un test que permite comprobar que el software cumple con un requisito de negocio. Como se vio en el capítulo de ATDD, un test de aceptación es un ejemplo escrito con el lenguaje del cliente pero que puede ser ejecutado por la máquina.
- 10Test Funcionales* Es un subconjunto de los test de aceptación. Es decir, comprueban alguna funcionalidad con valor de negocio.
* Un test funcional es un test de aceptación pero, uno de aceptación, no tiene por qué ser funcional.
- 11Test de Sistema* Integra varias partes del sistema.
* un test del sistema se ejercita tal cual lo haría el usuario humano, usando los mismos puntos de entrada y llegando a modificar la base de datos o lo que haya en el otro extremo.
*
- 12¿Cómo se puede automatizar el uso de la interfaz de usuario y validar que funciona? * Si la interfaz de usuario es web, el plugin Selenium para el navegador Mozilla Firefox nos permite registrar nuestra actividad en una página web como si estuviéramos grabando un vídeo para luego reproducir la secuencia automáticamente y detectar cambios en la respuesta del sitio web.Los test de sistema son muy frágiles en el sentido de que cualquier cambio en cualquiera de las partes que componen el sistema, puede romperlos. No es recomendable escribir un gran número de ellos por su fragilidad.
- 13Test UnitariosEs un paso que andamos en el camino de la implementación del software. Todo test unitario debe ser:
* Atómico ( significa que el test prueba la mínima cantidad de funcionalidad posible)
* Independiente
* Inocuo
* Rápido
Si no cumple estas premisas entonces no es un test unitario,aunque se ejecute con una herramienta tipo xUnit.
- 14F.I.R.S.TFast, Independent, Repeatable, Small y Transparent. Repetible encaja con inocuo, pequeño caza con atómico y transparente quiere decir que el test debe comunicar perfectamente la intención del autor.
- 15Test de Integración* Se pueden ver como tests de sistema pequeños.
* Integración significa que ayuda a unir distintas partes del sistema. Un test de integración puede escribir y leer de base de datos para comprobar que, efectivamente, la lógica de negocio entiende datos reales.
* Aunque los test de integración pueden saltarse las reglas, por motivos de productividad es conveniente que traten de ser inocuos y rápidos.
Informationen
- Beschreibung
- Resumen de los que son los TDD
- Erstellt von
- Aaron Chaves
- Aufrufe
- 2
- Bewertung