Excelente conteúdo! Sou adepto dos testes de unidade e sempre que possível gosto de frisar sua importância no ciclo de desenvolvimento de um software, além estar sempre em busca de aperfeiçoar meu conhecimento no assunto.
Uma dúvida, e que talvez possa ser usada como ideia para um próximo artigo: Até onde vai ou qual a responsabilidade das classes de mocks/builders?
Pergunto isso porque normalmente tenho classes específicas (como a EmployeeBuilder do seu exemplo) para fazer a criação de objetos com dados fakes. A partir delas, disponibilizo métodos e extensões mais genéricos e deixo a responsabilidade para os métodos de testes de criar e customizar os objetos de acordo com suas necessidades. Entretanto, já vi casos onde eram criados métodos específicos dentro das próprias builders para atender a diversos cenários de testes, que em sua grande parte acabavam inflando essas classes builders e deixando o código menos legível, o que acabou me gerando dúvidas se de fato estava correto usar uma abordagem como essa.
Opa, bom dia Luis! Obrigado pelo seu comentário. Fico feliz em saber que o conteúdo foi útil para você.
Sua dúvida sobre a responsabilidade das classes de mocks/builders é bastante pertinente e um ótimo tema para um próximo artigo. Vou compartilhar aqui alguns pontos que podem ajudar a esclarecer essa questão. As classes de mocks/builders são extremamente úteis para criar objetos com dados falsos, facilitando a escrita de testes de unidade. No entanto, é importante manter um equilíbrio para evitar que essas classes se tornem inchadas e difíceis de manter. Vou deixar algumas sugestões👇🏻 :
Responsabilidade Única: As classes de builders devem ter uma única responsabilidade: criar objetos. Evite adicionar lógica de negócios ou cenários específicos de testes dentro delas. Isso mantém o código limpo e mais fácil de entender.
Métodos Genéricos: É uma boa prática disponibilizar métodos genéricos para a criação e customização de objetos, como você mencionou. Dessa forma, os testes podem ajustar os objetos conforme necessário sem inflar as classes de builders.
Reutilização e Extensibilidade: Se você perceber que certos cenários de testes são recorrentes, considere criar métodos de extensão ou helpers separados que utilizem os builders. Isso ajuda a manter os builders enxutos e a lógica específica dos testes em um lugar apropriado.
Separação de Cenários Comuns: Para cenários de testes muito específicos, pode ser útil criar subclasses ou classes auxiliares específicas para esses casos, ao invés de adicionar mais métodos aos builders principais.
Essas dicas podem ser úteis! E mais uma vez, obrigado pela sugestão de tema. Com certeza vou considerar escrever um artigo detalhado sobre isso.
Excelente conteúdo! Sou adepto dos testes de unidade e sempre que possível gosto de frisar sua importância no ciclo de desenvolvimento de um software, além estar sempre em busca de aperfeiçoar meu conhecimento no assunto.
Uma dúvida, e que talvez possa ser usada como ideia para um próximo artigo: Até onde vai ou qual a responsabilidade das classes de mocks/builders?
Pergunto isso porque normalmente tenho classes específicas (como a EmployeeBuilder do seu exemplo) para fazer a criação de objetos com dados fakes. A partir delas, disponibilizo métodos e extensões mais genéricos e deixo a responsabilidade para os métodos de testes de criar e customizar os objetos de acordo com suas necessidades. Entretanto, já vi casos onde eram criados métodos específicos dentro das próprias builders para atender a diversos cenários de testes, que em sua grande parte acabavam inflando essas classes builders e deixando o código menos legível, o que acabou me gerando dúvidas se de fato estava correto usar uma abordagem como essa.
Opa, bom dia Luis! Obrigado pelo seu comentário. Fico feliz em saber que o conteúdo foi útil para você.
Sua dúvida sobre a responsabilidade das classes de mocks/builders é bastante pertinente e um ótimo tema para um próximo artigo. Vou compartilhar aqui alguns pontos que podem ajudar a esclarecer essa questão. As classes de mocks/builders são extremamente úteis para criar objetos com dados falsos, facilitando a escrita de testes de unidade. No entanto, é importante manter um equilíbrio para evitar que essas classes se tornem inchadas e difíceis de manter. Vou deixar algumas sugestões👇🏻 :
Responsabilidade Única: As classes de builders devem ter uma única responsabilidade: criar objetos. Evite adicionar lógica de negócios ou cenários específicos de testes dentro delas. Isso mantém o código limpo e mais fácil de entender.
Métodos Genéricos: É uma boa prática disponibilizar métodos genéricos para a criação e customização de objetos, como você mencionou. Dessa forma, os testes podem ajustar os objetos conforme necessário sem inflar as classes de builders.
Reutilização e Extensibilidade: Se você perceber que certos cenários de testes são recorrentes, considere criar métodos de extensão ou helpers separados que utilizem os builders. Isso ajuda a manter os builders enxutos e a lógica específica dos testes em um lugar apropriado.
Separação de Cenários Comuns: Para cenários de testes muito específicos, pode ser útil criar subclasses ou classes auxiliares específicas para esses casos, ao invés de adicionar mais métodos aos builders principais.
Essas dicas podem ser úteis! E mais uma vez, obrigado pela sugestão de tema. Com certeza vou considerar escrever um artigo detalhado sobre isso.
Abraços e bons testes! 🫱🏼🫲🏼