Como fazer testes desacoplados da implementação? Isso soa quase que impossível. Vou dar um exemplo. A classe CadastrarClienteUseCase tem uma dependência em seu construtor de uma interface para um serviço externo que busca o CEP, pode dar o nome que quiser (EnderecoClient, EnderecoProvider, EnderecoService, etc.). Essa interface de Endereco tem 5 métodos, mas o UseCase chama só um, buscarEnderecoPorCep, por exemplo. Se eu fizer o teste do UseCase, serei obrigado a conhecer detalhes da implementação, isto é, que ele depende do serviço de Endereco e especificamente desse método, para funcionar. Se no futuro o UseCase quiser obter o endereço de um outro método, mesmo que seja na mesma interface do serviço de Endereço, vai quebrar o teste, pois o "expect" estava programado para o outro método. Isso faz com que mudança nos detalhes da implementação me faça quebrar o teste, mesmo que o resultado seja o mesmo. Eu não sei como solucionar esse dilema.
Estou entrando na área de backend agora...iniciante msm. E no curso que tenho essa é uma das primeiras aulas. Esta certo msm? Pois não falam o por que de ser uma das primeiras.
Para falar a verdade, não sei. Talvez mais empresas gringas utilizam. O Dave Farley mostra inclusive alguns testes de aceitação de uma empresa que utiliza BDD em um dos vídeos dele. Quanto ao TDD o Uncle Bob estima que 1/4 dos desenvolvedores mais sêniores utilizem.
GDD - Gambiarra Driven Development
Sensacional !!!! Kkkkk
Boa! 😅
kkkk
Muitíssimo obrigado pelo excelente video.
Como fazer testes desacoplados da implementação? Isso soa quase que impossível. Vou dar um exemplo.
A classe CadastrarClienteUseCase tem uma dependência em seu construtor de uma interface para um serviço externo que busca o CEP, pode dar o nome que quiser (EnderecoClient, EnderecoProvider, EnderecoService, etc.).
Essa interface de Endereco tem 5 métodos, mas o UseCase chama só um, buscarEnderecoPorCep, por exemplo.
Se eu fizer o teste do UseCase, serei obrigado a conhecer detalhes da implementação, isto é, que ele depende do serviço de Endereco e especificamente desse método, para funcionar.
Se no futuro o UseCase quiser obter o endereço de um outro método, mesmo que seja na mesma interface do serviço de Endereço, vai quebrar o teste, pois o "expect" estava programado para o outro método.
Isso faz com que mudança nos detalhes da implementação me faça quebrar o teste, mesmo que o resultado seja o mesmo.
Eu não sei como solucionar esse dilema.
Cara, tu deu uma aula em completa em 5 minutos. Muito bom!
Muito obrigado Marlon! 😄
Bem esclarecedor. Parabens.
Uma excelente explanação 👏🏼👏🏼👏🏼👏🏼
Muito obrigado Igor! 😄
Ótimo conteúdo! Explicou bem a diferença desses dois conceitos!
Muito obrigado Rafa!
O YT nunca me notifica! Se eu não acompanhasse o LinkedIn..
Que pena: por que será? Bem, continuo fazendo propaganda no LinkedIn... 😅
Muito bom, em pouco tempo explicou de uma maneira clara e simples de entender.
Estou entrando na área de backend agora...iniciante msm. E no curso que tenho essa é uma das primeiras aulas. Esta certo msm? Pois não falam o por que de ser uma das primeiras.
que legal esse ponto do Spec, eu nao sabia rsrs
Massa né? 😄
@@otaviolemos Isso muda completamente o significado do que é escrever testes, realmente abriu meus olhos
Então, resumindo, TDD e BDD são a mesma coisa? Só foi mudado o nome, pois o pessoal estava entendendo o conceito de forma errada???
É isso?
BDD é muito utilizado? Eu quase não ouço falar sobre esta metodologia
Para falar a verdade, não sei. Talvez mais empresas gringas utilizam.
O Dave Farley mostra inclusive alguns testes de aceitação de uma empresa que utiliza BDD em um dos vídeos dele.
Quanto ao TDD o Uncle Bob estima que 1/4 dos desenvolvedores mais sêniores utilizem.
Cara, onde eu trabalho a gente implantou BDD no nosso processo.
Trablho aqui no BR mesmo em empresa BR
@@marciohenrique8814 massa demais! Mas você tem ideia se isso é comum entre as empresas ou só algumas implementam?
Mas como funciona o BDD na prática?
Da mesma forma que o TDD mas tradicionalmente trabalha-se de fora para dentro, começando com testes de mais alto nível, da perspectiva do usuário.
muito bom, mais a tag do vídeo deveria ser como surgi-o e não como é
Seria o BDD uma camada de teste pra galera do QA fazer ?
Boa pergunta