Hispanopedia WikiEl desarrollo guiado por pruebas ( TDD , por sus siglas en inglés) es una forma de escribir código que consiste en escribir un caso de prueba unitaria automatizado que falle, luego escribir el código justo y necesario para que la prueba pase, después refactorizar tanto el código de prueba como el código de producción, y luego repetir el proceso con otro caso de prueba nuevo.
Los enfoques alternativos para escribir pruebas automatizadas consisten en escribir todo el código de producción antes de comenzar con el código de prueba, o bien escribir todo el código de prueba antes de comenzar con el código de producción. Con TDD, ambos se escriben simultáneamente, lo que reduce el tiempo necesario para la depuración. [ 1 ]
TDD está relacionado con los conceptos de programación basada en pruebas de la programación extrema , que comenzó en 1999, [ 2 ] pero más recientemente ha generado un interés más general por derecho propio. [ 3 ]
Los programadores también aplican el concepto para mejorar y depurar código heredado desarrollado con técnicas más antiguas. [ 4 ]
Historia
El ingeniero de software Kent Beck , a quien se le atribuye haber desarrollado o "redescubierto" [ 5 ] la técnica, afirmó en 2003 que TDD fomenta diseños simples e inspira confianza. [ 6 ]
La descripción original de TDD se encontraba en un antiguo libro de programación. Decía que se tomaba la cinta de entrada, se escribía manualmente la cinta de salida esperada y luego se programaba hasta que la cinta de salida real coincidiera con la esperada. Después de escribir el primer framework xUnit en Smalltalk, recordé haber leído esto y lo puse en práctica. Ese fue el origen de TDD para mí. Cuando les explico TDD a programadores más veteranos, a menudo escucho: «Claro. ¿De qué otra forma se podría programar?». Por eso, me refiero a mi papel como el de «redescubrir» TDD.
Ciclo de codificación
Los pasos de TDD varían ligeramente según el autor en cuanto a número y descripción, pero generalmente son los siguientes. Estos se basan en el libro Desarrollo guiado por pruebas mediante ejemplos [ 6 ] y en el artículo de Kent Beck sobre TDD [ 8 ] .
- 1. Enumera los escenarios para la nueva función.
- Enumera las variantes esperadas en el nuevo comportamiento. "Está el caso básico, ¿y si el servicio se agota?, ¿y si la clave aún no está en la base de datos?..." El desarrollador puede descubrir estas especificaciones preguntando sobre casos de uso e historias de usuario . Una ventaja clave del TDD es que permite al desarrollador centrarse en los requisitos antes de escribir el código. Esto contrasta con la práctica habitual, donde las pruebas unitarias se escriben después de escribir el código.
- 2. Escribe una prueba para un elemento de la lista.
- Escribe una prueba automatizada que se ejecute correctamente si se cumple la condición de la variante en el nuevo comportamiento.
- 3. Ejecuta todas las pruebas. La nueva prueba debería fallar , por las razones esperadas .
- Esto demuestra que realmente se necesita código nuevo para la funcionalidad deseada. Valida que el entorno de pruebas funciona correctamente. Descarta la posibilidad de que la nueva prueba sea defectuosa y siempre pase.
- 4. Escribe el código más sencillo que pase la nueva prueba.
- Se acepta código poco elegante y codificación rígida . El código se perfeccionará en el paso 6. No se debe añadir código que exceda la funcionalidad probada.
- 5. Todas las pruebas deberían ser superadas ahora.
- Si alguna prueba falla, corríjala con cambios mínimos hasta que todas pasen.
- 6. Refactorizar según sea necesario, asegurándose de que todas las pruebas sigan pasando.
- El código se refactoriza para mejorar su legibilidad y mantenibilidad. En particular, se deben eliminar los datos de prueba codificados directamente en el código de producción. Ejecutar el conjunto de pruebas después de cada refactorización garantiza que no se rompa ninguna funcionalidad existente. Ejemplos de refactorización:
- mover el código al lugar donde lógicamente pertenece
- eliminando código duplicado
- Haciéndose un nombre autodocumentado
- dividir los métodos en partes más pequeñas
- reorganización de las jerarquías de herencia
- Repetir
- Repita el proceso, comenzando en el paso 2, con cada prueba de la lista hasta que todas las pruebas estén implementadas y superadas.
Cada prueba debe ser pequeña y las confirmaciones deben realizarse con frecuencia. Si el código nuevo falla en algunas pruebas, el programador puede deshacer o revertir los cambios en lugar de depurar excesivamente.
Cuando se utilizan bibliotecas externas , es importante no escribir pruebas tan pequeñas que solo prueben la biblioteca en sí misma, [ 3 ] a menos que haya alguna razón para creer que la biblioteca tiene errores o no es lo suficientemente rica en características como para satisfacer todas las necesidades del software en desarrollo.
Trabajo basado en pruebas
TDD se ha adoptado fuera del desarrollo de software, tanto en equipos de producto como de servicio, como trabajo guiado por pruebas . [ 9 ] Para que las pruebas sean exitosas, deben practicarse a nivel micro y macro. Cada método en una clase, cada valor de datos de entrada, mensaje de registro y código de error, entre otros puntos de datos, deben probarse. [ 10 ] De manera similar a TDD, los equipos que no son de software desarrollan controles de calidad (CC) (generalmente pruebas manuales en lugar de pruebas automatizadas) para cada aspecto del trabajo antes de comenzar. Estos controles de CC se utilizan luego para informar el diseño y validar los resultados asociados. Los seis pasos de la secuencia TDD se aplican con pequeños cambios semánticos:
- "Agregar una verificación" reemplaza a "Agregar una prueba".
- "Ejecutar todas las comprobaciones" reemplaza a "Ejecutar todas las pruebas".
- "Haz el trabajo" reemplaza a "Escribe algo de código".
- "Ejecutar todas las comprobaciones" reemplaza a "Ejecutar pruebas".
- "Limpiar el trabajo" reemplaza a "Refactorizar código".
- "Repetir"
Estilo de desarrollo
Existen varios aspectos del uso del desarrollo guiado por pruebas, por ejemplo, los principios de "mantenlo simple, estúpido" ( KISS ) y " no lo vas a necesitar " (YAGNI). Al centrarse en escribir solo el código necesario para pasar las pruebas, los diseños suelen ser más limpios y claros que los que se logran con otros métodos. [ 6 ] En Desarrollo guiado por pruebas mediante ejemplos , Kent Beck también sugiere el principio " fingir hasta lograrlo ".
Para lograr un concepto de diseño avanzado, como un patrón de diseño , se escriben pruebas que generan dicho diseño. El código puede ser más simple que el patrón original, pero aun así debe superar todas las pruebas requeridas. Esto puede resultar desconcertante al principio, pero permite al desarrollador centrarse únicamente en lo importante.
Escribir primero las pruebas: Las pruebas deben escribirse antes que la funcionalidad que se va a probar. Se ha afirmado que esto tiene muchos beneficios. Ayuda a garantizar que la aplicación esté escrita para ser testeable, ya que los desarrolladores deben considerar cómo probar la aplicación desde el principio en lugar de agregarlo posteriormente. También garantiza que se escriban pruebas para cada funcionalidad. Además, escribir primero las pruebas conduce a una comprensión más profunda y temprana de los requisitos del producto, garantiza la efectividad del código de prueba y mantiene un enfoque continuo en la calidad del software . [ 11 ]
Al escribir código centrado en las funcionalidades, los desarrolladores y las organizaciones tienden a presionar al desarrollador para que pase a la siguiente funcionalidad, incluso descuidando por completo las pruebas. La primera prueba TDD podría ni siquiera compilar inicialmente, ya que las clases y los métodos que requiere podrían no existir todavía. Sin embargo, esa primera prueba funciona como el inicio de una especificación ejecutable. [ 12 ]
Cada caso de prueba falla inicialmente: esto garantiza que la prueba funcione correctamente y pueda detectar errores. Una vez demostrado esto, se puede implementar la funcionalidad subyacente. Esto ha dado lugar al "mantra del desarrollo guiado por pruebas", que es "rojo/verde/refactorizar", donde rojo significa fallo y verde significa éxito . El desarrollo guiado por pruebas repite constantemente los pasos de añadir casos de prueba que fallan, superarlos y refactorizar. Recibir los resultados esperados en cada etapa refuerza el modelo mental del código por parte del desarrollador, aumenta la confianza y mejora la productividad.
Visibilidad del código
En el desarrollo guiado por pruebas, escribir pruebas antes de la implementación plantea interrogantes sobre si probar métodos privados o solo a través de interfaces públicas . Esta elección afecta el diseño tanto del código de prueba como del código de producción.
Aislamiento de prueba
El desarrollo guiado por pruebas (TDD) se basa principalmente en pruebas unitarias para lograr un ciclo rápido de refactorización (rojo-verde). Estas pruebas se ejecutan rápidamente al evitar límites de proceso, conexiones de red o dependencias externas. Si bien quienes practican TDD también escriben pruebas de integración para verificar las interacciones entre componentes, estas pruebas, más lentas, se mantienen separadas de las ejecuciones más frecuentes de las pruebas unitarias. Probar varios módulos integrados simultáneamente también dificulta la identificación del origen de los fallos.
Cuando el código en desarrollo depende de dependencias externas, TDD fomenta el uso de objetos de prueba para mantener pruebas unitarias rápidas y aisladas. [ 13 ] El enfoque típico implica el uso de interfaces para separar las dependencias externas y la implementación de objetos de prueba para fines de prueba.
Dado que los objetos simulados no demuestran la conexión con componentes externos reales, quienes practican el desarrollo guiado por pruebas (TDD) complementan las pruebas unitarias con pruebas de integración en los niveles adecuados. Para lograr una ejecución más rápida y confiable, se maximizan las pruebas a nivel unitario, minimizando al mismo tiempo las pruebas más lentas en niveles superiores.
Mantén la unidad pequeña
En TDD, una unidad se define comúnmente como una clase o un grupo de funciones relacionadas, a menudo llamado módulo. Se afirma que mantener las unidades relativamente pequeñas proporciona beneficios cruciales, entre ellos:
- Menor esfuerzo de depuración: cuando se detectan fallos en las pruebas, disponer de unidades más pequeñas facilita la localización de los errores.
- Pruebas autodocumentadas: los casos de prueba pequeños son más fáciles de leer y comprender. [ 11 ]
Las prácticas avanzadas de desarrollo guiado por pruebas pueden conducir al desarrollo guiado por pruebas de aceptación (ATDD) y a la especificación por ejemplo, donde los criterios especificados por el cliente se automatizan en pruebas de aceptación, que luego impulsan el proceso tradicional de desarrollo guiado por pruebas unitarias (UTDD). [ 14 ] Este proceso garantiza que el cliente tenga un mecanismo automatizado para decidir si el software cumple con sus requisitos. Con ATDD, el equipo de desarrollo ahora tiene un objetivo específico que cumplir: las pruebas de aceptación, lo que los mantiene continuamente enfocados en lo que el cliente realmente quiere de cada historia de usuario.
Mejores prácticas
Estructura de prueba
Un diseño eficaz de un caso de prueba garantiza que se completen todas las acciones requeridas, mejora su legibilidad y agiliza su ejecución. Una estructura coherente facilita la creación de un caso de prueba autodocumentado. Una estructura común para los casos de prueba incluye: (1) configuración, (2) ejecución, (3) validación y (4) limpieza.
- Configuración: Coloque la unidad bajo prueba (UUT) o el sistema de prueba general en el estado necesario para ejecutar la prueba.
- Ejecución: Activar/controlar la UUT para que realice el comportamiento deseado y capturar toda la salida, como los valores de retorno y los parámetros de salida. Este paso suele ser muy sencillo.
- Validación: Asegúrese de que los resultados de la prueba sean correctos. Estos resultados pueden incluir salidas explícitas capturadas durante la ejecución o cambios de estado en la unidad bajo prueba (UUT).
- Limpieza: Restaure la UUT o el sistema de prueba general al estado previo a la prueba. Esta restauración permite que se ejecute otra prueba inmediatamente después de esta. En algunos casos, para preservar la información para un posible análisis de fallos de la prueba, la limpieza debe comenzar justo antes de la ejecución de la configuración de la prueba. [ 11 ]
mejores prácticas individuales
Algunas buenas prácticas que una persona podría seguir serían separar la lógica común de configuración y desmontaje en servicios de soporte de pruebas utilizados por los casos de prueba apropiados, mantener cada oráculo de prueba enfocado solo en los resultados necesarios para validar su prueba, y diseñar pruebas relacionadas con el tiempo para permitir tolerancia a la ejecución en sistemas operativos que no son en tiempo real. La práctica común de permitir un margen del 5-10 por ciento para la ejecución tardía reduce la cantidad potencial de falsos negativos en la ejecución de pruebas. También se sugiere tratar el código de prueba con el mismo respeto que el código de producción. El código de prueba debe funcionar correctamente tanto para casos positivos como negativos, ser duradero y ser legible y mantenible. Los equipos pueden reunirse y revisar las pruebas y las prácticas de prueba para compartir técnicas efectivas y detectar malos hábitos. [ 15 ]
Prácticas que se deben evitar, o "antipatrones".
- Hacer que los casos de prueba dependan del estado del sistema manipulado a partir de casos de prueba ejecutados previamente (es decir, siempre se debe iniciar una prueba unitaria desde un estado conocido y preconfigurado).
- Dependencias entre casos de prueba. Un conjunto de pruebas donde los casos de prueba dependen unos de otros es frágil y complejo. No se debe dar por sentado el orden de ejecución. Una simple refactorización de los casos de prueba iniciales o de la estructura de la unidad bajo prueba provoca una espiral de impactos cada vez más generalizados en las pruebas asociadas.
- Pruebas interdependientes. Las pruebas interdependientes pueden provocar falsos negativos en cascada. Un fallo en una prueba inicial afecta a una prueba posterior, incluso si no existe ningún fallo real en la unidad bajo prueba, lo que aumenta el análisis de defectos y los esfuerzos de depuración.
- Pruebas de ejecución precisa, sincronización o rendimiento.
- Construir "oráculos omniscientes". Un oráculo que inspecciona más de lo necesario resulta más caro y frágil con el tiempo. Este error, muy común, es peligroso porque provoca una pérdida de tiempo sutil pero generalizada en todo el proyecto complejo. [ 15 ]
- Detalles de la implementación de las pruebas.
- Pruebas de ejecución lenta.
Comparación y delimitación
TDD y ATDD
El desarrollo guiado por pruebas (TDD) está relacionado con el desarrollo guiado por pruebas de aceptación (ATDD), pero es diferente. [ 16 ] TDD es principalmente una herramienta del desarrollador para ayudar a crear una unidad de código bien escrita (función, clase o módulo) que realice correctamente un conjunto de operaciones. ATDD es una herramienta de comunicación entre el cliente, el desarrollador y el probador para asegurar que los requisitos estén bien definidos. TDD requiere automatización de pruebas. ATDD no, aunque la automatización ayuda con las pruebas de regresión . Las pruebas utilizadas en TDD a menudo se pueden derivar de las pruebas de ATDD, ya que las unidades de código implementan alguna parte de un requisito. Las pruebas de ATDD deben ser legibles por el cliente. Las pruebas de TDD no necesitan serlo.
TDD y BDD
BDD ( desarrollo dirigido por el comportamiento ) combina prácticas de TDD y ATDD. [ 17 ] Incluye la práctica de escribir pruebas primero, pero se centra en pruebas que describen el comportamiento, en lugar de pruebas que prueban una unidad de implementación. Herramientas como JBehave , Cucumber , Mspec y Specflow proporcionan sintaxis que permiten a los propietarios del producto, desarrolladores e ingenieros de pruebas definir conjuntamente los comportamientos que luego se pueden traducir en pruebas automatizadas.
Software para TDD
Existen numerosos marcos de prueba y herramientas útiles en TDD.
Marcos de trabajo xUnit
Los desarrolladores pueden usar marcos de pruebas asistidas por computadora , comúnmente denominados colectivamente xUnit (derivados de SUnit, creado en 1998), para crear y ejecutar automáticamente los casos de prueba. Los marcos xUnit proporcionan capacidades de validación de pruebas tipo aserción e informes de resultados. Estas capacidades son fundamentales para la automatización, ya que trasladan la carga de la validación de la ejecución de una actividad de posprocesamiento independiente a una que se incluye en la ejecución de la prueba. El marco de ejecución proporcionado por estos marcos de prueba permite la ejecución automática de todos los casos de prueba del sistema o varios subconjuntos, junto con otras características. [ 18 ]
Resultados de TAP
Los marcos de prueba pueden aceptar la salida de las pruebas unitarias en el protocolo Test Anything, independiente del lenguaje, creado en 1987.
TDD para sistemas complejos
La aplicación de TDD en sistemas grandes requiere una arquitectura modular, componentes definidos con interfaces publicadas y una estratificación del sistema disciplinada que maximice la independencia de la plataforma. Estas prácticas probadas aumentan la capacidad de prueba y facilitan la aplicación de la automatización de la compilación y las pruebas. [ 11 ]
Diseño para la comprobabilidad
Los sistemas complejos requieren una arquitectura que cumpla con diversos requisitos. Un subconjunto clave de estos requisitos incluye el soporte para la realización de pruebas completas y efectivas del sistema. Un diseño modular eficaz genera componentes que comparten características esenciales para un desarrollo guiado por pruebas (TDD) efectivo.
- La alta cohesión garantiza que cada unidad proporcione un conjunto de capacidades relacionadas y facilita el mantenimiento de las pruebas de dichas capacidades.
- El bajo acoplamiento permite probar cada unidad de forma eficaz y aislada.
- Las interfaces publicadas restringen el acceso a los componentes y sirven como puntos de contacto para las pruebas, facilitando la creación de pruebas y garantizando la máxima fidelidad entre la configuración de la unidad de prueba y la de producción.
Una técnica clave para construir una arquitectura modular eficaz es el modelado de escenarios, donde se construye un conjunto de diagramas de secuencia, cada uno centrado en un único escenario de ejecución a nivel de sistema. El modelo de escenarios proporciona una excelente herramienta para crear la estrategia de interacciones entre componentes en respuesta a un estímulo específico. Cada uno de estos modelos de escenarios sirve como un conjunto completo de requisitos para los servicios o funciones que un componente debe proporcionar, y también dicta el orden en que estos componentes y servicios interactúan entre sí. El modelado de escenarios puede facilitar enormemente la construcción de pruebas TDD para un sistema complejo. [ 11 ]
Gestión de pruebas para equipos grandes
En un sistema más grande, el impacto de la mala calidad de los componentes se magnifica debido a la complejidad de las interacciones. Esta magnificación acelera aún más los beneficios del TDD en proyectos de mayor envergadura. Sin embargo, la complejidad del conjunto total de pruebas puede convertirse en un problema en sí misma, mermando las posibles ventajas. Aunque parezca sencillo, un paso inicial clave es reconocer que el código de prueba también es software importante y debe producirse y mantenerse con el mismo rigor que el código de producción.
Crear y gestionar la arquitectura del software de prueba dentro de un sistema complejo es tan importante como la arquitectura del producto principal. Los controladores de prueba interactúan con la UUT, los dobles de prueba y el marco de pruebas unitarias. [ 11 ]
Ventajas y desventajas
Los estudios empíricos sobre el desarrollo guiado por pruebas (TDD) han arrojado resultados mixtos. Las revisiones generalmente encuentran evidencia de que el TDD puede mejorar algunas medidas de calidad del software, pero su efecto en la productividad es menos consistente. Un metaanálisis de 27 estudios realizado en 2013 encontró un pequeño efecto positivo en la calidad externa y poco o ningún efecto general en la productividad, con mayores ganancias de calidad pero también mayores reducciones de productividad en los estudios industriales. [ 19 ] Una revisión sistemática de estudios publicados entre 1999 y 2014 realizada en 2016 encontró que la mayoría de los estudios reportaron mejoras en la calidad interna y externa del software, pero que los resultados de productividad variaron entre entornos académicos e industriales. [ 20 ]
Un análisis comparativo de estudios empíricos concluyó que el TDD puede reducir los defectos introducidos y generar código más mantenible, mientras que parte del código implementado puede ser más pequeño o menos complejo. [ 21 ] Sin embargo, un experimento industrial con desarrolladores profesionales encontró que el efecto del TDD dependía en gran medida de las características de la tarea y concluyó que se necesitaba más evidencia antes de determinar si el TDD era mejor o peor que el desarrollo incremental de pruebas al final en entornos industriales. [ 22 ] Un estudio posterior sobre las características del proceso TDD encontró que las mejoras en la calidad y la productividad estaban más asociadas con pasos de desarrollo pequeños y uniformes que con el orden de pruebas primero en sí mismo. [ 23 ]
Beneficios potenciales
TDD puede proporcionar retroalimentación rápida durante el desarrollo porque el desarrollador ejecuta repetidamente un conjunto creciente de pruebas automatizadas. Esto puede hacer que las regresiones sean más fáciles de detectar poco después de su introducción y puede respaldar la refactorización al proporcionar una red de seguridad para los cambios de comportamiento. [ 24 ] Debido a que las pruebas se escriben antes del código de producción correspondiente, el desarrollador debe considerar el comportamiento deseado y la interfaz del código antes de la implementación. Esto puede fomentar unidades de código más pequeñas, un acoplamiento más flexible e interfaces más claras, especialmente cuando las pruebas se escriben sobre el comportamiento público en lugar de los detalles de implementación. [ 24 ] [ 21 ]
El TDD también suele generar un conjunto de pruebas automatizadas como subproducto del desarrollo. Estas pruebas pueden ser útiles en flujos de trabajo de integración continua , donde los cambios se prueban con frecuencia antes de fusionarse o publicarse. En este sentido, el TDD puede mejorar la confianza en los cambios posteriores, aunque el hecho de que las pruebas unitarias se superen no demuestra por sí solo que el software sea correcto. [ 19 ] [ 20 ]
Limitaciones
El TDD no sustituye a otras formas de prueba de software . Dado que el TDD se practica comúnmente mediante pruebas unitarias , puede que no evalúe adecuadamente el comportamiento que depende de interfaces de usuario, bases de datos, sistemas distribuidos, hardware, sincronización, propiedades de seguridad o interacciones entre componentes. Estas áreas suelen requerir pruebas de integración , pruebas de sistema , pruebas de aceptación, pruebas de usabilidad u otros métodos de prueba especializados.
Las pruebas escritas durante el desarrollo guiado por pruebas (TDD) pueden presentar los mismos errores de interpretación que el código de producción. Si un desarrollador malinterpreta un requisito, tanto la prueba como la implementación pueden reflejar la misma suposición errónea, lo que provoca que la prueba pase mientras el software sigue presentando fallos. Por lo tanto, un gran número de pruebas exitosas puede generar una falsa sensación de seguridad si las pruebas son incompletas, demasiado específicas o se centran en detalles de implementación en lugar de en el comportamiento visible externamente.
Las pruebas automatizadas también generan costos de mantenimiento. Las pruebas que están estrechamente vinculadas a detalles de implementación internos, que utilizan simulaciones excesivas, que dependen de supuestos de temporización frágiles o que contienen código de configuración duplicado pueden volverse difíciles de mantener. [ 25 ] En algunos contextos, especialmente en tareas complejas de modernización o proyectos con experiencia limitada en pruebas automatizadas, el tiempo necesario para escribir y mantener las pruebas puede reducir la productividad a corto plazo. [ 22 ] [ 20 ]
Conferencia
La primera Conferencia TDD se celebró en julio de 2021. [ 26 ] Las conferencias se grabaron en YouTube. [ 27 ]
Véase también
- Pruebas de aceptación
- Desarrollo impulsado por el comportamiento
- Diseño por contrato
- Programación inductiva
- Pruebas de integración
- Lista de filosofías de desarrollo de software
- Lista de marcos de trabajo para pruebas unitarias
- Objeto simulado
- Programación mediante ejemplos
- Verificación de cordura
- Código de autocomprobación
- Pruebas de software
- Premisa de prioridad de la transformación
- Pruebas unitarias
- desarrollo continuo basado en pruebas
Referencias
- ↑ Parsa, Saeed; Zakeri-Nasrabadi, Morteza; Turhan, Burak (2025-01-01). "Desarrollo impulsado por la capacidad de prueba: una mejora en la eficiencia del TDD" . Computer Standards & Interfaces . 91 103877. doi : 10.1016/j.csi.2024.103877 . ISSN 0920-5489 .
- ↑ Lee Copeland (diciembre de 2001). "Programación extrema" . Computerworld. Archivado del original el 5 de junio de 2011. Consultado el 11 de enero de 2011 .
- 1 2 Newkirk, JW y Vorontsov, AA. Desarrollo guiado por pruebas en Microsoft .NET , Microsoft Press, 2004.
- ↑ Feathers, M. Trabajar eficazmente con código heredado, Prentice Hall, 2004
- ↑ Kent Beck (11 de mayo de 2012). "¿Por qué Kent Beck se refiere al "redescubrimiento" del desarrollo guiado por pruebas?" . Consultado el 1 de diciembre de 2014 .
- 1 2 3 Beck, Kent (2002-11-08). Desarrollo guiado por pruebas mediante ejemplos . Vaseem: Addison Wesley. ISBN 978-0-321-14653-3.
- ↑ Kent Beck (11 de mayo de 2012). "¿Por qué Kent Beck se refiere al "redescubrimiento" del desarrollo guiado por pruebas?" . Consultado el 1 de diciembre de 2014 .
- ↑ Beck, Kent (11 de diciembre de 2023). "Canon TDD" . Diseño de software: ¿Primero lo ordenado? . Recuperado el 22 de octubre de 2024 .
- ↑ Leybourn, E. (2013) Dirigiendo la organización ágil: un enfoque Lean para la gestión empresarial . Londres: IT Governance Publishing: 176-179.
- ↑ Mohan, Gayathri. "Pruebas de pila completa" . www.thoughtworks.com . Consultado el 7 de septiembre de 2022 .
- 1 2 3 4 5 6 "Documento técnico sobre TDD eficaz para sistemas embebidos complejos" (PDF) . Pathfinder Solutions. Archivado del original (PDF) el 16 de marzo de 2016.
- ↑ "Desarrollo ágil guiado por pruebas" . Agile Sherpa. 3 de agosto de 2010. Consultado el 14 de agosto de 2012 .
{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace ) - ↑ Fowler, Martin (1999). Refactoring - Improving the design of existing code . Boston: Addison Wesley Longman, Inc. ISBN 0-201-48567-2.
- ↑ Koskela, L. "Test Driven: TDD and Acceptance TDD for Java Developers", Manning Publications, 2007
- 1 2 Desarrollo guiado por pruebas (TDD) para sistemas complejos: Introducción en YouTube por Pathfinder Solutions
- ↑ Desarrollo ágil y ágil basado en pruebas de aceptación: Mejor software mediante la colaboración . Boston: Addison Wesley Professional. 2011. ISBN 978-0-321-71408-4.
- ↑ "BDD" . Archivado del original el 8 de mayo de 2015. Consultado el 28 de abril de 2015 .
- ↑ "Documento técnico sobre TDD eficaz para sistemas embebidos complejos" . Pathfinder Solutions. Archivado del original el 20 de agosto de 2013. Consultado el 27 de noviembre de 2012 .
- 1 2 Rafique, Yahya; Mišić, Vojislav B. (2013). "Los efectos del desarrollo guiado por pruebas en la calidad externa y la productividad: un metaanálisis". IEEE Transactions on Software Engineering . 39 (6): 835– 856. doi : 10.1109/TSE.2012.28 .
- 1 2 3 Bissi, Wilson; Neto, AGSS; Emer, MCFP (2016). "Los efectos del desarrollo guiado por pruebas en la calidad interna, la calidad externa y la productividad: una revisión sistemática". Information and Software Technology . 74 : 45– 54. doi : 10.1016/j.infsof.2016.02.004 .
- 1 2 Mäkinen, Simo; Münch, Jürgen (2014). "Efectos del desarrollo guiado por pruebas: un análisis comparativo de estudios empíricos". Calidad del software. Enfoques basados en modelos para la ingeniería avanzada de software y sistemas . Notas de clase en procesamiento de información empresarial. Vol. 166. Springer. págs. 155–169 . doi : 10.1007/978-3-319-03602-1_10 .
- 1 2 Tosun, A.; Dieste, O.; Fucci, D.; Vegas, S.; Turhan, B.; Erdogmus, H.; Santos, A.; Oivo, M.; Toro, K.; Järvinen, J.; Juristo, N. (2017). "Un experimento industrial sobre los efectos del desarrollo guiado por pruebas en la calidad externa y la productividad". Ingeniería de software empírica . 22 (6): 2763– 2805. doi : 10.1007/s10664-016-9490-0 .
- ↑ Fucci, Davide; Erdogmus, Hakan; Turhan, Burak; Oivo, Markku; Juristo, Natalia (2017). "Una disección del proceso de desarrollo guiado por pruebas: ¿Realmente importa probar primero o probar al final?". IEEE Transactions on Software Engineering . 43 (7): 597– 614. arXiv : 1611.05994 . doi : 10.1109/TSE.2016.2616877 .
- 1 2 Beck, Kent (2003). Desarrollo guiado por pruebas: mediante ejemplos . Addison-Wesley. ISBN 978-0321146533.
- ↑ Meszaros, Gerard (2007). Patrones de pruebas unitarias: Refactorización de código de prueba . Addison-Wesley. ISBN 978-0131495050.
- ↑ Bunardzic, Alex. "Primera Conferencia Internacional sobre Desarrollo Dirigido por Pruebas (TDD)" . Conferencia TDD . Consultado el 20 de julio de 2021 .
- ↑ Primera Conferencia Internacional TDD - Sábado 10 de julio de 2021 , 10 de julio de 2021, archivado del original el 21 de diciembre de 2021 , recuperado el 20 de julio de 2021
Enlaces externos
- Desarrollo TestDriven en WikiWikiWeb
- Bertrand Meyer (septiembre de 2004). "¿Prueba o especificación? ¿Prueba y especificación? ¡Prueba según la especificación!" . Archivado del original el 9 de febrero de 2005.
- Pruebas de equipo con Microsoft Visual Studio desde un enfoque TDD
- Escribe pruebas unitarias fáciles de mantener que te ahorrarán tiempo y quebraderos de cabeza.
- Mejora de la calidad de las aplicaciones mediante el desarrollo guiado por pruebas (TDD)
- Conferencia sobre desarrollo guiado por pruebas
- Programación extrema
- Filosofías de desarrollo de software
- proceso de desarrollo de software
- Pruebas de software
