229 - 8 princípios para BONS testes automatizados | theWiseDev Testing

Muita gente não gosta de teste automatizado porque não sabe escrevê-los bem.

Código de teste precisa ter QUALIDADE, tanto quanto código de produção.

Nesse vídeo eu discuto 8 princípios de bons testes automatizados descritos pelo Kent Beck, o idealizador do TDD (e, pode-se dizer até, do próprio teste automatizado).

Se você seguir esses princípios, garanto que terá bons testes em sua base de código!

Chega mais...

Referência
Programmer Test Principles

[daltonyon]

Excelente, vou colar na parede para sempre fazer um checking!! Continue com esse conteúdo que agrega muito valor para o desenvolvendor de software

[GoGamePlayRJ]

Cara, seu canal é sensacional. Não pare amigo, e muito sucesso!

[maxwelllaner]

Interessante! Obrigado pelo conhecimento e parabéns.

[alexandrequeiroz]

na real a galera não testa pois não sabe como fazer isso! Logo vídeos como os teus prof. Otavio, são essenciais!

[carlosvaltersantosferreira]

Nossa professor acabo de perceber que sempre amarro meu testes a estruturas... Tipo, eu forço no tdd a chamada de uma função. Exemplo, para eu forçar que seja criado um laço no código, eu verifico no teste se aquela função X foi chama 10 vezes por exemplo, com isso faço ter um loop de 10 vezes no meu código.

Claro q não é tão engessado, mas eu sempre verifico se as funções X, Y, Z são executadas, principalmente nos controller.

Com isso acontece exatamente o que vc está falando, se alguém fizer um merge de funções vai quebrar o código.

E em consequência disso, eu gasto muito tempo pensando em como fazer aquele teste, de forma que force a obrigatoriedade de chamadas de métodos ou funções.

Obrigado por esclarecer, vou rever esse vídeo e começar a colocar em prática.

Ah mais uma vez obrigado pelo seu curso de TDD, que veio com seu livro. Graças a isso eu estou me destacando no projeto que estou (em uma multinacional), e já fui chamado para dar um treinamento de TDD, pois descobri q a grande maioria dos programadores não conseguem aplicar o TDD. Com isso os testes deles nunca tem 100% de cobertura.

[cezargabrielheinenzaleski]

Bons esclarecimentos!
Mas tenho um ponto: quando o método não possui retorno ou quando o produto do método é um registro em banco de dados, não vejo uma forma de testar sem acoplar a implementação verificando se determinados métodos foram chamados com parâmetros específicos.

[Akhbash]

Qual o link para a matéria do Kent Beck no Medium?

[carlosrafael]

Qual a referência do vídeo mesmo, professor?

[artu_almeida]

Otavio, qual nome se dá para aqueles testes que são só para cobertura e na verdade não estão testando nada?

[marcosadriano]

Em testes onde são avaliados a inserção ou exclusão de informações num banco de dados, onde alguma alteração causada por um teste possa afetar o resultado de outro, isso seria considerado um teste não determinístico? Uma alternativa que eu penso para evitar esse problema seria executar os testes em série ao invés de paralelo e sempre reverter a ação que fizemos no banco de dados após cada teste, só que aí o tempo do teste aumentaria, ferindo o primeiro princípio. Existe uma solução melhor para esse tipo de problema? Ah, e muito obrigado pelo vídeo, professor!