{"id":9026,"date":"2022-01-26T01:34:13","date_gmt":"2022-01-26T01:34:13","guid":{"rendered":"https:\/\/www.cybermedian.com\/es\/?p=9026"},"modified":"2026-04-20T09:13:19","modified_gmt":"2026-04-20T09:13:19","slug":"enfoque-de-desarrollo-de-prueba-para-el-desarrollo-de-software-agil","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/es\/test-drive-development-approach-for-agile-software-development\/","title":{"rendered":"Enfoque de desarrollo de prueba para el desarrollo de software \u00e1gil"},"content":{"rendered":"
\n
\n
\n
\n

Ahora, la gente a menudo habla de desarrollo \u00e1gil.<\/p>\n

\u00bfQu\u00e9 es el desarrollo \u00e1gil?<\/span><\/h4>\n

El desarrollo \u00e1gil<\/a>\u00a0\u00a0es una capacidad de desarrollo de software que responde a necesidades que cambian r\u00e1pidamente.\u00a0Sus nombres espec\u00edficos, conceptos, procesos y terminolog\u00eda var\u00edan.\u00a0En comparaci\u00f3n con ”\u00a0no \u00e1giles<\/a>\u00a0“, enfatizan la estrecha colaboraci\u00f3n entre los equipos de programadores y los expertos comerciales, la comunicaci\u00f3n cara a cara (considerada m\u00e1s efectiva que la documentaci\u00f3n escrita) y, con frecuencia, entregan nuevas versiones de software,\u00a0\u00a0equipos peque\u00f1os y autoorganizados<\/a>\u00a0\u00a0para peque\u00f1os y enfoques de escritura de caracter\u00edsticas valiosas y organizaci\u00f3n de equipos que se adaptan a las necesidades cambiantes, con un mayor enfoque en el papel de las personas en el desarrollo de software.<\/p>\n

Sin embargo, existen varias versiones similares de m\u00e9todos de desarrollo \u00e1gil de TDD, como TDD: BDD, DDD y ATDD.\u00a0Perm\u00edtanme presentarles brevemente estos m\u00e9todos antes de presentar TDD en detalle:<\/p>\n

TDD: desarrollo basado en pruebas<\/strong><\/p>\n

Test Driven Development<\/a>\u00a0\u00a0(TDD) es un proceso de desarrollo de software, que se basa en transformar los requisitos de software en casos de prueba antes de que el software est\u00e9 completamente desarrollado, y rastrear todo el desarrollo de software probando repetidamente el software para todos los casos de prueba.\u00a0Esto es lo opuesto a desarrollar software primero y luego crear casos de prueba.\u00a0Algunos modelos populares admiten muy bien TDD, como MVC y\u00a0\u00a0MVP<\/a>\u00a0.<\/p>\n

<\/figure>\n

BDD: Desarrollo impulsado por el comportamiento (Behavior Driven Development)<\/strong><\/p>\n

El desarrollo impulsado por el comportamiento (BDD) tambi\u00e9n es un proceso \u00e1gil de desarrollo de software.\u00a0Fomenta la colaboraci\u00f3n entre desarrolladores, evaluadores de control de calidad y representantes de clientes en proyectos de software.\u00a0Alienta a los equipos a usar conversaciones y ejemplos concretos para formalizar un entendimiento com\u00fan de c\u00f3mo deber\u00eda funcionar la aplicaci\u00f3n.\u00a0Proviene del desarrollo guiado por pruebas (TDD).<\/p>\n

<\/figure>\n

ATDD: Desarrollo impulsado por pruebas de aceptaci\u00f3n<\/strong><\/p>\n

Para promover la realizaci\u00f3n de c\u00f3digo funcional a trav\u00e9s de casos de prueba de unidad, el equipo debe definir los est\u00e1ndares de calidad esperados y las reglas de aceptaci\u00f3n, y promover la pr\u00e1ctica de TDD de los desarrolladores y el desempe\u00f1o de los probadores a trav\u00e9s de un plan de prueba de aceptaci\u00f3n claro y consistente (que incluye una serie de pruebas). escenarios).\u00a0Para los desarrolladores, enfatiza c\u00f3mo implementar el sistema y c\u00f3mo probarlo.<\/p>\n

<\/figure>\n

DDD: dise\u00f1o de unidades de dominio<\/strong><\/p>\n

DDD se refiere al dise\u00f1o impulsado por el dominio, es decir, el desarrollo impulsado por el dominio.\u00a0En realidad, DDD se basa en esta base porque se enfoca en el dise\u00f1o de la capa de servicio, se enfoca en la implementaci\u00f3n comercial, combina an\u00e1lisis y dise\u00f1o, y ya no lo mantiene en un estado dividido, para implementar de manera correcta y completa las necesidades del cliente y construir un modelo de negocio. escalabilidad<\/p>\n

<\/figure>\n

Plan de implementaci\u00f3n de TDD<\/span><\/h3>\n

A trav\u00e9s de las pruebas para promover todo el desarrollo, pero el desarrollo basado en pruebas no es solo un simple trabajo de prueba, sino un proceso de cuantificaci\u00f3n de an\u00e1lisis de requisitos, dise\u00f1o y control de calidad.<\/em><\/p><\/blockquote>\n

Principios de desarrollo<\/strong><\/p>\n

Escriba primero el c\u00f3digo de prueba y luego escriba el c\u00f3digo para la funci\u00f3n.<\/em><\/p><\/blockquote>\n

    \n
  1. Escriba el c\u00f3digo de prueba de acuerdo con el documento de requisitos, para no realizar la funci\u00f3n;<\/li>\n
  2. No quiero engordar de un bocado.\u00a0Al probar bloques funcionales grandes, primero debe dividirlos en bloques funcionales m\u00e1s peque\u00f1os para realizar pruebas;<\/li>\n
  3. Recuerde no escribir c\u00f3digo para completar la funci\u00f3n, use el c\u00f3digo m\u00e1s simple posible para implementar la funci\u00f3n;<\/li>\n
  4. Si los requisitos se pueden probar, escriba c\u00f3digo de prueba y renuncie a aquellos que no se pueden probar o sienta que no necesitan probarse;<\/li>\n
  5. Antes de cambiar\/agregar cualquier c\u00f3digo de funci\u00f3n, primero debe pensar si desea cambiar\/agregar casos de prueba;<\/li>\n
  6. Funci\u00f3n\/c\u00f3digo de prueba, estructura irrazonable, c\u00f3digo duplicado, etc., refactorizar en el tiempo despu\u00e9s de que pase la prueba.<\/li>\n<\/ol>\n

    Proceso de desarrollo de TDD<\/strong><\/p>\n

      \n
    1. Analizar y determinar un escenario de prueba objetivo;<\/li>\n
    2. Agregue una prueba unitaria para verificar la entrada y salida del escenario de prueba;<\/li>\n
    3. Ejecute la prueba y obtenga el resultado de la prueba fallida;<\/li>\n
    4. Escriba el c\u00f3digo de funci\u00f3n m\u00e1s simple para pasar la prueba;<\/li>\n
    5. Vuelva a ejecutar la prueba y compruebe que pasa;<\/li>\n
    6. Llevar a cabo la refactorizaci\u00f3n del c\u00f3digo, incluido el c\u00f3digo funcional y el c\u00f3digo de prueba de la unidad;<\/li>\n
    7. Repita los pasos anteriores hasta completar el desarrollo.<\/li>\n<\/ol>\n

      Beneficios de TDD<\/strong><\/p>\n

        \n
      1. Reducir la carga de los desarrolladores<\/strong>\u00a0.\u00a0A trav\u00e9s de un proceso claro, centr\u00e9monos en un solo punto a la vez, y la carga de pensar es menor.<\/li>\n
      2. La red de protecci\u00f3n<\/strong>\u00a0.\u00a0Cubrir las pruebas unitarias completas proporciona una red protectora para el c\u00f3digo del producto, lo que facilita el cumplimiento de los cambios en los requisitos o la mejora del dise\u00f1o del c\u00f3digo.\u00a0Entonces, si los requisitos de su proyecto son estables, se realizan de una vez y no hay cambios posteriores, los beneficios de TDD son menores.<\/li>\n
      3. Aclare los requisitos con antelaci\u00f3n<\/strong>\u00a0.\u00a0Escribir pruebas primero puede ayudarnos a pensar en los requisitos y aclarar los detalles de los requisitos con anticipaci\u00f3n, en lugar de descubrir requisitos poco claros solo a la mitad del c\u00f3digo.<\/li>\n
      4. Comentarios r\u00e1pidos<\/strong>\u00a0.\u00a0Mucha gente dice que cuando TDD, mi volumen de c\u00f3digo aumenta, por lo que la eficiencia de desarrollo disminuye.\u00a0Sin embargo, si no tiene pruebas unitarias, debe probarlas manualmente, dedica mucho tiempo a preparar datos, iniciar aplicaciones, modificar interfaces, etc., y la retroalimentaci\u00f3n es lenta.\u00a0Para ser precisos, la retroalimentaci\u00f3n r\u00e1pida es un beneficio de las pruebas unitarias.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
        \n
        \n
        \n<\/div>\n
        \n
        \n

        Principios \u00e1giles y Scrum<\/span><\/h4>\n