Minhas impressões – Sexto encontro GURU-SP – 26-09-09

Caros leitores desse blog,

Na manhã do dia 26-09-09, juntamente com o companheiro de trabalho Fabrício Campos, estive presente no sexto encontro do grupo de usuários Ruby de São Paulo (GURU-SP), ocorrido no auditório da GoNow. O tema chave era testes automatizados, em ritmo de perguntas, respostas e bate papo, tendo uma mesa redonda com especialistas no assunto interagindo bastante com o público.

Por meio deste post vou fazer um resumo do que presenciei no período das 10h00 até 15h30 (~) do excelente dia de sábado (também em termos climáticos…rs).

Panorama geral

Platéia - Sexto encontro GURU-SP
A algum tempo atrás tivemos o quinto encontro do GURU-SP, ocorrido na Voice Technology, e que fez sucesso. Lá tivemos cerca de 30 pessoas. Muitas expectativas foram geradas para o sexto encontro, e todas positivas. O nível de discussão só tendia a aumentar e ser mais especializado, fora o aumento do número de participantes. Neste sexto encontro tivemos por volta de 40 a 45 pessoas (apesar de termos 67 inscritos) e as expectativas foram alcançadas.

Mesa de discussão

Fizeram parte da mesa:

Mesa de discussão

Não puderam estar presentes: Diego Carrion e o Fábio Kung.

O encontro – parte 1

Rafael Rosa Fu fez a introdução do evento, agradecendo as empresas patrocinadoras, pessoal presente em um sábado de céu azul as 10h00 (rs) e ao crescimento dessas reuniões. Apresentou os membros da mesa e fez uma pesquisa do tipo de pessoal presente (membros da comunidade Ruby, Java [os “estranhos no ninho”, como bem definiu o Jorge Diz…rs], etc.) e já deixando no ar o objetivo chave da discussão para todos: quem faz testes? Porque e para que fazer testes? Quais as dificuldades?Que ferramentas eu uso e quais são?

A partir daí cada membro da mesa mostrou o porque de testar e onde testam nas empresas em que trabalham. Algumas perguntas vieram da platéia para “encorpar” a discussão. Um dos exemplos, que foi bastante usado e citado no encontro, foi de um rapaz da platéia que tinha muita dificuldade de testar soluções com NFP, usando Java + JUnit, pois os testes cresciam de forma “exponencial”, devido ao número de possibilidades de transações, por exemplo.

O consenso a respeito desse assunto: é importante pensar até onde testar, pois testes tem custo, seja de tempo ou financeiro. São indispensáveis, sem dúvida, pois é preciso fazer entregas íntegras e imunes a bugs. Soluções empresariais geralmente tem “hot zones” em relação a bugs. Conhecer como identificá-las e atacá-las se torna necessário.

Jorge Diz trouxe uma opinião interessante a respeito dos muitos conceitos apresentados sobre “alguma coisa+DD” (Driven Development): eles existem em várias linguagens, mas os métodos de teste e ferramentas usadas ainda não convergem para um padrão. Ruby parece ser bastante eficaz, seja em TDD, BDD e outros “DD’s”, e é aplicável até para testar Java (!).

Mas, cuidado: metodologias ágeis + teste de software só funcionam se você conhece, entende e sabe aplicar testes nos seus projetos. Não ouse começar a fazer TDD se você não é maduro o suficiente para escrever testes primeiro para depois codificar (para mais detalhes veja o conteúdo da palestra “Só imaturos não testam”, do Carlos Brando).

Cássio falou um pouco de sua experiência acerca das linguagens de programação e como executou/executa testes nelas. Deu exemplos falando do passar do tempo e o avanço ocorrido, desde a linguagem  C, C++, Java até Ruby. Hoje é muito mais fácil escrever e desenvolver testes, portanto escrevem-se mais testes, e não é tão trabalhoso quanto as linguagens antigas. Se você não escreve/testa quando programa em Ruby então você está fora do cotidiano e do senso comum.

Alguns outros questionamentos:

  • É preciso testar bibliotecas baixadas (gems ou jars) e que vão interagir com sua aplicação? R: de preferência sim, pois o comportamento dele com o seu código não é descritível e sabido;
  • É preciso testar CRUD? R: sim, pois 90 % das aplicações tendem a quebrar neles, ou em pontos associados a ele. Em contrapartida, testes em banco de dados são difíceis de executar, independente da tecnologia.

Algumas observações:

  • Teoria da janela quebrada acontece muito: se você deixa de testar ou escrever testes para um componente, isso tende a não testar e escrever testes para outro. Mesmo que não exista 100% de cobertura nos testes, não seja “desleixado”. Isso dá aval para outros também serem;
  • Se você ler algo a respeito de “alguma coisa+DD” tenha certeza: é um modelo de desenvolvimento criado pelos agilistas. Os mais importantes são TDD e BDD. Qual a vantagem: detalhar e escrever algo antes e que precisa passar por aferição antes de desenvolver;

Esses pontos anteriores foram discussão para o período inteiro da manhã praticamente (!).

Para fechar, antes de ir para o coffee-break, Anderson Leite mostrou exemplo prático usando Cucumber, para mostrar como  funciona essa ferramenta de teste em Ruby. Selenium e Webrat foram citados e mostrados como alternativas para testes de interface web, sendo o Webrat o “motor nativo” em Ruby para estes testes. O diferencial foi a rapidez na construção das aplicações, pois muita coisa já está pronta (Scaffolds). RSpec e Shoulda foram citados de maneira breve nesse horário (test units). Vimos como funciona a escrita de testes e como esta se aproxima do conceito literal do caso de teste em si, facilitando a leitura e entendimento do corpo técnico (empresa) e do corpo não-técnico (clientes).

Anderson Leite e Cucumber

Hora do Rango (!)

Sem comentários. Excelente e precisa, pois não dispersou o pessoal do local, extendendo mais o horário do evento, e facilitou o networking (mais troca de cartões, idéias e etc.). 30 minutos preciosos de descanso. Parabéns a GoNow por disponibilizar os lanches, refrigerante e uma máquina de café.😉

O encontro – parte2: A volta aos testes (rs)

Jorge Diz foi a frente e fez uma apresentação “reciclada” de outras apresentações, mostrando os conceitos e premissas básicas da área de teste e qualidade de software. O que testar, quais são os papéis, tipos de testes, até onde testar, pessoas envolvidas, escolas de teste e etc, foram mostrados de forma conceitual. Jorge está se preparando para tirar uma certificação de teste de software, por isso o interesse e abordagem do assunto. Não é a toa que ele estará no encontro do dia 30 na ALATS, com o tema “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas. Eu e o colega Fabrício estaremos por lá🙂

Foi uma abordagem bastante ampla, apesar de corrida, mas que exemplificou e mostrou um “resumão” da área de testes e o que permeia a mesma. A título de informação: somente eu e Fabrício Campos éramos, dos presentes no evento, nativos da área de teste de software. A discussão e interação do público com a mesa continuou quando partiram para o assunto de quando usar mocks e stubs em Ruby. Como foi bem técnica a discussão não tenho como colocar mais detalhes no post, devido ao meu conhecimento limitado de Ruby.

Após a passagem de slides do Jorge, Thiago Scalone foi a frente e apresentou um “screencast” gravado pelo mesmo acerca do Selenium e integração com projetos Ruby. O exemplo foi prático e mostrou  uma sequência de clicks e navegação via browser, que após serem “copiados” (macro) podem ser executados pelo selenium. O Selenium em si é uma suite de aplicativos (Grid, IDE, Remote Control, etc.), cada qual com sua finalidade. Problemas o mesmo também tem, como timeout de execução de passos (deve ser “calibrado”, pois o tempo de resposta de uma requisição ou resposta pode variar, seja pelo site ou navegador acessado), por exemplo.

Após o pessoal da mesa fazer mais uma integração e conversa com o público a respeito do uso do Selenium, Anderson Leite voltou a frente para “saciar” o interesse, fora as dúvidas do pessoal, a respeito do RSpec, ferramenta de testes unitários que se aproxima do Junit. Ao mesmo modo do Cucumber, foi mostrado um exemplo prático com a ferramenta.

Anderson Leite e o RSpec

Conclusão

Achei o evento muito bom e esclaredor a respeito das ferramentas de testes que Ruby dispõe aos seus programadores. No quinto encontro do GURU-SP instalei Ruby na minha máquina, mas até agora não tive tempo para estudos😦 . Mas irei me empenhar, muito pelo que eu vi no sábado e pela oportunidade de unir o útil ao agradável: teste de software + desenvolvimento de software. Os únicos pontos que podem ser considerados “negativos” foram o ar-condicionado (geladíssimo…rs), a ausência de Wi-Fi destinado ao evento (usamos uma rede que estava com sinal aberto…rs) e a localização (apesar de o transporte público ficar perto do local o deslocamento até o mesmo é muito grande). Poderiam existir mais filtros de linha também :p

Deixo meus agradecimentos ao pessoal da GoNow (excelente recepção e auditório) e ao Rafael Rosa Fu, pelo trabalho e disposição para reunir o pessoal. A todos que participaram, obrigado pela oportunidade de participar das discussões e troca de conhecimento com vocês. Espero poder participar/ajudar/divulgar o sétimo, oitavo, nono, décimo…. (E lembrem-se: A Voice Technology é parceira do GURU-SP. Sintam-se a vontade para nos contactar a respeito de reuniões, eventos, coding dojo, etc).

As fotos desse post eu tomei licença de retirar do twitgoo do Rafael Rosa Fu.

Após o evento, o pessoal foi tomar uma cerveja e descontrair em uma happy hour, porque ninguém é de ferro (com certeza foi regado a Ruby…rs).

Happy Hour - GURU-SP - 26-09-09

Bom, encerro por aqui este report. Agradeço pela leitura dos que passaram por aqui!

Até a próxima!

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: