Testando. Muitas vezes fica para o último minuto, depois é cortado porque você está sem tempo, orçamento excedido ou qualquer outra coisa.

A gerência se pergunta por que os desenvolvedores não podem simplesmente 'acertar da primeira vez', e os desenvolvedores (especialmente em grandes sistemas) podem ser pegos de surpresa quando diferentes partes interessadas descrevem diferentes partes do sistema, como a história do homens cegos descrevendo um elefante .

como usar modelos de bootstrap

É inevitável, no entanto, que a primeira etapa em cada projeto seja uma discussão sobre os comportamentos do software ou recurso a ser construído. Um cliente ou empresário chega até alguém da equipe de desenvolvimento e explica o que deseja.

Às vezes, essas interações vêm na forma de um Ágil História do usuário . Às vezes, eles vêm na forma de documentos de design, como em Chris Fox's entrada de blog ano passado. Eles também podem vir como fluxogramas ou maquetes no Keynote, ou até mesmo telefonemas apressados.

Somente a partir dessas comunicações, um desenvolvedor é responsável por construir um sistema que 'simplesmente funcione'.

Somente a partir dessas comunicações, um desenvolvedor é responsável por construir um sistema que “simplesmente funcione”. Isso é especialmente difícil para freelancers trabalhando fora do sistema maior.

Por que o teste é interrompido?

Há uma lacuna óbvia aqui: se o proprietário da empresa imaginou os comportamentos do sistema no início, por que está testando se esses comportamentos realmente trabalhos frequentemente a etapa que é cortada?

A resposta pode ser extremamente simples: os testes muitas vezes não são vistos como capital compartilhado ; eles não são considerados como tendo valor para o projeto, porque 'eles são apenas para os engenheiros', ou similarmente, agregando valor a um único departamento ou grupo de pessoas.

Como fazemos testes desse capital compartilhado, dessa lista de comportamentos do sistema? Abraçando não apenas o desenvolvimento orientado a testes (TDD), mas o desenvolvimento dirigido por comportamento (BDD).

O que é BDD?

O desenvolvimento orientado por comportamento deve ser focado nos comportamentos de negócios que seu código está implementando: o “porquê” por trás do código . Ele oferece suporte a um fluxo de trabalho centrado na equipe (especialmente multifuncional).

Eu vi o BDD ágil funcionar muito bem quando um desenvolvedor e o proprietário do produto Agile ou um analista de negócios sentam-se juntos e escrevem especificações pendentes (a serem preenchidas posteriormente pelo desenvolvedor) em um editor de texto simples:

1. o pessoa de negócios especifica os comportamentos que eles desejam ver no sistema.
2. o desenvolvedor faz perguntas com base em sua compreensão do sistema, enquanto também escreve comportamentos adicionais necessários de uma perspectiva de desenvolvimento.

Idealmente, ambas as partes podem consultar a lista de comportamentos atuais do sistema para ver se esse novo recurso interromperá os recursos existentes.

Eu descobri que esse ato simples me dá restrições suficientes para que eu seja capaz de pensar como um desenvolvedor: 'dado que tenho que implementar esses testes, como isso me restringe / todos na especificação que posso implementar no código'? Como são especificações pendentes, eles são rápidos e fáceis de escrever no meio da colaboração.

Essa abordagem colaborativa permite que eu me concentre no que o recurso oferece ao usuário final, e ter o empresário ali me limita a falar sobre comportamento, não implementação. Isso destaca as diferenças entre BDD e TDD.

Vamos ver um exemplo de Desenvolvimento Orientado a Comportamento

O cenário: você é um desenvolvedor em uma equipe responsável pelo sistema de contabilidade da empresa, implementado em Rails. Um dia, um empresário pede que você implemente um sistema de lembrete para lembrar os clientes de suas faturas pendentes. Porque você está praticando BDD com esta tutoria; (versus TDD), você se senta com aquele empresário e começa a definir comportamentos.

Você abre seu editor de texto e começa a criar especificações pendentes para os comportamentos que o usuário empresarial deseja:

it 'adds a reminder date when an invoice is created' it 'sends an email to the invoice's account's primary contact after the reminder date has passed' it 'marks that the user has read the email in the invoice'

Esse foco no comportamento durante o desenvolvimento torna o teste útil como verificação de que você está construindo o recurso certo, não apenas se seu código está correto. Observe que a frase está em linguagem comercial, não na linguagem de implementação interna do sistema. Você não vê ou não se importa se uma fatura belongs_to uma conta, porque ninguém fora da equipe de desenvolvimento se preocupa com isso.

O fraseado está na linguagem comercial, não na linguagem de implementação interna do sistema. Você não vê ou se importa se uma fatura pertence a uma conta, porque ninguém de fora da equipe de desenvolvimento se preocupa com isso.

Alguns desenvolvedores preferem escrever casos de teste no local, chamando métodos no sistema, estabelecendo expectativas, assim:

it 'adds a reminder date when an invoice is created' do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

O conjunto de testes falhará porque ainda não escreveremos o código para definir o reminder_date.

Especificações com falhas vis-à-vis

Eu entendo os desenvolvedores que escrevem especificações defeituosas, mas com o empresário ao meu lado, isso nunca funcionou para mim. O empresário errado se distrairá com os detalhes ou pegará esse novo conhecimento e tentará microgerenciar coisas sobre as quais o desenvolvedor sabe mais (design de banco de dados adequado, reutilização de código).

Em minha experiência, escrever mais do que uma visão geral de uma linha de um comportamento específico entediará o empresário. Eles verão isso como um mau uso de seu tempo ou ficarão ansiosos para descrever o próximo comportamento enquanto ele está em sua mente.

Como o BDD difere do TDD?

Vamos olhar para isso de uma maneira diferente, com uma abordagem de Desenvolvimento Orientado a Testes, e escrever os testes pendentes:

it 'after_create an Invoice sets a reminder date to be creation + 20 business days' it 'Account#primary_payment_contact returns the current payment contact or the client project manager' it 'InvoiceChecker#mailer finds invoices that are overdue and sends the email'

Esses testes são úteis, mas úteis apenas para um grupo de pessoas: engenheiros. BDD é útil para comunicação com cada membro de uma equipe multifuncional de produtos.

Você certamente pode fazer o desenvolvimento test-first enquanto estiver em uma mentalidade BDD por meio do uso de comportamentos pendentes. Primeiro, escreva o teste; em seguida, execute-o (vermelho); em seguida, faça funcionar (verde); então faça certo (refatorar) .

Muito trabalho na comunidade BDD foi dedicado a fazer com que as verificações de asserção dentro do teste fossem lidas como inglês. Aqui está um teste RSpec estereotipado:

a = 42 a.should == 42

Este formato torna as coisas mais fáceis de ler mais tarde. Mas lembre-se de que não é isso que estamos fazendo aqui - o objetivo é diminuir os comportamentos o mais rápido possível - e fazer cumprir o princípio de 'um comportamento testado por especificação'. Idealmente, o título da especificação pendente deve informar o que você está testando.

O BDD não trata de maneiras sofisticadas de validar seus resultados; trata-se de compartilhar os comportamentos esperados entre todos os membros da equipe.

O desenvolvimento baseado em comportamento é sobre colaboração e comunicação

Vamos voltar ao nosso cenário: trabalhar no sistema de contabilidade da empresa.

Você percorre a funcionalidade do item com o empresário, analisando o sistema por meio de seus componentes internos (como os objetos se encaixam internamente) e eles analisando o sistema de fora.

Você pensa em algumas condições e pergunta ao analista de negócios o que acontece nos seguintes cenários:

* What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

E você consegue respostas . É importante que o empresário entenda que você não está tentando abrir buracos em sua ideia preferida ou sendo excessivamente pedante.

Desta forma, o Behavior-Driven Development é uma ferramenta para auxiliar a colaboração e iniciar uma conversa entre os dois departamentos. É também uma maneira de esclarecer o escopo de um recurso desejado e obter melhores estimativas da equipe de desenvolvimento. Talvez você perceba que não há como calcular 10 dias úteis a partir de um determinado momento; esse é um recurso adicional separado que você precisa implementar.

Os desenvolvedores terão considerações de desenvolvedor ('O que exatamente você quer dizer quando diz, 'dia'?'), Enquanto os empresários terão suas próprias considerações ('Por favor, não use o termo vencido aqui, isso significa algo diferente'). Ter um grupo ou outro tentando escrever esses testes de comportamento de lógica de negócios (a promessa de Pepino ) elimina a entrada valiosa de cada lado.

Também é um bom substituto para quando o cliente Agile não está mais fisicamente na sala: ter seus desejos no papel, misturados com a análise do desenvolvedor (e tradução) do que você está construindo.

Documentos de design

A Postagem anterior do blog ApeeScape, Chris Fox, fala sobre documentos de design , especialmente no início de um projeto. Compreender e extrair os comportamentos de negócios vai desde projetos em que o sistema é de alguma forma reconhecível, até aqueles que exigem décadas de programador-anos para serem realizados e têm centenas ou milhares de especificações comportamentais.

O artigo de Chris também menciona comportamentos na tela de elementos, e esta é uma área em que estou constantemente em conflito com designers: “Como é que este botão se parece quando está escuro” ou, “Como isso fica em telas de 11”, porque esta página é obviamente projetada para 24 ” telas? ” Esse vai e vem com o empresário pode encontrar lacunas nos recursos gráficos de um projeto ou no layout de uma página.

Em equipes multifuncionais muito grandes, há muitos membros da equipe com suas próprias preocupações: designers, desenvolvedores, potencialmente alguém de operações, o administrador de banco de dados - talvez pessoal de QA ( sim, há um lugar para todos em TDD e BDD! ), cada um com suas próprias preocupações e perguntas. O BDD pode conduzir essa colaboração mais do que o desenvolvimento orientado a testes. De “o que acontece quando os dados são muito grandes para esta tabela?” para, 'Hmmm, essa será uma consulta cara, vamos querer armazená-la em cache de alguma forma' para, 'Espere, o usuário deve ver todos dessas informações confidenciais? ”, pode haver mais em jogo do que apenas um desenvolvedor e um analista de negócios com dúvidas sobre este novo recurso

O desenvolvimento orientado por comportamento é sobre artefatos compartilhados

O que é um artefato compartilhado?

Gosto de pensar em “artefatos” na engenharia de software como coisas potencialmente físicas que descrevem o projeto ou a equipe do projeto e que podem ser encontradas seis meses depois. Bons artefatos explicam por que as coisas são como são.

quais são os cinco princípios de design

Bons artefatos explicam por que as coisas são como são. Um artefato é algum código-fonte salvo em um repositório ou espaço compartilhado, ou tickets no sistema de tickets.

As conversas de corredor não são artefatos. Nem são os desenhos do quadro branco. Desenhos do quadro branco que se transformam em grandes documentações de aula ou documentos de projeto - estes são artefatos. Minutos de reuniões também são artefatos.

Um artefato é algum código-fonte salvo em um repositório ou espaço compartilhado e tíquetes no sistema de tíquetes ou notas no Wiki interno - ou até mesmo logs de chat persistentes.

Artefatos compartilhados são, na minha opinião, os melhores artefatos . Eles mostram não apenas porque algo é do jeito que é, mas por que existe no aplicativo em absoluto .

Como você os usa no BDD?

Os comportamentos devem ser um artefato compartilhado da equipe - os testes não devem ser apenas trabalhosos para os programadores! Embora seja melhor ter um sistema em que toda a equipe possa visualizar facilmente as especificações atuais (talvez o sistema de implantação também extraia e salve a lista de comportamentos em uma área privada do site ou wiki), você também pode fazer isso manualmente a cada arrancada.

O nome do jogo é “ajudar os desenvolvedores a criar as especificações de que precisamos para agregar valor ao negócio com mais rapidez, colaborar interdepartamentalmente e fazer melhores estimativas”.

Este entendimento de toda a empresa de como é o sistema faz também é uma forma de capital. É o 'porquê' do 'como' do código.

Conclusão

Como resolvemos o problema da entrega de software com erros aos clientes? Certificando-se de que o teste não é visto como algo “com que apenas os desenvolvedores se importam”.

Descrever e compreender as necessidades de um sistema tem uma tonelada de benefícios além da correção do código: estabelecer diálogo interdepartamental e garantir que todas as preocupações das partes interessadas sejam atendidas (e não apenas as partes interessadas com grandes títulos sofisticados). Usando o desenvolvimento orientado por comportamento para entender essas necessidades desde o início e testando comportamentos de negócios externos com os quais toda a equipe se preocupa— este é uma ótima maneira de garantir um projeto de qualidade.