Sua didática é impressionante, consegue despertar a vontade de aprender um conteúdo independentemente da complexidade!

“A tarefa essencial do professor é despertar a alegria de trabalhar e conhecer.” – Albert Eisntein

Elas ajudam, sim! Mas mutantes conseguem ir além do que conseguir ver complexity coverage (que foi meu exemplo aqui)! Veja os operadores de mutação do site do pitest!

A ferramenta de code coverage, com certeza, executará muito mais rápido. Essa é uma vantagem forte, IMHO! Acho que as duas técnicas se complementam!

Acredito que você já tenha lido algo sobre branch coverage ou complexity coverage usados pelo JaCoCo. Tenho utilizando essas métricas e têm me ajudado bastante no dia-a-dia.
Qual sua opinião a respeito?

Valeu!

Infelizmente, temos muitos frameworks, que nos obriga ter construtores padrões, a até mesmo expor nossos atributos internos com get e set publicos :(, oque invalida quase todos os esforços em manter o encapsulamento e consistência da classe.

É isso mesmo. Quando mais maduro você é, melhor consegue tomar essas decisões!

Bom workshop!

Obrigada!

Bem legal o post. O resultado dessa pesquisa me parece não muito surpreendente, mas muito interessante! Quem já bateu o pé e disse “Quer saber? Eu vou praticar TDD 100%!” sabe quantos obstáculos encontra no caminho. No meu caso, o item mais importante talvez seja a velocidade. Se eles forem lentos para executar, ou se eu tiver que dar ALT+TAB > comando > ENTER e esperar um tempo, fatalmente vou querer rodá-los com menos frequência. Outra coisa que me irrita é quando você usa ferramentas externas (como frameworks de persistência) e elas te causam problemas para escrever os testes. Isso já me fez desistir uma vez.

Quase todos chegamos à conclusão de que 100% de TDD não vale a pena. E aí muitos se sentem mal, porque defenderam essa visão para os outros, e, de repente, não estão mais praticando-a. Acho importante que a gente saiba se colocar para as pessoas quando muda de ideia. Ninguém precisa defender a mesma coisa a vida inteira. Pelo contrário, quem faz isso normalmente se engana. É preciso ter a humildade de chegar e falar “Sabe aquilo que eu dizia tanto? Então… Descobri que não é bem assim”. Acredito que o resultado dessa pesquisa seja em parte devido a isso. Por medo de se expor, muita gente continua dizendo a mesma coisa, mas passa a fazer outra.

Pessoalmente, gosto muito do TDD (vou até dar um minicurso sobre ele no sábado), mas já aceitei que não rola 100%. Acredito que o iniciante, sim, deva buscar os 100%, porque ele ainda não consegue discernir direito entre “aqui não cabe TDD” e “aqui cabe, mas eu ainda não sei fazer”. Meus projetos atuais (https://github.com/awvalenti/bauhinia) são centrados no uso do Wii Remote no computador. Esses projetos envolvem Bluetooth, interface gráfica e threads. Ou seja: tudo o que NÃO casa bem com TDD! Então, até o momento, não escrevi nenhum teste automatizado. Até consigo imaginar algumas classes que pudessem ser testadas em isolamento, mas ainda não vi necessidade. Antigamente, eu me sentiria mal por isso; hoje em dia, estou tranquilo!

Sim, você tem que testar isso. Mas eu prefiro fazer por meio de testes de sistema. Faz sentido?