TDD: D de development ou design?
Tags: tdd, ddd, testing
Published: 2023-01-08 20:49:07

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](https://www.linkedin.com/feed/update/urn:li:activity:7013904355066068994/) 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.