• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em projetos OO
 

Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em projetos OO

on

  • 801 views

Defesa da minha dissertação de mestrado entitulada "Como a prática de TDD influencia no projeto de classes em projetos OO"

Defesa da minha dissertação de mestrado entitulada "Como a prática de TDD influencia no projeto de classes em projetos OO"

Statistics

Views

Total Views
801
Views on SlideShare
801
Embed Views
0

Actions

Likes
4
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em projetos OO Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em projetos OO Presentation Transcript

    • Como a prática deTDD influencia noprojeto de classes em sistemasorientados a objetosMauricio FinavaroAnicheOrientador: Prof. Dr. Marco Aurélio Gerosa
    • Agenda DesenvolvimentoGuiado porTestes (TDD) Motivação da Pesquisa Planejamento e Execução do Estudo Trabalhos Relacionados AnáliseQuantitativa AnáliseQualitativa e Padrões de Feedback Ameaças aValidade Conclusões Agradecimentos2
    • TDD Popularizado por Kent Beck [Bec04], a prática sugere aodesenvolvedor que escreva o código de teste antes do códigode produção. Ciclo em 5 etapas: escreva um teste que falha, veja-ofalhar, faça o teste passar da maneira mais simplespossível, veja-o passar, refatora para remover duplicação dedados e código.3
    • Efeitos da prática É comum relacionar a prática deTDD com efeitos positivosna qualidade externa do software. Muitos trabalhos nem mencionam possíveis efeitos da práticano projeto de classes. Mas muitos autores também afirmam que a prática podeinfluenciar positivamente no projeto de classes[Bec02], [Mar6], [eNP09], [Ast03]. Grande parte delas se baseia na ideia de que uma classe difícilde ser testada, é uma classe que possivelmente apresentaproblemas de projeto.4
    • Popularidade da prática Questionários feitos porWambler [Wam10] mostram ocrescimento na adoção da prática por parte da indústria. Empiricamente, notamos também o crescimento pela buscasobre o assunto em eventos ágeis.5
    • Motivação Apesar dos ditos efeitos da prática sobre o projeto de classes,na verdade pouco se sabe sobre eles. Fizemos um estudo qualitativo dentro de um evento ágil, epercebemos que os desenvolvedores não souberam afirmarcom segurança como a prática deTDD influenciava nos projetosde classe. Dado a crescente adoção da prática, é importante entendernão só se a prática influencia, mas também como se dá essainfluência.6
    • Caracterização da Pesquisa Este trabalho visa entender a influência da prática deTDD noprojeto de classes. A análise se baseou na percepção de programadores atuantesna indústria brasileira de desenvolvimento de software. Todos eles resolveram um conjunto de problemas em Java,utilizando ou nãoTDD. Em seguida, análises quantitativa e qualitativa ajudaram aentender os efeitos da prática.7
    • Objetivo da Pesquisa O objetivo principal: entender a relação da prática deTDD eas decisões de projeto de classes tomados pelodesenvolvedor. Qual a influência da prática deTDD no projeto de classes? Qual a relação entreTDD e as decisões de projeto feitas por umdesenvolvedor? Como a prática deTDD influencia o programador no projeto declasses, do ponto de vista do acoplamento, coesão ecomplexidade?8
    • Contribuições da Pesquisa Padrões de feedback da prática deTDD que guiam osdesenvolvedores ao longo do projeto de classes. Protocolo de um estudo qualitativo sobre os efeitos daprática, bem como um conjunto de lições aprendidas.9
    • Trabalhos Relacionados10
    • Discussão Pouco são os trabalhos que avaliam os efeitos da prática noprojeto de classes. E quando o fazem, apenas verificam se “existe algum efeito”. Não discutem exatamente como isso acontece. Também não levam em conta a experiência no desenvolvedor(grande parte dos estudos foram feitos com estudantes). Josefsson [Jos04] comenta que os estudos encontrados naliteratura são muito limitados e pouco generalizáveis.11
    • Posição desta pesquisa na literatura12
    • Planejamento do Estudo Conduzir um estudo experimental em engenharia desoftware sempre foi uma atividade difícil. Hoje tem-se considerado melhor a influência de projetos não-técnicos. Dado a complexidade do problema a ser estudado, optamospor uma pesquisa essencialmente qualitativa.13
    • Estudos qualitativos Pesquisador como instrumento chave da pesquisa. Múltiplas fontes de dados. Análise de dados indutiva. Visão do participante levada em consideração. Interpretativa.14
    • Projeto da pesquisa Participantes foram convidados a resolver problemas emJava, usando ou não a prática deTDD. A partir dos dados colhidos (questionários e métrica decódigo), entrevistamos alguns desses participantes. Com esses dados em mãos, utilizamos técnicas baseadas emGroundedTheory para analisar os dados.15
    • Participantes da Pesquisa Foram avaliados de acordo com os seguintes critérios: Experiência emTDD. Experiência e Desenvolvimento de Software. Conhecimentos em Java. Conhecimentos deTestes de Unidade. Essas informações foram avaliadas a partir de umquestionário, que continha questões abertas e fechadas.16
    • Execução do Estudo Participantes tem 2 horas para resolver 2 problemas. Um deles usandoTDD; outro não. A ordem dos exercícios e da obrigatoriedade do uso da práticaforam randomizados. Ao final do estudo, respondem um questionário sobre suas asimpressões da prática deTDD. Perguntas sobre a qualidade do código produzido e do possívelefeito da prática deTDD sobre o código gerado.17
    • Problemas Propostos Baseados em workshop dado naAgile Brazil e no IME/USP. Ao total, mais de 100 pessoas participaram. No exercício 1, o participante deve implementar uma calculadorade salário, que varia de acordo com o cargo do participante. No exercício 2, o participante deve fazer com que uma nota fiscalgerada seja enviada para diversos sistemas externos. No exercício 3, o participante deve fazer uma modificação em umsistema de pagamento de boletos. No exercício 4, o participante implementa uma sequência de filtrosde faturas.18
    • Escolha de candidatos para entrevista Os dados foram parcialmente analisados. Leitura dos questionários inicial e pós-experimento. Avaliação do código gerado com e sem a prática deTDD(princípios SOLID foram utilizados). Candidatos que apresentaram alguma divergência no queescreveram e no que produziram, foram selecionados. Apesar do processo, a avaliação do código gerado reflete oponto de vista do pesquisador.19
    • Entrevista Entrevista semi-estruturada. O foco era descobrir como a prática deTDD influencia oprogramador no projeto de classes. Sempre que algum ponto era mencionado, eu anotava e depoisretomava o ponto para discuti-lo mais a fundo, isoladamente. Foram gravadas, de maneira a possibilitar que os dadosfossem revistos a qualquer momento.20
    • Métricas de Código Métricas conhecidas pela academia. Complexidade ciclomática Fan-Out Falta de coesão dos métodos (LCOM) Quantidade de linhas por método Quantidade de métodos Ferramenta de cálculo de métrica implementada.21
    • Avaliação do Especialista Especialistas foram convidados a avaliar os código-fontegerados. Avaliaram em diferentes categorias: Simplicidade Testabilidade Qualidade do Projeto de Classes Especialistas não sabiam quais códigos foram escritos com ouso da prática deTDD. Ferramenta escrita para capturar avaliação.22
    • Validade e confiabilidade do estudo Revisão das transcrições. Verificação de pesquisador auxiliar. Rastreabilidade dos dados. Triangulação de diferentes fontes de dados. Esclarecer os possíveis vieses do estudo.23
    • Estudo piloto Três pilotos foram executados. Na primeira execução, descobrimos que 4 exercícios em 2 horasnão era factível. Na segunda execução, o participante teve dificuldades emmontar o ambiente. Um caderno junto com um pacote com áreade trabalho pronta no Eclipse foi criado. No terceiro, melhoramos o roteiro de entrevista, aopercebermos diversas perguntas repetidas.24
    • Execução do Estudo Ao todo, tivemos 25 participantes de 6 diferentes empresas. A grande maioria não era experiente emTDD (40% delesafirmam que começaram usar a prática apenas no último ano, e52% deles entre 1 e 3 anos). 24% desenvolve software entre 4 a 5 anos. 28% deles faz issoentre 6 a 10 anos. 64% utilizam Java no dia a dia, mas todos afirmam conhecerJunit. 64% deles utilizam objetos dublês.25
    • Na academia 21 estudantes do IME/USP. Surpreendentemente, 90% afirmam não conhecer Java. 61% não conheciamTDD e 76% conhecem objetos dublês nateoria. Por causa desses números, nenhum participante da academiafoi selecionado para a entrevista.26
    • Análise Quantitativa O teste estatístico escolhido foiWilcoxon. Classes e métodos separados em 2 grupos: produzidos com esemTDD. Olhamos apenas para o “lado” onde supostamente códigosproduzidos comTDD possuem valores de métricas menores queos códigos produzidos semTDD.27
    • Métricas de código na indústria28
    • Métricas de código na academia29
    • Relação com Experiência Ao separarmos os códigos produzidos de acordo com aexperiência do participante, percemos que ela não fezdiferença na qualidade do código gerado. Com exceção da falta de coesão dos métodos, que apresentoudiferença no grupo que era experiente tanto emdesenvolvimento de software quanto emTDD.30
    • Avaliação dos especialistas na indústria31
    • Avaliação dos especialistas na academia32
    • Discussão Não foram encontradas diferenças entre os códigosproduzidos com e semTDD, do ponto de vista das métricasde código e dos especialistas convidados. Os motivos disso precisam ser entendidos.33
    • Análise Qualitativa Participantes, em sua maioria, afirmaram que a prática deTDD não teria feito qualquer diferença no código gerado. A principal justificativa foi a de que a experiência econhecimento em orientação a objetos os guiaram durante aresolução dos exercícios. Dois exemplos foram dados pelos participantes. Um deles comentou que fez uso de um Padrão de Projeto queaprendera dias antes. Outro comentou que seus estudos sobre os princípios SOLID lheajudaram.34
    • Efeitos na qualidade externa Segundo eles,TDD tem efeitos na qualidade externa dosistema.35
    • Efeitos na qualidade interna Apesar de afirmarem queTDD não faria diferença no código,todos eles afirmaram que enxergam benefícios no projeto declasses quando usamTDD. Segundo eles, o ideal é unir a prática deTDD com a experiência.36
    • Segurança na refatoração 11 participantes afirmaram que os testes gerados durante aprática dão segurança para refatorar código. Um participante inclusive mencionou uma experiência real. Experiência foi novamente mencionada.37
    • Passos menores e simplicidade TDD sugere passos de bebê. Oito participantes afirmaram que tomar passos menores lhesajudam a pensar melhor no projeto de classes. Um deles afirmou que a ideia de ter um objetivo maiscurto, aumenta o foco.38
    • Espaço para pensar Testes são como “folha de rascunho”, onde o desenvolvedorpode pensar melhor sobre o projeto de classes. Segundo eles, quando não fazemTDD, eles estão tão focadosno código que estão escrevendo que acabam por não pensar noprojeto de classes.39
    • Feedback mais rápido Praticantes afirmaram queTDD dá feedback constante aodesenvolvedor.40
    • Busca pela testabilidade Muitos afirmaram que a grande maneira na qual a práticainfluencia no projeto de classes é observando a relação entrecódigo difícil de testar e um projeto de classes comproblemas. Código mais fácil de invocar. Código menos acoplado. Código mais simples.41
    • Padrões de Feedback Levantamos um conjunto de padrões de feedback que aprática deTDD pode dar ao desenvolvedor. Alguns deles vão de encontro ao que outros autores jácomentaram. Esses padrões foram separados em: Padrões de Acoplamento. Padrões de Coesão. Padrões de Falta de Abstração.42
    • Padrões ligados à coesão MuitosTestes para um Método. MuitosTestes para uma Classe. Cenário Muito Grande. Testes Em Método Que Não É Público.43
    • MuitosTestes Para um Método Quando um único método necessita de diversos testes paragarantir seu comportamento, o método em questãoprovavelmente é complexo e/ou possui diversasresponsabilidades. Códigos assim possuem geralmentediversos caminhos diferentes e tendem a alterar muitosatributos internos do objeto, obrigando o desenvolvedor acriar muitos testes, caso queira ter uma alta cobertura detestes. A esse padrão, demos o nome de MuitosTestes ParaUm Método.44
    • MuitosTestes Para Uma Classe O mesmo pode ser entendido quando o desenvolvedorescreve muitos testes para a classe como um todo. Classesque expõem muitos métodos para o mundo de fora tambémtendem a possuir muitas responsabilidades. Chamamos estepadrão de MuitosTestes Para Uma Classe.45
    • Cenário Muito Grande Outro problema de coesão pode ser encontrado quando oprogramador sente a necessidade de escrever cenários deteste muito grandes para uma única classe ou método. Épossível inferir que essa necessidade surge em códigos quelidam com muitos objetos e fazem muita coisa. Nomeamosesse padrão de Cenário Muito Grande.46
    • Testes em Método Que Não É Público Um padrão não explicitamente levantado pelosparticipantes, mas notado por nós, é quando odesenvolvedor sente a necessidade de se testar um métodoque não é público. Métodos privados geralmente servempara transformar o método público em algo mais fácil de ler.Ao desejar testá-lo de maneira isolada, o programador podeestar de frente a um método que possua uma responsabi-lidade suficiente para ser alocada em uma outra classe. Aesse padrão, chamamos deTestes em Método Que Não ÉPúblico.47
    • Padrões Ligados ao Acoplamento Objetos Dublê em Excesso Objetos Dublê não Utilizados48
    • Objetos Dublê em Excesso O uso abusivo de objetos dublês para testar uma única classeindica que a classe sob teste possui problemas deacoplamento. É possível deduzir que uma classe que faz usode muitos objetos dublês depende de muitas classes, eportanto, tende a ser uma classe instável. A esse padrão,demos o nome de Objetos Dublê em Excesso.49
    • Objetos Dublê não Utilizados Outro padrão percebido por nós é a criação de objetos dublêsque não são utilizados em alguns métodos de testes. Issogeralmente acontece quando a classe é altamente acoplada,e o resultado da ação de uma dependência não interfere naoutra.Quando isso acontece, o programador acaba porescrever conjuntos de testes, sendo que, em alguns deleslidam com um sub-conjunto dos objetos dublês, enquantooutros testes lidam com o outro sub-conjunto de objetosdublês. Isso indica um alto acoplamento da classe, queprecisa ser refatorada. A esse padrão demos o nome deObjetos Dublê Não Utilizados.50
    • Padrões Ligados à Falta de Abstração Mesma Alteração em DiferentesTestes. Testes Repetidos para Entidades Diferentes. Interface não Amigável. Condicional no Nome doTeste.51
    • Testes Repetidos A falta de abstração geralmente faz com que uma simplesmudança precise ser feita em diferentes pontos do código.Quando uma mudança acontece e o programador é obrigadoa fazer a mesma alteração em diferentes testes, isso indica afalta de uma abstração correta para evitar a repetiçãodesnecessária de código. A esse padrão damos o nome deMesma Alteração Em Diferentes Testes. Analogamente, oprogramador pode perceber a mesma coisa quando elecomeça a criar testes repetidos para entidades diferentes.Chamamos esse padrão de Testes Repetidos ParaEntidades Diferentes.52
    • Interface não Amigável Quando o desenvolvedor começa o teste e percebe que ainterface pública da classe não está amigável, pode indicarque abstração corrente não é clara o suficiente e poderia sermelhorada. A esse padrão, chamamos de Interface NãoAmigável.53
    • Condicional no Nome doTeste Outro padrão não mencionado explícitamente pelosparticipantes é a existência da palavra "se" no nome do teste.Testes que possuem nomes como esse geralmente indicam aexistência de um "if" na implementação do código deprodução. Essas diversas condições podem, geralmente, serrefatoradas e, por meio do uso de poliformismo, seremeliminadas. A falta de abstração nesse caso é evidenciadapelo padrão Condicional No Nome DoTeste.54
    • Relação dos princípios e SOLID55
    • Ameaças aValidade Alguns pontos podem ameaçar os dados encontrados poresta pesquisa.56
    • Validade de Construção Exercícios de pequeno porte. Eles são pequenos perto do mundo real, mas participantesafirmaram que todos eles contém problemas parecidos com osque enfrentam no dia a dia.57
    • Validade Interna Efeitos recentes deTDD na memória Por serem praticantes deTDD, eles podem ter “esquecido”como é pensar no projeto de classes. Por esse motivo, todosparticipantes resolveram exercícios com e semTDD. Exercícios inacabados Alguns participantes não terminaram a implementação dosexercícios. Isso pode ter afetado a análise das métricas decódigo. Influência do Pesquisador Em uma pesquisa qualitativa, o pesquisador faz a diferença. Poresse motivo, outro pesquisador revisou os resultadosencontrados dessa pesquisa.58
    • Validade Externa Desejabilidade social Enviesamento pela desejabilidade social é o termo científicousado para descrever a tendência dos participantes deresponder às questões de modo que sejam bem vistos pelosoutros membros da comunidade [CM60]. Eliminamos toda e qualquer informação dada, mas nãojustificada pelo participante. Quantidade de participantes insuficiente Não suficiente para generalizar os resultados encontrados.59
    • LiçõesAprendidas Deixar ambiente fácil de ser configurado. Muitos participantes de uma só vez dificultam o trabalho dopesquisador. Estudos com estudantes levam mais tempo para seremexecutados. Participantes da indústria são difíceis de encontrar (e os maisdiversos problemas podem acontecer). Apenas um piloto fez o estudo por completo, devido alimitações de tempo.60
    • Conclusões A prática deTDD pode influenciar no processo de criação doprojeto de classes. No entanto, ao contrário do que é comentado pela indústria, aprática deTDD não guia o desenvolvedor para um bom projeto declasses de forma automática; a experiência e conhecimento dodesenvolvedor são fundamentais ao criar software orientado aobjetos. A prática, por meio dos seus possíveis feedbacks em relação aoprojeto de classes pode servir de guia para o desenvolvedor. Essesfeedbacks, quando observados, fazem com que o desenvolvedorperceba problemas de projeto de classes de forma antecipada,facilitando a refatoração do código.61
    • Trabalhos Futuros Continuar a busca por outros padrões. Avaliar se um desenvolvedor que conhece os padrões aquilevantados encontram problemas de projeto antes dedesenvolvedores que não conhecem os mesmos.62
    • Produções ao longo do mestrado Artigo entitulado Most Common Mistakes inTest-Driven DevelopmentPractice: Results from an Online Survey with Developers, aceito no PrimeiroWorkshop Internacional sobreTDD, em 2010. Artigo entituladoWhatConcerns BeginnerTest-Driven DevelopmentPractitioners: A Qua- litative Analysis of Opinions in an Agile Conference, aceitonoWBMA em 2011. Relato de experiência entitulado Increasing Learning in anAgile Environment:Lessons Learned in an AgileTeam, aceito no Agile de 2011. Curso sobre evolução de software no CBSoft 2011. Apresentação sobreTDD e seus possíveis efeitos no projeto de classes naQCON 2011. Escrita da ferramenta de mineração de repositório de códigos rEvolution,utilizado para calcular as métricas em cima do código produzido pelosparticipantes.63
    • Resultados Esperados Nós esperamos que o resultado deste estudo ajudedesenvolvedores de software a antecipar pro- blemas deprojeto de classes, gerando melhorias constantes e, porconsequência, diminuindo o custo de manutenção e evoluçãodo sistema. Além disso, esperamos que agora o ditado sobre a influênciadeTDD no projeto de classes esteja melhor explicado, e quedesenvolvedores entendam que experiência e conhecimentoem boas práticas de codificação são necessários para queTDD os guie em direção a um bom projeto de classes.64
    • Agradecimentos Gostaria de agradecer ao prof. Marco por ter me ensinadomais do que eu poderia imaginar ao longo destes 3 anos. Gostaria de agradecer aos profs. Rafael e Ismar que mederam excelentes feedbacks na banca de qualificação. Agradeço também a toda minha família, namorada e amigos,que me apoiaram o tempo todo! Por fim, agradeço a todos que participaram do meu estudo!65
    • Não ganhei uma bola…66Obrigado, pai!