{"id":311,"date":"2009-09-07T23:59:30","date_gmt":"2009-09-07T22:59:30","guid":{"rendered":"http:\/\/www.dtsato.com\/blog\/?page_id=311"},"modified":"2009-09-08T00:16:42","modified_gmt":"2009-09-07T23:16:42","slug":"introduzindo_desenvolvimento_orientado_comportamento_bdd","status":"publish","type":"page","link":"https:\/\/www.dtsato.com\/blog\/work\/introduzindo_desenvolvimento_orientado_comportamento_bdd\/","title":{"rendered":"Introduzindo Desenvolvimento Orientado por Comportamento (BDD)"},"content":{"rendered":"

Esta \u00e9 uma tradu\u00e7\u00e3o do artigo Introducing BDD<\/a>, escrito por Dan North<\/a> e traduzido por Carlos Vilella<\/a> e Danilo Sato<\/a><\/em><\/p>\n

Eu estava com um problema. Ao usar e ensinar pr\u00e1ticas \u00e1geis como Test-Driven Development (Desenvolvimento Orientado por Testes ou TDD) em diferentes projetos, acabava topando sempre com as mesmas confus\u00f5es e desentendimentos. Programadores queriam saber por onde come\u00e7ar, o que testar e o que n\u00e3o testar, quanto testar de cada vez, como dar nomes aos testes e como entender a causa de uma falha.<\/p>\n

Quanto mais eu me aprofundei em TDD, mais eu senti que minha pr\u00f3pria jornada n\u00e3o tinha sido um processo gradual e cont\u00ednuo (“p\u00f5e a cera, tira a cera”<\/em>), mas sim uma s\u00e9rie enorme de becos sem sa\u00edda. Me lembro de pensar muito mais em \u201cse pelo menos algu\u00e9m tivesse me dito isso!\u201d<\/em> do que \u201cuau, uma porta se abriu\u201d<\/em>. Decidi que tinha que ser poss\u00edvel apresentar TDD de uma maneira que mostra diretamente as qualidades da t\u00e9cnica, evitando todas as armadilhas.<\/p>\n

Minha resposta \u00e9 o Behaviour-Driven Development<\/strong> (Desenvolvimento Orientado por Comportamentos ou BDD). Esta t\u00e9cnica evoluiu a partir de pr\u00e1ticas \u00e1geis estabelecidas e seu intuito \u00e9 torna-las mais acess\u00edveis e efetivas para times que est\u00e3o dando seus primeiros passos no desenvolvimento \u00e1gil de software. Com o tempo, BDD se amplout o cen\u00e1rio mais abrangente de an\u00e1lise \u00e1gil e testes de aceita\u00e7\u00e3o automatizados.<\/p>\n

Nomes de m\u00e9todos devem ser frases<\/h3>\n

Meu primeiro \u201caha!\u201d aconteceu quando me mostraram um utilit\u00e1rio extremamente simples, agiledox<\/a>, escrito pelo meu colega Chris Stevenson. O agiledox l\u00ea uma classe de testes do JUnit e exibe o nome dos m\u00e9todos em forma de frases, ent\u00e3o um conjunto de testes assim:<\/p>\n

\r\npublic class CustomerLookupTest extends TestCase {\r\n  public void testFindsCustomerById() {\r\n    ...\r\n  }\r\n  public void testFailsForDuplicateCustomers() {\r\n    ...\r\n  }\r\n}\r\n<\/pre>\n
fica mais ou menos assim:<\/p>\n
\r\nCustomerLookup\r\n- finds customer by id\r\n- fails for duplicate customers\r\n- ...\r\n<\/pre>\n
A palavra \u201ctest\u201d \u00e9 removida tanto do nome da classe quanto do nome dos m\u00e9todos e o texto do nome do m\u00e9todo \u00e9 convertido de camel-case para uma frase comum. Isso \u00e9 tudo que o agiledox faz, mas seu efeito \u00e9 impressionante.<\/p>\n
Os desenvolvedores descobriram que ele poderia ajud\u00e1-los gerando pelo menos uma parte da documenta\u00e7\u00e3o e come\u00e7aram a nomear os m\u00e9todos de teste com frases que faziam sentido. Melhor ainda, eles descobriram que quando escreviam nomes de m\u00e9todos na linguagem do cliente, os documentos gerados faziam sentido para o cliente, analistas e testadores.<\/p>\n
Um modelo de frase simples mant\u00e9m o foco do teste<\/h3>\n
Ent\u00e3o eu descobri a conven\u00e7\u00e3o de usar a palavra “deveria” (“should”<\/em>) nos m\u00e9todos de teste. Este modelo \u2013 a classe “deveria”<\/em> fazer alguma coisa \u2013 implica que voc\u00ea s\u00f3 pode definir um teste para uma classe espec\u00edfica. Isso mant\u00e9m seu foco. Se voc\u00ea estiver escrevendo um teste cujo nome n\u00e3o se encaixa no modelo, ent\u00e3o pode ser que o comportamento que voc\u00ea est\u00e1 tentando testar pertence a outro lugar.<\/p>\n
Por exemplo: eu estava escrevendo uma classe para valida\u00e7\u00e3o de entrada de uma tela. A maioria dos campos eram detalhes comuns de um cliente \u2013 nome, sobrenome, etc. \u2013 al\u00e9m de campos para data de nascimento e idade. Eu comecei escrevendo um ClientDetailsValidatorTest<\/code> com m\u00e9todos como testShouldFailForMissingSurname<\/code> e testShouldFailForMissingTitle<\/code>.<\/p>\n
Comecei a desenvolver a l\u00f3gica para calcular a idade e entrei num mundo confuso de regras de neg\u00f3cio: e se a idade e a data de nascimento forem preenchidas mas n\u00e3o coincidirem? E se a data de nascimento \u00e9 hoje? Como calcular a idade se tudo que eu tenho \u00e9 a data de nascimento? Eu estava escrevendo testes com nomes cada vez mais complicados para descrever tais comportamentos, ent\u00e3o eu decidi move-los para outro lugar. Isso me levou a criar uma nova classe, AgeCalculator<\/code>, com seu pr\u00f3prio AgeCalculatorTest<\/code>. Com todos os comportamentos relacionados ao c\u00e1lculo de idades movidos para a calculadora, o validador s\u00f3 precisava de um teste nessa \u00e1rea para garantir que ele interagia corretamente com a calculadora.<\/p>\n
Se uma classe est\u00e1 fazendo mais de uma coisa, eu geralmente tomo como indica\u00e7\u00e3o que eu devo introduzir outras classes para fazer um pouco do trabalho. Eu defino o novo servi\u00e7o como uma interface descrevendo o que ele faz, e passo o servi\u00e7o atrav\u00e9s do construtor da classe:<\/p>\n
\r\npublic client ClientDetailsValidator {\r\n  private final AgeCalculator ageCalc;\r\n    public ClientDetailsValidator(AgeCalculator ageCalc) {\r\n      this.ageCalc = ageCalc;\r\n  }\r\n}\r\n<\/pre>\n
Esta maneira de conectar os objetos, conhecida como \u201cinje\u00e7\u00e3o de depend\u00eancias” (dependency injection<\/a>), \u00e9 especialmente \u00fatil em conjunto com mocks.<\/p>\n
Um nome de teste expressivo ajuda quando o teste falha<\/h3>\n
Depois de um tempo, descobri que quando eu modificava c\u00f3digo que fazia um teste falhar, eu podia olhar para o nome do m\u00e9todo de teste e identificar qual o comportamento esperado do c\u00f3digo. Tipicamente, uma das tr\u00eas coisas havia acontecido:<\/p>\n