Como foi descrito na seção anterior, TDD não é apenas uma prática de verificação do código-fonte. Ela é uma prática de desenvolvimento de software que ajuda a criação de um código limpo que funcione e que influencie na elaboração do design. Apesar disso, TDD não deve ser utilizado como solução única para criação de sistemas bem desenhados. É imprescindível um vasto conhecimento de programação, tais como os principais conceitos de modularização e de orientação a objetos.
Além disso, um bom design de sistema é aquele que representa adequadamente o contexto da apli- cação e as necessidades do cliente. Para isso, é fundamental o entendimento dos requisitos. Métodos ágeis recomendam que haja colaboração com o cliente, principalmente por meio da comunicação fre- quente e efetiva (preferencialmente face a face).
Contudo, há uma grande ponte entre o entendimento dos requisitos e a implementação pertinente do código-fonte do sistema e dos testes. Este distanciamento pode ser reduzido com a ajuda dos testes de aceitação e com a utilização de uma linguagem única e fluente a todos os membros da equipe, incluindo os clientes [104]. Uma das tendências das ferramentas de testes automatizados é tornar os testes cada vez mais próximos de uma documentação do sistema com linguagem natural. Algumas ferramentas criam DSLs (Domain Specific Languages) próprias para isso, como a Hamcrest; já outras geram documentos legíveis a partir do código dos testes, como a TestDox.
Entretanto, mesmo com a ajuda destas ferramentas, não é trivial criar uma linguagem ubíqua entre cliente e time de desenvolvimento. Também não é certo que as histórias serão bem definidas e os testes de aceitação serão bem implementados. A comunicação e a colaboração entre os envolvidos no desenvolvimento de um sistema de software é algo tão subjetivo que pode ser impossível determinar todos os possíveis problemas que podem ocorrer. Pensar através do comportamento de um sistema pode ajudar a amenizar essas dificuldades.
Desenvolvimento Dirigido por Comportamento (BDD de Behavior-Driven Development) é uma prática de desenvolvimento identificada por Dan North em 2003 [34]. Ela recomenda o mesmo ciclo de desenvolvimento de TDD, contudo, induzindo os participantes a utilizar uma linguagem diferente. Ao invés de usar os termos típicos de testes e verificações como test suite, test case e assert das ferramentas xUnit, as ferramentas de BDD induzem o uso de uma linguagem única (ubíqua) entre cliente e equipe de desenvolvimento. Os termos utilizados por elas são comuns em descrições de requisitos, tais como specification, behavior, context e should.
Não obstante, BDD integra explicitamente alguns princípios de DDD, de testes de aceitação e das áreas de qualidade de software para simplificar e sistematizar a definição das funcionalidades e dos cenários de teste. A definição das funcionalidades deve complementar o esqueleto definido na Figura 9.4. Este formato simples torna a descrição das funcionalidades específica, mensurável, viável, relevante e estimável. Um exemplo de história pode ser visto na Figura 9.5.
1 Funcionalidade: ...
2 Como um(a) ...
3 Quero ...
4 Com o objetivo de ...
Figura 9.4: Esqueleto de história sugerido por BDD.
1 Funcionalidade: Cálculo total de imposto da empresa
2 Como um(a) contador(a)
3 Quero somar todos impostos da empresa dentro de um período
4 Com o objetivo de exibir os dados na internet para protestar contra o governo
Figura 9.5: Exemplo de história no formato sugerido por BDD.
Os cenários de teste também possuem um esqueleto predefinido de passos, que é o padrão das descrições de teste de analistas de qualidade (Figura 9.6). Os passos Dado são semelhantes aos métodos de set up das ferramentas xUnit. Os passos Quando correspondem à chamada da funcionalidade em teste. Por último, a chamada Então é análoga às verificações. A Figura 9.7 possui um exemplo de cenário de teste para a história da Figura 9.5.
A ferramenta JBehave (primeira ferramenta de BDD), que foi criada por Dan North, baseia-se na leitura de arquivos de texto com histórias descritas no formato de passos, com uma linguagem próxima a de pessoas que não possuem perfil técnico de computação. O código dos testes (comportamentos) carregam estes arquivos e os traduzem para fazer chamadas às funcionalidades em teste. Vale ressaltar que os passos podem ser parametrizáveis, o que facilita a reutilização de código-fonte dos testes.
A ideia do JBehave é semelhante à da ferramenta Fit1, criada por Ward Cunningham por volta de
2002. A principal diferença é que, enquanto Fit trabalha com arquivos contendo diversos tipos de tabelas, JBehave trabalha com arquivos unicamente neste formato. Essas ferramentas podem ser tanto utilizadas
1 Cenário: ... 2 Dado ...
3 Quando ...
4 Então...
5
6 # Cenários mais complexos podem possuir passos extras concatenados com "E":
7 Cenário: ... 8 Dado ... 9 E ... 10 Quando ... 11 Então ... 12 E ...
Figura 9.6: Esqueleto de história sugerido por BDD.
1 Cenário: Calcular total de impostos sobre o faturamento anual
2 Dado que em 2009 a empresa faturou R$ 200.000 ,00 bruto
3 E o total de impostos chega a 40% do total bruto
4 Quando calculo o total de impostos da empresa em 2009
5 Então a empresa gastou R$ 80.000 ,00 em impostos
6 E obteve rendimento líquido de apenas R$ 120.000 ,00
Figura 9.7: Exemplo de história no formato sugerido por BDD.
para testes de unidade quanto para testes integrados (como os de aceitação). Como mostra a Figura 9.8, pode-se escrever os testes com BDD seguindo o ciclo de ATDD, descrito na Seção 3.2.
Figura 9.8: Ciclo de ATDD.
Hoje, existe uma grande gama de ferramentas de BDD para diversas linguagens de programação, todas seguindo a mesma abordagem. Dentre elas estão RSpec, Cucumber, JDave e BDoc.
9.5 Conclusões
O nível de testabilidade do sistema implica diretamente na qualidade dos testes automatizados. Mesmo que o desenvolvedor conheça padrões e boas práticas de automação, nem sempre ele conseguirá colocar em prática seu conhecimento durante a implementação dos testes porque eles precisarão necessariamente contornar as dificuldades causadas pelo alto acoplamento dos módulos e objetos da aplicação.
Quando os sistemas são implementados sem se preocupar com os possíveis cenários de testes, os sistemas tendem a possuir uma baixa testabilidade, mesmo que eles tenham arquiteturas elegantes e estejam bem implementados. Apesar de os sistemas com código-fonte de qualidade serem mais fáceis de se testar, os testes automatizados precisam ter total controle do sistema em teste para que os casos de testes sejam implementados com facilidade.
Por isso, é altamente recomendável utilizar as abordagens em que os testes são implementados antes da implementação (TFD, TDD e BDD), pois elas forçam os desenvolvedores a criarem código mais coeso, pouco acoplado e com alta testabilidade.
Entretanto, programas que possuem uma boa modelagem orientados a objetos tende a ter alta testa- bilidade. Se cada classe tiver apenas uma responsabilidade e for possível injetar suas dependências, então a preparação dos testes tornam-se mais simples com o auxílio de Objetos Dublês (vide Seção 6.2) e as verificações necessárias ficam fáceis de serem elaboradas.
Para esses casos, o uso de TAD também se torna uma alternativa promissora. TAD só deve ser evitada quando o custo da criação e da manutenção dos testes se torna mais alto do que a execução monótona e repetida dos testes manuais.
Parte III
Capítulo 10
Métricas
Métrica é uma relação de uma ou mais medidas para definir se um sistema, componente ou processo possui um certo atributo. Uma medida é uma avaliação em relação a um padrão definido. Por exemplo, para saber se um sistema é grande (atributo) podemos utilizar a medida de linhas de código, que também podemos chamar de métrica de linhas de código [128, 127], já que toda medida representa um atributo, e uma métrica pode ser composta de uma única medida.
Métricas são fundamentais para revisão, planejamento e gerenciamento de projetos. Este capítulo discute seus benefícios e apresenta algumas métricas que são pertinentes para acompanhar os testes automatizados e a qualidade do sistema. Dentre elas estão Cobertura e Testabilidade, que podem ser úteis para muitos projetos, e outras que são mais benéficas para projetos com certas características, tais como projetos legados ou os que possuem equipes inexperientes em testes.
10.1 Métricas para Testes Automatizados
Toda metodologia de desenvolvimento de software busca respeitar acordos e contratos definidos com o cliente, sejam acordos de prazos, qualidade, escopo ou custo. O sucesso de um projeto depende de organização, planejamento, gerenciamento e aprendizado.
Organização é o princípio básico para que todas as informações estejam claras para facilitar o en- tendimento do contexto e da situação corrente do projeto. Áreas de trabalho informativas [130] contendo poucas informações, mas que são muito relevantes, são mais valiosas do que documentos completos e detalhados que acabam sendo deixados em segundo plano devido ao grande tempo que é necessário para o estudo.
Planejamento é uma proposta de organização de tarefas para serem executadas [41]. A proposta é feita contendo previsões do futuro, criadas, geralmente, com base na experiência obtida de trabalhos an- teriores. Como nenhum planejamento e ninguém consegue prever o futuro com exatidão, é indiscutível que todos eles estão sujeitos a enganos. O que pode ser feito é tentar minimizar a quantidade de enganos. Para isso, os métodos ágeis recomendam trabalhar em iterações curtas de desenvolvimento, pois é mais fácil prever o futuro próximo (uma ou duas semanas) do que prever o que irá acontecer a longo prazo (meses ou anos).
Já o gerenciamento é feito pela observação do andamento do projeto e pela coordenação da equipe para concentrar o trabalho nas tarefas mais prioritárias no momento da iteração. Para observar, com êxito, o andamento dos projetos, são necessárias informações rápidas, claras, atualizadas e pertinentes [41].
O aprendizado é fundamental para o sucesso de trabalhos futuros devido à experiência adquirida que ajuda a evitar que erros sejam repetidos. Métodos ágeis incentivam a criação de reuniões de retrospec- tivas depois do término de uma iteração de desenvolvimento para revisar e relembrar o andamento do projeto, principalmente referente às dificuldades encontradas [49]. Nessa reunião, devem ser reforçados
os pontos que foram positivos e que precisam ser valorizados nas iterações seguintes, assim como é previsto que sejam encontradas soluções para aspectos que não foram satisfatórios e que precisam ser melhorados [130].
As métricas são fundamentais para qualquer metodologia alcançar o sucesso em um projeto, pois elas são um artifício básico para revisão, planejamento e gerenciamento. Como diz Morris A. Cohen: “Não podemos gerenciar o que não podemos medir” [47]. Elas exercem um papel fundamental no gerenciamento de tarefas e projetos, mas precisam ser bem organizadas e utilizadas nos momentos cor- retos. Existem estudos e abordagens sistematizadas para coleta de métricas e avaliação da qualidade de sistemas [48].
As métricas podem ser utilizadas apropriadamente quando houver necessidade de conhecer certos aspectos de um trabalho para estabelecer objetivos, como sugere o processo PDCA1 [134]. Em alguns
momentos, os problemas não estão claros ou visíveis para a equipe, por isso a coleta de métricas ajuda a identificar pontos que devem ser melhorados. As curtas iterações das metodologias ágeis seguem esta estrutura.
Quando os objetivos já estão definidos, pode-se utilizar a abordagem GQM2 [12], que sugere a
coleta unicamente das métricas pertinentes para alcançar o objetivo definido. Isso evita um esforço desnecessário de coletar e interpretar outras métricas menos importantes para o contexto. Portanto, GQM é útil para ajudar a acompanhar as soluções propostas dos problemas citados nas retrospectivas.
Uma das tarefas mais importantes do processo de desenvolvimento é gerenciar a qualidade do código-fonte e do produto produzido, que é uma tarefa complexa devido ao caráter altamente subje- tivo e pessoal da característica. Para acompanhar a evolução da qualidade, é fundamental o emprego de uma ou mais métricas que consigam representar a qualidade para o contexto do projeto.
No caso das metodologias que integram testes automatizados como controle de qualidade, em es- pecial a Programação eXtrema que recomenda TDD como uma de suas práticas primárias, é comum a coleta de métricas de testes automatizados para o acompanhamento dos testes, da qualidade do código- fonte e do produto final [11, 101]. Como os testes influenciam diretamente a qualidade e o progresso de um projeto, um bom conjunto de métricas dos testes pode elucidar o estado e ajudar a corrigir o andamento do projeto, estabelecer prioridades e estipular novas metas.
As seções seguintes apresentam algumas métricas de testes automatizados e de qualidade que são úteis tanto para equipes que estão começando a aprender e aplicar testes automatizados como para aquelas já experientes que possuem grandes baterias de testes automatizados. Também são valiosas tanto para projetos legados quanto para os recém-criados.