Disser Ta Cao

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 emo-
cional 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 Web-
Goal (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!
i
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 Ex-
trema. 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 Qua-
lity.
iii
Sumrio
Lista de Abreviaturas viii
Lista de Figuras ix
Lista de Tabelas ix
1 Introduo 1
1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Caracterizao da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organizao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Desenvolvimento Guiado por Testes 4
2.1 Mtodos geis de Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . . . 4
2.2 Desenvolvimento Guiado por Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Benefcios de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Possveis Efeitos no Projeto de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.1 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.2 Posio desta pesquisa na literatura atual . . . . . . . . . . . . . . . . . . . . 9
3 Planejamento e Execuo do Estudo 11
3.1 Caractersticas de pesquisas qualitativas . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Estudos mistos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Questes de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Projeto da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 Participantes da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Resoluo dos problemas propostos . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 Problemas Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Questionrio ps-experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.5 Escolha de candidatos para a entrevista . . . . . . . . . . . . . . . . . . . . . 16
3.3.6 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.7 Mtricas de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.8 Avaliao do Especialista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Anlise dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Validade e Conabilidade do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6 Papel do Pesquisador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iv
SUMRIO v
3.7 Questes ticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.8 Estudo piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.9 Execuo do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.10 Descrio dos participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Relao entre TDD e Projeto de Classes: Anlise Quantitativa 25
4.1 Mtricas de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Inspeo do Cdigo-Fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Relao entre TDD e Projeto de Classes: Anlise Qualitativa 28
5.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Anlise das Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1 Segurana na refatorao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.2 Passos menores e simplicidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.3 Espao para se pensar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.4 Feedback mais rpido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.5 Busca pela testabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Padres de Feedback de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.1 Padres Ligados Coeso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.2 Padres Ligados ao Acoplamento . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.3 Padres Ligados Falta de Abstrao . . . . . . . . . . . . . . . . . . . . . . 36
5.3.4 Relao dos padres com os princpios de projeto de classes . . . . . . . . . . 36
6 Ameaas Validade 37
6.1 Validade de Construo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.1 Exerccios de pequeno porte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.2 Criao dos exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.3 Mtricas selecionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.4 Estudos piloto no foram at o m . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.5 Falta de medio sobre a utilizao da prtica de TDD . . . . . . . . . . . . . 37
6.1.6 Seleo dos candidatos para entrevista . . . . . . . . . . . . . . . . . . . . . . 38
6.2 Validade interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.1 Efeitos recentes de TDD na memria . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.2 Exerccios inacabados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.3 Inuncia do pesquisador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3 Validade externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1 Desejabilidade social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.2 Quantidade de participantes insuciente . . . . . . . . . . . . . . . . . . . . . 39
6.4 Validade de Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4.1 Padres encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
vi SUMRIO
7 Concluses e Trabalhos Futuros 40
7.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2 Qual a inuncia de TDD no projeto de classes? . . . . . . . . . . . . . . . . . . . . 40
7.3 Qual a relao entre TDD e as tomadas de decises de projeto feitas por um desen-
volvedor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
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? . . . . . . . . . . . . . . . 41
7.5 Lies Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.6 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.7 Produes ao Longo do Mestrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.8 Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A Projeto de Classes em Sistemas Orientados a Objetos 44
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 50
D Exerccios 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 Desenvolvimento Guiado por Testes (do ingls, Test-Driven Development)
XP Programao Extrema (do ingls, Extreme Programming)
BDUF Projeto de Classe Criado de Uma S Vez (Big Design Up-Front)
PRU Princpio da Responsabilidade nica (Single Responsibility Principle)
PID Princpio da Inverso de Dependncias (Single Responsibility Principle)
PAF Princpio do Aberto-Fechado (Open-Closed Principle)
PSL Princpio da Substituio de Liskov (Liskov Substitution Principle)
PSI Princpio da Segregao de Interfaces (Interface Segregation Principle)
OO Orientao a Objetos
WBMA Workshop Brasileiro de Mtodos geis
viii
Lista de Figuras
2.1 Posio desta pesquisa na literatura atual . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Processo de anlise dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Experincia dos participantes da indstria com TDD . . . . . . . . . . . . . . . . . . 23
3.3 Experincia dos participantes da indstria com desenvolvimento de software em geral 23
5.1 Feedback provido pela prtica de TDD . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Prticas de XP e Tempo de Feedback (baseado em [Van05]) . . . . . . . . . . . . . . 34
Lista de Tabelas
2.1 Relao entre efeitos de TDD e estudos na literatura . . . . . . . . . . . . . . . . . . 8
3.1 Exerccios propostos e mau cheiros de projeto de classes . . . . . . . . . . . . . . . . 15
3.2 Informaes que so extradas do questionrio ps-experimento. . . . . . . . . . . . . 16
3.3 Experincia em Java, JUnit, e Objetos Dubl dos participantes da indstria . . . . . 24
4.1 P-values encontrados para a diferena entre cdigos com e sem TDD na indstria . . 25
4.2 P-values encontrados para a diferena na Complexidade Ciclomtica entre experien-
tes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 P-values encontrados para a diferena no Fan-Out entre experientes e no experientes
na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 P-values encontrados para a diferena na falta de coeso nos mtodos entre experi-
entes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 P-values encontrados para a diferena na quantidade de mtodos por classe entre
experientes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 P-values encontrados para a diferena no nmero de linhas por mtodo entre expe-
rientes e no experientes na indstria . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7 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
x 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 ba-
seada 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
1
2 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 inds-
tria. 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 desenvolvi-
mento. 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 progra-
madores 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 3
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 qua-
lidade 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), pr-
tica 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.
4
2.3 BENEFCIOS DE TDD 5
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. Algu-
mas delas consideram apenas a ideia da inverso da ordem de desenvolvimento, na qual o progra-
mador 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]: "Test-
Driven 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".
6 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 7
O estudo feito por George e Williams [GW03] mostrou que, apesar de TDD poder reduzir inici-
almente 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 qua-
litativa 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 acre-
ditam 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 simi-
lares 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,
Possvel Efeito Tipo de Estudo Trabalho
Simplicidade
Quantitativo [Jan05], [JS06]
Qualitativo [Li09], [GW03]
Facilidade de manuteno Quantitativo [Lan01]
Melhor utilizao de conceitos de orientao a objetos
Quantitativo [JS06]
Qualitativo [Li09], [Pro09]
Separao de responsabilidades Quantitativo [JS06], [Ste01]
Menor acoplamento Quantitativo [JS06], [Ste01]
Maior reso de classes Quantitativo [MH02]
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. Ma-
deyski [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 en-
tre 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 pro-
duzidos 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 tra-
balho 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 arquite-
tural e os efeitos de TDD nesse quesito, chega mesma concluso. Segundo ele, os estudos sobre
2.5 TRABALHOS RELACIONADOS 9
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 facili-
dade 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.
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 me-
lhor 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 pe-
queno 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 fundamen-
tal 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 ml-
tiplas 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 enten-
dem. 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 m-
todo 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 parti-
cipantes 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 participa-
rem 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).
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 par-
ticipantes 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 parti-
cipantes 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 PROJETO DA PESQUISA 15
Exerccio Mau Cheiro Princpios A Serem Seguidos
Exerccio 1 Rigidez, Complexidade Desnecessria PRU, PAF
Exerccio 2 Fragilidade, Viscosidade, Imobilidade PRU, PID, PAF
Exerccio 3 Rigidez, Fragilidade PRU
Exerccio 4 Fragilidade, Viscosidade, Imobilidade 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
Bloco Objetivo
O estudo Este bloco objetiva obter a
opinio dos participantes so-
bre o estudo, como clareza dos
exerccios. O objetivo au-
mentar a validade do estudo.
Alm disso, entender se os
exerccios propostos so pare-
cidos com os problemas encon-
trados no mundo real ajudam
a aumentar a possibilidade de
generalizao do estudo.
Cdigo gerado 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 es-
creve.
Prtica de TDD O objetivo deste bloco en-
tender como a prtica pode ter
inuenciado nas decises de
projeto de classes feitas pelo
programador durante o exer-
ccio.
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 cdigo-
fonte 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 ques-
tionrio. 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 PROJETO DA PESQUISA 17
postas no questionrio inuenciaram na escolha.
O procedimento adotado para escolha dos candidatos foi:
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 resol-
vido 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.
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 ques-
tes 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 Henderson-
Sellers [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 implemen-
tao. 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 trans-
critas, 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 estatistica-
mente 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 ob-
tidos 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.
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 eletr-
nica.
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, pres-
suposies 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 acaba-
mos 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
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 (cdigo-
fonte 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 interes-
sante, 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 bra-
sileiro
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 ex-
perincia 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. En-
tretanto, 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 dubls
4
. De fato, 64% deles
aplicam objetos dubls durante suas atividades de desenvolvimento. Com relao a conhecimentos
3
Consideramos empresas de pequeno porte aquelas que tem menos de 50 funcionrios.
4
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].
Ferramenta Participantes que conhe-
cem
Participantes que no co-
nhecem
Java 16 9
JUnit 25 0
Objetos Dubl 16 (utilizam no dia a dia), 6
(na teoria)
3
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 pos-
suem 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 Quanti-
tativa
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 Complexi-
dade ci-
clomtica
Acoplamento
eferente
Falta de
coeso dos
mtodos
Nmero
de li-
nhas por
mtodo
Quantidade
de mto-
dos por
classe
Exerccio 1 0.8967 0.6741 2.04E-07* 0.4962 2.99E-06*
Exerccio 2 0.7868 0.7640 0.06132 0.9925 0.7501
Exerccio 3 0.5463 0.9872 0.5471 0.7216 0.3972
Exerccio 4 0.2198 0.1361 0.04891* 0.0032* 0.9358
Todos 0.8123 0.5604 0.3278 0.06814 0.5849
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 soft-
ware.
25
26 RELAO ENTRE TDD E PROJETO DE CLASSES: ANLISE QUANTITATIVA 4.2
Complexidade Ciclom-
tica
Experiente em TDD No experiente em TDD
Experiente em Desenvolvi-
mento de Software
0.09933 0.8976
No Experiente em Desenvol-
vimento de Software
NA 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 TDD No experiente em TDD
mento de Software
0.1401 0.6304
vimento de Software
NA 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 Mto-
dos
mento de Software
0.03061* 0.1284
vimento de Software
NA 0.0888
Tabela 4.4: P-values encontrados para a diferena na falta de coeso nos mtodos entre experientes e no
Quantidade de Mtodos
por Classe
mento de Software
0.09933 0.8976
vimento de Software
NA 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 TDD No experiente em TDD
mento de Software
0.0513 0.4319
vimento de Software
NA 0.5776
Tabela 4.6: P-values encontrados para a diferena no nmero de linhas por mtodo entre experientes e no
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 DISCUSSO 27
Especialista Projeto de classes Testabilidade Simplicidade
Especialista 1 0.4263 0.5235 0.3320
Especialista 2 0.7447 0.4591 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. Apa-
rentemente 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 pro-
cede 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 Quali-
tativa
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 mu-
dana 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 in-
trseca 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 refato-
rao, 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 as-
sunto. 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:
"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."
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 pro-
blemas 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 desen-
volvedor ler o teste, ele entender o que aquela classe faz ou qual sua importncia para o sistema:
"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:
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 facil-
mente 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 fra-
camente 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 responsabi-
lidade 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
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
Possveis
Princpios
Feridos
Muitos Testes Para Um Mtodo Complexidade Desnecessria,
Opacidade
PRU
Muitos Testes Para Uma Classe Complexidade Desnecessria,
Opacidade
PRU
Cenrio Muito Grande Opacidade, Fragilidade PRU
Testes Em Mtodo Que No Pblico Complexidade Desnecessria PRU, PAF
Objetos Dubl em Excesso Fragilidade PID, PAF
Objetos Dubls No Utilizados Fragilidade PID, PAF
Mesma Alterao Em Diferentes Testes Fragilidade, Rigidez PRU
Testes Idnticos Para Entidades Diferentes Repetio Desnecessria, Ri-
gidez
PRU
Interface No Amigvel Opacidade ISP
Condicional No Nome Do Teste Rigidez, Fragilidade PRU, PAF
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 pesquisa-
dores 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 seleci-
onadas 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 traba-
lho. 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 quali-
tativas. 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 inun-
cia 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 re-
sultados 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 soft-
ware, 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 de-
senvolvimento 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
7.5
COMO A PRTICA DE TDD INFLUENCIA O PROGRAMADOR NO PROCESSO DE PROJETO DE
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 con-
gurado, 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 participan-
tes 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, exe-
cutaram 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 es-
pecialistas 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 Qua-
litative Analysis of Opinions in an Agile Conference, aceito no WBMA em 2011;
5. Relato de experincia entitulado Increasing Learning in an Agile Environment: Lessons Lear-
ned in an Agile Team, aceito no Agile de 2011;
6. Artigo entitulado Como a Prtica de TDD Inuencia o Projeto de Classes em Sistemas Ori-
entados 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 utili-
zados nesta pesquisa;
8. Escrita da ferramenta de minerao de repositrio de cdigos rEvolution, utilizado para calcu-
lar as mtricas em cima do cdigo produzido pelos participantes. Software esse que deu origem
ao MetricMiner, ferramenta de minerao de repositrios web desenvolvida pelo LAPESSC
1
.
7.8 Resultados Esperados
Ns esperamos que o resultado deste estudo ajude desenvolvedores de software a antecipar pro-
blemas 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.
1
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, chama-
dos 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. Ge-
ralmente, 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 mu-
dana 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 APNDICE A
A.1.7 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 orien-
tao 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 soft-
ware (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 pro-
gramador 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 progra-
mador 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 in-
terfaces) 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 imedi-
amente 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 resul-
tados 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 resolv-
los, 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 cl ass NotaFi scal Dao {
2 public void s al va ( Not aFi s cal nf ) {
3 System . out . pr i nt l n ( " sal vando no banco" ) ;
4 }
5 }
6
7 cl ass SAP {
8 public void envi a ( Not aFi s cal nf ) {
9 System . out . pr i nt l n ( "envi ando pro sap" ) ;
10 }
11 }
12
13 cl ass Smtp {
14 public void envi a ( Not aFi s cal nf ) {
15 System . out . pr i nt l n ( "envi ando por emai l " ) ;
16 }
17 }
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
1. Durante os exerccios nos quais deveria-se utilizar TDD, como voc avalia a maneira com que
praticou?
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
1. Voc comentou sobre <discutir os pontos que o participante levantou at agora>. Voc con-
segue ver outras maneiras onde o teste inuencia o projeto de classes?
F.6 Opinies nais
1. Alguns autores falam que TDD ajuda o desenvolvedor a pensar no projeto de classes. O que
voc acha disso?
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 Test-
Driven Development e sua inuncia no processo de desenvolvimento de software.
Para alcanar esse objetivo, estou realizando entrevistas com desenvolvedores de diversas empre-
sas 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 de-
velopment 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, 1
o
edio, 2002. 1, 4, 6, 30
[Bec04] Kent Beck. Extreme Programming Explained. Addison-Wesley Professional, 2
o
edio,
2004. 1
[BN06] Thirumalesh Bhat e Nachiappan Nagappan. Evaluating the ecacy of test-driven deve-
lopment: 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 psycho-
pathology. Journal of Consulting Psychology, 24:349354, 1960. 39
[Cre08] John W. Creswell. Research design: qualitative, quantitative, and mixed methods ap-
proaches. 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 Compu-
ting Series, primeira edio, 1979. 46
[DLO05] Lars-Ola Damm, Lars Lundberg, e David Olsson. Introducing test automation and test-
driven 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 test-
rst 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, 1
o
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 pro-
gramming, 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, Soft-
ware 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. Prentice-
Hall, 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 Mar-
chesi 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 program-
ming annealed. Em OOPSLA 05: Proceedings of the 20th annual ACM SIGPLAN
conference on Object-oriented programming, systems, languages, and applications, p-
ginas 539545, New York, NY, USA, 2005. ACM. ix, 33, 34

Disser Ta Cao

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Disser Ta Cao

Enviado por

Direitos autorais:

Formatos disponíveis

Como a prtica de TDD

inuencia o projeto de classes

Você também pode gostar