Seu chefe não apreciará o TDD: experimente este exemplo de desenvolvimento orientado por comportamento

Teste. Muitas vezes é deixado para o último minuto e depois cortado porque você está sem tempo, com orçamento acima do orçamento ou qualquer outra coisa.

A gerência se pergunta por que os desenvolvedores não podem simplesmente “acertar na 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 dos cegos descrevendo um elefante.

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

Às vezes, essas interações vêm na forma de uma história de usuário ágil. Às vezes eles vêm na forma de documentos de design, como na entrada do blog de Chris Fox no ano passado. Eles também podem vir como fluxogramas ou maquetes no Keynote, ou até mesmo chamadas telefônicas apressadas.

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

Por que os testes são cortados?

Há uma lacuna óbvia aqui: se o proprietário da empresa visualizou os comportamentos do sistema no início, por que testar se esses comportamentos realmente funcionam com frequência é a etapa que é cortada?

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

Como fazemos para testar esse capital compartilhado, essa lista de comportamentos do sistema? Abraçando não apenas o desenvolvimento orientado a testes (TDD), mas o desenvolvimento orientado a 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 suporta um fluxo de trabalho centrado em 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. A pessoa de negócios especifica os comportamentos que deseja ver no sistema.
2. O desenvolvedor faz perguntas com base em sua compreensão do sistema, enquanto também anota 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.

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

Essa abordagem colaborativa me permite focar no que o recurso oferece para o usuário final, e ter a pessoa de negócios ali me restringe a falar sobre comportamento, não sobre implementação. Isso destaca as diferenças no BDD vs TDD.

Vamos ver um exemplo de Desenvolvimento Orientado por 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 lembretes para lembrar os clientes de suas faturas pendentes. Porque você está praticando BDD de acordo com este tutorial; (versus TDD), você 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 de negócios 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 que seu código está correto. Observe que o fraseado está na linguagem de negócios, não na linguagem de implementação interna do sistema. Você não vê ou se importa que uma fatura belongs_to uma conta, porque ninguém fora da equipe de desenvolvimento se importa com isso.

Alguns desenvolvedores preferem escrever casos de teste no local, chamando métodos no sistema, configurando 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 precisamos escrever o código para definir o reminder_date .

Especificações de falha vis-a-vis

Eu entendo desenvolvedores que escrevem especificações que falham, mas com a pessoa de negócios ao meu lado, isso nunca funcionou para mim. A pessoa de negócios errada 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).

Na minha experiência, escrever mais do que uma visão geral de uma linha de um comportamento específico vai 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 estiver em sua mente.

Como o BDD difere do TDD?

Vamos ver 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. O BDD é útil para se comunicar com todos os membros de uma equipe de produto multifuncional.

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); então faça funcionar (verde); então faça certo (refatorar).

Muito trabalho na comunidade BDD foi feito para fazer as verificações de asserção dentro do teste serem lidas como em 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 que não é isso que estamos fazendo aqui – o objetivo é reduzir os comportamentos o mais rápido possível – e aplicar o princípio de 'um comportamento testado por especificação'. Idealmente, o título de especificação pendente deve informar o que você está testando.

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

Desenvolvimento orientado por 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 a pessoa de negócios, com você analisando o sistema através de suas partes internas (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ê obtém respostas . É importante que a pessoa de negócios entenda que você não está tentando fazer furos em sua ideia favorita, 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 e separado que você precisará implementar.

Os desenvolvedores terão suas próprias considerações (“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 atrasado aqui, isso significa algo diferente”). Fazer com que um grupo ou outro tente escrever esses testes de comportamento de lógica de negócios (a promessa do Cucumber) corta a entrada valiosa de cada lado.

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

Documentos de projeto

Um post anterior do Toptal Blog, Chris Fox, fala sobre documentos de design, especialmente no início de um projeto. Compreender e extrair os comportamentos de negócios reduz desde projetos em que o sistema é um pouco conhecido, até aqueles que exigem décadas de programadores-anos para serem realizados e têm centenas ou milhares de especificações comportamentais.

O artigo de Chris também menciona os comportamentos de elementos na tela, e esta é uma área em que estou constantemente em desacordo com os designers: “Como esse botão se parece quando está escuro” ou “Como isso fica em telas de 11”, porque esta página é obviamente projetada para telas de 24”?” 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 controle de qualidade (sim, há um lugar para todos em TDD e BDD!), cada com suas próprias preocupações e perguntas. O BDD pode impulsionar 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 armazenar em cache de alguma forma" para "Espere, o usuário deve ver todas essas informações confidenciais?", pode haver mais em jogo do que apenas um desenvolvedor e um analista de negócios com dúvidas sobre esse novo recurso

Desenvolvimento orientado por comportamento é sobre artefatos compartilhados

O que é um artefato compartilhado?

Gosto de pensar em “artefatos” em 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 do jeito que são.

As conversas no corredor não são artefatos. Nem são os desenhos do quadro branco. Desenhos de quadro branco que são transformados em grandes documentações de longa duração ou documentos de design — esses 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 tickets no sistema de tickets ou notas no Wiki interno – ou até mesmo logs de bate-papo persistentes.

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

Como você os usa no BDD?

Os comportamentos devem ser um artefato de equipe compartilhado - os testes não devem ser apenas um trabalho ocupado para os programadores! Embora seja melhor ter um sistema no qual 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 em um wiki), você também pode fazer isso manualmente a cada corrida.

O nome do jogo é “ajudar os desenvolvedores a criar as especificações de que precisamos para entregar valor de negócios mais rapidamente, colaborar entre departamentos e fazer melhores estimativas”.

Esse entendimento de toda a empresa sobre o que o sistema faz é uma forma de capital também. É o “porquê” do “como” do código.

Conclusão

Como resolvemos o problema de software com bugs sendo entregue aos clientes? Certificando-se de que o teste não é visto como algo “apenas os desenvolvedores se preocupam”.

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