Práticas de desenvolvimento – TDD, BDD e DDD – Blue</>Dev
Como todos sabemos o software é classificado como a parte lógica de um computador, é ele que envia um conjunto de instruções para executar uma determinada tarefa. Sistemas de software tem crescido e são aprimorados cada vez mais, a maioria das empresas precisam ou precisarão de um sistema para auxiliar em diversas áreas da companhia.
Existem sistemas dos mais simples aos mais complexos, tendo uma coisa em comum: sua construção pode ser gerar vários problemas, sendo a maioria das vezes causado pela falta de comunicação com o cliente. Os requisitos podem não ser completamente entendidos pelos desenvolvedores da forma que o cliente espera o produto, dessa forma quando o software for entregue vai existir uma diferença do que foi entregue com o que o cliente gostaria. E isso é mais comum do que pensamos.
Hoje em dia a forma como o desenvolvimento de uma aplicação é feita mudou bastante, antes havia apenas um programador realizando suas tarefas, atualmente os projetos possuem uma equipe de especialistas para cada área necessária como desenvolvedor, gerente de projetos, arquiteto, especialista em banco de dados, analista de requisitos, engenheiro de qualidade, entre outros. Porém, mesmo com tantas pessoas desenvolvendo suas atividades para o mesmo produto final, as reclamações dos clientes ainda são as mesmas: Por que a demora? Por que o produto não foi entregue da forma que eu pedi? Por que tem tanta coisa que eu não utilizo? Por que os erros não podem ser encontrados antes da entrega?
Ter um processo bem definido e aplicar práticas de desenvolvimento ajuda a evitar retrabalho, porém hoje em dia existem várias metodologias e práticas de desenvolvimento, tornando-se fundamental analisar suas necessidades no projeto e identificar qual prática se encaixa mais com sua realidade, nesse artigo iremos entender um pouco mais sobre Desenvolvimento Orientado por Testes (TDD) , o Desenvolvimento Orientado por Comportamento (BDD) e o Desenvolvimento Orientado por Domínio (DDD).
O TDD se baseia em ciclos de repetições, no qual primeiro é escrito o caso de teste automatizado para uma funcionalidade e só depois o software começa a ser desenvolvido, porém antes de iniciar o trabalho para a próxima funcionalidade existem alguns passos onde o que já está pronto é passado por boas práticas de desenvolvimento. Assim, o ciclo de desenvolvimento nesse caso é:
Um caso de teste automatizado para uma determinada funcionalidade é escrito
Execute os testes, todos vão falhar, pois ainda não existe nada do software desenvolvido
A parte da aplicação que já possui os testes prontos no primeiro passo é desenvolvida
Realize os testes e veja se está tudo funcionando
Após os testes passarem, o código é refatorado sem alterar seu funcionamento, garantindo que esteja limpo e menos acoplado
Iniciamos o caso de teste para uma nova funcionalidade
Em um modelo de desenvolvimento"normal" o programador demora muito tempo até identificar quais os bugs existentes, realizando as correções somente quando terminar toda a fase de desenvolvimento causando na maioria dos casos atraso na entrega do produto final.
Utilizando o TDD o feedback sobre os resultados entregues devem ser constante, dessa forma o código pode ser escrito e corrigido logo em seguida evitando atrasos.
Como qualquer prática existe seus prós e contras, os benefícios de usar o TDD são:
Praticamente para todo código da aplicação existente vai haver um teste
Feedback mais rápido sobre a qualidade do software
Você consegue identificar como o cliente irá utilizar as funcionalidades
O tempo total do projeto é menor, ou seja, a entrega do produto é mais rápida
Menos quantidade de bugs
Menor tempo debugando o código para encontrar onde está o erro
Como é um processo diferente da realidade dos projetos, existe uma resistência para começar e aceitar essa nova metodologia
Os casos de testes são parte da manutenção e não apenas o software em si
Os testes precisam ser bem escritos
É preciso desenvolver apenas o que está escrito nos casos de teste, caso precise de alteração um novo caso de teste precisa ser escrito ou o antigo precisa ser modificado para só então alterar a aplicação.
Vale lembrar que para as classes que tem comunicação com o banco de dados não é interessante escrever e aplicar esses testes antes do desenvolvimento, pois não existe uma grande diferença em fazer isso depois, uma vez que suas funcionalidades não interferem tanto na parte de design.
Outro modelo é o BDD como o próprio nome já fiz foca no comportamento do software, integrando o design com a parte lógica. Nessa prática, os testes ainda são escritos no inicio, porém os caso de teste são escritos em sua própria língua nativa em combinação com a linguagem ubíqua (linguagem comum entre os especialistas, usuários, e todos os outros membros da equipe para falar a respeito do domínio, onde todos conseguem entender do que determinada palavra está se referindo). Através dos testes em BDD já conseguimos ter uma ideia do comportamento de cada funcionalidade e não apenas um se está funcionando ou não.
Geralmente a documentação segue um modelo padrão que possui o cenário, dado quando e então. Como o exemplo abaixo:
Cenário: sacar 100 reais na minha conta corrente
Dado que: Eu possuo uma conta corrente com o saldo de 2 mil reais
Quando: Eu sacar 100 reais da minha conta corrente
Então: Eu deveria ter um saldo de 1900,00 reais no banco
E: Eu deveria ter 100 reais em dinheiro na minha carteira
Só após estar escrito essa documentação para essa funcionalidade, o teste automatizado é feito através de especificações executáveis, validando o software e mantendo uma documentação atualizada e funcional.
Algumas vantagens do BDD são: utilizar linguagem natural para especificar o comportamento das funcionalidades, o próprio cliente é quem define o comportamento, uso de estórias para os casos de teste, os sprints podem ser definidos no inicio do projeto, os testes são mais fáceis de serem compreendidos.
Algumas ferramentas muito utilizadas são:
Cucumber: Executado em Java, .NET, Ruby, Flex ou qualquer outra aplicação através do Silenium ou Watir
Easyb: Groovy/Java
Instinct: Java
Gspec: Groovy
Behat: PHP
Bdoc: Extrai a documentação de testes unitários
CppSpec: C++
As desvantagens em se usar o desenvolvimento orientado por comportamento são bem parecidas com as do TDD, se destacando:
Manutenção não apenas no código, mas também nos casos de teste
Inicio do desenvolvimento pode ser mais lento
Em alguns casos o custo pode ser mais alto
E por fim o Design Dirigido a Domínio (DDD) em inglês Domain Driven Design, é uma forma de desenvolver um projeto/sistema focando no seu domínio onde encontramos toda a regra de negócio.
Quando dividimos em camadas temos: o domínio onde pertence toda a lógica do software, localizado entre a infra-estrutura que fornece toda a comunicação entre as partes, e a aplicação. Para que o DDD aconteça de forma correta é de extrema importância que cada uma das partes seja responsável apenas por suas atividades, se isolando das demais.
Uma vez que cada área do projeto tenha um conhecimento especifico diferente dos demais, nesse modelo, assim como o desenvolvimento guiado por comportamento (BDD), é importante que exista linguagem ubíqua, onde possa existir o mesmo entendimento para todos.
Visto que toda a regra de negócio se encontra no domínio, essa camada é constituída pelos seguintes componentes principais:
Entidades: Deve possuir uma identidade. Ex: um cliente, uma pessoa.
Objetos de Valor: Possui atributos e não identidade. Ex: tipos de conta.
Repositório: Sua funcionalidade é armazenar e recuperar as informações em forma de objeto, sem possuir regra de negócios.
Fábricas: Criam objetos
Serviços: São as tarefas que podem ser executadas sem uma entidade ou objeto de valor específico.
Normalmente o DDD é indicado para projetos complexos com várias regras de negócio, em alguns casos utiliza esse modelo em união com o TDD, para software simples esse modelo não é indicado.
Como eu disse no inicio existem vários métodos que podem auxiliar no projeto de um desenvolvimento de software, basta entender a sua necessidade e ver qual se aplica melhor.