Qual é o papel de um arquiteto de software no processo de desenvolvimento orientado a testes?

Pelo que entendi, o Desenvolvimento Orientado a Testes trata de escrever testes para definir as especificações do programa (você pode me corrigir se eu estiver errado).

Se houver alguém responsável por escrever as especificações (incluindo uma API pública) para o software (vamos chamá-lo de arquiteto de software), isso significa que o arquiteto de software deve escrever todos os testes?

Ou o arquiteto de software escreve as especificações e as entrega aos desenvolvedores para que testem?

Ou você permite que as especificações cresçam organicamente, permitindo que todos os desenvolvedores escrevam seus próprios testes e se esqueçam de ter um arquiteto de software?

architecture tdd

— Robert Harvey
fonte

Há algum debate sobre a english.se do que você entende por "crescer organicamente" - english.stackexchange.com/questions/17853/... - Gostaria de confirmar :)

— Josek

@ Joseph: A última frase do meu OP deve ser um pouco superficial, pois me parece óbvio que um programa deve sempre ter especificações detalhadas de um cliente. Mas os clientes nem sempre sabem exatamente o que querem, e é por isso que existem processos iterativos de desenvolvimento de software . Veja aqui para mais informações sobre a metáfora "crescente software".

— Robert Harvey

Respostas:

O Desenvolvimento Orientado a Testes trata de escrever testes para definir as especificações do programa

Você não escreve testes para definir a especificação, as descrições de teste, histórias de usuário e descrições de recursos são a especificação, no sentido de 'árvores mortas'.

Para revisar, o processo TDD em poucas palavras é:

definir um projeto em termos de recursos
descrever a parte interessada, o comportamento e a meta de cada recurso usando histórias de usuários
especifique os dados esperados, acionando eventos / condições e comportamentos / resultados associados a uma história de usuário usando descrições de teste [e isso completa a 'especificação']
escolha um conjunto de recursos para cada iteração; as iterações devem ser curtas [estou omitindo as etapas de planejamento e estimativa por questões de brevidade]
- codifique um teste para um recurso (ele falhará, mas você teve que tomar decisões de API para codificar o teste)
- implementar o suficiente do recurso para que o teste seja aprovado
- refatorar o código, se necessário
- repita com o próximo teste até que o recurso seja concluído
- repita com o próximo recurso até que a iteração seja concluída
repita com a próxima iteração até que o projeto seja concluído

quanto design, arquitetura, documentação de suporte etc. você não faz parte do TDD. Você pode ler sobre algumas das "melhores práticas" práticas, mas lembre-se de que essas são as "melhores" práticas no workshop de outra pessoa , não na sua.

observe que o ponto é o cliente e o desenvolvedor apresentar os recursos e escrever as histórias e as descrições dos testes juntos , para entendimento mútuo

então, com isso fora do caminho, a pergunta original era:

qual é o papel de um arquiteto de software no TDD?

E a resposta curta é:

O mesmo de sempre, o mesmo de sempre. --David Byrne

EDIT: A resposta longa é: o arquiteto desempenha as funções habituais de visionário / investigador / irritante / suporte / suporte durante todo o processo, conforme necessário.

EDIT 2: desculpe, eu perdi o ponto das sub-perguntas! Todos são responsáveis por escrever as especificações; todos os desenvolvedores, incluindo o arquiteto, se / quando apropriado, mais o cliente . Os desenvolvedores também codificam os testes.

— Steven A. Lowe
fonte

Isso faz sentido, mas os únicos passos que eu já ouvi as pessoas falarem no contexto do TDD são os cinco passos em suas cinco balas internas (descrevendo o processo de refatoração de vermelho-verde). As balas restantes realmente fazem parte do TDD ou são parte de alguma metodologia abrangente como Agile ou DDD?

— Robert Harvey

@Robert hmmm ... good question! tecnicamente, as outras balas seriam XP; Eu aprendi XP e TDD ao mesmo tempo e nunca pensei em separá-los. Até agora ;-)

— Steven A. Lowe

@Robert fez algumas leituras de atualização; veja edições (FYI usando XP ref extremeprogramming.org e TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Steven A. Lowe

Hmm, o link que você forneceu para o TDD diz que o TDD é realmente um design orientado a testes . Agora estou de volta onde comecei. "Você cria organicamente, com o código em execução fornecendo feedback entre as decisões".

— Robert Harvey

@ Robert as edições certamente me ajudaram a entender melhor a pergunta. Pego o D como Desenvolvimento e o interpreto como todo o ciclo de vida, não apenas a parte de codificação. TDDev é uma boa maneira de aprender habilidades arquitetônicas - a refatoração tem uma tendência a empurrar um nessa direção

— Steven A. Lowe

O arquiteto de software não está escrevendo todos os testes. Isso seria colocar muito nos ombros de uma pessoa na minha mente.

O arquiteto de software deve ser capaz de esboçar um formulário inicial para a API, para que os desenvolvedores gravem testes e depois criem a API. No entanto, o arquiteto de software pode ter vários padrões de código que não são necessariamente testáveis, por exemplo, documentação ou convenções de nomenclatura. Há também o potencial de a API inicial estar ausente de algumas chamadas que, à medida que a implementação é concluída, novas chamadas são adicionadas à API. Portanto, haverá algum crescimento orgânico na API à medida que a base de código crescer, mas o papel do Arquiteto é fornecer diretrizes de alto nível e tentar garantir que elas sejam seguidas.

Certamente, pode haver casos em que uma equipe pode decidir não ter um arquiteto de software, mas dependendo da escala da API e da empresa envolvida, isso pode ou não ser uma boa idéia.

— JB King
fonte