Ultimamente, no meu emprego atual, tenho a oportunidade de usar um excelente framework de testes de aceitação brasileiríssimo que é o pycurracy . Ele é uma ferramenta feita em python que permite que você escreva suas histórias de aceitação em linguagem natural. Isso significa dizer, que você pode escreve o seu teste em português.

Não preciso dizer o quanto isso traz de vantagem. Só para citar, uma das mais imediatas, pelo menos para mim, é a questão da documentação.  Quem já está na estrada um tempo, sabe como é uma verdadeira luta manter documentações atualizadas do produto.  Tudo sempre começa bem, mas com o passar do tempo, sempre surgem outras tarefas mais urgentes e os “casos de uso”  ou histórias acabam ficando não condizentes com a realidade da aplicação.  Para muitos, isso pode soar como preciosismo porém imagine um contexto de um projeto open source… sem uma documentação bem feita, colaborar pode ficar bem difícil.

Um outro aspecto também é que desenvolvedores “não são muito amigos” de escrever documentos. Esta aí uma tarefa que vejo poucos colegas fazerem com prazer. Se puderem evitar, a grande maioria em minha humilde opinião,  evitarão fazê-lo.

Ferramentas como o pyccuracy, vem unir o “útil ao agradável”: vem possibilitar escrever testes, programando, e como resultado indireto obter uma excelente fonte para consultas.  Por permitir escrever os cenários  em linguagem natural (inglês e português) acabamos por ter um documento descrevendo o funcionamento esperado… as nossas histórias.

O pyccurace é todo feito em python usando o Selenium .  Para maiores detalhes recomendo uma visita a página do projeto.

A única coisa que tenho a dizer sobre ele é que bem que poderia ter uma implementação que usasse o WebDriver ao invés do Selenium RC. Acredito que ficaria bem mais rápido. Mas, até agora só temos versões estáveis do WebDriver para Java. A versão python está bem timida ainda.

A pouco tempo consegui um brecha com ajuda da minha colega Arlene para implantarmos no projeto que estou trabalhando teste automatizados.  Com a carta de alforria em mãos partimos para pesquisar no mercado qual seria a melhor que se encaixaria em nosso contexto de aplicação.  Para que entenda,  trabalhamos com desenvolvimento de portal usando a ferramenta Lumis (eu trabalho na Lumis!!!).  Portais são aplicações bastante difíceis de serem testadas de forma automática; devido a questão do conteúdo dinâmico e pouco previsível não existe muita margem para que busque por padrões.

Com estas limitações em mãos, acabamos nos deparando com a api WebDriver . A um tempo atrás eu já tinha mexido um pouco com o selenium e adorei. Com isso, tentei achar algo que se assemelhasse a ele mas que me facilitasse a vida em relação a portais ( não tem muito como usar ids dos elementos no html, url não fixas, etc) . O webdriver, ao contrário do selenium, não é um javascript que executa dentro de uma página simulando a navegação… o webdriver é realmente um “envelope” em cima do seu navegador.  No caso do Firefox ele é uma extensão, no caso do Internet Explorer (blargh) ele usa as chamadas de control que ele proporciona, e por ai vai. Com isso, os teste ficam mais próximos da realidade de uso do usuário, e a api para escrever  os cenários mais simples.  Veja o trecho:

Pelo exemplo acima fica fácil de ver o quão fácil é criar um teste em webdriver.  Recomendo experimentar

Se você é um leitor assíduo do meu blog, já deve ter percebido o quanto gosto de testes automatizados. Não só gosto como acredito neles e no retorno que eles proporcionam. Sempre que tenho a oportunidade procuro “vender esse peixe”. O interessante é que com isso acabei escutando alguns exageros que chegam a ser engraçados.  Um exemplo foi após uma conversa em que até rolou uma  sessão de codificação em par com a pessoa, no final, ela soltou a seguinte pérola :”Agora então não preciso mais do pessoal de teste“.  Opa! Devagar com o andor que o santo é de barro, meu amigo.

Antes que concorde com isso,  deixa eu mostra meu ponto de vista.  Teste automatizados ajudam muito e realmente tornam a vida do desenvolvedor e do cliente melhores.  Torna a vida do desenvolvedor mais fácil quando permite que ele faça seus testes rapidamente e detecte um erro o mais cedo o possível.  Para o cliente significa que a automação mais testes podem ser executados num tempo menor e com isso mais qualidade com menor custo.  Mas e a história do cara de teste, onde entra? Calma.  Para automatizar os testes devemos fazer algumas considerações e escolhas.  Para facilitar o que quero ilustrar, imagine um portal. Portais são aplicações webs muito interessantes, pois a cada acesso o seu comportamento pode mudar e isso não é necessariamente um erro.  Por isso, testes automatizados, em ambientes como estes são bem complicados de serem feitos e levam a gente a fazer algumas “adaptações”. Com isso,  os teste acabam validando parte das coisas e logo, ainda temos a necessidade de uma pessoa testando.  Entretanto, agora, essa pessoa não precisa estar testando tudo e qualquer coisa. Ele pode focar um pouco mais, realizando apenas verificações pontuais.

Outra frase que sempre escuto é a questão do recurso e gastos.  Geralmente quando converso com os gerentes sobre testes – principalmente os ditos PMI – eles quase que instantaneamente dizem que isto é inviável e trabalhoso. Bom, primeiro devemos definir o contexto:  se imaginarmos os famosos “cowboys“, rapaziada que desenvolve a culhão e não teste se o objeto que eles estão pegando é nulo, realmente testes automatizados são trabalhosos, pois não fazem nenhum.  Para aqueles que pretendem o mínimo de qualidade, dá para dizer que, realmente, NO INÍCIO,  testes automatizados demandam mais tempos, mais se olharmos ao longo da linha tempo esse custo se dilui e tende a zero. Isso porque, após todos os casos criados, o trabalho será de executá-los e mantê-los atualizados.  Fora que, imagine o custo de pessoas, máquinas, tempo,  para que a cada alteração que um desenvolvedor fizesse na aplicação, toda ela fosse retestada.

Enfim,  caso ainda não acredite em mim quando digo que ferramentas de testes são legais e estão aí para nos ajudar,  experimente e tire suas próprias conclusões. Duvido, sendo você empresário, gerente pmi, coordenador, desenvolvedor, cliente, etc no final não ficará pelo menos tentado a usar algum no seu próximo projeto.

Esses dias li um e-mail numa lista de discussão que participo onde a pessoa perguntava como ela deveria fazer para documentar um projeto que ele desenvolveu sozinho. Ainda segundo ele, a ideia é de permitir que num futuro próximo um novo desenvolvedor possa trabalhar no sistema sem traumas e com uma curva de aprendizado rápida.

Antes de tentar responder a pergunta, acredito seja necessário entender a diferença entre análise e documentação.  Muitas pessoas que trabalham com  criação de softwares, acabam confundindo documentar com analisar.  Essa dúvida é normal pois muitas “ferramentas” e “métodos” também se apresentam como opção de documentação, ou o contrário : coisas que deveriam ser usadas para documentar são usadas para fazer análise ( e até acabam com uma má fama sem terem culpa disso – puro mal uso). Um exemplo disso, no meu ponto de vista, é o uml : Muitos usam a UML com o propósito de analisar e modelar. Ela até foi criada com esse intuito pois, quando foi concebida  era bastante custoso codificar e alterar o código feito (lembre-se dos cartões perfurados, cobols da vida, etc) mas hoje isso já não é válido (com linguagens modernas, codificar é rápido e alterá-lo mais ainda). Voltando, UML, no meu ponto de vista, é muito mais documentativa do que modelagem.  Seus diagramas tem um ótimo apelo de representar graficamente um sistema e como diz um ditado: “Uma imagem vale por mil palavras”.

Um outro mito a ser desfeito, insisto, no meu ponto de vista, é de que documentar não agrega valor. Por mais que ninguém diga isso, por mais que ninguém escreva isso, por mais que ninguém assuma isso, muitos de nós considera o ato de documentar como uma atividade secundária, e com isso, delegamos para que outros façam ou, em piores casos, nem o fazemos. A questão que ninguém escreve um sistema para si e, na maioria dos casos, não fazemos isso sozinhos.  Outro ponto é que, possivelmente, não ficaremos para o resto de nossa vidas com aquele projeto, passaremos para outros desafios e aquele sistema deverá ser cuidado por outro pessoa que não necessariamente participou da equipe que o desenvolveu. Tal fato, implica em ter que forma esse pessoa de forma que ela possa dar continuidade ao aplicativo sem comprometer a qualidade dele (estou assumindo que seja aqueles projetos onde temos testes automatizados, linguagens bem expressivas, etc). Logo, tendo todo esse contexto em mente, fica fácil mostrar que documentar, no mínimo, é evitar dores de cabeça futuras.

Mas, enfim, como documentar?

A pergunta poderia ser redigida da seguinte forma para ter mais sentido para nós : Como podemos documentar sem que isso seja uma atividade secundária e agregue mais valor ao sistema? .  A maioria das linguagens modernas oferecem recursos, bastante interessantes, que podem responder essas perguntas. Em Java, nós temos o recurso básico do JavaDoc (comentários em formato especiais que são colocados no código fonte. Depois, através de ferramenta exportamos para um html), em .NET (csharp) temos algo parecido, e por ai segue. Embora isso já seja algo que ajude, considero insuficiente como documentação pois, quem irá ler não terá uma visão do funcionamento ou do comportamento do sistema.

Nesse contexto de comportamento e funcionamento que entram a ajuda primordial dos teste automatizados. Um efeito secundário dos testes automatizados (tanto os teste unitários quando os testes de comportamento) é de, se bem escritos e de grande abrangência,  eles acabam sendo uma boa fonte de consulta para o entendimento da aplicação.  Existe, inclusive, frameworks de teste de comportamento (Behavior Tests) que permitem que se escrevam de forma literal facilitando ainda mais o seu uso como documentação, como por exemplo o Cucumber (Ruby), Pyccuracy ( espero ter escrito certo – Python), etc.

Por fim, eu pessoalmente, acredito que um bom diário de bordo também ajuda bastante. Um diário de bordo, consiste, em algo parecido com um blog ( pode até ser um blog), em que vou escrevendo o dia a dia do desenvolvimento tentando retratar as decisões não técnicas e situações vencidas pela equipe de forma que a pessoa que irá trabalhar com o sistema no futuro tenha também uma visão do por que de certas escolhas, do sentimento da equipe naquele momento, etc.