Navegando pelo Linkedin me deparei com uma publicação do Vaughn Vernon (autor do Implementando Domain Driven Design) qual me chamou muita atenção, sendo a qual me inspirou a escrever esse artigo.
Resumidamente, em sua publicação Vaughn Vernon fala sobre o segundo "D" do TDD (Test Driven Development) onde menciona que muitos desenvolvedores utilizam o segundo D para Design, e isso está errado. Porém, a publicação gerou diversos comentários interessantes que agregam muito para o conteúdo proposto.
Para quem utiliza o TDD de fato, sabe muito bem os benefícios que podem trazer para sua aplicação, o fato de escrever os testes antes do código de produção. Não irei mencionar todos, mas alguns dos principais são:
Uma aplicação mais segura/confiável, devido o fato de você estar escrevendo suas funcionalidades baseadas nos cenários bons e ruins.
Maior cobertura de testes unitários, quando você escreve o teste antes da funcionalidade, consequentemente você está cobrindo todos os cenários. Assim levando a uma maior cobertura. (É obvio que cobertura não é sinal de um código de qualidade/seguro, mas pode ser um bom parâmetro.)
E o que tem maior relação com o artigo: Uma aplicação mais desacoplada. Quando você está escrevendo os testes antes da funcionalidade, você se preocupa em facilitar a testabilidade do seu código, assim, afetando diretamente o seu código de produção.
No entanto, muitos desenvolvedores vão além disso, começam a utilizar o TDD para manipular o Design da aplicação. E é ai chegamos aos comentários, comentários esses onde levantaram pontos bastantes interessantes na abordagem do TDD e como ele reflete na sua aplicação.
Como já mencionei, é inegável que o TDD vai impactar positivamente a sua aplicação, a nível de qualidade de código, porém, não deve passar disso! A partir do momento que você deixa seus testes unitários direcionarem o Design da sua aplicação, você pode estar comprometendo a sua aplicação apenas pelo fato de estar facilitando a sua escrita de testes.
Para isso, existem práticas que podem ser abordadas antes mesmo do desenvolvimento, onde você começa a definir o Design da sua aplicação. Para isso, você pode utilizar o DDD (Domain Driven Design).
Aqui estão algumas abordagens que você pode colocar em prática utilizando o DDD:
Utilize a Linguagem Onipresente/Ubíqua para que você possa refletir os principais conceitos abordados com os especialistas do domínio no design da sua aplicação.
Delimite os Contextos da sua aplicação, fazendo isso, os desenvolvedores terão um melhor entendimento sobre a aplicação, agregando em um conhecimento compartilhado.
Com os Contextos Delimitados, utilize o Mapa de Contextos, para representar a comunicação entre os Contextos, dando maior clareza do todo da aplicação.
Qual seria o mundo ideal? Utilize o DDD para refletir a Linguagem Onipresente no seu Design e utilize o TDD para ter uma aplicação confiável e de qualidade.
Portanto, não utilize o TDD para refletir o seu Design, o TDD foi feito para se ter uma aplicação mais segura e confiável, consequentemente afetando a qualidade do seu código. Utilize o DDD para ter um design com contextos delimitados baseando-se na linguagem onipresente/ubíqua.
Top comments (0)