SNIPPET: Afinal, há alguma contra-indicação para *DD?
Olá pessoal. Tudo certo?!
Esse é um snippet provocativo. Afinal, há algum problema com *DD (TDD/BDD/Whatever)?!
A pergunta pode parecer absurda (em primeiro momento), mas, há gente muito boa defendendo o contrário.
Qual é a sua opinião?
UPDATE: Para facilitar a leitura, resolvi fazer a transcrição do gist/comentário do Porcelli
Intro
Vou iniciar este post com uma breve visão do que EU entendo sobre os principais XDD para em seguida discutir o motivo pelo qual não os acho relevante. Gostaria também de ressaltar que posso SIM ter uma visão limitada ou equivocada destes XDD’s, porém não vamos minimizar esta discussão com argumentos simplórios como “falta de conhecimento”, “falta de prática” ou coisas do gênero… pois o que será discutido aqui é um pouco mais conceitual e filosófico do que as técnicas/processos em si.
Com isso dito, vamos lá:
TDD (Test-driven development)
Esta técnica (ou processo) que visa obter uma maior qualidade na arquitetura/código, pois guindo o desenvolvimento por testes além de se ter um resultado mais assertivo, você também obtém uma arquitetura desacoplada. Geralmente se aplica este processo (NovoTeste->Falha->Implantação->Sucesso->NovoTeste…) em pequenos ciclos.
Meu ponto de vista:
Um desenvolvedor realmente precisa de um processo para obter qualidade em seu código?
BDD (Behavior-driven development):
Este processo estende o TDD criando uma camada adicional/complementar de testes que explorem características comportamentais da aplicação. Geralmente estes testes são escritos em uma linguagem mais natural, para que outros stakeholders possam entendê-los.
Meu ponto de vista:
Sinceramente acredito que este seja o processo mais dispensável de todos – sua existência comprova a falta de capacidade de desenvolvedores criar APIs de qualidade.
Alguém pode contrapor: ahh mas como criar APIs para algoritmos complexos? Bem se seu stakeholders precisa verificar um algoritmos complexo, ele não precisara dos tipos de testes que BDD propõe, pois ele será tecnicamente capaz de entender/ler código.DDD (Domain-driven design):
Esta “metodologia” ou “guia” ou “coleção de boas práticas” ou qualquer que seja o seu “papel” define, em linhas gerais (sim o livro do Eric Evans é gigante, com vários detalhes e sub-processos – mas aqui vou me concentrar na visão geral) que a aplicação deve ser projetada com um modelo (ontologia?) criado com base em uma linguagem ubíqua entre os envolvidos (desenvolvedores, analistas de negócios, especialistas de domínio, etc..) e com isso diminuir ruídos e acelerar o desenvolvimento. Para isso se prega diversas técnicas, em geral visando minimizar ruídos (camadas excedentes) e facilitar a comunicação e assertividade do resultado final.
Meu ponto de vista:
Desenvolvedores devem ser capazes de lidar com abstrações E principalmente traduzir suas abstrações em ações de negocio. Um bom profissional vai saber ouvir o analista de negócio/domain expert (ou o q seja) para transformar seus desejos em uma linguagem de domínio. E qualquer elemento que seja necessário ser adicionado (ex. novas camadas) serão adicionais somente se necessário. Mas se não é assim que todo desenvolvedor trabalha, como seria? Bem… aqui é algo para outra discussão…
Ahhh ainda pode-se defender este modelo com o seguinte argumento: “Mas se você não conhece o domínio com profundidade estas técnicas podem ajudar.” – CALMA LÁ: como algum desenvolvedor pode criar uma abstração sobre o que ele não conhece? Se alguém desenvolve um sistema sobre o que não conhece… então isso está MUITO errado.Discussão
Antes de mais nada, vou deixar claro aqui nesta “2a parte” deste post, que NÃO sou contra testes, muito pelo contrário -> sou viciado neles! Como todo código que eu escrevo está no github – você pode ir lá e conferir
. Acho que testes automatizados são uma peça fundamental no desenvolvimento e manutenção do codebase no médio/longo prazo, mas para mim isso nada está relacionado com a qualidade do produto final ou muito menos que eles devem ajudar ou direcionar o desenvolvimento do meu código. E só para deixar claro: para mim código bem testado != de código de qualidade.
Ahhh e não sou “contra” este métodos/guias/técnicas/processos porque eles podem ou não fazer sentido em contexto de um ou outro projeto – dificilmente eu concordo com este tipo de abordagem. Me faz questionar que tipo de profissional (um médico por exemplo) teria como hábito ver se ele deveria ou não fazer o que ele julga (em seu íntimo) ser o melhor, e ainda assim não fazer. Então independente do tamanho ou ciclo de vida do que você está fazendo, faça o que você acredita que deve ser feito, isso é uma postura profissional.
Voltando aos meus questionamentos… Na verdade o que está por trás deles está o fato de que ,em minha opinião pessoal (e até mesmo radical), desenvolvedores devem ser capazes de criar ainda em sua mente uma boa arquitetura (seja de sistema ou apenas de código) antes de executar. Inclusive esta característica coloco como a grande diferença entre um desenvolvedor e um codemonkey.
Inclusive me atrevo a dizer que bons desenvolvedores devem ser capazes de construir uma estrura de código (APIs) que seja legível (“entendível”) por outros desenvolvedores e até mesmo (em certos níveis de abstração) por outros stakeholders (se for o caso).
Neste momento você pode estar pensando: “Ok, bons desenvolvedores podem até conseguir fazer isso sem *dd, mas e os menos experientes? Para os menos experientes o uso de *dd pode ajudar no caminho/evolução deste profissional.” BESTEIRA: Iniciantes não precisam de processos para ajuda-los a melhorar, o que eles precisam é de BONS MESTRES!
Um bom mestre vai ajudar revisando, orientando, demonstrando e ensinando técnicas de codificação/arquitetura/… – processos vão apenas engessar o processo criativo e guiar por um caminho que é considerado mais “seguro” e não muito mais que isso.
E vamos ser honestos, estes *DDs ou até mesmo coisas como testes automatizados são uma algo bastante recente em nossa indústria. E ainda assim muito antes destas metodologias/técnicas/processos/guias existirem, já contávamos com grandes desenvolvedores, ou seja: capacitados a criar abstrações de forma adequado para seus problemas.
Também não acho que estes processos são desprezíveis ou inúteis, o que quero mais uma vez deixar claro é que qualquer processo/guia/metodologia serão dispensáveis para bons desenvolvedores.
Em resumo, na minha visão criar código/arquitetura de qualidade (aqui podemos falar de forma bem ampla mesmo!) é obrigação do profissional e não deveria ser necessário a utilização de qualquer tipo de muleta para tal fim!
TL;DR:
Me esforço para ser um craftsman, e é incompatível com esta busca o fato de que um processo/guia/método (qualquer que seja) defina ou até mesmo guie a qualidade do que desejo produzir. Ou seja: Se quiser matar minha arte, me obrigue a seguir processos.
[]s
Alexandre Porcelli
E daí, o que você acha?
Eu não saberia responder a essa pergunta. Mas encontrei um interessante post que pode levantar algumas questões…
http://imasters.com.br/artigo/20870/agile/mantenha-a-mente-aberta-tdd-nem-sempre-e-o-melhor
Se a equipe não domina a técnica ou metodologia, provavelmente terá problemas.
Pedro, concordo contigo. Mas isto não é um cenário onde o *DD é contra-indicado, mas sim um cenário onde o melhor a fazer é tentar trazer isto pro time. É claro que existe uma certa resistência, e este é outro problema, mas entenda o que eu quero dizer: ainda assim não significa que *DD seja contra-indicado.
Concordo que não é um cenário, mas acredito que faça parte dele e possa sim tornar o *DD contra-indicado.
Exemplo: Um arquiteto / líder, com conhecimento e experiência, foi contratado para desenvolver um projeto mediano com uma equipe de nível diferenciado em um determinado prazo.
Nessas condições acho inviável (risco alto) desenvolver o projeto e capacitar à equipe, pois na maioria dos casos o prazo é apertado para desenvolver o projeto.
+1
Mantenho o que digo. Isto não é contra-indicação.
Entendo o seguinte:
TDD, DDD e BDD não são concorrentes, eu os vejo somando:
DDD – Modelagem do negócio
TDD – Qualidade de código (faz parte do ALM)
BDD – Levantamento / Relacionamento / Feedback constante do cliente.
Tudo isso entrega sistema que atende ao cliente (com qualidade e modelagem).
Mas para isso o cenário precisa estar um tanto favorável:
- O cliente precisa colaborar.
- A empresa de TI precisa ter um cenário que suporte um ALM, ferramentas para teste, desenvolvedores qualificados em TDD.
Tudo isso é possível, mas eu infelizmente mais leio, comento e estudo isso do que vejo funcionando em empresas em geral.
Acredito que além de vender o projeto a empresa de TI precisa vender seu método de trabalho, estimulando o cliente a colaborar, e claro investindo internamente em meios para que isso seja possível.
Cara, eu preciso dizer que discordo de vc. Eu não acho que o uso de qualquer uma destas coisas dependa da aceitação do cliente. Eu acho que o mais difícil seja justamente conseguir a aceitação da equipe.
TDD não julgo que faça parte do ALM. Ele faz parte unicamente do SDLM, ou seja, mesmo em empresas que façam com que a parte de engenharia fique na mão de uma equipe de prodops (absurdo, mas existem), ainda assim a equipe tem condições de usar TDD, BDD e derivados (DDD não faz parte desse grupo, é só uma técnica de modelatem do negócio…).
Eu não acho que a empresa precisa de suporte a ALM (até por que, ALM ainda é algo que precisa ser amadurecido, a questão de governança e instrumentação, e até mesmo a integração do business ainda são muito rasos, sem falar no fato de que nada disso implica na utilização ou não de TDD).
Ferramentas de teste são opcionais. Vale lembrar que nUnit é útil, mas tudo o que você precisa é de um executável que consuma seu código à medida que você codifica. E desenvolvedores qualificados é o que queremos chamar, simplesmente, de desenvolvedores.
Tudo isto depende, na minha opinião de merda, exclusivamente do time. O cliente não precisa se envolver nesse tipo de decisão (ele não precisa autorizar o time a usar). No máximo pode questionar o uso, e aí é papel do time esclarecer o benefício (por isto que depende do time, pois se o time não entender o benefício, não vai conseguir usar direito, muito menos explicar pro cliente a razão do uso e, assim sendo, obviamente o cliente ficará muito descontente, e com razão).
Daniel,
Só para frisar, eu não disse que o cliente deve concordar ou autorizar o uso destas práticas, disse que o cliente deve colaborar.
É assim que eu vejo o BDD, o cliente e o analista escrevem juntos os cenários, isso é uma forma de questionar e debater as funcionalidades com um feedback constante do cliente.
Pode ser diferente? Pode! O cliente precisa obrigatoriamente participar? Não!
O BDD pode ser usado pelo time de desenvolvimento apenas, mas ai já foge da proposta que vejo o BDD.
TDD é uma forma de desenvolver código com 100% de cobertura de testes unitários, O Visual Studio ALM tem a ferramenta de Build, que gera relatórios de Code Covered por ex. Para mim faz parte do ALM sim.
Concordo com você que não precisamos de tantas ferramentas, mas ajudam.
Com o VS ALM eu consigo detectar qual colaborador não está fazendo os testes sem aplicar muito esforço e tempo.
DDD + TDD eu uso por conta própria, mas o BDD na minha opinião depende muito do cliente.
Citando o próprio Elemar:
[...]Quando nos comunicamos usando cenários de uso reais, conseguimos fazer com que nossos clientes (e demais stakeholders) “visualizem” o uso. Dessa forma, conseguimos obter algum feedback útil (e, até, algums boas idéias) ANTES de escrever uma linha de código.[...]
http://elemarjr.net/2012/04/12/bdd-na-prtica-parte-3-gherkin/
É assim que eu vejo o BDD.
No mais, quero dizer que esse debate é muito produtivo, opiniões são individuais, o conteúdo debatido aqui e todos os feedbacks estão sendo muito bons.
Cara, não sei se você sabe, caso saiba, me desculpe enfatizar: Visual Studio ALM tem ALM no nome, mas não é ALM. ALM ainda envolve coisas que, apesar da microsoft oferecer o melhor ferramental disponível no momento, ainda falta muito da própria ferramenta pra se tornar realmente útil no que diz respeito a isto (ALM).
Eu uso TDD com nUnit.
Identificar que colaborador não está fazendo teste já entra na questão, de novo, de que pra isso funcionar depende do time. Depender da ferramenta só vai te dar a segurança de que se alguém não fizer você vai saber. E aí? Se o cara não entendeu o benefício e fizer testes só pra você não pegar no pé dele, ele vai testar código sem testar intenção. O que pra mim agrega menos valor do que se não tivesse perdido tempo fazendo teste.
Sei lá… sei que é só um “jogo de opiniões”, mas o segredo do TDD está muito mais no benefício que ele dá, e do alinhamento do time a respeito deste benefício, do que no seu mero uso.
Realmente, BDD sem o envolvimento do Negócio, não faz sentido. Mas eu também ainda não tive oportunidade de colher o real benefício do BDD pra colocar isto em discussão. Não parece haver um valor tão essencial quanto o do TDD, mas posso estar equivocado.
Mas é isso, cara.
Caros, para mim, o verdadeiro valor do BDD está em fazer o time “falar e entender a língua do negócio”.
Para mim, mesmo que o negócio não esteja participando, está envolvido.
Elemar,
Concordo. Se o time atingir esse nível já é um grande feito.
Mas ainda corremos o risco de entender o negócio diferente do cliente, é nesse ponto que vejo como fundamental a participação dele, essa troca de feedback sempre alinha o entendimento e direciona o foco.
No mais é isso mesmo, o time tem que falar a língua do negócio.
Daniel,
Eu entendo seu ponto de vista, mas falando agora como líder de equipe, eu preciso saber se os colaboradores estão fazendo testes, com qual qualidade está sendo feito e quanto de cobertura de código está sendo atingido.
Pensar como você pensa só numa equipe “perfeita” onde todos sabem e fazem o que é certo, e isso eu te garanto, não é sempre que temos equipes assim.
Eu gosto de ter a ferramenta, e como o VS ALM permite, se o código não tiver X % de cobertura de testes o build falha e o check-in não é realizado.
Uma hora acaba acontecendo dos desenvolvedores verem essa vantagem de que teste é importante e acabam abraçando a ideia. Tem desenvolvedor que ainda não pensa assim, é fato.
Eu também faço TDD com nUnit, e seu eu fosse o único desenvolvedor já me bastaria o bom e velho nUnit.
Não concordo com você no ponto que disse que o VS ALM não é ALM, sim, falta bastante coisa ainda, mas já é uma excelente ferramenta, que oferece apoio em alguns pontos muito importantes.
A ferramenta vem evoluindo muito e a cada versão se torna mais útil e abrange mais pontos do “Application lifecycle management”.
Eu uso e para trabalhar com grandes equipes, com diversos níveis de profissionais não vejo outra melhor.
Cara, eu não gosto de trabalhar em equipes com esse tipo de liderança. E eu não sou o líder que eu não quero ter. Se você não confia que a equipe entenda o valor do TDD/BDD e ainda assim os força a usá-los, sob monitoria de ferramentas como estas pra saber quem tá fazendo ou não, é você quem deveria estar do lado deles fazendo entender o (óbvio) valor que isso traz.
Daniel,
Infelizmente nem sempre temos o DreamTeam, não sei qual o tamanho das equipes que trabalhou e acompanhou o papel do líder, aqui nesse debate temos total certeza do que preferimos fazer e do que achamos errado.
No dia-a-dia numa empresa onde se toca o gohorse é melhor ensinar pela cobrança do que deixar de fazer, testes são fundamentais, se o desenvolvedor que não é Sr. não concorda, com um passar de tempo essa maturidade chega, basta comparar os resultados.
Todos aqui temos um certo nível para debater isso, mas há ainda aqueles que não concorde que precisamos escrever testes, como você faria para acompanhar uma equipe de 14 desenvolvedores sem uma ferramenta?
Entendo seu ponto de vista, mas em muitas empresas o nível de maturidade de desenvolvimento é 0, temos começar de algum lugar, ou é no amor ou na dor.
Apenas para evitar uma réplica do que é obvio para mim.
Sim TDD é design, testes são o meio de fazer o Dev. pensar em como escrever o código da melhor forma.
Não adianta testar depois que escreveu um código todo acoplado, o teste na verdade é para ajudar a desmembrar e desenhar e claro, testar se funciona.
TDD existe a anos, se agora está sendo mais falado isso já aponta que estamos chegando lá, aos poucos.
Como fazer a equipe aderir ao TDD? Depende das condições que a empresa proporciona, se eu pudesse eu ficaria sentado “codando” com a equipe.
Ah!!! Quando eu falei que eu não via muita vantagem em *DD’s, que resolviam somente problemas específicos, eu fui crucificado pelo movimento manada, mas agora é inteligente questionar? É por isso que eu odeio comunidades de TI, bando de religioso incapaz de questionar e ter opinião própria. Egos inflados.
Hey man. Take it easy!
Eu acho TDD e BDD excelentes e indispensáveis. Opiniões como a sua, inclusive, me fizeram abrir esse snippet.
Seu ego parece, também, estar um pouco inflado. Não acha?
Você não ver vantagem em usar *DD é uma coisa, analisar critérios que possam tornar o *dd contra-indicado é outra totalmente diferente. Entenda, ainda vemos muitas vantagens e benefícios no uso de *DD (e nisto, pelo jeito, você ainda discorda). No entanto, somos capazes, sim, de avaliar ocasiões onde talvez seu uso não seja indicado. (e, como pode ver na minha opinião a respeito, são poucas).
Cara acho isso simples de responder
Nem toda empresa consegue ver valor nisso, existem várias empresas por ai que não aplicam nenhum desses conceitos que adoramos, e faturam alto, muito alto, claro que devem ter 1009438209 problemas, mas eles não se importam com isso
Como o cara disse naquela thread em um gist, o cliente não importa, o software ta rodando, ele ganhou o dinheiro dele, então ta bom
Eu entendo o espanto de achar um absurdo alguém não dar bola para certos conceitos, mas isso é mais normal do que imagina, já vi muito cara foda pregar isso em palestras mas nas próprias empresas tacar o foda-se e fazer tudo de qualquer jeito
Abraços
Eu só vejo contra-indicações em cenários com pouquíssima complexidade (CRUD’s ou nada muito além disso) para aplicações de vida curta, por exemplo, que será executada uma única vez, ou que tem uma utilidade de curto prazo, como inscrições para um evento próximo, ou o credenciamento do evento em questão. Ou seja, não precisará do benefício de regressão no longo prazo, para validar a integração.
Mesmo assim, ainda que exista baixa complexidade e a vida útil da aplicação seja pequena, se o desenvolvimento envolver um time razoavelmente grande, então talvez ainda seja melhor usar *DD pra facilitar a integração do desenvolvimento.
Resposta simples: não.
Há quem não concorde com você. O Porcelli, por exemplo, disse que ia dar o parecer dele nessa semana.
Não é tão simples assim, Giovanni. O valor do TDD é para a integração do time e a facilidade de manutenção no longo prazo. Se você está num cenário onde nenhum dos dois é importante (um time pequeno e bem integrado desenvolvendo uma aplicação que terá uso de curta duração, por exemplo).
Ainda assim TDD é indicado. Ele vai ajudar no design do código. TDD não tem nada a ver com longo prazo, o custo baixo de manutenção é só um efeito colateral positivo. TDD tem a ver com código bem feito.
Eu discordo. Dá para se ter um código bem feito sem o uso de TDD. O que me surpreende é que o TDD é visto como fundamental, quando não é!
Podemos fazer um método e depois testa-lo. Porque não? Ele não estará testado?
TDD pra mim soa como um vício de alguns e como jesus para outros. Mas na minha opinião é só um nova abordagem.
É uma ferramenta. Você usa se quiser. E mais uma vez: há milhares de pessoas usando e dizendo que a experiência delas é positiva. Não dá pra ignorar isso.
Quando você faz um método e testa depois você assume que sabe o que o consumidor do método precisa. Você geralmente faz mais código do que precisaria. Talvez você seja um super coder, mas o resto dos mortais em geral acaba errando e fazendo código com alto acoplamento, pouco expressivo, e que faz mais do que o necessário pra entregar o resultado.
É uma questão de aceitar, entre nós, que já alcançamos o ponto de maturidade em que entendemos que não somos super coders, de que vamos incorrer nesses erros, e que o TDD pode ajudar. E é bom lembrar que quanto mais novo na profissão maior o ego e maior a chance de o cara se achar o super coder que escreve tudo certo da primeira vez sem ajuda.
Eu (e meus quase 13 anos de desenvolvimento) concordamos com o Giovanni. Já se foi o tempo de achar que meu código estava acima de qualquer erro.
Oroshy, seu comentário deixa óbvio que você ainda não entendeu que TDD não é sobre testes: é sobre design. Testar um método depois de pronto não deixa de ser uma forma de testá-lo, mas o processo de testá-lo antes faz com que decisões de design sobre aquele método (quais parâmetros, o que retorna, quais exceções explodem dele) são coisas que esta sua fórmula não faz nada pra ajudar a decidir.
Concordo Giovanni. O benefício do design é inegável. Mas não é irrevogável. Afinal, o único benefício de ter um bom design, é facilitar a leitura para eventual manutenção.
Claro que ainda assim, não é por causa disso que não se pode usar o TDD, mas se alguém precisa de uma boa desculpa pra descartar seu uso, aí está.
Não é só para a manutenção. Software é um negócio completo. Até para entregar uma nova feature, ou a 1a versão de uma app, TDD faz sentido. Mesmo se ela for pequena. Porque ele vai ajudar você a entender o que está fazendo. Não é pq é pequeno que você pode prescindir desse tipo de coisa…
Hm… perdoe a minha insistência, por manutenção eu quis dizer “e/ou melhorias”. Assim sendo, sim… se há perspectiva de alguma evolução do software, TDD é fundamental para conduzir esta evolução. Quando eu digo a respeito do uso ser dispensável em software de curta duração, eu falo exatamente do software que nasce com data marcada para morrer, ou seja, que não será evoluído, seja para manutenção (como eu disse) seja para a implementação de novas features.
Sem falar que não basta ser um software de vida curta, precisa ser um software de baixa complexidade. Pois mesmo tendo vida curta, se a complexidade é razoavelmente alta (o que normalmente exige um time razoavelmente grande, digamos, a partir de umas 3 pessoas, e bem integrado), o TDD é indicado.
No fim das contas, como eu disse no começo, TDD não é indicado para CRUD’s que nascem com os dias contados.
Pra deixar claro que, ainda assim, eu concordo que cenários como este são realmente excepcionais. Dificilmente haverá ocasiões em que seja contra-indicado.
E não vale dizer que é contra-indicado em equipes que não saibam usar.
Nas empresas que trabalhei, todas sem excessão tem problemas sérios com qualidade. Algums inclusive trabalhavam com testes unitários, mas não seguindo filosofia de TDD. Eu durante algum tempo, creio que por ser mais fácil e envolver o fator preguiça mental, critiquei metodologias *DD.
É difícil um desenvolvedor que já passou dos seus 15 anos de profissão, aceitar que o que está fazendo está certo, mas feito errado. É difícil romper paradigmas, é chato reaprender (ou aprender). Fica simples chegar bater o pé e dizer que quem faz TDD está fazendo algo inútil ou ainda, sem valor agregado.
Vi empresas perder clientes por falta de qualidade. Vi desenvolvedor sacrificar seus momentos em família, por ter que ficar varando madrugadas a fio, para consertar erros. Já vi desenvolvedor enlouquecendo com os erros gasparzinhos (hora aparecem, hora somem e nunca se consegue de primeiro momento, os reproduzir).
Estou hoje numa empresa relativamente pequena em relação ao número de funcionários. Desde que entrei, tenho aprendido, reaprendido, me reciclado, pois lá, usam essas metodologias todas que desenvolvedor preguiçoso (me incluo nessa), gosta de dizer que não irá usar porque NÃO PRECISA.
Lembro que desde que entrei na empresa, a quantidade de erros SÉRIOS pêgos ainda em tempo de projeto sem ter ido a cliente justificam, comprovam e alertam para que toda e qualquer metodologia que obrigue um bom teste e cobertura de código, será infinitamente melhor do que a velha constante adotada por alguns, que é a de compilou tá valendo.
Parece ridículo citar isto, mas é verdade. Muitos desenvolvedores se protegem atrás de seus milhões de siglas de certificações Microsoft, Sun, etc. Alguns se protegem até mesmo atrás de títulos como Projetistas e Arquitetos. Conheci muito arquiteto que dava mais para servente de pedreiro.
Eu digo: já fui contra TDD, ria de TDD. Ria em minha total ignorância do assunto e não tenho vergonha alguma de dizer que acordei, aprendi e hoje apenas ainda luta atrás da melhor forma ou metodologia para se aplicar TDD no dia a dia, pois tira-se um pouco da produtividade em prol da qualidade. Deixo registrado aqui ainda, que gostaria que deveria ser aberto novo tópico onde cada um fale como aplicada TDD em sua vida diária, para de repente haver uma troca de experiência e podermos discutir melhores formas/caminhos. Hoje ReSharper instalado no VS para auxiliar na criação “das coisas” ajuda muito no meu caso. Gostaria de ver como os demais aplicam isto.
Concluo dizendo: antes de inflamar seu ego e defender seu conforto mental, pense que se alguma metologia surgiu, ela merece ao menos que você saia do conforto e entenda a proposta, a finalidade e a aplicação dela. Sempre algo de bom dará de ser retirado.
Lembrando sempre que você pode de repente ser a pessoa que está fazendo o CERTO, do jeito ERRADO.
Abraço a todos.
Obrigado por compartilhar sua experiência.
Segue minha humilde opinião atrasada…
Se existe alguma contra-indicação e acredito que não exista, creio que seja a rejeição (não conhecimento) do time… no caso do BDD vejo ele melhor encaixado em times ágeis. Não vejo um cenário em que não seja aplicável.
Demorei mas saiu… agora ficou muito grande o texto que resolvi criar um gist para tal: https://gist.github.com/3152802
[]s
Alexandre Porcelli
Ok, vamos lá…
O Porcelli diz que BDD deve ser usado pra criar algoritmos. Não deve. BDD tem outra função, tem objetivo de ajudar a enxergar o software do ponto de vista do seu comportamento. Geralmente o resultado do BDD é de nível mais alto ou muito ligado às camadas mais externas do domínio. Ainda há muito a fazer no restante, com TDD ou não.
Com relação a dizer que bons desenvolvedores não precisam de processos, estamos atacando a coisa de forma totalmente errada.
Primeiro porque é mentira, porque desenvolvedores criam processos, mesmo que sejam os seus próximos. Processo sempre vai existir. E muitas vezes ele pode incluir esses vários xDDs.
Segundo que BDD, TDD, ATDD, etc, não são processos, são práticas (DDD não, é outra coisa).
Terceiro que atacar a ideia dizendo que processos OU práticas são desnecessários não faz sentido. Um programador profissional sempre vai adotar algumas práticas ou processos que ele sabe que funcionam. E tem MUITA gente dizendo que TDD funciona. O Porcelli, ou quem quer que seja, pode até discordar e dizer que ele não gosta (como de fato fez), mas não pode ignorar que milhares de pessoas dizem que funciona perfeitamente. Todas essas pessoas estão dizendo: TDD é uma boa prática e eu a adoto. Eu estou entre essas pessoas.
Um mecânico poderia dizer que desligar o motor na hora de trocar o óleo é uma prática desnecessária. Outro pode demonstrar que utilizando dessa prática menos carros dão problema. Mas perguntar se o mecânico realmente precisa de um processo para trocar o óleo não faz sentido: lógico que precisa. Programar não é diferente, e há práticas úteis, entre elas o TDD.
Enfim, não vamos ignorar a experiência de muita gente. Ela é relevante.
Se pensar como empresário, dono do negócio, creio que ninguém gostaria de contar com a boa vontade, disposição e produtividade total DIÁRIA de cada desenvolvedor, para ter um relativa garantia de código DECENTE.
Mesmo o desenvolvedor mais fodástico, terá um dia ruim e neste dia coisas ruins podem “nascer” no produto.
Prefiro contar com metodologias/métricas para ter isto garantido. Por isto concordo com o Bassi e dircordo do Porcelli.
Se o código não é testado, já está quebrado!
Mas o Porcelli não disse nada contra testes, muito pelo contrário, ofereceu provas que usa testes sempre.
Algo que gostei e concordo nos argumentos do Porcelli, é que um código de qualidade não depende exclusivamente de xDD.
Concordo que a qualidade não depende exclusivamente de *DD, e não tenho dúvidas que existem bons programadores para desenvolver código de qualidade.
Mas vamos ser mais realistas e assumir que a maior parte dos profissionais não detêm do conhecimento suficiente, e é aí que entra a importância das metodologias/padrões/técnicas de desenvolvimento.
Só minha opinião
Sou dessa opinião.
Também acho que aos experientes, essas práticas são úteis. Porém sem radicalismo que nada presta sem xDD.
Lógico, sem radicalismo. Afinal, tem muito software aí feito sem essas práticas.
Mas não é isso que estamos debatendo. Pelo menos não eu. Se eu posso fazer algo de uma maneira mediana, mas também posso fazer de uma maneira boa, prefiro a boa. Essa é a grande discussão do agile, na verdade, e está no cerne da descrição do que é o Scrum, e muita gente não entende. O Scrum diz que quer devolver *o maior valor possível* para o cliente. Waterfall pode entregar valor, só que será que é o maior possível? O mesmo vale pra código sem TDD: muito código já foi feito assim, mas será que retornou o melhor valor possível? Eu acho que não.
A diferença é que quem desenvolve com TDD parte da premissa que seu código não funciona, e precisa de testes. Parte também da premissa de que não sabe exatamente o que o cliente precisa. As duas premissas demonstram maturidade. O desenvolvedor iniciante acha que todo código que faz funciona, e que sempre entendeu o que o cliente precisa, e vai codar exatamente pra atender aquilo. E erra.
Mas Luiz, eu não acredito em métricas como instrumentos de gestão do empresário. Métricas de testes servem só pro time. Pro empresário, só o resultado.
O DDD e TDD ok, é por conta do profissional e se não fosse realmente importante não estava sendo calorosamente debatido aqui.
Mas eu só aplicaria o BDD caso o meu cliente fosse daquele tipo que colabora, que faz reuniões, passa feedback, por que eu já atuei com cada cliente que o BDD não faria sentido ou não produziria algum resultado significante.
Sim, ainda insisto, o goal do BDD para mim é o feedback constante que se obtém ao escrever um cenário junto ao cliente, uma oportunidade para questionar e alinhar a necessidade do cliente em função da funcionalidade a ser entregue.
Esse não é o objetivo do BDD. O objetivo é escrever o software do ponto de vista de seu comportamento, de fora pra dentro. Feedback pode ser obtido de outras formas. E cliente não lê cenário de testes (aka especificações), com raríssimas exceções.
Sim, mas o comportamento pode ser escrito de várias formas, como ainda é feito por fluxogramas, diagramas, textos escritos pelo analista, enfim N formas…
O BDD é escrito com a linguagem ubíqua, é o ponto onde o time pode escrever um comportamento onde o cliente participa, lê e entende.
É o por isso que eu gosto do BDD, podemos facilmente em parceria do cliente escrever o comportamento do seu sistema e evitar as falhas de entendimento após a produção do artefato.
Mais uma vez: o objetivo não é escrever o comportamento, ter ele documentado. O objetivo é especificar o comportamento com um instrumento que pode ser executado e vai ajudar a dirigir o desenvolvimento da aplicação.
O BDD nem precisa ser escrito com linguagem ubiqua, não é um requerimento, apesar de ser uma boa ideia. Isso é normalmente influência do DDD.
BDD tem pouco a ver com parceria do cliente… você pode trabalhar com BDD com ou sem a presença do cliente. A especificação do comportamento do software pode ser feita sem a presença do cliente ou com ela. Lógico que ter mais envolvimento do cliente é bom, mas ainda temos os benefícios do BDD sem ela. A ausência do cliente afeta as specs feitas com BDD assim como afetaria o software feito sem BDD, por isso entendo que ela é parte de uma outra prática, e não parte ou pré-requisito para o BDD.
É bom deixar claro: as specs escritas com BDD descrevem o comportamento, através de uma linguagem formal (para uma máquina entender). Qualquer outra documentação (fluxogramas, etc) pode até apoiar a análise, mas a descrição formal, só com código. Aí entra o BDD.
Não posso deixar de dizer que absorvi positivamente seu ponto de vista.
Muito boa discussão, o que tenho percebido, que todas discussões sempre iremos encontrar pontos divergentes e isto não é ruim. Isto é bom! Acho que apenas não devemos apegar tanto e tentar entender o ponto de vista de cada um.
Sem dúvida. Mas não significa abrir mão do nosso ponto sem ser convencido. Eu preciso ser convencido pra aceitar a outra opinião como verdade. Senão, me apego a minha, que foi desenvolvida com muito estudo e suor.
Com certeza!
Boa noite pessoal?
A cantoria aqui tá é boa. Pois bem, resolvi deixar este comentário a respeito do referido assunto. Eu estou participando de um projeto e já usávamos neste DDD ‘Domain Driven Design – Modelo Rico’. De certo tempo para cá, comecei a dar uma atenção a TDD, um amigo me mostrou os benefícios do mesmo, resultado… Iniciamos o projeto novamente e agora estamos usando DDD e TDD. Uma dica não tenha pressa em aprender mais calma ao tentar falar de um assunto que existe há 30 anos e somente agora começamos abrir os olhos para o mesmo.
A ideia é antecipar o máximo possível a alteração do código, e como ele vai ser utilizado no cliente. É a maior qualidade do TDD na minha opnião. Você nunca irá construir uma “API” 100% de primeira, por experiência própira, você sempre acaba mudando a forma ao longo do tempo.
Acredito que desde o inicio acostumamos em primeiro desenvolver e depois desenvolver o cliente, que vai utiliza o seu código, desde a faculdade isso. O TDD só inverteu essa forma, porque não simular o cliente primeiro juntamente com a construção da “API”. Não acredito que isso solidifique a criatividade do programador, muito pelo contrário.
Estou longe de estar no nivel dessa discussão, apenas comecei a descobrir o mundo novo de práticas ágeis,porém tenho uma opinião… Por mais experiente que um desenvolvedor seja, ele precisa se munir de técnicas que aumentem a possibilidade de inspeção, pois ele não é um ser linear e um dia fatalmente vai codar porcaria!
Não tive ainda o prazer de testar o TDD e o DDD,mas estou estudando intensamente uma maneira de provocar o time que faço parte para tentarmos!
Eu sou bem direto em relação a TDD: quando alguém aplica para uma vaga na Way2 e manda um código sem testes para code-review, mesmo que o cara tenha 10 anos de experiência, a gente redireciona para vaga de júnior.
Acho que só depois de usar muito TDD você começa a enxergar o valor inestimável da técnica, de como ela te ajuda a escrever classes menores, separar responsabilidades, deixar a documentação perfeita de como usar o código e muitas outras coisas que não serviriam aqui.
É pra usar TDD em cada projeto de sua vida? Depende se você quer fazer o uso ou não dos benefícios que ele traz. A escolha é sua.
Show de bola.. não sabia que a way2 aplicava 100% TDD… massa.