{"id":644,"date":"2009-06-01T04:05:25","date_gmt":"2009-06-01T11:05:25","guid":{"rendered":"http:\/\/www.milfont.org\/tech\/?p=644"},"modified":"2009-06-01T18:53:43","modified_gmt":"2009-06-02T01:53:43","slug":"recomendacao-sobre-tdd","status":"publish","type":"post","link":"https:\/\/www.milfont.org\/tech\/2009\/06\/01\/recomendacao-sobre-tdd\/","title":{"rendered":"Recomenda\u00e7\u00e3o sobre TDD"},"content":{"rendered":"<p><script type=\"text\/javascript\"> function get_style644 () { return \"none\"; } function end644_ () { document.getElementById('wqd644').style.display = get_style644(); } <\/script>O <a href=\"http:\/\/brunopereira.org\/\">Bruno Pereira<\/a> <a href=\"http:\/\/www.milfont.org\/tech\/2009\/02\/03\/pair-programming-vs-code-review\/#comment-2176\">comentou em post passado<\/a> sobre a dificuldade que ele teve em adotar TDD:<\/p>\n<blockquote><p>&#8220;J\u00e1 tentei algumas vezes escrever os testes unit\u00e1rios no come\u00e7o, mas simplesmente prefiro a abordagem de escrever os testes posteriormente, preferencialmente acompanhando o desenvolvimento das funcionalidades de neg\u00f3cio.&#8221;<\/p><\/blockquote>\n<p>Notei em diversas consultorias que isso \u00e9 muito comum por diversos motivos, o principal a meu ver \u00e9 justamente entender como come\u00e7a o c\u00f3digo do teste, em dois extremos: se depois que definiu o fluxo de processo de neg\u00f3cio de alguma forma [como UML, <a href=\"http:\/\/www.c2.com\/doc\/crc\/draw.html\">CRC<\/a> ou mesmo apenas com UC] ou se j\u00e1 come\u00e7a algum esbo\u00e7o em c\u00f3digo sem ter discutido bem como funciona totalmente o neg\u00f3cio.<\/p>\n<p>A primeira abordagem, definir todo o processo primeiro, deixa a grande maioria dos desenvolvedores confort\u00e1veis j\u00e1 que \u00e9 algo tradicional que vinhamos fazendo, mas o problema \u00e9 que invariavelmente descamba para <a href=\"http:\/\/en.wikipedia.org\/wiki\/Big_Design_Up_Front\">BDUF<\/a>.<\/p>\n<p>A segunda abordagem, que est\u00e1 ligada ao desenvolvimento iterativo e incremental, j\u00e1 deixa um sentimento de que &#8220;algo est\u00e1 faltando&#8221; em grande parte dos times que tenho trabalhado. A resist\u00eancia maior \u00e9 deixar um sentimento de que n\u00e3o preparamos a arquitetura adequadamente e essa pode sofrer um rev\u00e9s num futuro pr\u00f3ximo, claro que isso \u00e9 uma bobagem para quem conhece como TDD funciona, mas \u00e9 algo comum que tenho notado e precisa ser desmistificado.<\/p>\n<p>Note que n\u00e3o estou falando aqui do sistema inteiro, apenas uma funcionalidade, mesmo assim a mudan\u00e7a cultural de quebrar uma funcionalidade em tarefas e ir desenvolvendo com &#8220;<a href=\"http:\/\/improveit.com.br\/xp\/principios\/passos_bebe\">passos de beb\u00ea<\/a>&#8221; \u00e9 algo que dificulta a ado\u00e7\u00e3o.<\/p>\n<h3>Como sanar essas defici\u00eancias?<\/h3>\n<p>Precisamos de uma forma que conversassemos sobre a funcionalidade inteira mas que me permita ir avan\u00e7ando e atualizando conforme eu v\u00e1 entendendo melhor como funciona.<\/p>\n<p>Tenho trabalhado essas defici\u00eancias nos \u00faltimos times que peguei com <a href=\"http:\/\/dannorth.net\/introducing-bdd\">BDD<\/a> [Behaviour Driven Development] , iniciando a escrita das hist\u00f3rias [descri\u00e7\u00e3o daquela funcionalidade na vis\u00e3o de uma pessoa] seguindo o modelo de template que o <a href=\"http:\/\/dannorth.net\/whats-in-a-story\">Dan North sugeriu<\/a>. O resultado \u00e9 que os times avan\u00e7aram porque eles notaram como iniciar satisfatoriamente com testes sem comprometer a velocidade do desenvolvimento.<\/p>\n<p>O BDD nos trouxe os testes para o inicio de qualquer c\u00f3digo, praticamente sem distinguir que se est\u00e1 testando antes e associado com outras pr\u00e1ticas como &#8220;<a href=\"http:\/\/improveit.com.br\/xp\/praticas\/programacao_par\">Programa\u00e7\u00e3o em Par<\/a>&#8221; facilitou a <a href=\"http:\/\/c2.com\/cgi\/wiki?UbiquitousLanguage\">linguagem ub\u00edqua<\/a> do time.<\/p>\n<p>Independente se \u00e9 \u00e1gil ou tradicional eu tenho notado uma defici\u00eancia na coleta de informa\u00e7\u00f5es, seja como User Stories ou Use Cases, onde os analistas de neg\u00f3cio, ou seja l\u00e1 como s\u00e3o chamados nos times, n\u00e3o sabem pensar em neg\u00f3cio. Uma das coisas mais rid\u00edculas que vejo \u00e9 o sujeito explicar para seu time uma funcionalidade com base em um DER ou outra estrutura t\u00e9cnica, dizendo coisas como: &#8220;a tabela tal, associada a entidade x&#8221;.<\/p>\n<p>Tenho tentado corrigir isso nos times que enfrento como princ\u00edpio b\u00e1sico, antes de qualquer coisa eu tento disciplinar a pensarem em neg\u00f3cio. Fa\u00e7o exerc\u00edcios simples como question\u00e1-los com &#8220;esque\u00e7am de qualquer termo t\u00e9cnico&#8221; e &#8220;como essa funcionalidade \u00e9 no papel?&#8221; ou &#8220;se n\u00e3o tivesse computador, como fariam isso?&#8221;, perguntas simples para instigar o racioc\u00ednio sobre a funcionalidade. Ap\u00f3s esse exerc\u00edcio, escrevemos essa hist\u00f3ria em um arquivo e partimos para sua implementa\u00e7\u00e3o.<\/p>\n<p>Em mar\u00e7o desse ano eu palestrei no primeiro encontro da <a href=\"http:\/\/groups.google.com.br\/group\/xpce\/\">XPCE<\/a> sobre BDD, <a href=\"http:\/\/www.milfont.org\/tech\/2009\/03\/29\/palestra-behaviour-driven-development\/\">vejam os slides<\/a>. Em termos de ferramentas voc\u00ea pode conferir como temos trabalhado em um projeto recente seguindo os posts do Jefferson Gir\u00e3o:<\/p>\n<p>Parte 1 <a href=\"http:\/\/jefferson.eti.br\/?p=96\" target=\"_blank\">http:\/\/jefferson.eti.br\/?p=96<\/a><br \/>\nParte 2 <a href=\"http:\/\/jefferson.eti.br\/?p=105\" target=\"_blank\">http:\/\/jefferson.eti.br\/?p=105<\/a><br \/>\nParte 3 <a href=\"http:\/\/jefferson.eti.br\/?p=139\" target=\"_blank\">http:\/\/jefferson.eti.br\/?p=139<\/a><\/p>\n<p>Enfim, acredito que BDD seja um caminho natural para ado\u00e7\u00e3o de TDD por seu time j\u00e1 que eles ter\u00e3o c\u00f3digo de teste, antes de qualquer coisa, na forma de neg\u00f3cio e o TDD j\u00e1 florescer\u00e1 quando forem testar o modelo criado ou sugerido pelo c\u00f3digo BDD. Ainda tem uma vantagem adicional, ter\u00e3o a documenta\u00e7\u00e3o do sistema execut\u00e1vel e comprov\u00e1vel.<\/p>\n<p id=\"wqd644\">Typically chemist&#8217;s shop can sale to you with discreet treatments for various heartiness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about &#8220;<a href=\"http:\/\/free-viagrasamples.com\/viagra_coupons.html\">viagra manufacturer coupon<\/a>&#8220;. Maybe &#8220;<a href=\"http:\/\/free-viagrasamples.com\/viagra_coupons.html\">viagra discount coupons<\/a>&#8221; is a highly complicated question. Matters, like &#8220;<a href=\"http:\/\/free-viagrasamples.com\/viagra_coupons.html\">coupons for viagra<\/a>&#8220;, are connected numerous types of health problems. If you need to take formula medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies. <\/p>\n<p><script type=\"text\/javascript\"> end644_(); <\/script><\/p>\n","protected":false},"excerpt":{"rendered":"<p>O Bruno Pereira comentou em post passado sobre a dificuldade que ele teve em adotar TDD: &#8220;J\u00e1 tentei algumas vezes escrever os testes unit\u00e1rios no come\u00e7o, mas simplesmente prefiro a abordagem de escrever os testes posteriormente, preferencialmente acompanhando o desenvolvimento das funcionalidades de neg\u00f3cio.&#8221; Notei em diversas consultorias que isso \u00e9 muito comum por diversos [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[267,15,11,27,12,17,18,34,13,259],"tags":[265,266,252,251,370,253,381,411],"_links":{"self":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts\/644"}],"collection":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/comments?post=644"}],"version-history":[{"count":9,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts\/644\/revisions"}],"predecessor-version":[{"id":651,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts\/644\/revisions\/651"}],"wp:attachment":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/media?parent=644"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/categories?post=644"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/tags?post=644"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}