¿Cuál es el papel de un arquitecto de software en el proceso de desarrollo basado en pruebas?

Según tengo entendido, Test-Driven Development se trata de escribir pruebas para definir las especificaciones del programa (puede corregirme si me equivoco).

Si hay alguien responsable de escribir las especificaciones (incluida una API pública) para el software (llamémoslo el Arquitecto de software), ¿eso significa que el Arquitecto de software debe escribir todas las pruebas?

¿O el Arquitecto de software escribe las especificaciones y luego las entrega a los desarrolladores para que escriban las pruebas?

¿O permite que las especificaciones crezcan orgánicamente al permitir que todos los desarrolladores escriban sus propias pruebas y se olviden de tener un Arquitecto de software?

architecture tdd

— Robert Harvey
fuente

Existe cierto debate sobre el english.se de lo que entendemos por "crecer orgánicamente" - english.stackexchange.com/questions/17853/... - ¿Le gustaría confirmar :)

— Josek

@Jose: La última oración en mi OP está destinada a ser un poco irónica, ya que me parece obvio que un programa siempre debe tener especificaciones detalladas de un cliente. Pero los clientes no siempre saben exactamente lo que quieren, por eso existen procesos iterativos de desarrollo de software . Consulte aquí para obtener más información sobre la metáfora del "software en crecimiento".

— Robert Harvey

Respuestas:

Test-Driven Development se trata de escribir pruebas para definir las especificaciones del programa

No escribe pruebas para definir la especificación, las descripciones de las pruebas, las historias de los usuarios y las descripciones de características son la especificación, en el sentido de 'árboles muertos'.

Para revisar, el proceso de TDD en pocas palabras es:

definir un proyecto en términos de características
Describir la parte interesada, el comportamiento y el objetivo de cada característica utilizando historias de usuario
especifique los datos esperados, los eventos / condiciones desencadenantes y los comportamientos / resultados asociados con una historia de usuario utilizando descripciones de prueba [y esto completa la 'especificación']
elija un conjunto de características para cada iteración; las iteraciones deben ser cortas [omito los pasos de planificación y estimación por brevedad]
- codifique una prueba para una función (fallará, pero tuvo que tomar decisiones de API para codificar la prueba)
- implementar suficiente de la función para que la prueba pase
- refactorizar el código si es necesario
- repita con la próxima prueba hasta que se complete la función
- repita con la siguiente característica hasta que se complete la iteración
repita con la siguiente iteración hasta que se complete el proyecto

la cantidad de diseño, arquitectura, documentación de respaldo, etc., que elija hacer no forma parte de TDD. Hay algunas 'mejores prácticas' prácticas sobre las que puede leer, pero tenga en cuenta que esas son las 'mejores' prácticas en el taller de otra persona , no en las suyas.

tenga en cuenta que el punto es que el cliente y el desarrollador presenten las características y escriban las historias y las descripciones de las pruebas juntas , para un entendimiento mutuo

entonces, con eso fuera del camino, la pregunta original fue:

¿Cuál es el papel de un arquitecto de software en TDD?

Y la respuesta corta es:

Igual que siempre, igual que siempre. --David Byrne

EDITAR: La respuesta larga es: el arquitecto desempeña los roles habituales de visionario / investigador / irritante / apoyo / respaldo durante todo el proceso, según sea necesario.

EDIT 2: lo siento, perdí el punto de las subpreguntas! Todos son responsables de escribir las especificaciones; todos los desarrolladores, incluido el arquitecto, si corresponde, más el cliente . Los desarrolladores también codifican las pruebas.

— Steven A. Lowe
fuente

Eso tiene sentido, pero los únicos pasos de los que he oído hablar en el contexto de TDD son los cinco pasos en sus cinco viñetas internas (que describen el proceso de refactorización rojo-verde). ¿Son las viñetas restantes realmente parte de TDD propiamente dicho, o son parte de alguna metodología más amplia como Agile o DDD?

— Robert Harvey

@Robert hmmm ... ¡buena pregunta! técnicamente las otras balas serían XP; Aprendí XP y TDD al mismo tiempo y nunca pensé en separarlos. Hasta ahora ;-)

— Steven A. Lowe

@Robert hizo algunas lecturas de actualización; ver ediciones (FYI usando XP ref extremeprogramming.org y TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Steven A. Lowe

Hmm, el enlace que proporcionó para TDD dice que TDD es realmente un diseño basado en pruebas . Ahora estoy de vuelta donde empecé. "Usted diseña orgánicamente, con el código en ejecución que proporciona comentarios entre las decisiones".

— Robert Harvey

@Robert las ediciones ciertamente me ayudaron a comprender mejor la pregunta. Tomo la D como Desarrollo y la interpreto como el ciclo de vida completo, no solo la parte de codificación. TDDev es una buena manera de aprender habilidades arquitectónicas: la refactorización tiende a empujar a uno en esa dirección

— Steven A. Lowe

El arquitecto de software no está escribiendo todas las pruebas. Eso sería poner demasiado sobre los hombros de una persona en mi mente.

El Arquitecto de software debería poder esbozar un formulario inicial para la API para que los desarrolladores escriban pruebas para eso y luego creen la API. Sin embargo, el Arquitecto de software puede tener varios estándares de código que no son necesariamente verificables, por ejemplo, documentación o convenciones de nomenclatura. También existe la posibilidad de que la API inicial pierda algunas llamadas que, a medida que se realiza una implementación, se agregan nuevas llamadas a la API. Por lo tanto, habrá un crecimiento orgánico en la API a medida que crezca la base del código, pero el papel del Arquitecto es proporcionar pautas de alto nivel e intentar asegurarse de que se sigan.

Ciertamente, puede haber casos en los que un equipo puede decidir no tener un Arquitecto de software, pero dependiendo de la escala de la API y la compañía involucrada, esto puede o no ser una buena idea.

— JB King
fuente