Essa parte é sobre minha palestra no AgileBrazil 2011. Sexta-feira, resolvi que apenas apresentaria minha palestra, depois iria curtir Fortaleza (sério, aquele lugar é muito bom!).
Enfim, minha palestra foi Mantendo a Qualidade dos Códigos de Teste, e nela resolvi arriscar duas coisas novas: primeira, em fazer uma palestra para pessoas de nível intermediário, para não ter que ficar explicando o que são mocks, stubs, etc. Segundo, que a palestra seria de duas horas, para dar tempo de falar tudo o que eu queria.
Claro, a segunda opção quase me deu um tiro no pé. Primeiro, porque para não soar irreal, eu resolvi que todo o código da palestra (que por sinal, está disponível no link acima. Recomendo que vocês baixem o link, a versão do slideshare esconde algumas coisas) ficaria disponível no Github, com exemplos reais (assim, qualquer pessoa poderia rodar os códigos e ver que é possível sim fazer testes daquela forma). Segundo, porque essas duas idéias me tomaram um tempo absurdo para escrever a palestra. Demorei MUITO para fazê-la, bem mais do que eu esperava. E terceiro, porque descobri que duas horas também não é muito tempo…
Mas enfim, comecei a apresentação (por sinal, parabéns para a equipe do Agile, o projetor estava 100% configurado, nenhum pedaço dos slides ficou cortado) e comecei a ver algumas pessoas saindo. Isso é comum em palestras, mas no fim vi que muitas pessoas deixavam a sala. Decidi então dar a palestra para os que estavam presentes mesmo, e manter o nível técnico aonde estava. Minha noiva assistia a palestra também, e mencionou (depois) que muitos comentaram “mas o que são mocks e stubs que ele tanto fala?” e coisas tipo “não entendi, esses testes são o quê?”, então acredito que não tenha ficado claro para o pessoal que a palestra era para nível intermediário…
Enfim, sobre a palestra. Nela, tentei passar idéias que não são muito seguidas pelos desenvolvedores de software. A primeira, é que quando se cria um sistema, é necessário que se pense em como ele vai ser testado. É muito difícil escrever testes sem mudar, e às vezes não só um pouco, a forma como se programaria sem testes… ao mesmo tempo, é muito difícil também fazer um sistema que, com o tempo, adicionar novas funcionalidades seja fácil, e não mais difícil, e principalmente fazer um sistema que, à medida que ele vai crescendo, é mais fácil adicionar novos testes, tão sucintos quanto os testes mais antigos.
Porém, não existe uma regra simples. Na verdade, a única regra é que não existem regras. Acho que foi isso que faltou em muita gente que assistiu a palestra, perceber que aquilo não é uma receita de bolo. É o velho Know-How versus o Know-Why. E, afinal, estamos numa conferência de métodos ágeis! Não seria lá que deveríamos nos perguntar “por quê?”, ao invés de procurarmos receitas de bolo? Mas isso fica pra outro post.
A idéia final da palestra foi tentar escrever um teste de forma que ele seja facilmente lido. Para isso, apresentei um exemplo do teste escrito em linguagem natural, depois ainda em linguagem natural, mas próximo dos testes, e por fim em testes. Foi legal ver a expressão das pessoas, quando eu mostrei que o código de teste não é muito diferente do inglês…
Por fim, brinquei um pouco de “advogado do diabo”, apresentando críticas à própria apresentação. A coisa que eu mais ouço sobre o assunto é que “na correria, não dá pra manter tanto assim a qualidade”. Bom, a resposta é simples: crie a cultura. A qualidade que você ganha permite que você demore, digamos, dois meses para escrever uma funcionalidade que você escreveria em um mês. Mas, ao mesmo tempo, você dá uma semana de manutenção e correção de bugs naquilo, e não dois meses. E você demora um mês para escrever a nova funcionalidade, ao invés de dois. Isso se paga com o tempo, e foi algo que eu experimentei ao longo de vários projetos como programador.
As perguntas também foram bem pertinentes. Muitos me perguntaram sobre como testar métodos privados, que é um assunto interessante. Idealmente, não se testa. Se é necessário por causa de algum código legado, ou faz-se algum hack (reflexion API, por exemplo), ou faz-se algum mini-teste de integração, fechando todas as condicionais, e então refatora-se o código.
Enfim, não sei se considero minha palesta um sucesso. Também, não a considero uma falha. Eu a declararia como “sucesso parcial”, consegui passar a minha mensagem para uns (tive feedbacks positivos de muita gente) porém sei também que não agradei quase nada outras pessoas (a principal reclamação é que faltou didática). Acredito que não dê pra agradar todos, e fico feliz que o resultado foi positivo para alguns.