Em pleno sabadão, num dia lindo acordo antes das 07:00, e não é para ir para a praia ou coisa do tipo, e sim para ir ao 6º Encontro do Guru-SP. 
Mas que “diacho” de encontro é esse Fabrício? Você foi consultar um guru espiritual?
Não, não (rsrs). O Guru-SP é esse daqui:
Hmmm… agora entendi. Mas o que você foi fazer num encontro de usuários de Ruby? Você programa em Ruby?
Não (mas depois de hoje fiquei com mais vontade ainda de aprender).
Um dos motivos para ter ido ao encontro foi o tema “Testes Automatizados” dele. Não tem jeito, colocar a palavra “teste” no tema de um evento, é mais efetivo do que falar que vai ter coffee break, para me fazer participar.
rsrs… que atitude nerd, perder um dia lindo desse, para ir num evento só por causa que vai falar sobre testes.
Que isso, olha o preconceito. Não é todo dia que você tem a oportunidade de participar de um evento sobre testes, onde que ia falar não atua na área de Teste de Software ou QA, e sim o pessoal do “lado negro da força” (“brincadeira minha, não é falando mal!”).
Interessante mesmo! Quem organizou o evento?
O 6º Encontro do Guro-SP foi organizado pelo Rafael Rosa, com o apoio da GoNow (local do encontro), Voice Technology (empresa na qual trabalho), O’Reilly e Ruby Inside Brasil, além é claro do Grupo de Usuário Ruby de SP.
E como foi o formato do encontro?
Foi no formato de mesa redonda (muito bom!), o pessoal da mesa ia falando sobre vários temas, que foram votados antes pelo pessoal que participou do encontro. Os debatedores foram:
- Anderson Leite
- Cássio Marques
- Diego Carrion (não pode comparecer)
- Fabio Kung (não pode comparecer)
- Jorge Diz (o Jorge será o palestrante do 6º Encontro Mensal da ALATS-SP, a ser realizado nessa quarta-feira)
- Ricardo Yasuda
- Thiago Scalone
E o encontro foi dividido em duas partes, a primeira estimado das 10:00 ao 12:00 e a segunda das 12:30 às 15:00.
Da hora, a primeira parte como foi?
Ela começou com quase uma hora de atraso, com o Rafael Rosa falando sobre o encontro e como seria feito esse. Logo após, o pessoal já começou a “descer a lenha” falando sobre “Por que testar”, e pude perceber que a galera é bem comprometida como a realização dos testes, eles levam a sério mesmo e entendem as razões de porque testar.
Os debatedores também contaram experiências que tiveram fazendo BDD com o Cucumber e realizando testes de interface com o Selenium, por exemplo. Esse foi um ponto muito positivo do evento, ficou claro que os debatedores fazem o que eles falam, e puderam compartilhar experiências bem interessantes com o público. E a interação do público foi muito boa também, várias pessoas contaram os cenários que vivem, e também algumas dificuldades que tem em realizar os testes:
- Tempo: projetos com prazos para ontem. Na minha opinião, realizar testes, principalmente na fase de desenvolvimento é uma prática que gera efeitos não tão bons a curto prazo, mas que a médio e longo prazo, se mostra essencial! Porém, como vivemos numa geração imediatista, muitas vezes as pessoas tem dificuldade em entender isso.
- Complexidade: a criação de testes em sistemas complexos é um desafio maior ainda, às vezes pode ser mais difícil do que a própria implementação.
- Sistemas legados: se dá uma manutenção em um sistema legado já é uma missão de embrulhar o estômago, imagine só criar testes para ele. Uma solução legal, comentada pelo pessoal e colocada em prática é realizar testes em nível de sistema, utilizando o Selenium por exemplo.
O Jorge Diz lembrou que a área de Teste de Software, costuma vir no reboque quando se usa metodologias frágeis (tradicionais). Mas usando metodologias ágeis o Teste de Software é incentivado, as novas técnicas já trazem na sua essência o pensamento de testar. Aliás, um exemplo disso é o uso de programação em par, onde uma pessoa já está revisando o código (lembrando que revisar é uma forma de testar).
Sobre o uso de BDD e TDD, o Anderson Leite disse que antes de partir para o uso delas, as pessoas precisam primeiro adquirir o hábito e prática de testar, só depois que já tiverem maduras podem começar a usar o BDD e TDD.
O Cássio Marques contou um pouco da sua experiência com linguagens de comparação, comparando no quesito de facilidade de testar. E disse que escrever testes em C e C++ é bem difícil, em Java também é meio enrolado. Já em Ruby é bem mais fácil. Podemos dizer que Ruby tem uma melhor “testabilidade”, que as outras, ou seja, se você é desenvolvedor Ruby e não testa, então você tem uma desculpa a menos para usar. 
Um ponto importante discutido foi que se você testa, você não pode se dar ao luxo de deixar de testar uma funcionalidade, pois poderá resultar na velha história da janela quebrada.
Para terminar a primeira parte, houve uma demonstração do uso do Cucumber pelo Anderson. A minha primeira impressão foi que pareceu mágica o que ele fez (rsrs), ele escreveu os testes usando TDD e gerou o código usando o Scaffold de um cadastro de participante que tinha os campos nome e e-mail. Achei bem legal a demonstração, o Cucumber é uma ferramenta muito legal, nela você cria o teste como se estivesse criando uma caso de teste, segue abaixo um exemplo:
O Cucumber utiliza por default o Webrat, porém também é possível realizar o teste usando o Selenium RC, basta passar como parâmetro. O interessante do uso do Webrat é que diferente do Selenium, ele simula o navegador, rodando em background, ou seja, é muito mais rápido que o Selenium RC, porém tem a limitação de não conseguir testar javascript.
E depois do “rango”, a segunda parte foi no mesmo nível que a primeira?
Depois do excelente coffee break, o Jorge Diz passou vários slides explicando a teoria de testes, abordando desde as escolas de teste até sobre os tipos de dublês. Essa parte fugiu um pouco do formato de debate, mas logo o Rafael Rosa retomou o formato, estimulando uma discussão sobre mocks e o perigo de “engessar muito” utilizando eles.
Do debate sobre mocks, o pessoal chegou a seguintes conclusões:
- Se você está “mockando” muito, pode ser um sinal que a sua classe está fazendo mais do que ela deveria fazer. Então REFATORE;
- Sempre tente modularizar ao máximo a sua aplicação, nada de ter uma classe “sistema”;
- Os dublês em geral, devem ser usados sempre para resolver uma dependência.
Um assunto interessante abordado na apresentação do Jorge, foi como deve ser a pirâmide dos testes, de acordo com o nível:
Mas o que ocorre, geralmente, sem essa cultura de que desenvolvedor também testar, é uma inversão dessa pirâmide, ou seja, não há quase nenhum teste de unidade e integrado realizado, e muitos testes de sistema feitos pelo pessoal de Teste de Software.
E ainda houve mais duas práticas, uma com o Thiago Scalone mostrando o Selenium IDE e o RC. E depois mais uma com o Anderson apresentando o RSpec (o JUnit do Ruby)
E o que você achou? Pelo jeito deve ter sido ótimo, afinal além de falar de testes deve coffee break na faixa.
Excelente encontro! Comprovou que é mito essa história que desenvolvedor não testa, eles testam sim, e até melhor do que muito testador que tem por aí. E Ruby é uma linguagem que oferece uma “testabilidade” incrível, as ferramentas que existem são muito boas, e ajudam desde o teste de nível unitário até o teste de nível de aceite. E essa brincadeira que faço sobre “lado negro da força”, em breve ficará sem sentido, pois os testes estão se tornando cada vez mais uma tarefa inerente ao desenvolvimento.
Para encerrar o post, parabéns a todos que participaram, e principalmente, ao Rafael Rosa, pela excelente organização!
Para saber mais sobre o 6ºEncontro acesse a wiki do Guru-SP:
http://guru-sp.com/index.php/Sexto_Encontro
E para saber sobre os próximos encontros acompanhe o Ruby Inside Brasil:
Fique por dentro das novidades, assine o feed do QualidadeBR.
