Testes não devem verificar unidades de código. Em vez disso, devem verificar unidades de comportamento: algo que seja significativo para o domínio do problema. - Vladimir Khorikov
O livro do Vladimir está na minha lista tem um tempo e ler esse artigo só o moveu mais pra cima da lista 😅
Eu tenho um histórico meio peculiar com testes. Comecei minha carreira como front, onde na época o ecossistema de testes era bem menos desenvolvido que hoje (2016/17).
Front, de certa maneira, é mais simples de testar manualmente. Pois estamos ali vendo todas as coisas acontecerem.
Claro que tem mts problemas com isso. Nossos vieses pessoais pra testar apenas o caminho feliz, APIs sempre retornando sucesso, etc.
Conforme fui progredindo na carreira, comecei a ver mais ainda o valor dos testes.
E caí muito nesse ponto que vc comentou: responsabilidade.
Software é algo fantástico. Vc faz uma vez, e virtualmente ele está ao vivo e agora disponível para todo mundo. 24 horas por dia.
E as pessoas hoje em dia esperam que ele esteja sempre disponível e funcionando.
Mas, além disso, as pessoas esperam melhorias e inovações. Mas sem quebrar aquilo que já existe.
Pra mim, hoje em dia escrever um teste é um investimento. Que tem um retorno enorme.
Com essas ferramentas de IA hoje em dia, minha velocidade aumentou muito. As vezes coisas mais simples que demoravam 1 dia são coisas de 1 hora ou até menos.
E isso é sensacional.
Mas isso tbm quer dizer que minha chance pra shippar bugs aumentou ainda mais 😂
E os testes pra mim são como se fosse um funcionário trabalhando 24/7 em todas as minhas mudanças pra impedir eu de quebrar esse delicado balanceamento sobre softwares
Enfim, escrevi uma redação e isso aqui já até estendeu demais.
Mas concordo com tudo que vc escreveu Rafael. Valeu demais por ter tido o tempo de escrever um artigo tão profundo.
Hoje em dia, teste é essencial pra qualquer engenheiro de software responsável. Que se importa não só com o código, mas com que seus usuários nunca sejam prejudicados também
E esse retorno sobre investimento fica ainda maior quando vc lida com grandes equipes de software e produtos complexos.
Pq é muito raro ter uma pessoa que saiba como tudo funciona em todos os domínios diferentes do sistema.
Mas os testes agem não só como segurança, mas como documentação pra cada funcionalidade
Pô, Lucas… que comentário sensacional, cara. Obrigado demais por compartilhar tudo isso com tanta clareza e profundidade.
Me identifiquei muito com a tua trajetória — principalmente essa transição do front pro backend e a forma como os testes passaram a fazer parte do teu olhar mais estratégico sobre software. A metáfora do “funcionário 24/7” é perfeita, e real demais 😂
É isso mesmo: com a IA acelerando nosso ritmo de entrega, a responsabilidade só aumenta. E, no meio dessa correria, teste virou um tipo de “seguro emocional” também. Não só pro sistema, mas pra gente mesmo dormir tranquilo depois do merge 😅
E esse ponto que você trouxe sobre equipes grandes e produtos complexos é chave. A gente não testa só pra garantir o que a gente fez agora, mas pra proteger o trabalho de um time inteiro, hoje e daqui seis meses, quando nem vamos lembrar direito o que fizemos.
Feliz demais de saber que o artigo te fez subir o livro do Vladimir na lista. Vale cada página e, conhecendo tua jornada, sei que você vai tirar muito valor dali.
Valeu mesmo, irmão. Ler um comentário como esse me dá ainda mais vontade de continuar escrevendo. Tamo junto sempre! 👊🚀
O livro do Vladimir está na minha lista tem um tempo e ler esse artigo só o moveu mais pra cima da lista 😅
Eu tenho um histórico meio peculiar com testes. Comecei minha carreira como front, onde na época o ecossistema de testes era bem menos desenvolvido que hoje (2016/17).
Front, de certa maneira, é mais simples de testar manualmente. Pois estamos ali vendo todas as coisas acontecerem.
Claro que tem mts problemas com isso. Nossos vieses pessoais pra testar apenas o caminho feliz, APIs sempre retornando sucesso, etc.
Conforme fui progredindo na carreira, comecei a ver mais ainda o valor dos testes.
E caí muito nesse ponto que vc comentou: responsabilidade.
Software é algo fantástico. Vc faz uma vez, e virtualmente ele está ao vivo e agora disponível para todo mundo. 24 horas por dia.
E as pessoas hoje em dia esperam que ele esteja sempre disponível e funcionando.
Mas, além disso, as pessoas esperam melhorias e inovações. Mas sem quebrar aquilo que já existe.
Pra mim, hoje em dia escrever um teste é um investimento. Que tem um retorno enorme.
Com essas ferramentas de IA hoje em dia, minha velocidade aumentou muito. As vezes coisas mais simples que demoravam 1 dia são coisas de 1 hora ou até menos.
E isso é sensacional.
Mas isso tbm quer dizer que minha chance pra shippar bugs aumentou ainda mais 😂
E os testes pra mim são como se fosse um funcionário trabalhando 24/7 em todas as minhas mudanças pra impedir eu de quebrar esse delicado balanceamento sobre softwares
Enfim, escrevi uma redação e isso aqui já até estendeu demais.
Mas concordo com tudo que vc escreveu Rafael. Valeu demais por ter tido o tempo de escrever um artigo tão profundo.
Hoje em dia, teste é essencial pra qualquer engenheiro de software responsável. Que se importa não só com o código, mas com que seus usuários nunca sejam prejudicados também
E esse retorno sobre investimento fica ainda maior quando vc lida com grandes equipes de software e produtos complexos.
Pq é muito raro ter uma pessoa que saiba como tudo funciona em todos os domínios diferentes do sistema.
Mas os testes agem não só como segurança, mas como documentação pra cada funcionalidade
Pô, Lucas… que comentário sensacional, cara. Obrigado demais por compartilhar tudo isso com tanta clareza e profundidade.
Me identifiquei muito com a tua trajetória — principalmente essa transição do front pro backend e a forma como os testes passaram a fazer parte do teu olhar mais estratégico sobre software. A metáfora do “funcionário 24/7” é perfeita, e real demais 😂
É isso mesmo: com a IA acelerando nosso ritmo de entrega, a responsabilidade só aumenta. E, no meio dessa correria, teste virou um tipo de “seguro emocional” também. Não só pro sistema, mas pra gente mesmo dormir tranquilo depois do merge 😅
E esse ponto que você trouxe sobre equipes grandes e produtos complexos é chave. A gente não testa só pra garantir o que a gente fez agora, mas pra proteger o trabalho de um time inteiro, hoje e daqui seis meses, quando nem vamos lembrar direito o que fizemos.
Feliz demais de saber que o artigo te fez subir o livro do Vladimir na lista. Vale cada página e, conhecendo tua jornada, sei que você vai tirar muito valor dali.
Valeu mesmo, irmão. Ler um comentário como esse me dá ainda mais vontade de continuar escrevendo. Tamo junto sempre! 👊🚀
Excelente artigo !!
Em momentos que vejo resistência dentro do time, sempre falo que os testes são mais aliados dos dev que da empresa!!
Sugestão.. veja se faz sentido quebrar em 2 o artigo.
Muito obrigado pelo feedback! Como certeza vou começar a aplicar sua sugestão. Obrigado por ler! Ótima semana!