Hola, soy Weiki y bienvenido a ape java.
¿Has oído hablar o has oído hablar de TDD? ¿Sabes qué es TDD? ¿Sabes cómo funciona? Hoy hablaremos de TDD.
Una vez leí una publicación en el blog personal de Martin Fowler (Martin Fowler) sobre la discusión de Is TDD Dead por Kent Beck, David y Martin Fowler y David
's TDD is dead. Larga vida a las pruebas .
Algunas introducciones de varios autores.
Martin Fowler(马丁·福勒)，出生于英格兰，后移居美国，像微服务，
DSL(领域设计语)，统一建模语言等思想都是出自他，大家有兴趣可以看看他的个人博客：
https://martinfowler.com/，上面有很多优秀的博文，思想值得我们拜读。
Kent Beck：美国人，JUnit单元测试框架作者之一，敏捷开发的开创者之一
David Heinemeier Hansson：丹麦人，Ruby语言创始人
¿Qué es TDD?
TDD proviene de Extreme Programming. Baidu Encyclopedia lo explica de la siguiente manera:
TDD es la abreviatura en inglés de Test-Driven Development. Es una práctica y tecnología central en el desarrollo ágil, y también es una metodología de diseño. El principio de TDD es escribir código de caso de prueba de unidad antes de desarrollar código funcional, y el código de prueba determina qué código de producto debe escribirse. Aunque TDD es la práctica central de los métodos ágiles
, no solo es aplicable a XP (programación extrema), sino que también es aplicable a otros métodos y procesos de desarrollo.
Esta explicación es relativamente unilateral. De hecho, TDD consta de dos partes: ATDD y UTDD.
ATDD
Desarrollo impulsado por pruebas de aceptación, desarrollo impulsado por la aceptación. Por ejemplo, QA (Garantía de calidad) escribirá casos de prueba y luego los revisará con PM (Gerente de producto) y RD (Desarrollo técnico). Este proceso puede ayudar a RD a comprender mejor los requisitos comerciales y las condiciones de aceptación, para que puedan escribirse más tarde con metas de aceptación hasta que pasen los casos de prueba de aceptación.
Hay muchas formas de realizar pruebas, como BDD (pruebas funcionales), pruebas de caja blanca, pruebas de integración, etc. Se utilizan diferentes métodos de prueba de acuerdo con diferentes escenarios para lograr la aceptación.
UTDD
Desarrollo controlado por pruebas unitarias, desarrollo controlado por pruebas unitarias, RD primero escribe casos de prueba unitaria y luego escribe el código de implementación hasta que pasa la prueba unitaria.
Acerca de ATDD y UTDD En el sitio web oficial de Thoughtworks, hay una imagen abstracta, puede consultar lo siguiente:
El siguiente es un diagrama de xmind
¿Cómo hacer bien TDD?
Antes de analizar la solución TDD, resolvamos un problema: el desarrollo basado en pruebas, ¿dónde comienza todo el proceso?
respuesta: prueba
Entonces, ¿dónde comienzan las pruebas?
Respuesta: demanda.
¿Cuál es el propósito de las pruebas si no hay requisitos? Por lo tanto, los requisitos son la fuente de las pruebas; ante requisitos enormes, ¿cómo probar? El método consiste en descomponer los requisitos en pequeñas tareas que se pueden probar una por una.
Entonces, el desarrollo basado en pruebas comienza con la descomposición de tareas.
Las siguientes son dos imágenes del sitio web oficial de Thoughtworks para expresar todo el proceso de TDD.
Implementación de TDD - diagrama esquemático de pasos:
Diagrama de implementación-colaboración de TDD:
Personalmente, creo que TDD se puede implementar tanto desde una perspectiva estratégica como táctica, al igual que DDD.
ángulo estratégico
Desde una perspectiva estratégica, es más una metodología a nivel ideológico, que nos puede guiar para implementar TDD de una mejor manera.
A continuación se describe el ciclo de vida completo de un requisito desde la propuesta hasta el lanzamiento:
Cuando se recibe una nueva solicitud,
- En primer lugar, PM tendrá una revisión de la demanda, que explicará los antecedentes comerciales, explicará los problemas a resolver y qué objetivos alcanzar;
- Luego, RD llevará a cabo la descomposición comercial, la comunicación ascendente y descendente de acuerdo con la revisión de la demanda, y luego realizará un diseño técnico detallado y seminarios técnicos;
- Luego, QA escribirá casos de prueba y revisiones de casos de uso en combinación con la revisión de requisitos y las conferencias técnicas de RD, y verificará los objetivos de aceptación y el tiempo de lanzamiento de varias partes;
- Luego, RD hará el diseño de arquitectura, diseño de código, escritura de código y prueba de código, QA hará el trabajo relacionado con las pruebas, como: diseño de casos de uso, scripts de prueba, etc.;
- Finalmente, el desarrollo de RD se completa y prueba, QA realiza pruebas hasta que se aprueba y PM realiza la aceptación final hasta que el código se pone en línea;
Todo el proceso encarna el pensamiento estratégico de TDD, y todo el ciclo de vida proporciona ciertas especificaciones de proceso para ATDD y UTDD.
ángulo táctico
Desde un punto de vista táctico, se explica más desde un nivel técnico. Desde un punto de vista estratégico, hemos propuesto una metodología de cómo implementar cada paso del proceso, este es el punto de vista táctico.
- Por ejemplo: Descomposición de requisitos, según qué dimensión se debe descomponer, si se debe dividir según dominio o proceso, y en qué tamaño se debe descomponer una tarea es razonable.
- Por ejemplo: diseño de arquitectura, qué idea de arquitectura usar, si es una arquitectura hexagonal o una arquitectura de cebolla.
- Por ejemplo: diseño de código, qué patrón de diseño debe usarse, patrón de adaptador o patrón de fábrica.
- Por ejemplo: escritura de código, qué estructuras de datos y algoritmos deben usarse y cómo hacer que el código sea más reutilizable.
- Por ejemplo: pruebas, cómo diseñar casos de prueba, qué marco de pruebas elegir, cómo automatizar las pruebas
La implementación de TDD tiene una trilogía clásica: rojo-verde-refactorización. Tanto ATDD como UTDD se pueden implementar de acuerdo con este proceso de tres pasos. El diagrama esquemático de la trilogía es el siguiente:
En muchos marcos de pruebas, el rojo significa que la prueba no ha pasado y el verde significa que la prueba ha pasado. Convertir el rojo en verde requiere una refactorización constante.
Por lo tanto, podemos entender: para escribir pruebas, primero nos "impulsamos" a comprender el negocio, descomponemos los requisitos en tareas individuales y luego nos "impulsamos" a dar un diseño comprobable, y en la etapa específica de escritura de código, y "impulsará" el código que seguimos mejorando y escribiendo. Juntando estas cosas, realmente estamos "impulsando" el desarrollo con pruebas.
Con la orientación de la estrategia y la táctica, lo más importante es cultivar la capacidad de apoyar estas estrategias. Idealmente, la implementación de TDD requiere la capacidad de:
- Prueba la capacidad de avanzar (desplazamiento a la izquierda)
- Análisis de requisitos comerciales y técnicos y capacidades de división de tareas
- Capacidad de diseño de casos de prueba
- Desarrollo de pruebas automatizado
- Refactorización de código de capacidad
- Capacidad de mejora continua
malentendido
Mito 1
En la comprensión de muchos programadores, UTDD es TDD y TDD es UTDD, por lo que ignoramos el ATDD orientado a los negocios o a las pruebas. Por lo tanto, el alcance de TDD es prácticamente reducido. A continuación se proporciona una tabla de evaluación comparativa para ATDD y UTDD
mito 2
TDD es para escribir la prueba antes de escribir el código, la razón se ha analizado en la sección de tácticas de TDD.
¿TDD está realmente "muerto"?
Como en el comienzo del artículo ¿Está muerto TDD?
La respuesta es: NO, y TDD sigue funcionando bien en la actualidad. Muchas empresas lo han estado practicando, pero no han enfatizado específicamente que pertenece a la categoría de TDD. Al mismo tiempo, TDD no es una bala de plata, y es imposible resolver cualquier problema en el trabajo real. Lo que tenemos que hacer es aprender, comparar y resumir continuamente, e implementarlo de acuerdo con las necesidades reales del negocio. Después de todo, el mejor es el correcto.
¿Los programadores realmente necesitan dominar TDD?
Es necesario, no tenemos que enfatizar el concepto de TDD, pero TDD es para garantizar la calidad del código de los programadores, y la calidad del código es el resultado final de los programadores. UTDD puede ayudar a los programadores a escribir pruebas unitarias mejor y más sistemáticamente
; ATDD puede permitir a los programadores comprender mejor el negocio y garantizar la solidez del código para el negocio a través de una comprensión más profunda del negocio.
referencias
Sitio web oficial de Thoughtworks TDD
Libro: Java Test Driven Development (Escrito por Viktor Farcic, traducido por Yuan Guozhong)
Desarrollo ágil de software (por Robert C. Martin)