Certamente, quem trabalha, ou já trabalhou com desenvolvimento do software, testes ou até gerenciamento de projetos e outros relacionados a tecnologia da informação, com certeza, em alguma etapa destas jornadas, já se deparou com essas duas siglas relacionadas no tema deste arquivo em algum momento, quer seja brevemente, ou mesmo mais a fundo, como no caso de equipes de teste, QA e afins. O BDD e o TDD são temas amplamente estudados e acatados em livros, blogs, artigos, vídeos e outras mídias, espalhados por fóruns de discussão, as vezes lembrados em forma de microcosmo em reuniões de brainstorm e Design Thinking, ou mesmo referenciados em processos de compliance dentro de status report. Em tese, são fáceis de serem diferenciados… Em tese, porque, geralmente causam bastante discussão a respeito de suas bases, seu uso e abordagem. E é por aí que vamos seguir neste artigo, tentando expor esta problematização e, quem sabe, senão dermos a resposta, gerarmos perguntas cada vez mais coerentes para outrem desvenda-las.
Começando do começo: O que são afinal TDD e BDD?
O TDD, sigla para Test Driven Development, ou Desenvolvimento Orientado a Testes foi criado lá pelos idos dos anos 90 tendo como missão, um tanto arrojada é claro, de fazer com que a codificação se tornasse mais simples e, em função disso, pudesse ser testada de forma mais simples, objetiva e ágil.
Foi claramente cozido no caldeirão processual da época de onde saíram os primeiros conceitos de processos ágeis e afins, comuns nos dias de hoje. Ele se baseia em uma formula muito eficaz e inteligente de se estruturar os testes, na materialização de uma cadeia, dividida por três etapas, que representariam as fases da criação deste teste simples: O Vermelho, onde seria escrito o teste mais “cru”, que com certeza daria erro, mas este justamente seria o intuito. O Verde, onde o código, a partir do anterior, seria construído já com o processo corrigido para que passasse no teste e, por fim, mas não menos importante, o refactor, ou refatoração, onde o teste, mesmo corrigido, passaria por um “pente fino” uma limpeza em seu código para deixa-lo mais simples, elegante e performático.
Mas o grande pulo do gato deste processo era justamente que o mesmo era feito antes de se ter o código pronto, e muitas vezes antes até de documentações mais complexas do que se deveria ser codificado, ou seja, testar antes para se ter o conceito do que pode dar errado, bem como iniciar um processo mais eficaz de cobertura de código ainda nos primórdios do desenvolvimento.
Já o BDD, Behavior Driven Development ou Desenvolvimento Orientado ao Comportamento, como até já fora explicado em posts anteriores, tem um contexto um tanto diferente, sendo este criado por volta de 2003 como uma resposta ao TDD, que era bem mais técnico. No BDD entram os conceitos de colaboração entre as áreas de tecnologia e de negócio, com o intuito de realmente trazer este valor do negócio em si e seus benefícios, que é o fim para todo o processo de desenvolvimento afinal. Para isso também entra o conceito de linguagem ubíqua, ou seja, a linguagem comum que é normalmente utilizada pelo negocio em si, fazendo com que o foco deste desenvolvimento seja muito mais afinado ao que o negócio precisa, criando um propósito muito mais definido do que simplesmente criar códigos. Com a inserção do BDD também entram em cena processos como o DDD, Domain Driven Design ou Desenho orientado a Domínio (tema para outro artigo talvez), processo esse onde, em resumo, a modelagem do sistema também sofre uma abordagem focada no negócio e na linguagem ubíqua, no Core Business, também ajudando a integrar as equipes de desenvolvimento ao entendimento do negócio em si. Neste caso o teste é construído depois da codificação, geralmente já com um processo mais documentado de histórias de testes até com jornadas bem definidas, ou seja, com uma jornada definida não só pelo sistema, mas pelo negócio, com interfaces gráficas ou não, mas já realmente estabelecendo o comportamento dos diversos níveis de usuários que possam existir e suas experiências especificas.
Mas e aí? Qual é o melhor? Como aplicar?
Observo muito esta pergunta entre fóruns de discussões, feita tanto por desenvolvedores, testadores e profissionais voltados a processos, até porque é passível de se entender a dúvida, já que também existe muita informação que tenta justificar um sobre o outro, principalmente quando o intuito é ganhar tempo nos processos de qualidade e testes de um modo geral dentro de um projeto. Mas é aí que, na minha humilde opinião, está uma das maiores armadilhas dentro de um projeto onde está sendo feito um desenvolvimento que, obviamente, necessitará de testes, geralmente, de formas variadas: Não gerar um plano de testes adequado. Ainda não é a hora de responder à pergunta sobre qual seria o melhor, e sim de problematizar ainda mais a situação. Se faz necessário.
Em muitos casos, muitos projetos em que trabalhei, quer seja de forma mais direta ou indiretamente, quando o assunto, seja ele no nível de como serão os testes, ainda nos estágios iniciais dos referidos projetos e mesmo após acaloradas e, a princípio, bem embasadas defesas, uma hora ou outra chega-se à conclusão magica: – “Vamos reduzir o número de testes para assim ganhar mais do tempo do projeto para o que mais importa: O desenvolvimento! – ”Afinal, para que testar demais? Vamos gastar muito dinheiro alocando gente para testar telinha?” – “O desenvolvedor mesmo pode fazer uns testes básicos” ou ainda, uma das minhas preferidas, a formula mágica, o Santo Graal das decisões de testes, a Magnum Opus: – “Só vamos fazer testes automatizados porque é mais rápido. Fazer teste funcional é perda de tempo e dinheiro”
Se você, caro leitor, que leu até agora, não entendeu ainda onde quero chegar e porque raios a conversa começou com TDD e BDD e chegou a este nível? Se acalme, pois, agora tudo será esclarecido. Lembre-se de que eu falei que iria problematizar, já que uma das formas de se entender melhor alguma situação é justamente antes tentar problematiza-la para atacar seus pontos principais, tentar ir ao amago do problema. Pois bem.
Com algumas das barbaridades ditas em forma de frases (sim eu já ouvi isso pessoalmente em várias ocasiões, não é ficção) acima citadas que escolhi para ilustrar essa parte do artigo, uma constante fica clara que é indiferença, a diminuição e , as vezes a repulsa em se testar, ou investir tempo, esforço e dinheiro, em processo de testes, mesmo neste nosso século 21 que fala tanto em transformação digital. Um fato é que (me perdoem a maioria dos desenvolvedores. Caras, eu gosto de vocês, sério) existe um comportamento, muitas vezes velado, onde alguns poucos desenvolvedores gostam de testes, uma outra parcela, um pouco maior, os aceita mesmo que com ressalvas, e a grande maioria os detesta, afinal de contas, ninguém gosta de tratar bugs não é, ou mesmo ninguém que codifica, na verdade gosta muito de que digam que seu trabalho deu algum problema. Essa richa velada e cultural, que não é nova e se iniciou desde o início da computação, geralmente consegue força, pendendo contra os testes, iniciando com estes desenvolvedores que não querem ficar “tratando Bugs desnecessários”, com a gerência de projetos que atua com prazos apertados e orçamentos contados centavo a centavo e que não quer se indispor com os patrocinadores, bem como de decisões “top down” de altas diretorias, que até não deveriam estar tanto envolvidas em projetos mas que tem acordos específicos em seus níveis que nós mortais nem temos ideia, mas que precisam ser cumpridos. Deste turbilhão processual e burocrático, um dos resultados é justamente esta “adequação” onde os testes são reduzidos e, para ao menos constar que existem processos de qualidade (o compliance vai perguntar com certeza!) surgem embates diversos com o intuito de reduzir estas horas, tais como: “Quem é melhor para usar e fazer testes mais rapidamente? BDD, TDD?”
Sacaram? Viram como uma pergunta simples como se um é melhor que o outro pode levantar tal situação? ECCE HOMO! Eis a nossa cultura corporativa do século 21! Ou, ao menos, boa parte dela…
Agora, deixemos esse embate um pouco de lado e vamos dissecar o BDD e TDD, bem como encaixa-los em um processo coeso de qualidade ponto a ponto em um projeto, a um ponto onde vamos verificar que, de repente, compara-los não pode ser uma boa ideia.
Como foi dito anteriormente, no TDD, o teste é feito ANTES de se ter sequer o código, onde um teste é criado para se tentar simular um comportamento sistêmico, partindo de seu erro, sendo esse erro “corrigido” e refinado a ponto de se tornar um código limpo. Portanto, é um processo muito subjetivo, especulativo, byroniano até, e que, apesar disso, contribui sim para preparar melhor processo de codificação, em nível de código e de funcionamento do sistema como um todo. Já o lado não tão legal dessa ótima ideia é que, quando o sistema começa ser codificado, obviamente surgirão mudanças, o que é normal, e estes testes feitos anteriormente podem perder parte ou toda sua força, dependendo das alterações pós codificação. Obviamente fica a questão do código que, mesmo assim, em sua essência, já ficou mais limpo, ou ao menos o modo de como faze-lo mais claro.
Mas espere aí, falei em TDD e falei em comportamento? Isso não é coisa do BDD (Behavior)? Não! Pois, em seu amago, TDD TAMBÉM É A RESPEITO DE COMPORTAMENTO! Porém, uma forma diferente de comportamento, um comportamento do sistema em si, de como sua mecânica vai comportar mais adequadamente as regras do negócio que, mais a frente, serão testadas pelo BDD, com uma jornada de usuário que vai preencher a ponta faltante do que realmente precisa ser testado, isso em forma de toda uma gama de tipos de testes diferentes que vão levar estes conceitos em conta, desde testes unitários (antes que alguém me xingue, sei que não são nem TDD nem BDD, mas, esses sim sendo feitos pelo desenvolvedor, ajudam a somar possíveis erros detectáveis entre os testes sendo feitos com TDD e os com BDD onde os módulos e funções mais simples também já passaram por uma verificação prévia e uma chancela de seu criador, aumentando a segurança do código em seu nível mais básico) testes funcionais manuais, onde o pente fino é passado por um tester devidamente treinado e os Bugs mais grosseiros e em maior quantidade das funcionalidades são identificados e resolvidos, bem como em um nível mais alto de maturidade, com o código bem mais limpo e seguro, os mesmos testes manuais já executados e bem sucedidos vão passar por uma triagem e, entre eles, serem escolhidos os testes que podem ser automatizados para, por exemplo, uma regressão do sistema inteiro ou seu caminho critico, que vai ratificar um processo posterior de teste de aceitação do usuário já com o chamado “release candidate” onde os mesmos só vão precisar validar a regra do negócio que será sustentada por este sistema, antes da ida para a produção em si. Isso tudo só para dar um exemplo de coerência de processo básico de qualidade, a ponta de um iceberg bem maior que nunca é visto em sua plenitude. Mas quem o ver, sai ganhando.
Em resumo e em conclusão, eu disse tudo isso para constatar que não tem que se preocupar em escolher um ou outro, pois TDD e BDD, embora talvez em seu primórdio, um tenha surgido para substituir o outro, muitas outras pessoas antes de mim descobriram que, na verdade, eles se complementam e se ajudam para, em conjunto com outras técnicas e processos de qualidade, elevar a própria qualidade do código, a um passo necessário de cada vez, desde sua ideação até a entrada do sistema em produção, e com olho e foco principal no negócio em si que é onde se sustenta a necessidade sistêmica.
Parece muito obvio e até simples, não é? Pois é, mas, hoje em dia, as vezes para explicar algo assim tão simples, temos que passar por todo um contexto ou uma problematização para poder mostrar este simples, já que o diabo está nos detalhes e, neste caso, a escolha de uma metodologia, um processo especifico, ou melhor, a perda de tempo nesta, de forma errônea, podando outros processos complementares e necessários somente para justificar uma cultura também errônea, que desencadeia uma sucessão de erros e, na pratica, gera sistemas ruins em produção, experiências ruins para os usuários, perda financeira e imagem para a empresa, onde, por fim, o investimento inicial, com a “economia” nos testes, se torna um custo altíssimo na resolução de problemas em produção, salas de guerras e horas extras intermináveis nos finais de semana. Já dizia Clarice Lispector: -“ O Obvio é a verdade mais difícil de se enxergar”
Fernando Gomes
Posts Relacionados
