Como a prtica de TDD inuencia o projeto de classes em sistemas orientados a objetos

Mauricio Finavaro Aniche

Dissertao apresentada ao Instituto de Matemtica e Estatstica da Universidade de So Paulo para obteno do ttulo de Mestre em Cincia da Computao

Programa: Mestrado em Cincia da Computao Orientador: Prof. Dr. Marco Aurlio Gerosa

So Paulo, Maro de 2012

Como a prtica de TDD inuencia o projeto de classes em sistemas orientados a objetos

Este exemplar corresponde redao nal da dissertao devidamente corrigida e defendida por Mauricio Finavaro Aniche e aprovada pela Comisso Julgadora.

Comisso Julgadora: Prof. Dr. Marco Aurlio Gerosa (orientador) - IME-USP Prof. Dr. Ismar Frango Silveira - Mackenzie Prof. Dr. Rafael Prikladnicki - PUC-RS

Agradecimentos
Em primeiro lugar, gostaria de agradecer a meu orientador, Prof. Dr. Marco Aurlio Gerosa, que ao longo destes trs anos me ensinou mais do que eu poderia imaginar. Entrei no mestrado com o intuito de aprender sobre TDD, e sa de l entendendo melhor sobre cincia. Lies essas que levarei para toda minha vida na academia e indstria. Aproveito tambm para agradecer aos professores Dr. Ismar Frango Silveira e Dr. Rafael Prikladnicki, que aceitaram participar da banca avaliadora e deram excelentes sugestes durante a qualicao. Gostaria tambm de agradecer aos amigos Gustavo Oliva e Mauricio de Diana, que criticaram a pesquisa durante todo o tempo, fazendo-me pensar novamente sobre vrias das minhas crenas em engenharia de software. Gostaria muito que continussemos nosso grupo de pesquisa, pois devo a vocs grande parte do que aprendi no mestrado. Agradeo tambm a minha famlia, amigos e namorada, por terem me dado todo o suporte emocional que precisei ao longo desta caminhada. Uma meno especial ao meu pai, que me presenteou com um livro de programao para crianas quando eu tinha por volta de 9 anos. Talvez, sem esse presente, essa pesquisa nunca teria acontecido. Agradeo aos meus amigos de trabalho da Locaweb e Caelum Ensino e Inovao, por aguentar meus discursos e palestras sobre TDD, e mostrar diferentes pontos de vista. Isso me ajudou a entender mais sobre a prtica, o que resultou em uma discusso mais rica ao longo do trabalho. Por m, agradeo s empresas que aceitaram participar do meu estudo, Bluesoft, Amil, e WebGoal (So Paulo e Poos de Caldas). Alm disso, obrigado aos meus colegas de prosso Rafael Werner, Murilo Amndola e Juan Lopes, por tambm terem participado da pesquisa de maneira independente. Fico muito feliz por ter sido bem recebido pela indstria, e espero que possamos continuar essa parceria entre academia e indstria. Um forte abrao a todos!

Resumo
Como a prtica de TDD inuencia o projeto de classes em sistemas orientados a objetos Desenvolvimento Guiado por Testes (TDD) uma das prticas sugeridas na Programao Extrema. A mecnica da prtica simples: o programador escreve o teste antes de escrever o cdigo. , portanto, possvel inferir que a prtica de TDD uma prtica de testes de software. Entretanto, muitos autores de livros conhecidos pela indstria e academia armam que os efeitos da prtica vo alm. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura so voltados a descobrir se a prtica faz diferena na qualidade do cdigo gerado, mas poucos so os autores que discutem como a prtica realmente auxilia. Mesmo os prprios praticantes no entendem ou conseguem expressar bem como a prtica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua prtica inuencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entend-las, neste trabalho optamos por um estudo exploratrio essencialmente qualitativo, no qual participantes foram convidados a resolver exerccios pr-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, ns levantamos detalhes sobre como a prtica inuenciou as decises de projeto de classes dos participantes por meio de entrevistas. Ao nal, observamos que a prtica de TDD pode guiar o desenvolvedor durante o processo de criao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possveis problemas, como alto acoplamento ou baixa coeso. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padres de feedback percebidos pelos participantes. Palavras-chave: Desenvolvimento Guiado por Testes, Sistemas Orientados a Objetos, Projeto de Classes, Qualidade Interna de Cdigo.

ii

Abstract
How the practice of TDD inuences the class design on object-oriented systems Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on nding the dierence between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the eects of TDD and how the practice inuences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice inuenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants. Keywords: Test-Driven Development, Object-Oriented Systems, Class Design, Internal Code Quality.

iii

Sumrio

Lista de Abreviaturas Lista de Figuras Lista de Tabelas 1 Introduo 1.1 1.2 1.3 1.4 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caracterizao da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii ix ix 1 2 2 3 3 4 4 4 5 6 6 8 9 11

2 Desenvolvimento Guiado por Testes 2.1 2.2 2.3 2.4 2.5 Mtodos geis de Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . . . Desenvolvimento Guiado por Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benefcios de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Possveis Efeitos no Projeto de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 2.5.2 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posio desta pesquisa na literatura atual . . . . . . . . . . . . . . . . . . . .

3 Planejamento e Execuo do Estudo 3.1 3.2 3.3 3.1.1

Caractersticas de pesquisas qualitativas . . . . . . . . . . . . . . . . . . . . . . . . . 12 Estudos mistos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Questes de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Projeto da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 Participantes da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Resoluo dos problemas propostos . . . . . . . . . . . . . . . . . . . . . . . . 14 Problemas Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Questionrio ps-experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Escolha de candidatos para a entrevista . . . . . . . . . . . . . . . . . . . . . 16 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Mtricas de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Avaliao do Especialista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 3.5 3.6

Anlise dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Validade e Conabilidade do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Papel do Pesquisador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 iv

SUMRIO

3.7 3.8 3.9

Questes ticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Estudo piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Execuo do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.10 Descrio dos participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4 Relao entre TDD e Projeto de Classes: Anlise Quantitativa 4.1 4.2 4.3 25

Mtricas de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.1 Inspeo do Cdigo-Fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28

5 Relao entre TDD e Projeto de Classes: Anlise Qualitativa 5.1 5.2

Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Anlise das Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 Segurana na refatorao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Passos menores e simplicidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Espao para se pensar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Feedback mais rpido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Busca pela testabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Padres Ligados Coeso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Padres Ligados ao Acoplamento . . . . . . . . . . . . . . . . . . . . . . . . . 35 Padres Ligados Falta de Abstrao . . . . . . . . . . . . . . . . . . . . . . 36 Relao dos padres com os princpios de projeto de classes . . . . . . . . . . 36 37

5.3

Padres de Feedback de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.1 5.3.2 5.3.3 5.3.4

6 Ameaas Validade 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.2 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.4 6.4.1

Validade de Construo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Exerccios de pequeno porte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Criao dos exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Mtricas selecionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Estudos piloto no foram at o m . . . . . . . . . . . . . . . . . . . . . . . . 37 Falta de medio sobre a utilizao da prtica de TDD . . . . . . . . . . . . . 37 Seleo dos candidatos para entrevista . . . . . . . . . . . . . . . . . . . . . . 38 Efeitos recentes de TDD na memria . . . . . . . . . . . . . . . . . . . . . . . 38 Exerccios inacabados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Inuncia do pesquisador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Desejabilidade social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Quantidade de participantes insuciente . . . . . . . . . . . . . . . . . . . . . 39 Padres encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Validade interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Validade externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Validade de Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

vi

SUMRIO

7 Concluses e Trabalhos Futuros 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8

40

Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Qual a inuncia de TDD no projeto de classes? . . . . . . . . . . . . . . . . . . . . 40 Qual a relao entre TDD e as tomadas de decises de projeto feitas por um desenvolvedor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Como a prtica de TDD inuencia o programador no processo de projeto de classes, do ponto de vista do acoplamento, coeso e complexidade? . . . . . . . . . . . . . . . 41 Lies Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Produes ao Longo do Mestrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 44

A Projeto de Classes em Sistemas Orientados a Objetos

A.1 Sintomas de Projetos de Classes em Degradao . . . . . . . . . . . . . . . . . . . . . 44 A.1.1 Rigidez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.1.2 Fragilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.1.3 Imobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1.4 Viscosidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1.5 Complexidade Desnecessria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1.6 Repetio Desnecessria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1.7 Opacidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.2 Princpios de Projeto de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.2.1 Princpio da Responsabilidade nica . . . . . . . . . . . . . . . . . . . . . . . 46 A.2.2 Princpio do Aberto-Fechado . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 A.2.3 Princpio de Substituio de Liskov . . . . . . . . . . . . . . . . . . . . . . . . 47 A.2.4 Princpio da Inverso de Dependncias . . . . . . . . . . . . . . . . . . . . . . 48 A.2.5 Princpio da Segregao de Interfaces . . . . . . . . . . . . . . . . . . . . . . . 48 A.3 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 B Protocolo do estudo 49

B.1 Execuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 B.2 Anlise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 C Questionrio inicial D Exerccios 50 51

D.1 Lembrete ao participante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 D.2 Exerccio 1 - Calculadora de Salrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 D.3 Exerccio 2 - Gerador de Nota Fiscal . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.4 Exerccio 3 - Processador de Boletos . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.5 Exerccio 4 - Filtro de Faturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 E Questionrio ps-experimento 54

E.1 O Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 E.2 Cdigo gerado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

SUMRIO

vii

E.3 Prtica de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 F Entrevista 55

F.1 Dados bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 F.2 A Prtica de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 F.3 Relao entre TDD e projeto de classes . . . . . . . . . . . . . . . . . . . . . . . . . 55 F.4 Relao entre TDD e experincia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 F.5 Resumo dos Pontos Encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 F.6 Opinies nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 G Informaes ao participante 57

G.1 Convite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 G.2 Qual o objetivo desta pesquisa? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 G.3 Qual meu papel dentro dela? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 G.4 Quais so os benefcios? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 G.5 Minha privacidade ser garantida? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 G.6 Qual o tempo de participao na pesquisa? . . . . . . . . . . . . . . . . . . . . . . . 57 G.7 Em caso de dvidas, o que devo fazer? . . . . . . . . . . . . . . . . . . . . . . . . . . 58 H Autorizao 59

H.1 Consentimento de Participao na Pesquisa . . . . . . . . . . . . . . . . . . . . . . . 59 Referncias Bibliogrcas 60

Lista de Abreviaturas
TDD XP BDUF PRU PID PAF PSL PSI OO WBMA Desenvolvimento Guiado por Testes (do ingls, Test-Driven Development ) Programao Extrema (do ingls, Extreme Programming ) Projeto de Classe Criado de Uma S Vez (Big Design Up-Front ) Princpio da Responsabilidade nica (Single Responsibility Principle ) Princpio da Inverso de Dependncias (Single Responsibility Principle ) Princpio do Aberto-Fechado (Open-Closed Principle ) Princpio da Substituio de Liskov (Liskov Substitution Principle ) Princpio da Segregao de Interfaces (Interface Segregation Principle ) Orientao a Objetos Workshop Brasileiro de Mtodos geis

viii

Lista de Figuras

2.1 3.1 3.2 3.3 5.1 5.2

Posio desta pesquisa na literatura atual . . . . . . . . . . . . . . . . . . . . . . . . 10 Processo de anlise dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Experincia dos participantes da indstria com TDD . . . . . . . . . . . . . . . . . . 23 Experincia dos participantes da indstria com desenvolvimento de software em geral 23 Feedback provido pela prtica de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Prticas de XP e Tempo de Feedback (baseado em [Van05]) . . . . . . . . . . . . . . 34

Lista de Tabelas

2.1 3.1 3.2 3.3 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Relao entre efeitos de TDD e estudos na literatura . . . . . . . . . . . . . . . . . .

Exerccios propostos e mau cheiros de projeto de classes . . . . . . . . . . . . . . . . 15 Informaes que so extradas do questionrio ps-experimento. . . . . . . . . . . . . 16 Experincia em Java, JUnit, e Objetos Dubl dos participantes da indstria . . . . . 24 P-values encontrados para a diferena entre cdigos com e sem TDD na indstria . . 25 P-values encontrados para a diferena na Complexidade Ciclomtica entre experientes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 P-values encontrados para a diferena no Fan-Out entre experientes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 P-values encontrados para a diferena na falta de coeso nos mtodos entre experientes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 P-values encontrados para a diferena na quantidade de mtodos por classe entre experientes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . 26 P-values encontrados para a diferena no nmero de linhas por mtodo entre experientes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 P-values encontrados para a diferena entre as anlises dos especialistas com e sem TDD na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1

Relao entre os padres de feedback de TDD e mau cheiros de projeto de classes . . 36

ix

LISTA DE TABELAS

Captulo 1

Introduo
Desenvolvimento Guiado por Testes, traduo do termo em ingls Test-Driven Development (TDD), uma das prticas sugeridas pela Programao Extrema (XP) [Bec04]. A prtica baseada em um pequeno ciclo, no qual o desenvolvedor escreve um teste antes de implementar a funcionalidade esperada e, depois, com o cdigo passando no recm-criado teste, refatora para remover possveis duplicao de dados e de cdigo [Bec02]. Com a prtica de TDD, um desenvolvedor s escreve cdigo que seja coberto por um teste. Por esse motivo, comum relacionar a prtica de TDD com a rea de teste de software. Mas, alm do ponto sobre a qualidade externa do cdigo, um discurso comum entre os praticantes de TDD na indstria os efeitos da prtica tambm sobre a qualidade interna do cdigo. Autores de livros conhecidos pela indstria e academia, como Kent Beck [Bec02], Robert Martin [Mar06], Steve Freeman [eNP09] e Dave Astels [Ast03], armam que a prtica de TDD promove uma melhoria signicativa no projeto de classes, auxiliando o programador a criar classes mais coesas e menos acopladas. Entretanto, a maneira na qual a prtica de TDD guia o desenvolvedor durante o processo de criao do projeto de classes no clara. Observamos isso em nosso estudo qualitativo com os praticantes de TDD, feito dentro de um evento de desenvolvimento gil brasileiro, no qual entrevistamos dez participantes da conferncia sobre os efeitos de TDD e, para nossa surpresa, nenhum soube armar, com clareza, como a prtica os guia em direo a um bom projeto de classes [AFG11]. Siniaalto e Abrahamsson [SA08] tambm compartilham dessa opinio e, alm disso, notaram que os efeitos de TDD podem no ser to automticos ou evidentes como o esperado. Os prprios trabalhos relacionados, discutidos na Seo 2.5, apenas avaliam se a prtica de TDD faz diferena na qualidade dos cdigos produzidos. Poucos deles possuem um estudo qualitativo, detalhando como a prtica faz tal diferena. Com essa informao em mos, os desenvolvedores saberiam, de forma mais clara, como utilizar a prtica de TDD para obter uma maior qualidade no processo de criao do projeto de classes. Entretanto, para entender essas razes necessrio conduzir uma pesquisa no mundo real, o que implica um equilbrio entre o nvel de controle e o grau de realismo. Uma situao realista , geralmente, complexa e no determinstica, dicultando o entendimento sobre o que acontece. Por outro lado, aumentar o controle sobre o experimento reduz o grau de realismo, muitas vezes fazendo com que os reais fatores de inuncia quem fora do escopo do estudo [RH09]. Baseando-se no fato de que o processo de desenvolvimento de software envolve diversos fatores humanos e totalmente sensvel ao contexto em que ele est inserido, neste trabalho optamos por um estudo exploratrio essencialmente qualitativo, no qual participantes foram convidados a

INTRODUO

1.3

resolver exerccios pr-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, detalhes sobre como a prtica inuenciou as decises de projeto de classes foram extrados dos participantes atravs de entrevistas. Ao nal do estudo, acabamos por encontrar diversos padres de feedback que a prtica de TDD d ao desenvolvedor ao longo do projeto de classes. Esses padres podem ser interpretados como pequenas evidncias que o desenvolvedor, ao praticar TDD, encontra sobre possveis mau cheiros em seu cdigo. Esses padres so extrados pelo desenvolvedor atravs do teste de unidade que escrito pelo desenvolvedor enquanto pratica TDD. Eles foram discutidos e detalhados no Captulo 5.

1.1

Motivao

Esta pesquisa possui diversas motivaes. A primeira delas a crescente popularidade da prtica de TDD, tanto por parte da indstria, quanto por parte da academia. Alm disso, conforme discutido anteriormente, os efeitos da prtica de TDD so comumente mencionados por autores de livros, mas pouco explorados. Entender como a prtica de TDD pode inuenciar no processo de criao do projeto de classes pode trazer grandes benefcios aos desenvolvedores de software de maneira geral. Descobrir problemas de projeto de classes sempre foi um grande problema enfrentado pela indstria. Como descrito pela Lei da Evoluo de Software [Leh96], cdigos tendem a perder qualidade ao longo do tempo. Qualquer prtica que ajude desenvolvedores a encontrar de forma mais rpida possveis problemas em seus cdigos, deve ser estudada e avaliada pelas equipes de desenvolvimento. TDD frequentemente mencionado como uma possvel prtica para ajudar o desenvolvedor na rdua tarefa de criar projetos de classes exveis. Ao saber de maneira mais precisa como a prtica de TDD inuencia no projeto de classes, desenvolvedores poderiam fazer melhor uso da prtica, obter informaes sobre seu projeto de classes de maneira mais frequente e diminuir a velocidade na qual cdigos tendem a degradar.

1.2

Caracterizao da Pesquisa

Este trabalho visa compreender a inuncia de TDD no projeto de classes. Para isso, avaliamos a relao entre a prtica de TDD e as decises de projeto de classes tomadas pelos desenvolvedores no processo de criao de classes. A anlise foi feita por meio de dados que foram capturados baseados na percepo de programadores atuantes na indstria, aps a implementao de alguns pequenos problemas especialmente criados para esta pesquisa. O objetivo principal deste estudo entender a relao da prtica de TDD e as decises de projeto de classes tomadas pelo programador durante o processo de projeto de sistemas orientados a objetos. Para compreend-la, tentou-se responder s questes listadas abaixo: 1. Qual a inuncia de TDD no projeto de classes? 2. Qual a relao entre TDD e as tomadas de decises de projeto feitas por um desenvolvedor? 3. Como a prtica de TDD inuencia o programador no processo de projeto de classes, do ponto de vista do acoplamento, coeso e complexidade?

1.4

CONTRIBUIES

1.3

Contribuies

As contribuies deste trabalho para a rea de engenharia de software so: 1. Padres de feedback da prtica de TDD que guiam os desenvolvedores ao longo do processo de criao do projeto de classes; 2. Protocolo de um estudo qualitativo sobre os efeitos da prtica de TDD no projeto de classes, bem como lies aprendidas sobre a execuo do mesmo;

1.4

Organizao do trabalho

Este trabalho est dividido da seguinte maneira: O Captulo 2 discute sobre a prtica de TDD, com nfase no ponto de vista do projeto de classes, e mostra trabalhos j realizados pela academia sobre os efeitos de TDD; O Captulo 3 discute o planejamento e execuo do estudo, bem como o processo de captura de dados e anlise; O Captulo 5 apresenta os resultados encontrados no estudo qualitativo e os discute; O Captulo 4 apresenta os resultados encontrados no estudo quantitativo e os discute; O Captulo 6 discute as possveis ameaas aos resultados encontrados na pesquisa; O Captulo 7 resume o trabalho realizado, apresenta as lies aprendidas, resultados esperados, produes gerados ao longo do mestrado e possibilidades de trabalhos futuros.

Captulo 2

Desenvolvimento Guiado por Testes

2.1 Mtodos geis de Desenvolvimento de Software

Desenvolver software uma atividade complexa, caracterizada por tarefa e requisitos que tendem a mudar constantemente [BB05]. Mtodos geis de desenvolvimento de software apareceram para atacar os diversos problemas que aparecem devido ao alto grau de incerteza existente no processo, consequente da constante mudana de requisitos e prioridades. As ideias geis, sumarizadas no manifesto conhecido por Manifesto gil , baseiam-se em valores como comunicao, feedback constante, colaborao com o cliente e constante adaptao. Os quatro mandamentos principais do manifesto deixam claro o que se espera de qualquer mtodo gil: Indivduos e interaes sobre processos e ferramentas; Software funcionando sobre documentao extensiva; Colaborao com o cliente sobre negociao de contrato; Responder a mudanas sobre seguir um planejamento. Erdogmus, na introduo do livro de Dingsyr [TDM10], cita que desenvolvimento gil de software o mais importante paradigma de desenvolvimento de software que apareceu na ltima decada. Mesmo que no represente o mais popular deles, com certeza o mais comentado.. Um desses mtodos geis, conhecido por Programao Extrema (do ingls, Extreme Programming, ou XP), bastante popular entre desenvolvedores de software, uma vez que discute prticas de focadas em cdigo, como programao pareada, integrao contnua e desenvolvimento guiado por testes. Neste trabalho, estamos interessados apenas em uma das prticas mencionadas por XP, que desenvolvimento guiado por testes, discutido na seo a seguir.

2.2

Desenvolvimento Guiado por Testes

Mtodos geis de desenvolvimento de software focam em constante feedback, seja ele da equipe em relao ao cliente, seja da qualidade (interna e externa) do cdigo produzido equipe [BBvB+ 01]. Com isso, muitas das prticas sugeridas por mtodos geis visam aumentar a quantidade e a qualidade desse feedback ; a ideia da programao pareada, por exemplo, dar feedback sobre o cdigo durante sua escrita. Desenvolvimento Guiado por Testes (conhecido por TDD, ou, Test-Driven Development ), prtica popularizada por Kent Beck por meio de seu livro TDD: By Example em 2001 [Bec02], mais
0

http://www.agilemanifesto.org. ltimo acesso em 02/06/2012.

2.3

BENEFCIOS DE TDD

uma das prticas geis na qual o foco dar feedback. TDD tem grande importncia durante o ciclo de desenvolvimento uma vez que, conforme sugerido pelas prticas geis, o projeto de classes de um software deve emergir medida que o software cresce. E, para responder rapidamente a essa evoluo, necessrio um constante feedback sobre a qualidade interna e externa do cdigo. TDD uma prtica de desenvolvimento de software que se baseia na repetio de um pequeno ciclo de atividades. Primeiramente, o desenvolvedor escreve um teste que falha. Em seguida, o faz passar, implementando a funcionalidade desejada. Por m, refatora o cdigo para remover qualquer duplicao de dados ou de cdigo gerada pelo processo. Alm disso, simplicidade deve ser tambm algo intrnseco ao processo; o praticante busca escrever o teste mais simples que falhe e escrever a implementao mais simples que faa o teste passar. Esse ciclo tambm conhecido como "Vermelho-Verde-Refatora"(ou "Red-Green-Refactor" ), uma vez que lembra as cores que um desenvolvedor normalmente v quando faz TDD: o vermelho signica que o teste est falhando, e o verde que o teste foi executado com sucesso. Este captulo aborda a prtica de TDD, bem como cita seus possveis efeitos no processo de desenvolvimento de software, conforme relatado pela literatura.

2.3

Benefcios de TDD

Uma consequncia da prtica de TDD a bateria de testes de unidade gerada. A prtica ajuda o programador a evitar erros de regresso, em que a implementao de uma nova funcionalidade quebra uma outra funcionalidade j existente no sistema. Essa bateria tambm prov segurana durante as constantes refatoraes de cdigo que so feitas durante o processo de desenvolvimento. A quantidade de cdigo coberto pelos testes tambm tende a ser alta, uma vez que o desenvolvedor deve sempre escrever um teste antes de implementar uma nova funcionalidade. comum relacionar TDD a prticas de testes de software. No entanto, apesar de constar o termo teste no nome, TDD no visto apenas como uma prtica de testes. Embora a criao de testes seja algo intrnseco ao processo, dito que TDD tambm auxilia o desenvolvedor a criar classes mais exveis, mais coesas e menos acopladas [Bec01] [Mar02] [Ast03]. Os testes so a ferramenta que o programador utiliza para validar o projeto de classes criado. Por esse motivo, muitos se referem a TDD como Projeto de Classes Guiado por Testes [JS05]. Autores como Kent Beck [Bec01], Dave Astels [Ast03] e Robert Martin [Mar02] armam que TDD , na verdade, uma prtica de projeto de classes [JS05] [Bec01]. Na opinio desses autores, a mudana na ordem do ciclo de desenvolvimento tradicional, apesar de simples, agrega diversos outros benefcios ao cdigo produzido: maior simplicidade, menor acoplamento e maior coeso das classes criadas, levando a um melhor projeto de classes, entre outros. Ward Cunningham, um dos pioneiros da Programao Extrema, resume essa discusso em uma frase: "Test-First programming is not a testing technique" que, em uma traduo livre, signica "Escrever primeiro os testes no uma prtica de testes". No entanto, possvel encontrar muitas denies que no levam tal armao em conta. Algumas delas consideram apenas a ideia da inverso da ordem de desenvolvimento, na qual o programador primeiro escreve o teste e depois escreve o cdigo que o faa passar. Um exemplo a denio que pode ser encontrada no livro JUnit in Action [MH03]: "TestDriven Development uma prtica de programao que instrui desenvolvedores a escrever cdigo novo apenas se um teste automatizado estiver falhando, e a eliminar duplicao. O objetivo de TDD cdigo claro que funcione".

DESENVOLVIMENTO GUIADO POR TESTES

2.5

Janzen levantou esse problema nas denies e comenta que um possvel motivo o prprio nome da prtica, uma vez que ela possui a palavra testes, mas no contm a palavra projeto [JS08]. Segundo ele, uma denio mais clara a de que TDD a arte de produzir testes automatizados para cdigo de produo, usando esse processo para guiar o projeto e a programao [All05] [JS05].

2.4

Possveis Efeitos no Projeto de Classes

Como mencionado anteriormente, os praticantes de TDD acreditam que os testes de unidade podem ajud-los a criar um projeto de classes de qualidade. Uma das explicaes mais populares para esse fenmeno a relao entre um cdigo que possui uma alta testabilidade, ou seja, fcil de ser testado por meio de um teste de unidade, e um projeto de classes de alta qualidade [Fea07]. TDD tambm sugere que o programador d sempre pequenos passos (conhecidos pelo termo em ingls, baby steps ): deve-se escrever testes sempre para a menor funcionalidade possvel, escrever o cdigo mais simples que faa o teste passar e fazer apenas uma refatorao por vez [Bec02]. Uma justicativa para tal a de que, quanto maior o passo que o programador d, mais tempo ele leva para conclu-lo e, consequentemente, ele ca mais tempo sem feedback sobre o cdigo. Alm disso, faz com que o programador no crie solues mais complexas do que elas precisam ser, tornando o cdigo, a longo prazo, o mais simples possvel. No entanto, apesar de muito ser dito sobre os efeitos de projeto de classes, e alguns deles at serem demonstrados em estudos (conforme citado na Seo 2.5), pouco se sabe como a prtica realmente inuencia os desenvolvedores no momento da criao do projeto das classes. Para que possamos denir o que esperamos de um projeto de classes, discutimos no Apndice A prncipios de projeto de classes orientados a objetos, baseados no trabalho de Martin [Mar02], que sero utilizados na avaliao dos cdigos produzidos pelos participantes deste estudo.

2.5

Trabalhos Relacionados

Muitos estudos empricos j foram realizados para avaliar os efeitos de TDD. Em grande parte deles, os possveis efeitos da prtica no projeto de classes no levado em conta, e apenas os efeitos da prtica na qualidade externa so medidos, conforme apresentado ao longo dessa seo. Alm disso, diferentemente do que esta pesquisa prope, muitos desses estudos optaram por um maior controle no experimento, e os realizaram dentro de ambientes acadmicos com estudantes dos mais diversos cursos de computao. Janzen [Jan05] mostrou que programadores que usam TDD na indstria produziram cdigo que passaram em, aproximadamente, 50% mais testes caixa-preta do que o cdigo produzido por grupos de controle que no usavam TDD. O grupo que usava TDD gastou menos tempo depurando. Janzen tambm apontou que a complexidade dos algoritmos era muito menor e a quantidade e cobertura dos testes era maior nos cdigos escritos com TDD. Outros trabalhos realizados na indstria tambm apresentam resultados parecidos. Um estudo feito por Maximillien e Williams [MW03] mostrou uma reduo de 40-50% na quantidade de defeitos e um impacto mnimo na produtividade quando programadores usaram TDD. Outro estudo feito por Lui e Chan [LC04] comparando dois grupos, um utilizando TDD e o outro escrevendo testes apenas aps a implementao, mostrou uma reduo no nmero de defeitos no grupo que utilizava TDD. Alm disso, os defeitos que foram encontrados eram corrigidos mais rapidamente pelo grupo que utilizou TDD. O estudo feito por Damm et al. [DLO05] tambm mostra uma reduo em torno de 40% a 50% na quantidade de defeitos.

2.5

TRABALHOS RELACIONADOS

O estudo feito por George e Williams [GW03] mostrou que, apesar de TDD poder reduzir inicialmente a produtividade dos desenvolvedores mais inexperientes, o cdigo produzido passou entre 18% a 50% mais em testes caixa-preta do que cdigos produzidos por grupos que no utilizavam TDD. Esse cdigo tambm apresentou uma cobertura de testes entre 92% a 98%. Uma anlise qualitativa mostrou que 87.5% dos programadores acreditam que TDD facilitou o entendimento dos requisitos e 95.8% acreditam que TDD reduziu o tempo gasto com depurao. 78% tambm acreditam que TDD aumentou a produtividade da equipe. Entretanto, apenas 50% dos participantes disseram que TDD ajuda a diminuir o tempo de desenvolvimento. Sobre qualidade, 92% pensam que TDD ajuda a manter um cdigo de maior qualidade e 79% acreditam que ele promove um projeto de classes mais simples. Turnu et al. [Tea04] discutem produtividade em projetos de cdigo aberto. Segundo eles, a produtividade caiu quando TDD foi adotado completamente, mas em compensao o nmero de problemas diminuiu consideravelmente. Nagappan [BN06] conduziu estudos de caso na Microsoft e na IBM e os resultados indicaram que o nmero de defeitos de quatro produtos diminuiu de 40% a 90% em relao a projetos similares que no usaram TDD. Entretanto, o estudo mostrou tambm que TDD aumentou o tempo inicial de desenvolvimento entre 15% a 35%. Langr [Lan01] apontou que TDD aumenta a qualidade cdigo, prov uma facilidade maior de manuteno e ajuda a produzir 33% mais testes comparado a abordagens tradicionais. Um estudo feito por Erdogmus et al. [EMT05] com 24 estudantes de graduao mostrou que TDD aumenta a produtividade. Entretanto, nenhuma diferena de qualidade no cdigo foi encontrada. Outro estudo feito por Janzen [JS06] com trs diferentes grupos de alunos (cada um deles usando uma abordagem diferente: TDD, testes depois, sem testes) mostrou que o cdigo produzido pelo time que fez TDD usou melhor os conceitos de orientao a objetos e as responsabilidades foram separadas em 13 diferentes classes, enquanto os outros times produziram um cdigo mais procedural. O time de TDD tambm produziu mais cdigo e entregou mais funcionalidades. Os testes produzidos por esse time tiveram duas vezes mais asseres que os outros e cobriram 86% mais possveis caminhos no cdigo do que o time test-last. As classes testadas tinham valores de acoplamento 104% menor do que as classes no testadas e os mtodos eram, na mdia, 43% menos complexos do que os no-testados. Dogsa e Batic [DB11] tambm encontraram uma melhora no projeto de classes feita com TDD. Mas, segundo os autores, essa melhora consequncia da simplicidade que a prtica de TDD agrega ao processo. Eles tambm armaram que a bateria de testes de regresso gerada durante a prtica possibilita ao desenvolvedor a constante refatorao do cdigo. Li [Li09] props um estudo qualitativo para entender a eccia de TDD. Por meio de um estudo de caso, ela coletou as percepes de benefcios que os praticantes de TDD tm sobre a prtica. Para isso ela fez uso de cinco entrevistas semi-estruturadas realizadas em empresas de software de Auckland, Nova Zelndia. Os resultados das entrevistas foram analisados e alinhados com os maiores temas discutidos sobre o assunto na literatura: qualidade de cdigo, qualidade da aplicao e produtividade do desenvolvedor. No que diz respeito qualidade de cdigo, Li chegou a concluso de que TDD guia o desenvolvedor para classes mais simples e com melhor projeto de classes. Alm disso, o cdigo tende a ser mais simples e fcil de ler. De acordo com o trabalho, os principais fatores que contribuem para esses benefcios a maior conana em refatorar e modicar cdigo,

DESENVOLVIMENTO GUIADO POR TESTES

2.5 Tipo de Estudo Quantitativo Qualitativo Quantitativo Quantitativo Qualitativo Quantitativo Quantitativo Quantitativo Trabalho [Jan05], [JS06] [Li09], [GW03] [Lan01] [JS06] [Li09], [Pro09] [JS06], [Ste01] [JS06], [Ste01] [MH02]

Possvel Efeito Simplicidade Facilidade de manuteno Melhor utilizao de conceitos de orientao a objetos Separao de responsabilidades Menor acoplamento Maior reso de classes

Tabela 2.1: Relao entre efeitos de TDD e estudos na literatura

uma maior cobertura de testes, entendimento mais profundo dos requisitos, maior facilidade na compreenso do cdigo, grau e escopo de erros reduzidos, alm de uma maior satisfao pessoal do desenvolvedor. O prossional da prtica de TDD geralmente faz uso tambm de outras prticas geis, como programao pareada, o que pode dicultar o processo de avaliao dos benefcios de TDD. Madeyski [Mad06] observou os resultados entre grupos que praticavam TDD, grupos que praticavam programao pareada, e a combinao entre elas, e no conseguiu mostrar grande diferena entre equipes que utilizam programao pareada e equipes que utilizam TDD, no que diz respeito ao gerenciamento de dependncias entre pacotes de classes. Entretanto, ao combinar os resultados, Madeyski encontrou que TDD pode ajudar no nvel de gerenciamento de dependncias entre classes. Segundo ele, o programador deve utilizar TDD, mas car atento a possveis problemas de projeto de classes. O estudo de Muller e Hagner [MH02] apontou que TDD no resulta em melhor qualidade ou produtividade. Entretanto, os estudantes avaliados perceberam um melhor reso dos cdigos produzidos com TDD. Steinberg [Ste01] mostrou que cdigo produzido com TDD mais coeso e menos acoplado. Os estudantes tambm reportaram que os defeitos eram mais fceis de serem corrigidos. A pesquisa feita por Edwards [Edw03], com 59 estudantes, mostrou que o cdigo produzido com TDD tem 45% menos defeitos e faz o programador se sentir mais vontade com ele. Aprender TDD tambm no tarefa fcil. Mugridge [Mug03] identicou dois desaos principais em ensinar TDD: fazer os estudantes pensarem novamente sobre o projeto de classes, e faz-los se envolver com essa nova abordagem. Contudo, segundo Proulx [Pro09], a partir do momento em que o estudante aprende TDD, ele tende a ter uma melhor performance em disciplinas de orientao a objetos. Segundo ele, essa melhora percebida inclusive pelos empregadores desses alunos. Como os estudos discutidos acabam por misturar efeitos da prtica de TDD na qualidade externa e interna, a Tabela 2.1 mostra quais trabalhos apontaram efeitos no projeto de classes. Outras compilaes de estudos sobre TDD tambm podem ser encontradas no livro Test-Driven Development: An Empirical Evaluation of Agile Practice, escrito por Madeyski [Mad09] ou no trabalho entitulado Test driven development: empirical body of evidence, feito por Siniaalto [Sin06]. 2.5.1 Discusso

Como apresentado, poucos trabalhos avaliam os efeitos de TDD sobre o projeto de classes. Quando o fazem, apenas discutem quais os efeitos da prtica e no exatamente como TDD os inuencia. Josefsson [Jos04], em sua discusso sobre a necessidade de uma fase de projeto arquitetural e os efeitos de TDD nesse quesito, chega mesma concluso. Segundo ele, os estudos sobre

2.5

TRABALHOS RELACIONADOS

TDD encontrados na literatura atual so muito limitados e no so generalizveis. Por esse motivo, os ditos efeitos que TDD tm sobre o projeto de classes no podem ser provados. Com base no levantamento bibliogrco realizado, acreditamos que esta limitao se mantm. Grande parte desses estudos tambm no levam em conta a experincia do programador que est praticando TDD. Geralmente esse ponto discutido apenas na seo de ameaas validade do estudo. Janzen, em seu doutorado, percebeu que desenvolvedores mais maduros obtm mais benefcios de TDD, escrevendo classes mais simples. Alm disso, desenvolvedores maduros que experimentam a prtica tendem a optar por TDD mais do que desenvolvedores menos experientes [Jan06]. Os trabalhos que analisam TDD do ponto de vista de projeto de classes, no entanto, no chegam a resultados conclusivos; muitos deles dizem que os efeitos de TDD no so to diferentes daqueles dos times que no praticam TDD. A prpria tese de doutorado de Janzen foi inconclusiva no que diz respeito inuncia de TDD no acoplamento e na coeso [Jan06]. Alm disso, outro ponto fortemente relacionado com projeto de classes a simplicidade e facilidade de evoluo. Um projeto de classes rgido, no favorvel a mudanas, difcil de ser avaliado de maneira quantitativa. Complexidade desnecessria tambm totalmente subjetiva. Portanto, nossa crtica com relao aos trabalhos relacionados justamente na anlise feita sobre os efeitos da prtica no TDD. necessrio mais do que uma comparao analtica; o ponto de vista dos desenvolvedores, que atuam naquele cdigo-fonte durante todo o dia de trabalho deve ser levado em considerao. 2.5.2 Posio desta pesquisa na literatura atual

Esta pesquisa se mostra diferente da maioria dos trabalhos encontrados na literatura atual. Alm de observar TDD pelo ponto de vista nica e exclusivamente do projeto de classes, colhe-se informaes baseadas no ponto de vista de desenvolvedores que a praticam. Talvez o trabalho mais parecido com o que proposto aqui o realizado por Angela Li, em 2009, que apresenta um estudo qualitativo sobre os efeitos de TDD no processo de desenvolvimento de software [Li09]. A diferena que esta pesquisa se concentra em entender os efeitos de TDD no projeto de classes. Alm disso, diferentemente de outros trabalhos qualitativos, nossas entrevistas foram abertas e totalmente focadas na criao do projeto de classes. Muitos argumentos interessantes surgiram ao fazer o programador pensar melhor a respeito sobre o assunto. O caminho em destaque da Figura 2.1 mostra a nossa posio em relao ao que j encontrado na literatura.

10

DESENVOLVIMENTO GUIADO POR TESTES

2.5

Figura 2.1: Posio desta pesquisa na literatura atual

Captulo 3

Planejamento e Execuo do Estudo

Conduzir um estudo experimental em engenharia de software sempre foi uma atividade difcil. Uma das razes para isso o fator humano, muito presente no processo de desenvolvimento de software, como sugerido por mtodos geis em geral [BBvB+ 01]. Dessa maneira, o paradigma de pesquisa analtico no suciente para investigar casos reais complexos envolvendo pessoas e suas interaes com a tecnologia [RH09]. Esses problemas j foram levantados por muitos pesquisadores, e hoje tem-se considerado melhor a inuncia de problemas no-tcnicos e a interseco entre eles e a parte tcnica dentro da engenharia de software [Sea99]. Apesar disso, o nmero de estudos empricos ainda muito pequeno dentro da rea de pesquisa em cincia da computao: Sjoberg et al. [SHea05] encontraram apenas 103 experimentos em 5.453 artigos, e Ramesh et al. [RGV04] identicaram menos de 2% de experimentos envolvendo humanos e apenas 0.16% estudos em campo dentre 628 artigos. Uma pesquisa qualitativa um meio para se explorar e entender a inuncia que indivduos ou grupos atribuem a um problema social ou humano. O processo de pesquisa envolve questes emergentes e procedimentos, dados geralmente colhidos sob o ponto de vista do participante, com a anlise feita de maneira indutiva indo geralmente de um tema especco para um tema geral e com o pesquisador fazendo interpretaes do signicado desses dados. Dados capturados por estudos qualitativos so representados por palavras e guras, e no por nmeros. O relatrio nal tem uma estrutura exvel e os pesquisadores que se dedicam a esta forma de pesquisa apoiam uma maneira de olhar para a pesquisa que honra o estilo indutivo, o foco em termos individuais e a importncia de mostrar a complexidade de uma situao [Cre08]. Conforme discutido na Seo 2.5, muitos trabalhos avaliaram TDD, e alguns deles relatam inclusive uma melhora no projeto de classes, como um menor acoplamento, uma maior coeso, e at mesmo mais simplicidade. Grande parte deles focam nos efeitos da prtica no cdigo nal, mas poucos estudos tentam entender a possvel inuncia da experincia nos resultados encontrados, e como TDD e a prtica de escrever o teste antes do cdigo real realmente guiam o programador em direo a essas melhorias. Para entend-las, neste trabalho optamos por um estudo exploratrio essencialmente qualitativo, no qual participantes foram convidados a resolver exerccios pr-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, detalhes sobre como a prtica inuenciou as decises de projeto de classes foram extrados dos participantes atravs de entrevistas. Este captulo detalha o planejamento do estudo, bem como o processo de anlise dos dados colhidos.

11

12

PLANEJAMENTO E EXECUO DO ESTUDO

3.2

3.1

Caractersticas de pesquisas qualitativas

Mtodos qualitativos de pesquisa possuem diversas caractersticas, que juntas fazem com que a pesquisa se torne rica em detalhes. Creswell [Cre08] lista algumas delas: 1. Pesquisador como instrumento chave de pesquisa. O pesquisador tem papel fundamental no processo, visto que ele o responsvel pela captura dos dados, por meio da examinao de documentos, entrevistas ou observaes feitas no mundo real. Pesquisadores tendem a no utilizar questionrios ou instrumentos desenvolvidos por outros pesquisadores; 2. Mltiplas fontes de dados. Pesquisas qualitativas geralmente colhem informaes de mltiplas fontes de dados, como entrevistas, observaes e documentos; 3. Anlise dos dados indutiva. Os dados so analisados de dentro para fora, por meio da categorizao dos mesmos em unidades de informao cada vez mais abstratas. Esse processo indutivo gera diversas idas e vindas entre os temas encontrados e a base de dados, at o momento em que os pesquisadores estabeleam um conjunto extensivo de temas; 4. Viso do participante. Trabalhos qualitativos focam na viso do participante sobre o objeto em estudo, e no na viso que o pesquisador ou a literatura tem a respeito do mesmo; 5. Projeto emergente. O processo de pesquisa qualitativa emergente. Isso signica que o processo no deve ser completamente descrito desde o comeo, mas sim modicado de acordo com o incio da coleta dos dados. A ideia chave por trs da pesquisa qualitativa aprender sobre o problema com os participantes e direcionar a pesquisa para obter aquela informao; 6. Interpretativa. Pesquisadores fazem uma interpretao daquilo que veem, ouvem e entendem. As interpretaes do pesquisador no podem ser separadas do seu conhecimento, histria, contexto e entendimentos anteriores do problema. Ao nal do relatrio da pesquisa, leitores tambm fazem suas crticas, oferecendo ainda novas interpretaes para o estudo. Com os leitores, participantes e pesquisadores fazendo interpretaes, mltiplas vises do problema podem emergir. 3.1.1 Estudos mistos

Abordagens que combinam tanto mtodos qualitativos quanto quantitativos so conhecidos por mtodos mistos. mais do que apenas coletar e analisar ambos tipos de dados; tambm fazer interpretaes que unam ambos resultados encontrados, de forma que a fora do estudo seja maior do que se ambos os mtodos fossem usados separadamente [Cre08]. Possveis diferentes abordagens podem ser levadas em conta em estudos mistos. Eles podem comear com estudos qualitativos de explorao, seguidos de um estudo quantitativo com uma populao maior de forma a generalizar os resultados para a populao. Alternativamente, o estudo pode comear com um estudo quantitativo no qual uma teoria ou conceito testado, seguido de um estudo qualitativo, envolvendo explorao detalhada de alguns casos ou indivduos [Cre08]. Reconhecendo que todos possuem limitaes, pesquisadores perceberam que um vis de um mtodo pode ser reduzido por um outro mtodo, e para isso devem sempre tentar triangular conjuntos de dados diferentes. Por exemplo, os resultados de um mtodo podem ajudar a identicar participantes a serem estudados por um outro mtodo. Dados qualitativos e quantitativos podem ser

3.3

QUESTES DE PESQUISA

13

unidos em um nico conjunto de dados ou seus resultados usados lado a lado para que um refore as ideias do outro [Cre08].

3.2

Questes de pesquisa

Conforme j mencionado na introduo, o objetivo principal deste estudo entender a relao da prtica de TDD e as decises de projeto de classes tomadas pelo programador durante o processo de projeto de sistemas orientados a objetos. Para compreend-la, tenta-se responder s questes listadas abaixo: 1. Qual a inuncia de TDD no projeto de classes? 2. Qual a relao entre TDD e as tomadas de decises de projeto de classes feitas por um desenvolvedor? 3. Como a prtica de TDD inuencia o programador no processo de projeto de classes, do ponto de vista do acoplamento, coeso e complexidade?

3.3

Projeto da pesquisa

Participantes de diferentes empresas de desenvolvimento de software do mercado brasileiro foram selecionados. Todos eles foram solicitados a resolver alguns problemas utilizando Java, dentro de um perodo de tempo limitado. Os participantes utilizaram TDD em um problema, e no o utilizaram no outro. Os problemas resolvidos bem como em qual deles o participante deveria utilizar TDD foram aleatorizados, a m de diminuir o problema do aprendizado. Todas as implementaes feitas foram salvas, para posterior clculo de mtricas de cdigo. Ao nal do exerccio, todos participantes tambm responderam um questionrio, sobre seu desempenho na resoluo dos problemas. Em seguida, uma anlise ltrou os candidatos mais interessantes, que foram posteriormente entrevistados. Todos os dados gerados no processo, como cdigo produzido e as entrevistas, foram analisados. As sub-sees a seguir detalham cada um dos pontos levantados. A ordem das sub-sees tambm representam a ordem de execuo dos passos do estudo, uma vez que o executamos de maneira sequncial. Um roteiro mais resumido e pronto para ser utilizado em replicaes tambm pode ser encontrado no Apndice B. 3.3.1 Participantes da pesquisa

Desenvolvedores atuantes no mercado de software brasileiro foram selecionados para participarem da pesquisa. Dada a diculdade de se encontrar desenvolvedores e empresas interessadas em participar de estudos cientcos, todos os que se candidataram, foram utilizados no estudo. Para anlise futura, os participantes foram avaliados de acordo com certos critrios: Experincia em TDD. Eles foram categorizados em programadores inexperientes em TDD (pouco conhecimento terico e prtico) e programadores com experincia em TDD (praticantes frequentes h no mnimo 3 anos). Experincia em desenvolvimento de software. Participantes podem ser experientes (com no mnimo 3 anos de desenvolvimento e bons conhecimentos em orientao a objetos) ou inexperientes (com no mximo 1 ano de desenvolvimento e pouco conhecimento de orientao a objetos).

14

PLANEJAMENTO E EXECUO DO ESTUDO

3.3

Conhecimentos em Java. Nvel de conhecimento na linguagem Java. Conhecimentos em Testes de Unidade. Conhecimento em testes de unidade e na prtica de TDD. Esses pontos foram avaliados por meio de um questionrio, respondido por todos os participantes antes do incio do estudo. Este questionrio, alm de perguntar qual a experincia do participante (de maneira quantitativa, em anos), continha questes nas quais o participante podia falar sobre sua expriencia em projeto orientado a objetos, Java e TDD de forma mais aberta. Uma cpia deste questionrio pode ser encontrada no Apndice C. O objetivo de trazer participantes com as mais diferentes experincias em desenvolvimento de software e TDD fazer anlises para os seguintes grupos: Experientes em desenvolvimento de software e em TDD: Por ser composto de participantes com experincia tanto em desenvolvimento de software quanto em TDD, devemos entender por que pessoas com alta experincia optam por utilizar a prtica; Experientes em desenvolvimento de software, mas no em TDD: Por serem participantes com experincia em desenvolvimento de software, mas no os praticantes de TDD, devemos entender a diferena entre praticar TDD e no praticar TDD; Inexperientes tanto em desenvolvimento de software, quanto em TDD: Por serem participantes sem nenhuma experincia, esperado que a prtica ajude na qualidade do cdigo. Caso isso no acontea, devemos entender o motivo de TDD no ter auxiliado os desenvolvedores durante a criao do projeto de classes. 3.3.2 Resoluo dos problemas propostos

Todos os participantes foram convidados a resolver os exerccios preparados. Para isso, criamos um caderno de exerccios que foi seguido pelo participante. Esse caderno de exerccios continha nada mais do que os exerccios selecionados para aquele participante, com a instruo de praticar ou no TDD. Os participantes tiveram duas horas para resolver todos os exerccios. Embora no houvesse nenhuma regra denida, ao nal da primeira hora, ns os avisavmos para que pudessem controlar melhor o tempo e sugeramos que eles partissem para o segundo exerccio. Todos os cdigos foram salvos ao nal do estudo para que pudessem ser analisados junto com os dados das entrevistas. O tempo foi considerado suciente para que o participante resolvesse todos os exerccios (atravs do questionrio respondido aps a resoluo dos exerccios). Os participantes no podiam se comunicar durante o exerccio, e cada um deles recebeu os exerccios em ordens diferentes, para tentar diminuir o fator de aprendizado que pudesse ocorrer durante a resoluo dos problemas. Cada participante recebeu dois exerccios. Em um deles, o participante praticou TDD; no outro, ele programou sem a prtica. A razo disso fazer com que o participante exercite ambos estilos de desenvolvimento (com e sem TDD) e tenha mais embasamento para ser entrevistado nas prximas etapas do estudo. Cada participante recebeu instrues claras no caderno de exerccios sobre quais exerccios deveriam ser feitos com TDD. A escolha desses exerccios tambm foi randomizada na tentativa de diminuir o efeito do aprendizado.

3.3 Exerccio Exerccio 1 Exerccio 2 Exerccio 3 Exerccio 4 Mau Cheiro Rigidez, Complexidade Desnecessria Fragilidade, Viscosidade, Imobilidade Rigidez, Fragilidade Fragilidade, Viscosidade, Imobilidade

PROJETO DA PESQUISA

15

Princpios A Serem Seguidos PRU, PAF PRU, PID, PAF PRU PAF, PRU, PID

Tabela 3.1: Exerccios propostos e mau cheiros de projeto de classes

Ao nal, todos responderam a um questionrio online, que continha perguntas sobre a qualidade do cdigo que acabaram de produzir. Esse questionrio melhor detalhado na Seo 3.3.4. 3.3.3 Problemas Propostos

Foram propostos quatro problemas que deveriam ser resolvidos pelos participantes, utilizando linguagem Java. O objetivo desses exerccios foi simular problemas de projeto de classes recorrentes em diversos projetos de software. Os enunciados encontram-se no Apndice D. Na Tabela 3.1, apresentamos a relao entre uma m implementao dos exerccios e os princpios de projeto de classes feridos por ela. As boas prticas de projeto de classes que foram utilizados ao longo deste estudo so baseadas nos prncipios catalogados por Martin [Mar02] e conhecidos pelo acrnimo SOLID. No Apndice A, discutimos esses princpios em detalhes. Foi dito ao participante que os exerccios simulam problemas do mundo real, e ele deveria ter em mente que as solues geradas supostamente seriam mantidas por uma outra equipe. Por esse motivo, foi solicitado ao participante que implemente a soluo mais elegante e exvel possvel. O primeiro exerccio pede ao participante que implemente uma calculadora de salrio, em que o algoritmo de clculo varia de acordo com o cargo do funcionrio. Em uma implementao procedural e mais difcil de ser mantida, esse problema seria resolvido por meio de uma sequncia de "ifs"; todo novo cargo obrigaria o desenvolvedor a acrescentar mais um "if"nessa classe. Uma implementao mais exvel teria cada algoritmo de clculo em uma classe separada. O segundo exerccio pede que o participante implemente o processo de gerao de uma nota scal e, aps esse processo, a nota gerada deve passar por diversos outros processos, como envio por e-mail, envio para um sistema externo, persistir na base de dados, etc. Possveis ms implementaes incluem a implementao de uma nica classe que faria todo o processo, ou uma classe altamente acoplada. Uma soluo mais elegante seria extrair cada responsabilidade em uma classe diferente e comp-las por meio, por exemplo, da implementao do padro Observer [FRea04]. O terceiro exerccio pede ao participante a implementao de um simples processador de boletos que deve marcar a fatura como paga, caso a soma de pagamentos seja maior ou igual ao valor da fatura. Em uma implementao elegante, o comportamento de marcar a fatura como paga deveria estar encapsulado, e car dentro da classe "Fatura", ou entidade similar criada pelo participante. No quarto exerccio, o participante deveria escrever um algoritmo responsvel por ltrar faturas de acordo com diferentes critrios. Em uma implementao procedural, esse nico algoritmo seria responsvel por validar todos os critrios. Mas, por serem complexos, esses ltros deveriam ser divididos em vrias classes, em vez de carem em uma nica classe responsvel por todos os critrios. Os exerccios propostos so baseados em um workshop criado pelo autor desta pesquisa, e o mesmo foi aplicado para 2 turmas diferentes, uma delas dentro do Agile Brazil 2011, o maior evento brasileiro de mtodos geis, que tinha um pblico heterogneo, e uma delas para uma das turmas do curso de Cincia da Computao do Instituto de Matemtica e Estatstica da Universidade de

16

PLANEJAMENTO E EXECUO DO ESTUDO

3.3 Objetivo Este bloco objetiva obter a opinio dos participantes sobre o estudo, como clareza dos exerccios. O objetivo aumentar a validade do estudo. Alm disso, entender se os exerccios propostos so parecidos com os problemas encontrados no mundo real ajudam a aumentar a possibilidade de generalizao do estudo. O objetivo obter a viso do desenvolvedor sobre o prprio cdigo gerado e como ele faz para obter feedback sobre a qualidade do cdigo que escreve. O objetivo deste bloco entender como a prtica pode ter inuenciado nas decises de projeto de classes feitas pelo programador durante o exerccio.

Bloco O estudo

Cdigo gerado

Prtica de TDD

Tabela 3.2: Informaes que so extradas do questionrio ps-experimento.

So Paulo, na qual o pblico era constitudo em sua maioria de alunos de graduao. Neste workshop, os participantes, alm de receberem os mesmos exerccios, tambm possuam um cdigo-fonte inicial do exerccio, e a tarefa era apenas nalizar a soluo. No entanto, o cdigofonte inicial enviesava o participante a gerar uma m implementao. O resultado de ambas as turmas foram semelhantes; alguns participantes no perceberam a m qualidade do cdigo inicial e apenas deram prosseguimento ao cdigo de m qualidade. Outros perceberam os problemas e refatoraram os cdigos em busca de um melhor projeto de classes. Ambas as turmas avaliaram positivamente os exerccios propostos. 3.3.4 Questionrio ps-experimento

Como mencionado anteriormente, ao nal dos exerccios o participante responderam a um questionrio. Algumas perguntas foram abertas, nas quais o participante podia dar uma opinio mais embasada sobre o assunto, e outras foram fechadas, escolhendo um valor dentro de uma escala Likert com 5 valores. Para melhor explicar cada questo encontrada no questionrio, dividimo-as em pequenos blocos. Na Tabela 3.2, apresentamos as informaes extradas desse questionrio, e qual o objetivo de cada uma delas. Uma cpia do mesmo pode ser encontrada no Apndice E. 3.3.5 Escolha de candidatos para a entrevista

Aps a implementao, os dados colhidos foram parcialmente analisados. O intuito foi encontrar, dentre todos os participantes, aqueles com dados mais relevantes e que meream ser aprofundados. Para isso, informaes como qualidade dos cdigos gerados, grupo que participa do estudo e res-

3.3 postas no questionrio inuenciaram na escolha. O procedimento adotado para escolha dos candidatos foi:

PROJETO DA PESQUISA

17

1. Leitura dos questionrio inicial e ps-experimento respondidos pelo participante. 2. Avaliao do cdigo gerado, levando-se em conta qual foi resolvido com TDD e qual foi resolvido sem TDD. 3. Gerao de relatrio para cada participante, descrevendo as opinies do participante e o nosso ponto de vista sobre os dados colhidos at ento. 4. Candidatos que apresentaram cdigos de qualidade ou alguma divergncia entre as respostas no questionrio e os cdigos feitos com TDD e sem TDD (por exemplo, participante comentou no questionrio que TDD o ajudou no projeto de classes, mas no percebemos uma melhora no projeto de classes no cdigo que ele produziu), que merecesse ateno especial, foram selecionados para a entrevista. 3.3.6 Entrevistas

A entrevista foi semi-estruturada, dando liberdade ao pesquisador para mudar o rumo das perguntas, caso se zesse necessrio. Alm disso, todas as perguntas foram abertas, permitindo que o desenvolvedor desse uma resposta ampla sobre o assunto. Uma cpia do roteiro da entrevista pode ser encontrada no Apndice F. O processo de entrevista composto por uma breve introduo da pesquisa, tomando o cuidado para no enviesar o participante, seguida de algumas perguntas que visam caracterizar o perl do participante; perguntas como qual a experincia do desenvolvedor em desenvolvimento de software e TDD so necessrias para ajudar o pesquisador no entendimento das respostas dadas. Alm disso, perguntas sobre referncias, livros e outros pontos de informao nas quais o participante l a respeito da prtica servem para que entendamos o embasamento terico dos praticantes sobre TDD. Apesar das perguntas j terem sido feitas durante o questionrio inicial, essa parte inicial importante para tranquilizar o participante, e possibilitar com que ele esteja mais conante e fale mais durante as perguntas mais cruciais. Em seguida, ns perguntamos os principais pontos da pesquisa. Para isso, zemos uso no s de perguntas abertas, mas tambm voltamos aos cdigos gerados durante o exerccio, para que as respostas se tornassem tcnicas e especcas, caso necessrio. A ideia foi fazer com que o participante nos explicasse como que o projeto de classes daquele exerccio foi concebido. Uma vez que as decises tomadas por um programador durante a atividade de projeto de classes podem ser inuenciadas por vrios diferentes fatores, as perguntas foram feitas de modo que o participante triangule suas respostas, e tente isolar o mximo possvel a atividade de TDD dos outros possveis fatores de inuncia. Participantes que no articulassem bem suas respostas seriam eliminados durante o processo de anlise. Todas as entrevistas foram gravadas para que ns pudssemos fazer a transcrio e rever os dados a qualquer momento durante o processo. Alm disso, ns tambm tomamos notas, capturando informaes como reaes dos participantes a determinadas perguntas, ou qualquer outra informao relevante. As entrevistas tambm foram feitas em dias diferentes de acordo com a disponibilidade de cada participante.

18

PLANEJAMENTO E EXECUO DO ESTUDO

3.4

Entrevistas, de maneira geral, tendem a ser teis j que os participantes podem prover dados histricos sobre o objeto em estudo. Alm disso, entrevistas nos permitem o controle sobre as questes a serem feitas. Mas, um possvel problema que as entrevistas geralmente provm informaes indiretas, ltradas por meio da viso dos participantes. Alm disso, a presena do pesquisador pode intimidar o participante ou enviesar as respostas. Outro possvel problema que nem todos os participantes so articulados e perceptivos, e conseguem formalizar, em palavras, o que conhecem ou esto pensando. 3.3.7 Mtricas de cdigo

Com o cdigo-fonte em mos, possvel utilizar-se de mtricas de cdigo para avaliar sua qualidade. As mtricas utilizadas foram: 1. Complexidade Ciclomtica: Optamos por utilizar o algoritmo de complexidade ciclomtica criado por McCabe [McC76]. Uma simples explicao desse algoritmo seria que, para cada mtodo, um contador incrementado sempre que um if, for, while, case, catch, E lgico, OU lgico, ou if ternrio aparece. Todos os mtodos tem ainda seus contadores iniciados com 1. 2. Fan-Out : Essa mtrica conta o nmero de classes que uma classe conhece e faz uso [Lor94]. 3. Falta de Coeso dos Mtodos: A verso implementada do algoritmo de falta de coeso dos mtodos (ou, do ingls, Lack of Cohesion of Methods (LCOM) ) foi a sugerida por HendersonSellers [HS96]. Neste algoritmo, uma classe considerada altamente coesa se e somente se todos os seus mtodos usam todos seus atributos de instncia. Neste caso, a mtrica resulta em zero. 4. Quantidade de Linhas por Mtodo: Essa mtrica conta o nmero de linhas em cada mtodo de cada classe. Linhas em branco dentro dos mtodos tambm entram na conta. 5. Quantidade de Mtodos: A mtrica conta o nmero de mtodos por classe. Todas as mtricas citadas j so de uso conhecido na academia e indstria, e de fcil implementao. Para calcular essas mtricas, ns implementamos nossa prpria ferramenta. O motivo para tal que grande parte das ferramentas existentes fazem uso de cdigo compilado, e no apenas do cdigo-fonte. Nossa ferramenta possui bateria de testes automatizados e cdigo-fonte aberto 1 . 3.3.8 Avaliao do Especialista

Dois especialistas foram convidados a analisar os cdigos-fonte e a dar notas para cada um deles. Apesar das mtricas de cdigo nos darem informaes preciosas sobre a qualidade do cdigo, a opinio de um especialista, baseada em sua experincia passada, pode ser bastante enriquecedora. As categorias nas quais eles deveriam avaliar eram: Simplicidade, Testabilidade e Qualidade do Projeto de Classes. Em cada uma dessas categorias, os especialistas puderam dar notas entre 1 (ruim) e 5 (bom), ou optar por no avaliar aquele exerccio. Como alguns participantes no terminaram o exerccio, o especialista foi avisado de que ele deve avaliar inclusive a "inteno"de projeto de classes criado pelo participante, e no s o cdigo atual. Para que a opinio do especialista fosse imparcial, ele no sabia a qual grupo pertencia e como cada cdigo-fonte analisado foi desenvolvido (com ou sem a prtica de TDD).
1

http://www.github.com/mauricioaniche/msr-asserts. ltimo acesso em 10 de Fevereiro de 2012.

3.4

ANLISE DOS DADOS

19

3.4

Anlise dos dados

O procedimento de anlise, baseado em [Cre08], que est representado na Figura 3.1, ilustra o processo de anlise utilizado nessa pesquisa. Apesar de parecer uma abordagem em cascata, ele na prtica iterativo, visto que os passos so interconectados.

Figura 3.1: Processo de anlise dos dados

A princpio, todos os dados recolhidos foram reunidos e preparados. As entrevistas foram transcritas, assim como as observaes feitas sobre as gravaes das implementaes. A seguir, para que ns possamos buscar por erros no processo de transcrio, todos os dados foram re-lidos. Essa primeira leitura tambm serviu para ns termos uma ideia inicial das informaes ali presentes. O processo de codicao e o agrupamento por temas foi ento realizado. Os cdigos gerados eram derivados da opinio dos participantes, e os mesmos eram constantemente revistos e unidos, quando dois cdigos eram similares. Alm disso, quando o participante mencionava algum padro de feedback, um cdigo diferente era dado para esse trecho, para que ns o pudssemos encontr-lo facilmente durante a escrita deste texto. Os cdigos que mais foram relacionados apareceram como maiores contribuies da pesquisa qualitativa, durante o processo de interpretao dos dados. O software utilizado para o processo de codicao foi o Atlas.ti 2 , produzido na Alemanha, que nos possibilitou organizar textos e junt-los com cdigos e anotaes. Alm disso, as mtricas calculadas foram utilizadas na busca por alguma diferena estatisticamente signicante entre cdigos produzidos com e sem TDD. Testes estatsticos para anlise de varincia foram utilizados para vericar se TDD inuencia nas mesmas. A varincia dos dados obtidos na opinio do especialista sobre cada cdigo-fonte gerado foi utilizada tambm como entrada para algoritmos estatsticos. Como esses dados no seguem uma distribuio normal, o teste de Wilcoxon foi escolhido. Este um teste de hipotse no-paramtrico, usado para comparar duas amostras e vericar se h diferena na mdia das populaes. O teste de Wilcoxon recebe dois conjuntos de dados como entrada, que so os conjuntos na qual ele procurar por diferenas nas mdias.
2

http://www.atlasti.com/. ltimo acesso em 3 de maio de 2011.

20

PLANEJAMENTO E EXECUO DO ESTUDO

3.7

Executamos o teste de Wilcoxon diversas vezes, uma para cada mtrica de cdigo que calculamos: complexidade ciclomtica, acoplamento eferente, falta de coeso dos mtodos, nmero de linhas por mtodos, e quantidade de mtodos por classe. Para cada uma dessas mtricas, separamos o conjunto de valores encontrados pela mtrica em cdigos no produzidos com TDD, do conjunto de valores para cdigos produzidos com TDD. Durante o processo, o pesquisador constantemente validou toda e qualquer informao colhida e, quando se fez necessrio, a coleta de qualquer entrevista, observao ou mtrica foi refeita.

3.5

Validade e Conabilidade do Estudo

Para garantir a conabilidade deste estudo, ns realizamos os seguintes procedimentos: Checar as transcries. O objetivo foi garantir que nenhum erro bvio tenha sido cometido; Vericao de pesquisador auxiliar. Um pesquisador auxiliar checou a interpretao dos dados gerada por esta pesquisa; Rastreabilidade dos dados. Todos os dados colhidos foram preservados em forma eletrnica. A validade do estudo foi buscada por alguns procedimentos executados pelos pesquisadores, dentre eles: Prover descrio rica e detalhada sobre o ambiente. A riqueza dos detalhes mostra a qualidade do estudo, alm de possibilitar a repetio do experimento por outros pesquisadores; Esclarecer todos os possveis vieses da pesquisa. A pesquisa deixa claro quais so suas limitaes. Todas elas so discutidas no Captulo 6. Em resumo, o principal meio de validao do estudo foi o rico detalhamento dos participantes, dos dados colhidos e instrumentos de coleta, de forma que qualquer pesquisador interessado em replicar o experimento ter um arcabouo slido para comparao [Mer98]. A anlise de dados tambm foi relatada em detalhes para que os leitores tenham uma viso clara sobre o mtodo utilizado na pesquisa. Alm disso, esta pesquisa tambm foi acompanhada pelo meu orientador, que constantemente validou e discutiu os pontos levantados nesse planejamento.

3.6

Papel do Pesquisador

Em um estudo qualitativo, o pesquisador tem como papel fundamental participar do processo de captura dos dados, bem como seu preparo e interpretao nal. Creswell [Cre08], citando Locke [LL07], lembra que a contribuio do investigador para o contexto da pesquisa pode ser til e positiva. Alm do mais, o pesquisador responsvel por identicar todos os valores pessoais, pressuposies e vieses do estudo. O autor desta pesquisa tem formao em Cincia da Computao, e desenvolve software h 9 anos, pratica TDD diariamente nos ltimos 3 anos e possui profundos conhecimentos tericos e prticos sobre orientao a objetos e mtodos geis. Alm disso, o autor palestrou sobre TDD em eventos da indstria brasileira de desenvolvimento de software, como a Agile Brazil 2010, o .NET Architects 2010 e o QCON So Paulo 2010. O autor desta pesquisa acredita que sua experincia nessas reas aumentam sua capacidade de anlise dos efeitos de TDD no projeto de classes de sistemas orientados a objetos.

3.9

QUESTES TICAS

21

3.7

Questes ticas

Esta pesquisa pode revelar desenvolvedores que produzem projeto de classes no satisftorios ou no utilizam a prtica corretamente. Por esse motivo, todos os dados colhidos pelo pesquisador foram mantidos em sigilo e todos os nomes de desenvolvedores e projetos omitidos, conforme acordo assinado entre o pesquisador e a participante.

3.8

Estudo piloto

Antes da execuo do estudo com participantes reais, um estudo piloto foi executado para que o pesquisador pudesse validar todos os instrumentos de pesquisa, como exerccios, gravao de vdeo, protocolo e roteiro de entrevista. Com os resultados do estudo piloto, o pesquisador fez melhorias nos diversos instrumentos de pesquisa. Vale ressaltar que as pessoas que participaram do estudo piloto no foram reutilizadas no estudo nal. Na primeira verso, o participante deveria implementar todos os quatro exerccios em 2 horas. Mas, aps a execuo do primeiro piloto, o participante nos contou que se sentiu muito cansado, e que, ao nal, no estava mais trabalhando direito. Por esse motivo, decidimos que os participantes resolveriam apenas 2 exerccios. No segundo piloto, o participante teve diculdades para congurar a rea de trabalho no Eclipse e para entender o que deveria fazer em cada exerccio. Para resolver este problema, adotamos um caderno de questes bem explicado, alm de sugerir ao participante o download de uma rea de trabalho do Eclipse previamente congurada. O mesmo participante tambm comentou que os exerccios poderiam ser simplicados. Essa sugesto no foi aceita, j que queramos que os exerccios fossem parecidos com os do mundo real. No entanto, passamos a avisar aos participantes que eles no precisavam necessariamente terminar o exerccio, mas sim trabalhar com qualidade. J o terceiro piloto nos ajudou a melhorar o roteiro de entrevista. Percebemos a existncia de diversas perguntas repetidas. Aps o trmino, removemos essas questes e deixamos o roteiro de entrevistas mais simples. Infelizmente no conseguimos executar mais pilotos, devido a falta de tempo e disponibilidade de possveis participantes.

3.9

Execuo do estudo

Como os estudos foram executados sicamente em muitas das empresas selecionadas, ns acabamos por ajudar na organizao do ambiente, mesmo a equipe tendo recebido o caderno de questes com as instrues da instalao alguns dias antes. A ideia era tambm gravar a implementao dos alunos, mas diculdades em se encontrar um software de vdeo para as diferentes plataformas, e arquivos muito grandes, impossibilitaram a gravao. Todos os participantes eram avisados de que tinham por volta de 50 minutos por exerccio. Eles tambm sabiam que, mesmo que no terminassem o exerccio, deveriam focar sempre na qualidade do cdigo gerado. Eles tambm eram solicitados a implementar um projeto de classes exvel para os problemas. A frase que dizamos para eles era geralmente: "Levem os exerccios para o mundo real, onde um outro desenvolvedor dever manter o cdigo gerado. Lembrem-se de implementar o cdigo mais fcil possvel para evoluir. As regras de negcio que existem hoje no enunciado tendem a aumentar de nmero e, portanto, deixem a manuteno do cdigo de vocs mais simples." Durante a execuo, ns tirvamos diversas dvidas sobre enunciados dos exerccios, e at mesmo

22

PLANEJAMENTO E EXECUO DO ESTUDO

3.10

sobre procedimentos que os participantes podiam adotar durante a execuo. Um deles, por exemplo, perguntou se poderia refatorar o cdigo durante a implementao sem TDD. Ns tambm no os pressionvamos em nenhum momento. Eles cavam, cada um em suas mquinas, trabalhando na implementao. No cvamos passando atrs das mquinas para ver como estavam indo, na tentativa de evitar qualquer possvel alterao de comportamento pela nossa presena. Ao nal de cada intervalo de 50 minutos, ns avisvamos para eles nalizarem a linha de raciocnio e partir para o prximo exerccio. Todo o experimento ocorreu bem, com exceo do que foi executado dentro da universidade. Alm de diversos problemas de infraestrutura, como a falta de espao em disco disponvel para alguns alunos, que impedia at mesmo o JUnit de executar, todos os participantes conseguiram fazer apenas 1 exerccio. Diante dessa situao, optamos por deix-los implementar o mesmo exerccio at o nal da aula j que, aps os 50 minutos iniciais, ns observamos que pouco cdigo havia sido escrito. Outro problema levantado foi que alguns alunos no se mostraram muito dispostos a participar do estudo. Ao contrrio, a grande maioria dos participantes da indstria conseguiram implementar o exerccio no tempo delimitado, e todos se mostraram muito receptivos para o estudo. Um ponto que se mostrou bem til para convencer participantes da indstria a participar foi a proposta posterior de ns apresentarmos os resultados encontrados em uma palestra. Ao nal da execuo do estudo em cada empresa, ns guardvamos os dados gerados (cdigofonte e caderno de questes assinado), e dvamos o nome da pasta do participante, de acordo com o seguinte formato: id-nome-combinao. O id aponta para um nmero nico do participante no estudo, e a combinao aponta quais exerccios ele resolveu, bem como em qual deles ele utilizou TDD. As entrevistas foram, em grande parte, realizadas pessoalmente com o desenvolvedor. Quando o participante no estava disponvel (por estar localizado em outra cidade), a entrevista era realizada por Skype. Durante toda a entrevista, o participante podia observar o cdigo que produziu. Para isso, ns criamos uma simples aplicao web para facilitar a exibio dos cdigos-fonte. O objetivo do participante ver o cdigo era lembrar sobre suas decises, e nos possibilitar perguntas especcas sobre o projeto de classes gerado. Em mdia, as entrevistas levavam 30 minutos. Quando o participante comentava algo interessante, ns adaptvamos o roteiro para permitir que ele falasse mais do assunto, e anotvamos o ponto para que, ao nal, fosse possvel discutir novamente sobre o assunto. O roteiro de entrevistas sofreu uma pequena mudana ao nal da primeira entrevista, j que percebemos que comunicar ao participante que o cdigo que ele produziu no apresenta um bom projeto de classes no era uma tarefa fcil, e talvez, no tica. Optamos por perguntar sobre como aquele projeto de classes foi construdo, mesmo que ele no estivesse bem construdo em nossa opinio. Para manter um padro, ns sempre perguntvamos primeiro sobre o exerccio que ele fez com TDD, independente da ordem que ele implementou no dia da execuo. Notamos que muitos participantes discutiram sobre os exerccios e possveis implementaes com seus colegas aps a realizao do exerccio. Dos trs especialistas convidados a avaliar os cdigos produzidos, apenas um no completou a tarefa. Sugerimos a todos eles, antes do incio da avaliao, que avaliassem no s a quantidade de cdigo escrito, mas as decises de projeto de classes tomadas por aquele participante. Para que os especialistas avaliassem cada cdigo gerado, ns implementamos uma aplicao web, que eles

3.10

DESCRIO DOS PARTICIPANTES

23

tinham acesso a qualquer momento, e podiam parar ou continuar a avaliar na hora que preferissem.

3.10

Descrio dos participantes

Ao todo tivemos 25 participantes, de 6 diferentes empresas de pequeno porte do mercado brasileiro 3 . Os participantes da indstria, em sua maioria, eram pessoas com pouca experincia em TDD. 40% deles disseram utilizar a prtica h no mximo um ano. 52% deles praticam TDD entre 1 e 3 anos. Apenas 4% praticou entre trs e quatro anos, e nenhum participante possua mais experincia do que isso. Na Figura 3.2, mostramos a distribuio da experincia da prtica de TDD entre os participantes. Os nmeros so um pouco diferentes quando se trata da experincia em desenvolvimento de software. 24% dos participantes desenvolve software entre 4 e 5 anos. 28% deles faz isso entre 6 e 10 anos. 20% possui at 2 anos de experincia. Na Figura 3.3, mostramos a distribuio.

Figura 3.2: Experincia dos participantes da indstria com TDD

Figura 3.3: Experincia dos participantes da indstria com desenvolvimento de software em geral

Entrando em aspectos mais tcnicos, 64% dos participantes armaram programar em Java. Entretanto, 36% disseram que no trabalham com Java no seu dia a dia. Todos eles armam conhecer JUnit, e s 12% diz nunca ter ouvido falar sobre o conceito de objetos dubls4 . De fato, 64% deles aplicam objetos dubls durante suas atividades de desenvolvimento. Com relao a conhecimentos
Consideramos empresas de pequeno porte aquelas que tem menos de 50 funcionrios. Objetos dubl ou, do ingls, mock objects, so objetos criados durante um teste de unidade, e que imitam o comportamento de um outro objeto concreto. Geralmente so muito utilizados quando queremos isolar nosso teste de outras classes do sistema. Mais informaes sobre objetos dubls podem ser encontradas em [MT01].
4 3

24

PLANEJAMENTO E EXECUO DO ESTUDO

3.10 Participantes que no conhecem 9 0 3

Ferramenta Java JUnit Objetos Dubl

Participantes que conhecem 16 25 16 (utilizam no dia a dia), 6 (na teoria)

Tabela 3.3: Experincia em Java, JUnit, e Objetos Dubl dos participantes da indstria

em orientao a objetos, na pergunta aberta do questionrio, grande parte deles armou que possuem uma boa experincia e alguns chegam at a armar que dominam o assunto. Poucos disseram que possuem conhecimentos bsicos. Na Tabela 3.3, apresentamos o conhecimento dos participantes em relao a Java, JUnit e objetos dubls. Em relao experincia com TDD, podemos armar que metade dos participantes ainda est experimentando a prtica, enquanto outros j a tem mais consolidada. Isso positivo, j que foi possvel capturar informaes da prtica de TDD por pessoas com diferentes nveis de maturidade. Em relao ao alto nmero de pessoas que no utilizam Java, isso se deve ao fato de uma das empresas fazer uso de PHP para seu trabalho do dia a dia. No entanto, ns conhecemos a equipe e vericamos que, apesar de no utilizarem a linguagem constantemente, eles no tiveram problema algum durante a execuo dos exerccios.

Captulo 4

Relao entre TDD e Projeto de Classes: Anlise Quantitativa

Na tentativa de encontrar os ditos efeitos de TDD sobre o projeto de classes, calculamos mtricas em cima dos cdigos gerados, para vericar se houve alguma diferena na qualidade dos cdigos gerados com e sem a prtica de TDD. Conforme discutido no Captulo 3, o teste estatstico escolhido foi o Wilcoxon. Nas sub-sees abaixo, discutimos os nmeros encontrados.

4.1

Mtricas de cdigo

Na Tabela 4.1, mostramos os p-values encontrados para a diferena entre cdigos produzidos com e sem TDD na indstria. Pelos nmeros, observamos que em nenhum exerccio houve diferena signicativa nas mtricas de complexidade ciclomtica e acoplamento eferente. J a mtrica de falta de coeso dos mtodos apresentou diferenas em dois exerccios (1 e 4). A diferena tambm apareceu na quantidade de linhas por mtodo (exerccio 4) e quantidade de mtodos (exerccio 1). Ao olhar os dados de todos os exerccios juntos, nenhuma mtrica apontou uma diferena signicativa. Isso nos mostra que, ao menos quantitativamente, a prtica de TDD no fez diferena nas mtricas de cdigo. Exerccio Complexidade ciclomtica 0.8967 0.7868 0.5463 0.2198 0.8123 AcoplamentoFalta de eferente coeso dos mtodos 0.6741 0.7640 0.9872 0.1361 0.5604 2.04E-07* 0.06132 0.5471 0.04891* 0.3278 Nmero de linhas por mtodo 0.4962 0.9925 0.7216 0.0032* 0.06814 Quantidade de mtodos por classe 2.99E-06* 0.7501 0.3972 0.9358 0.5849

Exerccio Exerccio Exerccio Exerccio Todos

1 2 3 4

Tabela 4.1: P-values encontrados para a diferena entre cdigos com e sem TDD na indstria

J nas Tabelas 4.2, 4.3, 4.4, 4.5 e 4.6, calculamos os p-values das mtricas, separando-as por experincia em desenvolvimento de software e TDD na indstria. Os valores para o grupo experiente em TDD e no experiente em desenvolvimento de software no foram calculados, j que nenhum participante se enquadrou nele. Pelos nmeros, percebemos que a mtrica de coeso foi a nica que apresentou uma diferena signicativa entre desenvolvedores experientes, tanto em TDD quanto em desenvolvimento de software. 25

26

RELAO ENTRE TDD E PROJETO DE CLASSES: ANLISE QUANTITATIVA

4.2

Complexidade Ciclomtica Experiente em Desenvolvimento de Software No Experiente em Desenvolvimento de Software

Experiente em TDD 0.09933 NA

No experiente em TDD 0.8976 0.4462

Tabela 4.2: P-values encontrados para a diferena na Complexidade Ciclomtica entre experientes e no experientes na indstria

Fan-Out Experiente em Desenvolvimento de Software No Experiente em Desenvolvimento de Software

Experiente em TDD 0.1401 NA

No experiente em TDD 0.6304 0.2092

Tabela 4.3: P-values encontrados para a diferena no Fan-Out entre experientes e no experientes na indstria

Falta de Coeso nos Mtodos Experiente em Desenvolvimento de Software No Experiente em Desenvolvimento de Software

Experiente em TDD 0.03061* NA

No experiente em TDD 0.1284 0.0888

Tabela 4.4: P-values encontrados para a diferena na falta de coeso nos mtodos entre experientes e no experientes na indstria

Quantidade de Mtodos por Classe Experiente em Desenvolvimento de Software No Experiente em Desenvolvimento de Software

Experiente em TDD 0.09933 NA

No experiente em TDD 0.8976 0.4462

Tabela 4.5: P-values encontrados para a diferena na quantidade de mtodos por classe entre experientes e no experientes na indstria

Linhas por Mtodo Experiente em Desenvolvimento de Software No Experiente em Desenvolvimento de Software

Experiente em TDD 0.0513 NA

No experiente em TDD 0.4319 0.5776

Tabela 4.6: P-values encontrados para a diferena no nmero de linhas por mtodo entre experientes e no experientes na indstria

4.2

Especialistas

Ambos os especialistas no encontraram diferenas entre cdigos produzidos com e sem TDD. Na Tabela 4.7, mostramos os p-values encontrados para a diferena de avaliao dos especialistas entre cdigos produzidos com e sem TDD.

4.3 Especialista Especialista 1 Especialista 2 Projeto de classes 0.4263 0.7447 Testabilidade 0.5235 0.4591

DISCUSSO

27

Simplicidade 0.3320 0.9044

Tabela 4.7: P-values encontrados para a diferena entre as anlises dos especialistas com e sem TDD na indstria

4.2.1

Inspeo do Cdigo-Fonte

Ns avaliamos cada cdigo-fonte manualmente. Em sua maioria, os cdigos eram claros e fceis de entender, com classes, mtodos e variveis bem nomeados. Mas, para nossa surpresa, poucos foram os participantes que zeram uso de polimorsmo. A grande maioria das implementaes fazia uso de cadeias de condies para alcanar o objetivo. Ns tambm no conseguimos identicar, por inspeo manual, quais cdigos eram produzidos com TDD e quais no eram pois, independente da prtica utilizada, ambos eram muito semelhantes. De todos os participantes da indstria, apenas um foi completamente eliminado: suas classes eram completamente vazias.

4.3

Discusso

Os valores apresentados anteriormente corroboram com muitos dos trabalhos relacionados. Aparentemente TDD no inuencia a ponto de alterar de maneira signicativa os valores das mtricas de acoplamento, coeso e simplicidade. Porm, isso incoerente com o sentimento comum no mercado de que praticar TDD traz benefcios para o projeto de classes. Conforme previsto, neste estudo conduzimos uma etapa qualitativa para entender como se procede essa inuncia, do ponto de vista dos desenvolvedores. Tal estudo parece vital para a real compreenso dos efeitos da prtica. A anlise qualitativa encontrada no captulo a seguir.

Captulo 5

Relao entre TDD e Projeto de Classes: Anlise Qualitativa

5.1 Introduo

Neste captulo apresentamos e discutimos sobre a anlise e interpretao dos dados colhidos na execuo deste estudo. Em particular, na Seo 5.3, levantamos os padres de feedback que a prtica de TDD pode dar ao desenvolvedor. Um ponto interessante a ser notado que os participantes, independente de experincia em TDD ou em desenvolvimento de software, comentaram pontos similares. Por esse motivo, no separamos a discusso pelas categorias levantadas no Captulo 3.

5.2

Anlise das Entrevistas

Diferente do esperado, a maioria absoluta dos participantes armou que a prtica de TDD no faria com que seus projetos de classes fosse de alguma forma diferentes, caso tivessem feito ambos os exerccios com a prtica. A principal justicativa dada pelos participantes foi que a experincia e o conhecimento prvio em orientao a objetos os guiaram durante o processo de criao do projeto de classes. Nenhum dos participantes, por exemplo, armou que um desenvolvedor sem conhecimento em alguma das reas citadas criaria um bom projeto de classes somente por praticar TDD. Dois bons exemplos foram dados pelos participantes, que ajudam a reforar esse ponto. Um deles comentou que fez uso de um padro de projetos [FRea04] que aprendeu apenas alguns dias antes. Outro participante mencionou que seus estudos sobre os princpios SOLID (discutidos no Apndice A) o ajudaram durante os exerccios. Segue o trecho mencionado pelo participante:

"At foi engraado, eu estou lendo o Design Patterns (livro), e ele fala de polimorsmo, e foi l que eu mirei pra fazer, porque eu nunca tinha feito nada assim (...), aqui dicilmente eu crio coisa nova, s dou manuteno no cdigo." Alm do mais, o nico participante da indstria que nunca havia praticado TDD armou que no sentiu diferena no processo de criao de classes durante a prtica. Curioso que esse mesmo participante que nunca praticou TDD armou que "sabia que TDD era uma prtica de projeto de classes", diferentemente dos participantes mais experientes que sempre armavam que TDD no s uma prtica de projeto de classes, mas tambm de testes. Isso indica, de certa forma, que a popularidade dos efeitos de TDD no projeto de classes, por mais que nada tenha sido provado, grande.

28

5.2

ANLISE DAS ENTREVISTAS

29

Quando perguntados sobre o que TDD, muitos dos participantes lembraram sobre os efeitos da prtica na qualidade externa e a segurana que isso traz ao desenvolvedor. Uma frase que exemplica isso foi dita por um dos participantes: "[TDD] acho que tem muita relao com qualidade do cdigo e testes de regresso. Acho que as duas principais vantagens que eu tenho quando uso TDD isso: o cdigo ca melhor e depois eu tenho a segurana dos testes de regresso para refatorar." Entretanto, apesar do TDD no guiar o desenvolvedor diretamente para um bom projeto de classes, todos eles armaram que enxergam benefcios na prtica de TDD, mesmo do ponto de vista de projeto de classes. Muitos deles, inclusive, mencionaram a diculdade de parar de usar TDD:

"Voc vai fazer alguma coisa, voc acaba pensando j nos testes que voc vai fazer. difcil falar assim: "programa sem pensar nos testes!"Depois que voc acostuma, voc no sabe outra maneira de programar..."

" complicado se disciplinar [a praticar TDD], mas conforme vai passando o tempo, voc percebe que a curva para se manter o projeto ca bem menos ngreme, comea a perceber os benefcios e a vicia. Voc acaba no se sentindo mais confortvel de escrever cdigo sem teste." Segundo eles, TDD pode ajudar no processo de projeto de classes, mas, para isso, o desenvolvedor deve possuir certa experincia em desenvolvimento de software. Grande parte dos participantes armaram que o projeto de classes criado surgiu de experincias e aprendizados passados. Segundo eles, a melhor opo unir a prtica de TDD com a experincia: "O ideal somar as duas coisas [experincia e TDD] (...) No acredito que TDD sozinho consiga fazer as coisas carem boas. Tem outros conceitos para as coisas carem boas." Nas sub-sees abaixo, apresentamos cada um dos pontos levantados pelos participantes, bem como discutimos sobre o tpico. 5.2.1 Segurana na refatorao

Onze participantes armaram que, durante o processo de criao de projeto de classes, a mudana de ideia constante, anal pouco se conhece do problema, e de como a classe deve ser construda. Este foi o ponto mais comentado pelos participantes. Segundo eles, uma vantagem intrseca do TDD a sute de testes gerada. Essa sute possibilita ao desenvolvedor mudar de ideia e refatorar todo o projeto de classes com segurana. A segurana, segundo eles, fator importante para mudanas de projeto de classes ou mesmo de implementao: "Sim, me d a chance de aprender pelo caminho e fazer algumas coisas diferentes. (...) O teste te d segurana."

30

RELAO ENTRE TDD E PROJETO DE CLASSES: ANLISE QUALITATIVA

5.2

Um participante inclusive mencionou uma experincia real, na qual o TDD fez a diferena. Segundo ele, em muitos momentos ele mudava completamente de ideia sobre a implementao, e conava na bateria de testes para garantir o comportamento esperado: "No TCC da ps, eu estava desenvolvendo uma ferramenta que trabalhava com manipulao de cdigo, e z tudo com TDD. Vrias vezes eu chegava a apagar todo cdigo do sistema, mantinha os testes, e comeava uma nova linha de raciocnio. Achei que me ajudou muito fazer TDD (...), tanto que no m que eu fui executar a ferramenta, antes eu s validava pelos testes."

Novamente, experincia fator fundamental. Para buscar um cdigo melhor durante a refatorao, desenvolvedores devem fazer uso de suas experincias:

"(...) se voc no tiver embasamento sobre esses aspectos de nica responsabilidade, coeso, acoplamento, acho que no adianta muito [fazer TDD]. Voc precisa ter isso em mente para conseguir mudar, precisa desse conhecimento para conseguir refatorar." 5.2.2 Passos menores e simplicidade

TDD sugere que o programador d sempre pequenos passos (conhecidos pelo termo em ingls, baby steps ): deve-se escrever testes sempre para a menor funcionalidade possvel, escrever o cdigo mais simples que faa o teste passar e fazer sempre apenas uma refatorao por vez [Bec02]. Uma justicativa para tal a de que, quanto maior o passo que o programador d, mais tempo ele leva para conclu-lo e, consequentemente, ele ca mais tempo sem feedback sobre o cdigo. Alm disso, faz com que o programador no crie solues mais complexas do que elas precisam ser, tornando o cdigo, a longo prazo, o mais simples possvel. Manter o projeto de classes simples no tarefa fcil, e TDD sugere que o programador escreva sempre o cdigo mais simples que atenda a necessidade. Somente se a necessidade crescer, que o programador dever evoluir o projeto. Uma deciso de projeto de classes pode ser mais complicada do que parece e, sem um teste para mostrar isso rapidamente, o programador dicilmente perceberia o problema [Bec01]. Todas essas armaes podem ser validadas pela observao de oito participantes sobre o assunto. Um deles comentou que, ao no fazer teste, o programador pensa no projeto de classes de uma s vez, criando, por vezes, estruturas mais complexas do que o necessrio. Isso faz com que ele perceba mais tardiamente possveis problemas no desenho inicial: "Porque sem os testes, ns no pensamos em passos menores, mas sim na soluo inteira e acaba por no observar problemas que podem acontecer pelo caminho." Um dos participantes deixou bem claro como ele faz uso dos baby steps, e como isso o ajuda a pensar melhor no projeto de suas classes:

5.2

ANLISE DAS ENTREVISTAS

31

"Porque ns comeamos a pensar no pequeno e no no todo. Quando fao TDD eu escrevo uma regra simples (...), a vou l e escrevo o mtodo. Se passou, passou! Como voc vai aos poucos, a arquitetura vai cando legal. (...) Eu tinha mania de pensar no todo (...), s vezes em vez de voc pensar em um negcio pequeno, voc pensa em um enorme. Acho que o crebro funciona melhor quando voc pensa pequeno. Se voc pensa grande, pra mim bvio que voc vai deixar alguma coisa faltando." Essa armao similar ao discurso comum das metodologias geis. Equipes que seguem as ideias geis optam por no fazer o chamado big design up-front (BDUF), e deixam que o projeto de classes evolua ao longo do tempo, mantendo o cdigo o mais claro e simples possvel, e refatorando sempre que h necessidade. Decises de projeto de classes so tomadas com a conscincia de que elas sero alteradas no futuro [Fow04]. Um deles comentou inclusive da falta de foco que o programador tem quando no pratica TDD. Ao ter um objetivo curto (que, no caso dos praticantes de TDD, fazer o teste passar), o desenvolvedor se concentra mais para alcan-lo: "Talvez sejamos pessoas desfocadas naturalmente. Voc v uma coisa e j te d vontade de corrigir aquilo. (...)"

Outros estudos tambm, de certa forma, mostraram que os efeitos de baby steps podem ir alm. Em projetos novos, os praticantes de TDD armam que sentem menos necessidade da utilizao de recursos de depurao de cdigo [GW04] [Jan05]. A quantidade de cdigo escrita entre um teste e outro tende a ser pequena, e caso um teste falhe inesperadamente, o programador pode simplesmente reverter as alteraes para a verso anterior estvel e comear novamente. Essa abordagem pode muitas vezes ser mais produtiva do que a atividade de depurao [Jan05]. Por essas e outras razes, desenvolvedores armam que so mais produtivos quando praticam TDD. Apesar de o custo da escrita do teste existir, a longo prazo o desenvolvedor gasta menos tempo com depuraes ou erros de regresso, e com isso tem sua produtividade aumentada [GW03]. 5.2.3 Espao para se pensar

Em uma analogia feita por um dos participantes, os testes so como uma folha de rascunho, onde eles podem tentar diferentes abordagens e mudar de ideia constantemente. Segundo ele, ao comear a escrever um teste, os programadores esto, pela primeira vez, utilizando a sua prpria classe. Isso faz com que ele busque por uma maneira melhor e mais clara de invocar seus comportamentos, e facilitar a utilizao da classe: "Os testes ajudam nisso. So uma folha de rascunho para voc tentar modelar isso da melhor maneira possvel. Se fosse modelar isso direto, como se voc tivesse uma forma, e se errar, quebrou. Ou se voc errar, voc vai ter muito trabalho pra consertar. O lance de voc testar e comear a pensar em testes, voc est ali com uma folha em branco, e voc pode arrancar qualquer coisa que est ali, pois essa coisa ainda no existe."

32

RELAO ENTRE TDD E PROJETO DE CLASSES: ANLISE QUALITATIVA

5.2

Por diversas vezes, ao ouvir este tipo de armao, sempre indagvamos ao participante os motivos dele no pensar sobre o projeto de classes mesmo quando no fazem TDD. Segundo eles prprios, quando no se pratica TDD, os desenvolvedores cam to focados no cdigo que estavam escrevendo, que acabam por no pensar no projeto das classes que estavam criando. Segundo os participantes, os testes fazem eles pensarem em como a classe que est sendo criada interagir com outros objetos, e no quo fcil fazer uso da mesma. Os trechos abaixo mostram as diferentes opinies sobre o mesmo ponto: "Acho que o normal das pessoas no pensar antes. Parece que o natural j sair fazendo (at pela presso interna, que aqui no to grande). (...) Poucas pessoas pensam antes de comear. Com TDD, voc obrigado a pensar, o TDD faz voc parar e pensar, estruturar. No meu natural pensar antes, mas com TDD sim."

"Como eu primeiro penso no que eu vou precisar a partir dos testes, ou seja, eu preciso disso e daquilo, o teste me faz pensar antes de sair desenvolvendo. Com os testes eu paro pra pensar antes. A acredito que ns consigamos pensar melhor, numa soluo mais bacana." Um dos participantes foi ainda mais preciso na sua declarao. Segundo ele, o desenvolvedor que no pratica TDD, por no pensar no projeto de classes criado, acaba por no fazer bom uso da orientao a objetos. E, novamente, isso se deve velocidade com que desenvolvedores sem TDD escrevem cdigo. Ao contrrio, TDD fora o programador a desacelerar, possibilitando-o a pensar melhor sobre o que est fazendo: "Porque sem o TDD, no calor do momento, voc vai acoplando, vai herdando, vai agregando, e no pensa que no futuro isso possa dar algum problema. Com TDD, voc forado a ir mais devagar, d tempo de pensar melhor nas coisas." O teste, no m, o primeiro cliente da classe que o programador ainda est por escrever e isso o faz pensar melhor a respeito do comportamento que ele espera da classe. Alm disso, programadores contemplam e decidem tambm sobre a interface (como nomes de classes e mtodos, tipos de retorno e excees lanadas) que a classe ter [JS06]. No diretamente relacionado a projeto de classes, um participante comentou inclusive que a prtica de TDD faz com que ele encontre problemas inclusive no requisito. Segundo ele, isso se deve ao fato do teste faz-lo pensar melhor sobre o que o cdigo que est sendo escrito deve fazer:

"Algumas vezes ele [o teste] acaba mostrando problemas da regra de negcio. Mostrava problemas que s vezes o especicador no pegava. (...)."

Seguindo a mesma linha de raciocnio, outro participante comentou sobre a possibilidade do teste servir como documentao para outros desenvolvedores. Segundo ele, quando um outro desenvolvedor ler o teste, ele entender o que aquela classe faz ou qual sua importncia para o sistema:

5.2

ANLISE DAS ENTREVISTAS

33

"Quando estou escrevendo meu rascunho, eu tenho a liberdade de pensar o mximo possvel para quando algum pegar isso para entender, ou para debugar, ou mesmo para corrigir bug, ele vai conseguir saber o que uma Fatura ou faz. Sem precisar abrir uma Fatura real." 5.2.4 Feedback mais rpido

A grande maioria dos participantes tambm comentaram que uma diferena que percebem no momento que praticam TDD o feedback mais constante. Na maneira tradicional, o tempo entre a escrita do cdigo de produo e o cdigo de testes muito grande. O TDD, ao solicitar que o desenvolvedor escreva o teste antes, tambm faz com que o desenvolvedor receba o feedback que os testes podem dar mais cedo: "Voc ia olhar pro teste, e falar: "Est legal? No est?", e ia fazer de novo." Na Figura 5.1, ilustramos a diferena entre a quantidade de feedback durante a prtica de TDD em relao ao desenvolvimento tradicional.

Figura 5.1: Feedback provido pela prtica de TDD

A velocidade em que a prtica de TDD d feedback ao desenvolvedor possibilita que o mesmo tome decises sobre o cdigo enquanto o custo de mudana ainda baixo. O trabalho de Vanderburg [Van05] tambm conrma esse ponto. Ele diz que TDD d feedback em questo de minutos e, em questo de tempo, s inferior programao pareada. O grco, baseado no trabalho dele, pode ser visto na Figura 5.2. Um participante comentou que, com o teste, o desenvolvedor pode observar e criticar o cdigo que escreveu no momento logo aps a escrita. E essa crtica, de forma contnua, faz com que o desenvolvedor acabe por pensar constantemente no cdigo que est produzindo:

"Quando voc faz o teste, voc v logo o que no gostou do mtodo daquele jeito (...), voc no percebe isso at que voc use o teste." Diminuir o tempo entre a escrita do cdigo e a escrita do teste tambm o ajuda a desenvolver cdigo que efetivamente resolve o problema. Segundo os participantes, na maneira tradicional, o desenvolvedor escreve muito cdigo antes de saber se o mesmo funciona:

34

RELAO ENTRE TDD E PROJETO DE CLASSES: ANLISE QUALITATIVA

5.3

Figura 5.2: Prticas de XP e Tempo de Feedback (baseado em [Van05])

"[O teste] no s uma especicao; ele tem que de fato funcionar. Ento, como voc diminui muito o tempo entre escrever um programa que funcione e testar aquilo, voc consegue mais rpido ver se aquela parte pequena funciona ou no (...)" 5.2.5 Busca pela testabilidade

Talvez o principal ponto pelo qual a prtica ajude os desenvolvedores no projeto de classes seja pela constante busca pela testabilidade. possvel inferir que, quando se comea a escrita do cdigo pelo seu teste, o cdigo de produo deve ser, necessariamente, possvel de testar. Por outro lado, quando o cdigo no fcil de ser testado, os desenvolvedores entendem isso como um mau cheiro de projeto de classes. Quando isso acontece, os desenvolvedores geralmente tentam refatorar o cdigo para possibilitar que os mesmos sejam testados mais facilmente. Um dos participantes, inclusive, armou que leva isso como uma regra: se est difcil testar, possvel melhorar: "Eu utilizo isso como uma regra: sempre que est muito complexo [o teste], acho que ns temos que parar e refatorar, porque, na minha opinio, d pra car mais simples." Esse ponto, na verdade, j foi levantado antes por Feathers [Fea07]. Quanto mais difcil for a escrita do teste, maior a chance da existncia de algum problema de projeto de classes. Segundo ele, existe uma sinergia muito grande entre uma classe com alta testabilidade e um bom projeto de classes: se o programador busca por testabilidade, acaba criando um bom projeto de classes; se busca por um bom projeto de classes, acaba escrevendo cdigo mais testvel. Mas, os participantes foram ainda mais longe. Durante as entrevistas, vrios deles mencionaram diversos padres que encontram no feedback dos testes, e que os fazem pensar sobre os possveis problemas de acoplamento, coeso, falta de abstrao, etc., na classe que esto criando. Esses padres so melhor discutidos a seguir.

5.3

Padres de Feedback de TDD

Na busca pela testabilidade, o desenvolvedor encorajado a escrever um cdigo que seja facilmente testvel. Cdigos assim possuem algumas caractersticas interessantes, como a facilidade para

5.3

PADRES DE FEEDBACK DE TDD

35

invocar o comportamento esperado, a no necessidade de pr-condies complicadas e a explicitao de todas as dependncias que a classe possui. Outros autores j comentaram que TDD encoraja o programador a escrever componentes fracamente acoplados, de maneira que eles possam ser testados de maneira isolada e, em um nvel maior, combinados com outros componentes. Programar voltado para a criao de abstraes uma prtica de orientao a objetos h muito tempo conhecida. Pensar em classes e dar maior foco maneira com que elas se relacionam do que com o modo no qual determinado comportamento ser implementado torna-se mais natural ao praticar TDD [eNP09]. Como mencionado anteriormente, grande parte do feedback que os testes do, acontecem no momento em que o programador encontra diculdades para a escrita dos mesmos. Esta seo discute padres levantados pelos praticantes que os levam a crer que h um problema de projeto de classes no cdigo que est sendo testado. 5.3.1 Padres Ligados Coeso

Quando um nico mtodo necessita de diversos testes para garantir seu comportamento, o mtodo em questo provavelmente complexo e/ou possui diversas responsabilidades. Cdigos assim possuem geralmente diversos caminhos diferentes e tendem a alterar muitos atributos internos do objeto, obrigando o desenvolvedor a criar muitos testes, caso queira ter uma alta cobertura de testes. A esse padro, demos o nome de Muitos Testes Para Um Mtodo. O mesmo pode ser entendido quando o desenvolvedor escreve muitos testes para a classe como um todo. Classes que expem muitos mtodos para o mundo de fora tambm tendem a possuir muitas responsabilidades. Chamamos este padro de Muitos Testes Para Uma Classe. Outro problema de coeso pode ser encontrado quando o programador sente a necessidade de escrever cenrios de teste muito grandes para uma nica classe ou mtodo. possvel inferir que essa necessidade surge em cdigos que lidam com muitos objetos e fazem muita coisa. Nomeamos esse padro de Cenrio Muito Grande. Um padro no explicitamente levantado pelos participantes, mas notado por ns, quando o desenvolvedor sente a necessidade de se testar um mtodo que no pblico. Mtodos privados geralmente servem para transformar o mtodo pblico em algo mais fcil de ler. Ao desejar test-lo de maneira isolada, o programador pode estar de frente a um mtodo que possua uma responsabilidade suciente para ser alocada em uma outra classe. A esse padro, chamamos de Testes em Mtodo Que No Pblico. 5.3.2 Padres Ligados ao Acoplamento

O uso abusivo de objetos dubls para testar uma nica classe indica que a classe sob teste possui problemas de acoplamento. possvel deduzir que uma classe que faz uso de muitos objetos dubls depende de muitas classes, e portanto, tende a ser uma classe instvel. A esse padro, demos o nome de Objetos Dubl em Excesso. Outro padro percebido por ns a criao de objetos dubls que no so utilizados em alguns mtodos de testes. Isso geralmente acontece quando a classe altamente acoplada, e o resultado da ao de uma dependncia no interfere na outra. Quando isso acontece, o programador acaba por escrever conjuntos de testes, sendo que alguns deles lidam com um sub-conjunto dos objetos dubls, enquanto outros testes lidam com o outro sub-conjunto de objetos dubls. Isso indica um alto acoplamento da classe, que precisa ser refatorada. A esse padro demos o nome de Objetos

36

RELAO ENTRE TDD E PROJETO DE CLASSES: ANLISE QUALITATIVA

5.3

Dubl No Utilizados. 5.3.3 Padres Ligados Falta de Abstrao

A falta de abstrao geralmente faz com que uma simples mudana precise ser feita em diferentes pontos do cdigo. Quando uma mudana acontece e o programador obrigado a fazer a mesma alterao em diferentes testes, isso indica a falta de uma abstrao correta para evitar a repetio desnecessria de cdigo. A esse padro damos o nome de Mesma Alterao Em Diferentes Testes. Analogamente, o programador pode perceber a mesma coisa quando ele comea a criar testes repetidos para entidades diferentes. Chamamos esse padro de Testes Repetidos Para Entidades Diferentes. Quando o desenvolvedor comea o teste e percebe que a interface pblica da classe no est amigvel, pode indicar que abstrao corrente no clara o suciente e poderia ser melhorada. A esse padro, chamamos de Interface No Amigvel. Outro padro no mencionado explcitamente pelos participantes a existncia da palavra "se" no nome do teste. Testes que possuem nomes como esse geralmente indicam a existncia de um "if" na implementao do cdigo de produo. Essas diversas condies podem, geralmente, ser refatoradas e, por meio do uso de poliformismo, serem eliminadas. A falta de abstrao nesse caso evidenciada pelo padro Condicional No Nome Do Teste. 5.3.4 Relao dos padres com os princpios de projeto de classes

possvel relacionar os padres de feedback levantados pelos participantes com os mau cheiros de projeto de classes comentados nesta pesquisa. Na Tabela 5.1, mostramos essa relao, e como esses padres podem efetivamente ajudar o desenvolvedor a procurar por problemas no seu projeto de classes. Padro Possveis Mau Cheiros de Projeto de Classes Complexidade Desnecessria, Opacidade Complexidade Desnecessria, Opacidade Opacidade, Fragilidade Complexidade Desnecessria Fragilidade Fragilidade Fragilidade, Rigidez Repetio Desnecessria, Rigidez Opacidade Rigidez, Fragilidade Possveis Princpios Feridos PRU PRU PRU PRU, PAF PID, PAF PID, PAF PRU PRU ISP PRU, PAF

Muitos Testes Para Um Mtodo Muitos Testes Para Uma Classe Cenrio Muito Grande Testes Em Mtodo Que No Pblico Objetos Dubl em Excesso Objetos Dubls No Utilizados Mesma Alterao Em Diferentes Testes Testes Idnticos Para Entidades Diferentes Interface No Amigvel Condicional No Nome Do Teste

Tabela 5.1: Relao entre os padres de feedback de TDD e mau cheiros de projeto de classes

Captulo 6

Ameaas Validade
6.1 Validade de Construo

Uma pesquisa vlida do ponto de vista de construo quando seus instrumentos realmente medem as informaes necessrias para o estudo. 6.1.1 Exerccios de pequeno porte

Os exerccios propostos so pequenos perto de um projeto real. Todos os exerccios propostos contm problemas localizados de projeto de classes. E, uma vez que esta pesquisa tenta avaliar os efeitos de TDD no projeto de classes, acreditamos que os problemas conseguem simular de forma satisfatria problemas de projeto de classes que desenvolvedores encaram no dia a dia de trabalho. Alm disso, ao nal do exerccio, os participantes responderam uma pergunta sobre a semelhana entre os problemas de projeto de classes propostos e os problemas encontrados no mundo real. Todos os participantes da indstria armaram que os problemas se parecem com os que eles enfrentam no dia a dia de trabalho. 6.1.2 Criao dos exerccios

Outra possvel ameaa relacionada aos exerccios que todos eles foram criados pelos pesquisadores desta pesquisa. Eles podem, de certa forma, ter beneciado a prtica de TDD. Conforme armado acima, os participantes disseram que os problemas propostos eram similares aos encontrados no mundo real. Contudo, o mesmo estudo deve ser executado com novos e diferentes exerccios. 6.1.3 Mtricas selecionadas

Apesar de todas as mtricas selecionadas serem de grande uso pela academia elas foram selecionadas puramente por convenincia. Talvez o uso de diferentes mtricas pudesse levar a diferentes resultados na anlise quantitativa. 6.1.4 Estudos piloto no foram at o m

Por no termos executado um estudo piloto por completo, comeamos o estudo sem realmente validar o protocolo sugerido. Entretanto, na prtica, isso no se mostrou um problema, uma vez que o protocolo foi utilizado sem grandes diculdades. 6.1.5 Falta de medio sobre a utilizao da prtica de TDD

No conseguimos medir de maneira precisa se o participante fez uso de TDD conforme sugerido pelos livros. No primeiro desenho da pesquisa, sugerimos o uso de ferramentas automatizadas, como

37

38

AMEAAS VALIDADE

6.3

plugins do Eclipse para monitorar o desenvolvedor. Mas, devido a alta complexidade de se criar um desses, optamos por apenas perguntar sobre isso no questionrio aps a resoluo dos exerccios. Conforme esperado, os participantes armaram fazer uso de TDD durante grande parte do tempo que eram solicitados a praticarem. 6.1.6 Seleo dos candidatos para entrevista

A escolha dos candidatos para o processo de entrevista foi subjetiva, baseada na identicao dos participantes que nos deram informaes contraditrias. Por esse motivo, participantes com informaes importantes podem no ter sido entrevistados.

6.2

Validade interna

Uma pesquisa tem alta validade interna quando ela capaz de diminuir o valor das hipteses alternativas, mostrando que a hiptese estudada a explicao mais plausvel dos dados. Para isso, a pesquisa precisa controlar as possveis variveis que poderiam inuenciar na coleta, anlise e interpretao dos dados. A validade interna portanto garantida quando o planejamento do estudo nos possibilita ter certeza de que as relaes observadas de forma emprica no podem ser explicadas por outros fatores. As sub-sees abaixo discutem as possveis ameaas validade interna. 6.2.1 Efeitos recentes de TDD na memria

Muitos dos participantes da indstria armaram que utilizam TDD no seu dia a dia de trabalho. Isso pode fazer com que o participante no avalie friamente as vantagens e desvantagens do desenvolvimento sem TDD. Para diminuir esse vis, os participantes zeram alguns exerccios tambm sem TDD, para que ambos os estilos de desenvolvimento (com e sem TDD) estivessem recentes em sua memria. 6.2.2 Exerccios inacabados

Alguns participantes no terminaram suas implementaes dos exerccios. Isso pode inuenciar na anlise quantitativa, anal, um projeto de classes que seria complexo assim que pronto, ao olho da mtrica, pode aparentar ser simples. 6.2.3 Inuncia do pesquisador

Como discutido no captulo 3, o pesquisador possui um papel fundamental em pesquisas qualitativas. Mas isso pode fazer com que a interpretao dos resultados seja inuenciada pelo contexto, experincias, e at vises do prprio pesquisador. Neste estudo, a nossa opinio teve forte inuncia na seleo dos candidatos para a entrevista. Para diminuir esse problema, revisamos todas as anlises, buscando por concluses incorretas ou no to claras.

6.3

Validade externa

Uma pesquisa possui validade externa quando ela possibilita ao pesquisador generalizar os resultados obtidos a outras populaes ou outros contextos. As sub-sees abaixo discutem as possveis ameaas validade externa desta pesquisa. 6.3.1 Desejabilidade social

Enviesamento pela desejabilidade social o termo cientco usado para descrever a tendncia dos participantes de responder s questoes de modo que sejam bem vistos pelos outros membros

6.4

VALIDADE DE CONCLUSO

39

da comunidade [CM60]. Mtodos geis e TDD possuem um discurso forte. A comunidade brasileira de mtodos geis ainda nova e percebe-se de maneira emprica que muitos repetem o discurso sem grande experincia ou embasamento no assunto. No caso desta pesquisa, um possvel vis o participante responder o que a literatura diz sobre TDD, e no exatamente o que ele pratica e sente sobre os efeitos da prtica. Para diminuir esse vis, eliminaramos do processo de anlise os participantes que responderam as perguntas de forma supercial, apenas repetindo a literatura. Na prtica, isso no aconteceu. Em sua maioria, poucas foram as respostas nas quais os participantes foram superciais. Nestes casos, essas respostas foram eliminadas da anlise. 6.3.2 Quantidade de participantes insuciente

Apesar de termos feito contato com diversas empresas e grupos de desenvolvimento de software, objetivando encontrar um bom nmero de participantes para a pesquisa, a quantidade de participantes nal do estudo pode no ser suciente para generalizar os resultados encontrados.

6.4

Validade de Concluso

A validade de concluso discute se os pontos as quais a pesquisa chegou realmente fazem sentido. 6.4.1 Padres encontrados

Os padres levantados pelos participantes durante o processo de entrevistas foi revisado pelos autores desta pesquisa e, ao nal, consideramos que todos eles fazem sentido. No entanto, podem haver ainda mais padres a serem descobertos.

Captulo 7

Concluses e Trabalhos Futuros

7.1 Introduo

Neste trabalho, provemos evidncia emprica sobre os benefcios da prtica de TDD no projeto de classes. Discutimos e entendemos como a prtica pode fazer a diferena no dia a dia de um desenvolvedor de software, trazendo um melhor signicado armao de que a prtica de TDD melhora o projeto de classes. Ao revisitarmos as questes levantadas no comeo desta pesquisa, percebemos que as respostas que chegamos so muito parecidas com as que so encontradas na literatura, com a diferena de que conseguimos observar padres de feedback que aparecem no momento em que o desenvolvedor pratica TDD, e que o guia durante o desenvolvimento. Divulgar o que foi encontrado por este trabalho de extrema importncia para times de desenvolvimento de software, especialmente aos que seguem algum tipo de metodologia gil pois, ao conhecer os padres aqui catalogados, os desenvolvedores podero perceber problemas de projeto mais cedo e melhorar seu projeto de classes. Nas sub-sees abaixo, respondemos cada uma das questes levantadas por este trabalho.

7.2

Qual a inuncia de TDD no projeto de classes?

A prtica de TDD pode inuenciar no processo de criao do projeto de classes. No entanto, ao contrrio do que comentado pela indstria, a prtica de TDD no guia o desenvolvedor para um bom projeto de classes de forma automtica; a experincia e conhecimento do desenvolvedor so fundamentais ao criar software orientado a objetos. A prtica, por meio dos seus possveis feedbacks em relao ao projeto de classes, discutidos em profundidade na Seo 5.3, pode servir de guia para o desenvolvedor. Esses feedbacks, quando observados, fazem com que o desenvolvedor perceba problemas de projeto de classes de forma antecipada, facilitando a refatorao do cdigo. Portanto, essa a forma na qual a prtica guia o desenvolvedor para um melhor projeto de classes: dando retorno constante sobre os possveis problemas existentes no atual projeto de classes. tarefa do desenvolvedor perceber estes problemas e melhorar o projeto de acordo.

7.3

Qual a relao entre TDD e as tomadas de decises de projeto feitas por um desenvolvedor?

Como discutido acima, a prtica de TDD e seus testes de unidade, intrsecos ao processo, podem ajudar os desenvolvedores a antecipar os problemas do projeto por meio de um feedback rpido. Em outras palavras, o desenvolvedor que pratica TDD escreve os testes antes do cdigo. Isso faz com 40

COMO A PRTICA DE TDD INFLUENCIA O PROGRAMADOR NO PROCESSO DE PROJETO DE

7.5

CLASSES, DO PONTO DE VISTA DO ACOPLAMENTO, COESO E COMPLEXIDADE?

41

que o teste de unidade que est sendo escrito sirva de rascunho para o desenvolvedor. Ao observar o cdigo do teste de unidade com ateno, o desenvolvedor pode perceber problemas no projeto de classes que est criando. Problemas esses como classes que possuem diversas responsabilidades ou que possuem muitas dependncias. Outras prticas do o mesmo feedback para o desenvolvedor, mas a vantagem do teste que o retorno praticamente imediato. Alm disso, como o teste escrito antes, o desenvolvedor pode mudar de ideia sobre o projeto enquanto o custo de mudana ainda baixo (anal, o projeto ainda no foi implementado).

7.4

Como a prtica de TDD inuencia o programador no processo de projeto de classes, do ponto de vista do acoplamento, coeso e complexidade?

Ao escrever um teste de unidade para uma determinada classe, o desenvolvedor obrigado a passar sempre pelos mesmos passos. Todo teste de unidade composto de um conjunto de linhas responsveis por montar o cenrio do teste, um conjunto de linhas que executam a ao sob teste e, por m, um conjunto de linhas que garantem que o comportamento foi executado de acordo com o esperado. Uma diculdade na escrita de qualquer um desses conjuntos pode implicar em problemas no projeto de classes. Por exemplo, uma classe que para ser testada necessita de grandes cenrios, pode nos indicar que a classe sob teste possui pr-condies muito complicadas. J diculdades na hora de executar a ao sob teste pode nos indicar que a interface pblica dessa classe no amigvel. Classes pouco coesas, por exemplo, possuem diversas responsabilidades diferentes. Isso implica em mais pontos a serem testados que, por consequncia, implica em um maior nmero de testes para aquela unidade. Classes altamente acopladas, por exemplo, exigem uma grande quantidade de objetos dubls, tornando a escrita do teste mais difcil. Seguindo esta linha de pensamento, concordamos com a opinio do Feathers [Fea07], que diz que uma classe difcil de ser testada muito provavelmente no apresenta um bom projeto de classes.

7.5

Lies Aprendidas

Ao longo desta pesquisa, ns aprendemos, na prtica, muita coisa sobre planejamento e execuo de estudos em engenharia de software. Alguns desses pontos valem a pena serem mencionados para que o pesquisador que decidir evoluir o estudo no cometa os mesmos erros que acabamos por cometer. A execuo do nosso estudo inicial exigia um ambiente razoavelmente complicado de ser congurado, com software de gravao de tela instalado, plugins do Eclipse, controlador de verso Git, entre outros. Isso dicultou as empresas que participaram do estudo. A consequncia disso foi um certo atraso para iniciar a execuo do estudo nas empresas, devido ao alto nmero de software a serem iniciados antes da implementao. Alm do mais, em muitas empresas, o software de gravao de tela e o plugin do Eclipse no funcionaram e, ao m, abandonamos a ideia de obter esses dados. Muitos participantes de uma s vez faz com que o pesquisador no consiga dar ateno a todos os participantes. J que o ambiente era complicado de ser montado, muitos participantes esqueciam de determinadas etapas, ou tinham dvidas sobre o enunciado. Na prxima execuo, uma alternativa levar um pesquisador auxiliar, ou at mesmo um ajudante.

42

CONCLUSES E TRABALHOS FUTUROS

7.7

Como o tempo dado a todos os participantes de uma empresa era xo, alguns deles acabavam o exerccio antes que outros. Em muitos casos, os participantes nos perguntavam o que deveriam fazer com o tempo restante. Constantemente eles nos perguntam sobre a possibilidade de refatorar o cdigo que haviam escrito, e ns aceitvamos. Sugerimos ao pesquisador que pense antecipadamente nesses casos extremos. Por trabalhar com indstria, os mais diferentes problemas podem acontecer at a execuo do estudo. Uma empresa, por exemplo, cancelou sua participao dias antes. Em outras, alguns participantes que eram dados como certos, tambm no estavam presentes no dia. Sugerimos ao prximo pesquisador que faa contatos com muitas empresas e j trabalhe pensando em possveis desistentes. Algumas empresas fora da regio aceitaram participar do estudo. Em uma delas, conseguimos viajar at a cidade e executar o estudo. Nas outras optamos por no prosseguir com o estudo, anal nosso planejamento no contemplava a execuo do estudo de forma remota. Sugerimos a possibilidade de execuo remota nos prximos planejamentos. Foi realizado apenas um piloto por inteiro; os outros convidados, por falta de tempo, executaram apenas determinadas partes do estudo. Nos prximos, sugerimos que o pesquisador encontre participantes com mais tempo disponvel e com experincias variadas.

7.6

Trabalhos Futuros

Todos os padres comentados neste trabalho foram levantados junto aos desenvolvedores da indstria de software brasileira. Apesar do pequeno nmero de desenvolvedores entrevistados, muitos padres emergiram. Isso pode signicar que existam ainda outros padres de TDD. Um possvel trabalho futuro seria continuar na busca de padres de feedback. Alm disso, um estudo que visa entender se desenvolvedores que conhecem esses padres de antemo percebem problemas de projeto antes de desenvolvedores que no conhecem esses padres, poderia ser de grande valia para a indstria. Como observamos neste estudo, nem mesmo os especialistas perceberam diferenas entre os cdigos produzidos com e sem TDD. Uma justicativa para tal a falta de conhecimento sobre os padres aqui discutidos. de vital importncia que os desenvolvedores, alm de conhecer a mecnica da prtica, entendam tambm como extrair retorno constante sobre a qualidade do seu projeto de classes. Ns comeamos esta pesquisa com estudantes de diferentes semestres em uma universidade particular em So Paulo. Mas, devido ao baixo nmero de participantes, optamos por no discutir os dados analisados nesta pesquisa. Uma outra sugesto, levantada apenas aps a nalizao do estudo, a de que os prprios participantes poderiam estar se observando para ter um entendimento melhor dos efeitos da prtica. Um novo estudo qualitativo, levando isso em conta, poderia ser interessante e agregar ainda mais valor discusso. Encontrar os momentos onde o teste fez o desenvolvedor mudar de ideia sobre o projeto que est escrevendo pode agregar novas informaes ao trabalho. A criao de um software, como um plugin para Eclipse, no qual o desenvolvedor descreve sua linha de pensamento e decises tomadas seria de grande valia.

PRODUES AO LONGO DO MESTRADO

43

7.7

Produes ao Longo do Mestrado

Ao longo do mestrado, produzimos outros estudos, workshops e palestras que nos agregaram valor e nos ajudaram a melhorar este trabalho. Como principais trabalhos, listamos: 1. Curso sobre evoluo de software, dado em conjunto com Gustavo Oliva e Marco Aurlio Gerosa, no SBES de 2011; 2. Apresentao sobre TDD e seus possveis efeitos no projeto de classes no QCON 2010; 3. Artigo entitulado Most Common Mistakes in Test-Driven Development Practice: Results from an Online Survey with Developers, aceito no Primeiro Workshop Internacional sobre TDD, em 2010; 4. Artigo entitulado What Concerns Beginner Test-Driven Development Practitioners: A Qualitative Analysis of Opinions in an Agile Conference, aceito no WBMA em 2011; 5. Relato de experincia entitulado Increasing Learning in an Agile Environment: Lessons Learned in an Agile Team, aceito no Agile de 2011; 6. Artigo entitulado Como a Prtica de TDD Inuencia o Projeto de Classes em Sistemas Orientados a Objetos: Padres de Feedback para o Desenvolvedor, aceito no Simpsio Brasileiro de Engenharia de Software em 2012; 7. Execuo de um workshop sobre TDD na Agile Brazil 2011, que originou os exerccios utilizados nesta pesquisa; 8. Escrita da ferramenta de minerao de repositrio de cdigos rEvolution, utilizado para calcular as mtricas em cima do cdigo produzido pelos participantes. Software esse que deu origem ao MetricMiner, ferramenta de minerao de repositrios web desenvolvida pelo LAPESSC1 .

7.8

Resultados Esperados

Ns esperamos que o resultado deste estudo ajude desenvolvedores de software a antecipar problemas de projeto de classes, gerando melhorias constantes e, por consequncia, diminuindo o custo de manuteno e evoluo do sistema. Com o catlogo de padres levantados aqui, o desenvolvedor praticante de TDD pode agora perceber novos feedbacks que a prtica pode lhe dar. Aos que no praticam TDD, a leitura deste trabalho pode ajudar na deciso de comear a utilizar TDD ou no durante seu ciclo de desenvolvimento. Alm disso, esperamos que agora o ditado sobre a inuncia de TDD no projeto de classes esteja melhor explicado, e que desenvolvedores entendam que experincia e conhecimento em boas prticas de codicao so necessrios para que TDD os guie em direo a um bom projeto de classes.

http://lapessc.ime.usp.br. ltimo acesso em 19 de junho de 2012.

Apndice A

Projeto de Classes em Sistemas Orientados a Objetos

Conforme sugerido por esta pesquisa, para escrever classes com alta testabilidade, o praticante de TDD acaba por fazer uso de boas prticas de desenvolvimento de software. Esse apndice discute algumas dessas boas prticas, que foram utilizadas durante o processo de avaliao desta pesquisa.

A.1

Sintomas de Projetos de Classes em Degradao

Diz-se que um projeto de classes est degradando quando o mesmo comea a car difcil de evoluir, o reso de cdigo se torna mais complicado do que repetir o trecho de cdigo, ou o custo de se fazer qualquer alterao no projeto de classes se torna alto. Robert Martin [Mar02] enumerou alguns sintomas de projeto de classes em degradao, chamados tambm de "maus cheiros" de projeto de classes. Esses sintomas so parecidos com os maus cheiros de cdigo ("code smells" ), mas em um nvel mais alto: eles esto presentes na estrutura geral do software ao invs de estarem localizados em apenas um pequeno trecho de cdigo. Esses sintomas podem ser medidos de forma subjetiva e algumas vezes de forma at objetiva. Geralmente, esses sintomas so causados por violaes de um ou mais princpios de projeto de classes, apresentados na seo A.2. Muitos desses problemas so relacionados gerncia de dependncias. Quando essa atividade no feita corretamente, o cdigo gerado torna-se difcil de manter e reusar. Entretanto, quando bem feita, o software tende a ser exvel, robusto e suas partes reusveis. A.1.1 Rigidez

Rigidez a tendncia do software em se tornar difcil de mudar, mesmo de maneiras simples. Toda mudana causa uma cascata de mudanas subsequentes em mdulos dependentes. Quanto mais mdulos precisam ser modicados, maior a rigidez do projeto de classes. Quando um projeto de classes est muito rgido, no se sabe com segurana quando uma mudana ter m. Mudanas simples passam a demorar muito tempo at serem aplicadas no cdigo e frequentemente acabam superando em vrias vezes a estimativa de esforo inicial. Frases como "isto foi muito mais complicado do que eu imaginei" tornam-se populares. Neste momento, gerentes de desenvolvimento comeam a car receosos em permitir que os desenvolvedores consertem problemas no crticos. A.1.2 Fragilidade

Fragilidade a tendncia do software em quebrar em muitos lugares diferentes toda vez que uma nica mudana acontece. Frequentemente, os novos problemas ocorrem em reas no relacionadas conceitualmente com a rea que foi mudada, tornando o processo de manuteno demasiadamente custoso, complexo e tedioso.

44

SINTOMAS DE PROJETOS DE CLASSES EM DEGRADAO

45

Consertar os novos problemas usualmente passa a resultar em outros novos problemas e assim por diante. Infelizmente, mdulos frgeis so comuns em sistemas de software. So estes os mdulos que sempre aparecem na lista de defeitos a serem corrigidos. Alm disto, desenvolvedores comeam a car receosos de alterar certos trechos de cdigo, pois sabem que estes esto to frgeis que qualquer mudana simples fatalmente acarretar na introduo de problemas inesperados e de naturezas diversas. A.1.3 Imobilidade

Imobilidade a impossibilidade de se reusar software de outros projetos ou de partes do mesmo projeto. Neste cenrio, o mdulo que se deseja reutilizar frequentemente tem uma bagagem muito grande de dependncias e no possui cdigo claro. Depois de muita investigao, os arquitetos descobrem que o trabalho e o risco de separar as partes desejveis das indesejveis so to grandes, que o mdulo acaba sendo reescrito ao invs de reutilizado. A.1.4 Viscosidade

Quando uma mudana deve ser realizada, usualmente h vrias opes para realizar tal mudana. Quando as opes que preservam o projeto de classes so mais difceis de serem implementadas do que aquelas que no o preservam, h alta viscosidade de projeto de classes. Neste cenrio, fcil fazer a "coisa errada"e difcil fazer a "coisa certa", ou seja, difcil preservar e aprimorar o projeto de classes. A.1.5 Complexidade Desnecessria

Detecta-se complexidade desnecessria no projeto de classes quando ele contm muitos elementos inteis ou no utilizados (dead code ). Geralmente ocorre quando h muito projeto inicial (up-front design ) e no se segue uma abordagem de desenvolvimento iterativa e incremental, de modo que os projetistas tentam prever uma srie de futuros requisitos para o sistema e concebem um projeto de classes demasiadamente exvel ou desnecessariamente sosticado. Frequentemente apenas algumas previses acabam se concretizando ao longo do tempo e, neste meio perodo, o projeto de classes carrega o peso de elementos e construes no utilizados. O software ento se torna complexo e difcil de ser entendido. Projetos com complexidade muito alta comumente afetam a produtividade, porque quando os desenvolvedores herdam tal projeto, eles gastam muito tempo aprendendo as nuances do projeto de classes antes que possam efetivamente estend-lo ou mant-lo confortavelmente [Ker04]. A.1.6 Repetio Desnecessria

Quando h repetio de trechos de cdigo, sinal de que uma abstrao apropriada no foi capturada durante o processo de projeto de classes (ou inclusive na anlise). Esse problema frequente e comum encontrar softwares que contenham dezenas e at centenas de elementos com cdigos repetidos. Descobrir a melhor abstrao para eliminar a repetio de cdigo geralmente no est na lista de itens de alta prioridade dos desenvolvedores, de maneira que a resoluo do problema acaba sendo eternamente postergada. Tambm, o sistema se torna cada vez mais difcil de entender e principalmente de manter, pois os problemas encontrados em uma unidade de repetio devem ser corrigidos potencialmente em toda repetio, com o agravante de que uma repetio pode ter forma ligeiramente diferente de outra.

46 A.1.7

APNDICE A

Opacidade

Opacidade a tendncia de um mdulo ser difcil de ser entendido. Cdigos podem ser escritos de maneira clara e expressiva ou de maneira "opaca"e complicada. A tendncia de um cdigo se tornar mais e mais opaco medida que o tempo passa e, para que isso seja evitado, necessrio um esforo constante em manter esse cdigo claro e expressivo. Uma maneira para prevenir isso fazer com que os desenvolvedores se ponham no papel de leitores do cdigo e refatorem esse cdigo de maneira que qualquer outro leitor poderia entender. Alm disso, revises de cdigo feita por outros desenvolvedores tambm uma possvel soluo para manter o cdigo menos opaco.

A.2

Princpios de Projeto de Classes

Todos os problemas citados na seo A.1 podem ser evitados pelo uso puro e simples de orientao a objetos. A mxima da programao orientada a objetos diz que classes devem possuir um baixo acoplamento e uma alta coeso. Alcanando esse objetivo, mudanas no cdigo seriam executadas mais facilmente; alteraes seriam feitas em pontos nicos e a propagao de mudanas seria bem menor. Com as abstraes bem estabelecidas, novas funcionalidades seriam implementadas atravs de novo cdigo, sem a necessidade de alteraes no cdigo j existente. Necessidades de evoluo do projeto de classes seriam feitas com pouco esforo, j que mdulos dependeriam apenas de abstraes. Mas, alcanar tal objetivo no tarefa fcil. Criar classes pouco acopladas e altamente coesas demanda um grande esforo por parte do desenvolvedor e requer grande conhecimento e experincia no paradigma da orientao a objetos. Os princpios comentados nesta seo so muito discutidos por Robert Martin em vrios de seus livros e artigos publicados [Mar02]. Esses princpios so produto de dcadas de experincia em engenharia de software. Segundo ele, esses princpios no so produto de uma nica pessoa, mas sim a integrao de pensamentos e trabalhos de um grande nmero de desenvolvedores de software e pesquisadores, e visam combater todos os sintomas de degradao discutidos na Seo A.1. Conhecidos pelo acrnimo SOLID (slido, em portugus), so eles: Princpio da Responsabilidade nica (Single-Responsibility Principle (SRP) ) Princpio do Aberto-Fechado (Open-Closed Principle (OCP) ) Princpio de Substituio de Liskov (Liskov Substitution Principle (LSP) ) Princpio da Inverso de Dependncia (Dependency Inversion Principle (DIP) ) Princpio da Segregao de Interfaces (Interface Segregation Principle (ISP) ) A.2.1 Princpio da Responsabilidade nica

O termo coeso dene a relao entre os elementos de um mesmo mdulo [DeM79] [PJ88]. Isso signica que os todos elementos de uma classe que tem apenas uma responsabilidade tendem a se relacionar. Diz-se que uma classe como essa uma classe que possui alta coeso (ou que coesa). J em uma classe com muitas responsabilidades diferentes, os elementos tendem a se relacionar apenas em "grupos", ou seja, com os elementos que tratam de uma das responsabilidades da classe. A esse tipo de classe, diz-se que ela possui uma baixa coeso (ou que no coesa). Robert Martin

PRINCPIOS DE PROJETO DE CLASSES

47

altera esse conceito de coeso e a relaciona com as foras que causam um mdulo ou uma classe a mudar. No caso, o Princpio de Responsabilidade nica diz que uma classe deve ter apenas uma nica razo para mudar [Mar02]. Esse princpio importante no momento em que h uma alterao em alguma funcionalidade do software. Quando isso ocorre, o programador precisa procurar pelas classes que possuem a responsabilidade a ser modicada. Supondo uma classe que possua mais de uma razo para mudar, isso signica que ela acessada por duas partes do software que fazem coisas diferentes. Fazer uma alterao em uma das responsabilidades dessa classe pode, de maneira no intencional, quebrar a outra parte de maneira inesperada. Isso torna o projeto de classes frgil, como comentado na sub-seo A.1.2. A.2.2 Princpio do Aberto-Fechado

O Princpio do Aberto-Fechado, cunhado por Bertrand Meyer, diz que as entidades do software (como classes, mdulos, funes, etc) devem ser abertas para extenso, mas fechadas para alterao [Mey97]. Se uma simples alterao resulta em uma cascata de alteraes em mdulos dependentes, isso cheira rigidez, conforme descrito na sub-seo A.1.1. O princpio pede ento para que o programador sempre refatore as classes de modo que mudanas desse tipo no causem mais modicaes. Quando esse princpio aplicado de maneira correta, novas alteraes fazem com que o programador adicione novo cdigo, e no modique o anterior. Isso alcanado atravs da criao de abstraes para o problema. Linguagens orientadas a objetos possuem mecanismos para cri-las (conhecido com interfaces em linguagens como Java ou C#). Atravs dessas abstraes, o programador consegue descrever a maneira em que uma determinada classe deve se portar, mas sem se preocupar em como essa classe faz isso. A.2.3 Princpio de Substituio de Liskov

Esse princpio, que discute sobre tipos e sub-tipos, criado por Barbara Liskov em 1988 [Lis87], importante j que herana uma das maneiras para se suportar abstraes e polimorsmo em linguagens orientadas a objetos e, como visto na seo A.2.2, o Princpio do Aberto-Fechado se baseia fortemente na utilizao desses recursos. O problema que utilizar herana no tarefa fcil, pois o acoplamento criado entre classe lha e classe pai grande. Fazer as classes lhas respeitarem o contrato do pai, e ainda permitir que mudanas na classe pai no inuenciem nas classes lhas requer trabalho. O princpio de Liskov diz que, se um tipo S sub-classe de um tipo T, ento objetos do tipo T podem ser substitudos por objetos do tipo S, sem alterar nenhuma das propriedades desejadas daquele programa. Um clssico exemplo sobre Princpio de Substituio de Liskov o exemplo dos Quadrados e Retngulos. Imagine uma classe Retngulo. Um retngulo possui dois lados de tamanhos diferentes. Imagine agora uma classe Quadrado (gura geomtrica que possui todos os lados com o mesmo tamanho) que herde de Retngulo. A nica alterao fazer com que os dois lados tenham o mesmo tamanho. Apesar de parecer lgico, anal um Quadrado um Retngulo com apenas uma condio diferente, a classe Quadrado quebra o Princpio de Liskov: a pr-condio dela mais forte do que a do quadrado, anal os dois lados devem ter o mesmo tamanho. Quebras do princpio de Liskov geralmente levam o programador a quebrar o princpio do OCP

48

APNDICE A

tambm. Ele percebe que, para determinados sub-tipos, ele precisa fazer um tratamento especial, e acaba escrevendo condies nas classes clientes que fazem uso disso. A.2.4 Princpio da Inverso de Dependncias

Classes de baixo nvel, que fazem uso de infraestrutura ou de outros detalhes de implementao podem facilmente sofrer modicaes. E, se classes de mais alto nvel dependerem dessas classes, essas modicaes podem se propagar, tornando o cdigo frgil. O Princpio de Inverso de Dependncias se baseia em duas armaes: Mdulos de alto nvel no devem depender de mdulos de baixo nvel. Ambos devem depender de abstraes Abstraes no devem depender de detalhes. Detalhes devem depender de abstraes Em resumo, as classes devem, na medida do possvel, acoplar-se sempre com mdulos mais estveis do que ela prpria, j que, como as mudanas em mdulos estveis so menos provveis, raramente essa classe precisar ser alterada por mudanas em suas dependncias [Mar94]. A.2.5 Princpio da Segregao de Interfaces

Acoplar-se com uma interface de baixa granularidade (ou gordas, do termo em ingls fat interfaces ) pode ser perigoso, j que qualquer alterao que um outro cliente forar nessa interface poder ser propagada para essa classe. O princpio da segregao de interfaces diz que classes cliente no devem ser forados a depender de mtodos que eles no usam. Quando uma interface no coesa, ela contm mtodos que so usados por um grupo de clientes, e outros mtodos que so usados por outro grupo de clientes. Apesar de uma classe poder implementar mais de uma interface, o princpio diz que o cliente da classe deve apenas depender de interfaces coesas.

A.3

Concluso

Todos os princpios discutidos na seo A.2 tentam diminuir os possveis problemas de projeto de classes que possam eventualmente aparecer. Discutir o que um bom projeto de classes algo difcil; mas possvel enumerar algumas das caractersticas desejveis: isolar elementos reusveis de elementos no reusveis, diminuir a propagao de alteraes em caso de uma nova funcionalidade. Esses sero os princpios de projeto de classes levados em conta no momento da anlise dos dados colhidos.

Apndice B

Protocolo do estudo
B.1 Execuo

Nesta seo, apresentamos o protocolo utilizado na execuo do estudo. Como este estudo no precisa ser executado em grupo, entende-se que este roteiro deve ser feito de maneira sequncial para cada um dos participantes do estudo. Convite para possvel participante do estudo; Envio do questionrio inicial para levantamento do perl do participante (encontra-se no Apndice C); Entrega do caderno de exerccios (encontrados no Apndice D) j devidamente randomizado e nicio da resoluo dos problemas por parte do participante; Envio do questionrio nal (que se encontra no Apndice E), que deve ser respondido imediamente aps a nalizao da implementao; Colheta do cdigo-fonte gerado pelo participante; Anlise do cdigo-fonte e dos dados em ambos os questionrios preenchidos para possvel seleo para entrevista; Caso o participante tenha sido selecionado, executar entrevista, detalhada no Apndice F.

B.2

Anlise

Aqui apresentamos o processo de anlise utilizado ao longo do estudo. Clculo das mtricas de cdigo para uso na anlise quantitativa; Execuo do teste estatstico sobre os valores encontrados; Transcrio dos roteiros de entrevista; Reviso dos roteiros de entrevista; Processo de codicao da entrevista; Anlise dos dados encontrados pelo teste estatstico e pelas entrevistas, e redao dos resultados encontrados.

49

Apndice C

Questionrio inicial
1. Seu e-mail? 2. Empresa em que atua? 3. Seu nome? 4. Experincia em desenvolvimento de software (0, Entre 0 e 1 anos, Entre 1 e 2 anos, Entre 2 e 3 anos, Entre 3 e 4 anos, Entre 4 e 5 anos, Entre 5 e 6 anos, Entre 6 e 7 anos, Entre 7 e 8 anos, Entre 8 e 9 anos, Entre 9 e 10 anos, Mais que 10 anos) 5. Experincia com TDD (0, Entre 0 e 1 anos, Entre 1 e 2 anos, Entre 2 e 3 anos, Entre 3 e 4 anos, Entre 4 e 5 anos, Entre 5 e 6 anos, Entre 6 e 7 anos, Entre 7 e 8 anos, Entre 8 e 9 anos, Entre 9 e 10 anos, Mais que 10 anos) 6. Java sua principal linguagem de programao? (Sim, No) 7. Como voc avalia seus conhecimentos em Java? Fale um pouco sobre ele. 8. Voc conhece JUnit? (Sim, No) 9. Conhece o conceito de Mock Objects? (Sim e utilizo no meu dia a dia, Sim s na teoria, No) 10. Como voc avalia seus conhecimentos em TDD? Fale um pouco sobre ele. 11. Como voc avalia seus conhecimentos em orientao a objetos e em projeto de sistemas OO? Fale um pouco sobre ele. 12. Como voc avalia sua experincia no processo de desenvolvimento de software em geral? Fale um pouco sobre ele.

50

Apndice D

Exerccios
Os exerccios so os mesmos para todos os grupos. O participante, em caso de dvidas, poder perguntar ao pesquisador.

D.1

Lembrete ao participante

Caro participante, Lembre-se que os problemas aqui propostos simulam complicaes do mundo real. Ao resolvlos, tenha em mente que esses cdigos sero futuramente mantidos por voc ou at por uma equipe maior. Tente criar o projeto de classes mais elegante possvel em todas as solues. Por serem problemas recorrentes, imagine que amanh esse mesmo problema se repetir. Escreva um cdigo exvel o suciente para que novas mudanas sejam fceis de serem implementadas. Voc tem 50 minutos por exerccio. Mas lembre-se de focar na qualidade. Um exerccio de qualidade pela metade mais importante do que um exerccio completo, sem qualidade. Lembre-se: d o melhor de si em ambos os exerccios!

D.2

Exerccio 1 - Calculadora de Salrio

O participante deve implementar uma calculadora de salrio de funcionrios. Um funcionrio contm nome, e-mail, salrio-base e cargo. De acordo com seu cargo, a regra para clculo do salrio lquido diferente: 1. Caso o cargo seja DESENVOLVEDOR, o funcionrio ter desconto de 20% caso o salrio seja maior ou igual que 3.000,00, ou apenas 10% caso o salrio seja menor que isso. 2. Caso o cargo seja DBA, o funcionrio ter desconto de 25% caso o salrio seja maior ou igual que 2.000,00, ou apenas 15% caso o salrio seja menor que isso. 3. Caso o cargo seja TESTADOR, o funcionrio ter desconto de 25% caso o salrio seja maior ou igual que 2.000,00, ou apenas 15% caso o salrio seja menor que isso. 4. Caso o cargo seja GERENTE, o funcionrio ter desconto de 30% caso o salrio seja maior ou igual que 5.000,00, ou apenas 20% caso o salrio seja menor que isso. Exemplos de clculo do salrio: DESENVOLVEDOR com salrio-base 5,000.00. Salrio nal = 4.000,00 GERENTE com salrio-base de 2.500,00. Salrio nal: 2.000,00 51

52

APNDICE D

TESTADOR com salrio de 550.00. Salrio nal: 467,50 O participante deve criar todo o cdigo responsvel para esse clculo. Uma classe com o mtodo "main()"dever ser entregue ao nal, com exemplo de uso das classes criadas.

D.3

Exerccio 2 - Gerador de Nota Fiscal

O participante deve implementar um sistema de gerao de nota scal a partir de uma fatura. Uma fatura contm o nome e endereo do cliente, tipo do servio e valor da fatura. O gerador de nota scal dever gerar uma nota scal que contm nome do cliente, valor da nota e valor do imposto a ser pago. O valor da nota o mesmo do valor da fatura. J o clculo do imposto a ser pago deve seguir as seguintes regras: 1. Caso o servio seja do tipo "CONSULTORIA", o valor do imposto de 25 2. Caso o servio seja do tipo "TREINAMENTO", o valor do imposto 15 3. Qualquer outro, o valor do imposto 6 Ao nal da gerao da nota scal, o sistema ainda deve enviar essa nota por e-mail, para o SAP, e persistir na base de dados. Por simplicidade, o desenvolvedor pode usar os cdigos abaixo, que simulam o comportamento do SMTP, SAP e banco de dados:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 c l a s s NotaFiscalDao { public void s a l v a ( N o t a F i s c a l n f ) { System . out . p r i n t l n ( " s a l v a n d o no banco " ) ; } } c l a s s SAP { public void e n v i a ( N o t a F i s c a l n f ) { System . out . p r i n t l n ( " e n v i an d o pro sap " ) ; } } c l a s s Smtp { public void e n v i a ( N o t a F i s c a l n f ) { System . out . p r i n t l n ( " e n v i an d o por e m a i l " ) ; } }

O participante livre para alterar os mtodos, parmetros recebidos ou qualquer outra coisa das classes acima. Ao nal, o participante deve entregar todo o cdigo responsvel por gerao e encaminhamento da nota scal para os processos acima citados. Uma classe com o mtodo "main()"dever ser entregue ao nal, com exemplo de uso das classes criadas.

D.4

Exerccio 3 - Processador de Boletos

Nesse exerccio, o participante dever implementar um processador de boletos. O objetivo desse processador vericar todos os boletos e, caso o valor da soma de todos os boletos seja maior que o valor da fatura, ento essa fatura dever ser considerada como paga.

EXERCCIO 4 - FILTRO DE FATURAS

53

Uma fatura contm data, valor total e nome do cliente. Um boleto cntem cdigo do boleto, data, e valor pago. O processador de boletos, ao receber uma lista de boletos, deve ento, para cada boleto, criar um "pagamento"associado a essa fatura. Esse pagamento contm o valor pago, a data, e o tipo do pagamento efetuado (que nesse caso "BOLETO"). Como dito anteriormente, caso a soma de todos os boletos ultrapasse o valor da fatura, a mesma deve ser marcada como "PAGA". O participante deve criar todo o cdigo responsvel pelo processador de boletos. Uma classe com o mtodo "main()"dever ser entregue ao nal, com exemplo de uso das classes criadas. Exemplos de processamento: Fatura de 1.500,00 com 3 boletos no valor de 500,00, 400,00 e 600,00: fatura marcada como PAGA, e trs pagamentos do tipo BOLETO criados Fatura de 1.500,00 com 3 boletos no valor de 1000,00, 500,00 e 250,00: fatura marcada como PAGA, e trs pagamento do tipo BOLETO criados Fatura de 2.000,00 com 2 boletos no valor de 500,00 e 400,00: fatura no marcada como PAGA, e dois pagamentos do tipo BOLETO criados

D.5

Exerccio 4 - Filtro de Faturas

O participante dever implementar um ltro de faturas. Uma fatura contm um cdigo, um valor, uma data, e pertence a um cliente. Um cliente tem um nome, data de incluso e um estado. O ltro dever ento, dado uma lista de faturas, remover as que se encaixam em algum dos critrios abaixo: Se o valor da fatura for menor que 2000; Se o valor da fatura estiver entre 2000 e 2500 e a data for menor ou igual a de um ms atrs; Se o valor da fatura estiver entre 2500 e 3000 e a data de incluso do cliente for menor ou igual a 2 meses atrs; Se o valor da fatura for maior que 4000 e pertencer a algum estado da regio Sul do Brasil. O participante deve criar todo o cdigo responsvel pelo ltro de faturas. Uma classe com o mtodo "main()"dever ser entregue ao nal, com exemplo de uso das classes criadas.

Apndice E

Questionrio ps-experimento
E.1 O Estudo

1. Como voc avalia a clareza do primeiro exerccio que voc resolveu? 2. Como voc avalia a clareza do segundo exerccio que voc resolveu? 3. Como voc avalia o tempo que teve para resolver cada um dos exerccios? 4. Voc sentiu diculdades para escrever cdigo de testes para algum dos exerccios? 5. Em sua opinio, os problemas de projeto de classes enfrentados nos exerccios se parecem com os do mundo real?

E.2

Cdigo gerado

1. Qual sua opinio em relao a qualidade do cdigo que voc gerou? 2. Em relao ao projeto das classes que voc criou, como eles surgiram? 3. O que voc fez para avaliar a qualidade do seu projeto de classes?

E.3

Prtica de TDD
praticou?

1. Durante os exerccios nos quais deveria-se utilizar TDD, como voc avalia a maneira com que

2. Em sua opinio, a prtica de TDD fez alguma diferena no projeto de classes gerado? 3. Voc resolveu exerccios com e sem a prtica de TDD. Voc percebeu alguma diferena em relao ao processo de criao do projeto de classes? 4. Voc percebeu alguma diferena entre a qualidade do projeto de classes dos exerccios que voc resolveu sem TDD e dos exerccios que voc resolveu com TDD? 5. Ao pensar em projeto de classes, ser que TDD realmente necessrio ou basta apenas o desenvolvedor usar a sua experincia? 6. Em sua opinio, para que serve TDD? 7. Gostaria de fazer algum comentrio nal sobre TDD ou o cdigo que voc escreveu?

54

Apndice F

Entrevista
O pesquisador deve primeiramente se apresentar e dizer que ele ser entrevista sobre Test-Driven Development.

F.1

Dados bsicos

1. Nome completo? 2. Qual seu cargo na empresa atual? 3. Em que projetos trabalha atualmente? 4. H quanto tempo est na empresa?

F.2

A Prtica de TDD

1. Voc pratica TDD h quanto tempo? 2. Em sua opinio, o que TDD? 3. Quais as suas referncias em TDD (livros, blogs, etc.)? Leu os livros do Kent Beck, Dave Astels ou Freeman sobre TDD? 4. Voc cr em tudo que eles falam? 5. Voc j leu o meu blog? Sabe citar algum post? 6. Por que voc pratica TDD? 7. O que voc tem achado de praticar TDD?

F.3

Relao entre TDD e projeto de classes

1. No exerccio X, como voc chegou nesse projeto de classes? 2. Voc usou TDD nesse exerccio. Qual o papel que a prtica exerceu na hora de criar esse projeto de classes ? 3. Caso o exerccio tenha sido resolvido com TDD: (a) Em relao a qualidade do cdigo, qual seria a diferena de no usar TDD nesse exerccio? (b) Ao praticar TDD, caso ele tenha dito que o teste fez diferena: i. Como especicamente o teste te ajudou nisso? 55

56

APNDICE F

ii. Como voc sabe que o motivo desse bom projeto de classes o TDD, e no apenas sua experincia com projeto OO? 4. Caso o exerccio no tenha sido resolvido com TDD: (a) Se tivesse resolvido o exerccio utilizando TDD, qual seria a diferena?

F.4

Relao entre TDD e experincia

1. Como voc compararia as primeiras vezes que voc praticou TDD com agora? 2. Voc acha que a sua experincia como desenvolvedor, sua experincia em OO e etc, inuenciam na qualidade do projeto de classes que voc cria? 3. Somente para experientes. Os exerccios que voc resolveu por exemplo, se um desenvolvedor sem muito experincia com desenvolvimento de software ou OO os resolvesse utilizando TDD, qual seria a diferena, pensando no cdigo gerado?

F.5

Resumo dos Pontos Encontrados

segue ver outras maneiras onde o teste inuencia o projeto de classes?

1. Voc comentou sobre <discutir os pontos que o participante levantou at agora>. Voc con-

F.6

Opinies nais
voc acha disso?

1. Alguns autores falam que TDD ajuda o desenvolvedor a pensar no projeto de classes. O que

2. Gostaria de dizer mais algo sobre TDD que no disse nas perguntas anteriores? 3. Como voc compararia a qualidade de cdigos escritos com TDD e sem TDD?

Apndice G

Informaes ao participante
G.1 Convite

Meu nome Mauricio Aniche. Sou aluno de mestrado em Cincia da Computao pelo Instituto de Matemtica e Estatstica da Universidade de So Paulo (USP). Atualmente pesquiso sobre TestDriven Development e sua inuncia no processo de desenvolvimento de software. Para alcanar esse objetivo, estou realizando entrevistas com desenvolvedores de diversas empresas do mercado brasileiro. Este convite permite a voc compartilhar suas experincias e sentimentos em relao prtica e cooperar com as pesquisas na rea. importante reforar que a participao totalmente voluntria e no h nenhum tipo de remunerao associada. Voc pode desistir da sua participao sem nenhum tipo de consequncia.

G.2

Qual o objetivo desta pesquisa?

O objetivo desta pesquisa entender de maneira mais profunda a inuncia de TDD no processo de desenvolvimento de software. Essas informaes sero capturadas baseadas na percepo dos participantes dessa pesquisa.

G.3

Qual meu papel dentro dela?

Como participante dessa pesquisa, voc dever vir ao laboratrio em uma data denida com antecedncia e resolver a 2 exerccios usando Java e TDD. O cdigo-fonte do exerccio, bem como a gravao em vdeo do seu monitor caro com o pesquisador. Aps isso, uma nova data ser marcada para que voc seja entrevistado sobre os exerccios resolvidos.

G.4

Quais so os benefcios?

Alm de cooperar com o avano da pesquisa na rea de engenharia de software, os resultados obtidos por essa pesquisa so compartilhadas com voc, e eu espero que as informaes ali contidas possam ser teis para a evoluo da tcnica.

G.5

Minha privacidade ser garantida?

Sim, todas as informaes gravadas sero mantidas em completo sigilo. Apenas os pesquisadores participantes desse trabalho tero acesso ao mesmo. Alm disso, nenhum nome ser revelado no resultado nal da pesquisa.

G.6

Qual o tempo de participao na pesquisa?

O participante gastar em torno de 2 horas para resolver os exerccios. Alm disso, o pesquisador precisar de 1 hora (em um outro dia) para a realizao da entrevista. Caso uma nova entrevista seja necessria, ele marcar a mesma com antecedncia. 57

58

APNDICE G

G.7

Em caso de dvidas, o que devo fazer?

Em caso de dvida, favor contatar o pesquisador ou o orientador dessa pesquisa. Mauricio Finavaro Aniche (aniche@ime.usp.br) Marco Aurlio Gerosa (gerosa@ime.usp.br) Departamento de Cincia da Computao - Instituto de Matemtica e Estatstica - Universidade de So Paulo (USP) - Caixa Postal 66.281 - 05.508-090 - So Paulo - SP - Brasil

Apndice H

Autorizao
H.1 Consentimento de Participao na Pesquisa

Caro participante, por favor preencha atentamente as instrues abaixo: Eu recebi, li e entendi as informaes sobre essa pesquisa; Eu tive a oportunidade de tirar dvidas sobre a pesquisa; Eu entendo que meu monitor ser gravado durante a implementao dos exerccios; Eu entendo que eu posso desistir da minha participao ou de qualquer informao que eu provi a qualquer momento antes da nalizao do processo de coleta de dados, sem qualquer tipo de dano ou perda; Eu entendo que, em caso de desistncia, a gravao, transcrio ou qualquer outra informao persistida ser destruda; Eu entendo que o plugin Sessions (que particular, e foi cedido apenas para o uso dentro desta pesquisa) dever ser desinstalado aps a aplicao do estudo; Eu aceito fazer parte desta pesquisa; Eu gostaria de receber uma cpia do resultado nal da pesquisa; Assine este documento, informando seu nome e data corrente.

59

Referncias Bibliogrcas
[AFG11] M.F. Aniche, T.M. Ferreira, e M.A. Gerosa. What concerns beginner test-driven development practitioners: A qualitative analysis of opinions in an agile conference. 2o Workshop Brasileiro de Mtodos geis (WBMA), 2011. 1 [All05] Agile Alliance. Test-driven development. http://www.agilealliance.org/programs/ roadmaps/Roadmap/tdd/tdd_index.htm, 2005. 6 [Ast03] D. Astels. Test-Driven Development: A Practical Guide. Prentice Hall, segunda edio, 2003. 1, 5 [BB05] Turner R. Boehm B. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Longman Publishing Co., 2005. 4 [BBvB+ 01] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, e Je Sutherland Dave Thomas. Manifesto for agile software development. http://agilemanifesto.org/, 02 2001. ltimo acesso em 01/10/2010. 4, 11 [Bec01] Kent Beck. Aim, re. IEEE Software, 18:8789, 2001. 5, 30 [Bec02] Kent Beck. Test-Driven Development By Example. Addison-Wesley Professional, 1o edio, 2002. 1, 4, 6, 30 [Bec04] Kent Beck. Extreme Programming Explained. Addison-Wesley Professional, 2o edio, 2004. 1 [BN06] Thirumalesh Bhat e Nachiappan Nagappan. Evaluating the ecacy of test-driven development: industrial case studies. Em Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering, ISESE 06, pginas 356363, New York, NY, USA, 2006. ACM. 7 [CM60] D. P. Crowne e D. Marlowe. A new scale of social desirability independent of psychopathology. Journal of Consulting Psychology, 24:349354, 1960. 39 [Cre08] John W. Creswell. Research design: qualitative, quantitative, and mixed methods approaches. Sage Publications, third edition edio, 2008. 11, 12, 13, 19, 20 [DB11] Tomaz Dogsa e David Batic. The eectiveness of test-driven development: an industrial case study. Software Quality Journal, pginas 119, 2011. 10.1007/s11219-011-9130-2. 7 [DeM79] Tom DeMarco. Structured Analysis and System Specications. Yourdon Press Computing Series, primeira edio, 1979. 46 [DLO05] Lars-Ola Damm, Lars Lundberg, e David Olsson. Introducing test automation and testdriven development: An experience report. Electronic Notes in Theoretical Computer Science, 116:3 15, 2005. Proceedings of the International Workshop on Test and Analysis of Component Based Systems. 6 60

REFERNCIAS BIBLIOGRFICAS

61

[Edw03] S. H. Edwards. Using test-driven development in a classroom: Providing students with automatic, concrete feedback on performance. International Conference on Education and Information Systems: Technologies and Applications, 2003. 8 [EMT05] Hakan Erdogmus, Maurizio Morisio, e Marco Torchiano. On the eectiveness of the testrst approach to programming. IEEE Transactions on Software Engineering, 31:226 237, 2005. 7 [eNP09] Steve Freeman e Nat Pryce. Growing Object-Oriented Software, Guided by Tests. Addison-Wesley Professional, 1o edio, 2009. 1, 35 [Fea07] Michael Feathers. The deep synergy between testability and good design. http:// michaelfeathers.typepad.com/michael_feathers_blog/2007/09/the-deep-synerg.html, 2007. ltimo acesso em 27/10/2010. 6, 34, 41 [Fow04] Martin Fowler. Is design dead? http://martinfowler.com/articles/designDead.html, 2004. ltimo acesso em 28/10/2010. 31 [FRea04] Eric T Freeman, Elisabeth Robson, e et al. Head First Design Patterns. OReilly Media, primeira edio, 2004. 15, 28 [GW03] Boby George e Laurie Williams. An initial investigation of test driven development in industry. Em Proceedings of the 2003 ACM symposium on Applied computing, SAC 03, pginas 11351139, New York, NY, USA, 2003. ACM. 7, 8, 31 [GW04] Boby George e Laurie Williams. A structured experiment of test-driven development. Information and Software Technology, 46(5):337 342, 2004. Special Issue on Software Engineering, Applications, Practices and Tools from the ACM Symposium on Applied Computing 2003. 31 [HS96] B. Henderson-Sellers. Object-oriented metrics: measures of complexity. Prentice-Hall, 1996. 18 [Jan05] David S. Janzen. Software architecture improvement through test-driven development. Em Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, OOPSLA 05, pginas 240241, New York, NY, USA, 2005. ACM. 6, 8, 31 [Jan06] David Janzen. An Empirical Evaluation of the Impact of Test-Driven Development on Software Quality. Tese de Doutorado, University of Kansas, 2006. 9 [Jos04] Marc Josefsson. Making architectural design phase obsolete - tdd as a design method. http://www.soberit.hut./T-76.5650/Spring_2004/Papers/M.Josefsson_ 76650_nal.pdf, 2004. T-76.650 Seminar course on SQA in Agile Software Development Helsinki University of Technology. ltimo acesso em 01/03/2011. 8 [JS05] D. Janzen e H. Saiedian. Test-driven development concepts, taxonomy, and future direction. Computer, 38(9):43 50, sept. 2005. 5, 6 [JS06] David Janzen e Hossein Saiedian. On the inuence of test-driven development on software design. Proceedings of the 19th Conference on Software Engineering Education and Training (CSEET06), pginas 141148, 2006. 7, 8, 32 [JS08] David Janzen e Hossein Saiedian. Does test-driven development really improve software design quality? IEEE Software, 25:7784, 2008. 6 [Ker04] Joshua Kerievsky. Refactoring to Patterns. Addison-Wesley Professional, primeira edio, 2004. 45

62

REFERNCIAS BIBLIOGRFICAS

[Lan01] J. Langr. Evolution of test and code via test-rst design. http://eisc.univalle.edu.co/ materias/TPS/archivos/articulosPruebas/test_rst_design.pdf, 2001. ltimo acesso em 01/03/2011. 7, 8 [LC04] Kim Man Lui e Keith C.C. Chan. Test driven development and software process improvement in China. Em Jutta Eckstein e Hubert Baumeister, editors, Extreme Programming and Agile Processes in Software Engineering, volume 3092 of Lecture Notes in Computer Science, pginas 219222. Springer Berlin / Heidelberg, 2004. 6 [Leh96] M. Lehman. Laws of software evolution revisited. Em Carlo Montangero, editor, Software Process Technology, volume 1149 of Lecture Notes in Computer Science, pginas 108124. Springer Berlin / Heidelberg, 1996. 10.1007/BFb0017737. 2 [Li09] Angela Ling Li. Understanding the ecacy of test driven development. Dissertao de Mestrado, Auckland University of Technology, 2009. 7, 8, 9 [Lis87] Barbara Liskov. Keynote address - data abstraction and hierarchy. Em OOPSLA 87: Addendum to the proceedings on Object-oriented programming systems, languages and applications (Addendum), pginas 1734, New York, NY, USA, 1987. ACM. 47 [LL07] Stephen J. Silverman Lawrence Locke, Waneen Wyrick Spirduso. Proposals that work: A guide for planning dissertations and grant proposals. Sage Publications, 2007. 20 [Lor94] J. Lorenz, M.; Kidd. Object-Oriented Software Metrics: A Practical Guide. PrenticeHall, 1994. 18 [Mad06] Lech Madeyski. The impact of pair programming and test-driven development on package dependencies in object-oriented design - an experiment. Em Jurgen Munch e Matias Vierimaa, editors, Product-Focused Software Process Improvement, volume 4034 of Lecture Notes in Computer Science, pginas 278289. Springer Berlin / Heidelberg, 2006. 8 [Mad09] Lech Madeyski. Test-Driven Development: An Empirical Evaluation of Agile Practice. Springer, primeira edio, 2009. 8 [Mar94] Robert C. Martin. Oo design quality metrics, 1994. 48 [Mar02] Robert C. Martin. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall, primeira edio, 2002. 5, 6, 15, 44, 46, 47 [Mar06] Robert Martin. Agile Principles, Patterns, and Practices in C#. Prentice Hall, primeira edio, 2006. 1 [McC76] T. McCabe. A complexity measure. IEEE TSE, 4:308320, 1976. 18 [Mer98] Sharan B. Merriam. Qualitative Research and Case Study Applications in Education. Jossey-Bass, 1998. 20 [Mey97] Bertrand Meyer. Object Oriented Software Construction. Prentice Hall, segunda edio, 1997. 47 [MH02] M.M. Muller e O. Hagner. Experiment about test-rst programming. Software, IEE Proceedings -, 149(5):131 136, oct 2002. 8 [MH03] Vicent Massol e Ted Husted. JUnit in Action. Manning Publications, segunda edio, 2003. 5

REFERNCIAS BIBLIOGRFICAS

63

[MT01] Craig P. Mackinnon T., Freeman S. Endotesting: unit testing with mock objects. Em G. Succi e M. Marchesi, editors, Extreme Programming Examined, pginas 287301. Addison-Wesley Longman Publishing Co., 2001. 23 [Mug03] Rick Mugridge. Challenges in teaching test driven development. Em Michele Marchesi e Giancarlo Succi, editors, Extreme Programming and Agile Processes in Software Engineering, volume 2675 of Lecture Notes in Computer Science, pginas 10151015. Springer Berlin - Heidelberg, 2003. 8 [MW03] E. Michael Maximilien e Laurie Williams. Assessing test-driven development at IBM. Em Proceedings of the 25th International Conference on Software Engineering, ICSE 03, pginas 564569, Washington, DC, USA, 2003. IEEE Computer Society. 6 [PJ88] Meilir Page-Jones. The Practical Guide to Structured Systems Design. Yourdon Press Computing Series, segunda edio, 1988. 46 [Pro09] Viera K. Proulx. Test-driven design for introductory oo programming. Em Proceedings of the 40th ACM technical symposium on Computer science education, SIGCSE 09, pginas 138 142, New York, NY, USA, 2009. ACM. 8 [RGV04] V. Ramesh, Robert L. Glass, e Iris Vessey. Research in computer science: an empirical study. Journal of Systems and Software, 70(1-2):165 176, 2004. 11 [RH09] Per Runeson e Martin Host. Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14(2):131164, 2009. 1, 11 [SA08] Maria Siniaalto e Pekka Abrahamsson. Does test-driven development improve the program code? Alarming results from a comparative case study. Balancing Agility and Formalism in Software Engineering, 5082:143156, 2008. 1 [Sea99] Carolyn B. Seaman. Qualitative methods in empirical studies of software engineering. IEEE Transactions Software Engineering, 25(4):557572, 1999. 11 [SHea05] D.I.K. Sjoeberg, J.E. Hannay, e et al. A survey of controlled experiments in software engineering. Software Engineering, IEEE Transactions, 31(9):733753, 2005. 11 [Sin06] Maria Siniaalto. Test-driven development: empirical body of evidence. D.2.7:15, 2006. 8 [Ste01] D. H. Steinberg. The eect of unit tests on entry points, coupling and cohesion in an introductory java programming course. XP Universe, 2001. 8 [TDM10] Tore Dyb Torgeir Dingsyr e Nils Brede Moe. Agile Software Development: Current Research and Future Directions. Springer Publishing Company, Incorporated, primeira edio, 2010. 4 [Tea04] Ivana Turnu e Marco Melis et al. Introducing tdd on a free libre open source software project: a simulation experiment. Em Proceedings of the 2004 workshop on Quantitative techniques for software agile process, QUTE-SWAP 04, pginas 5965, New York, NY, USA, 2004. ACM. 7 [Van05] Glenn Vanderburg. A simple model of agile software processes or extreme programming annealed. Em OOPSLA 05: Proceedings of the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pginas 539545, New York, NY, USA, 2005. ACM. ix, 33, 34