Passos a tomar para integrar lentamente teste de unidade em um projeto

StackOverflow https://stackoverflow.com/questions/1017917

Pergunta

Atualmente estou em um prazo co-op trabalhando em um projeto em fase de conclusão com um outro estudante co-op. Uma vez que este projecto tem sido passado de co-op para co-op, más práticas foram tomadas ao longo do caminho e teste foi deixado até o fim. Eu decidi que eu gostaria de escrever unidade-testes para aprender algo novo, enquanto testar.

No entanto, eu estou trabalhando em um 3-tier, app fortemente acoplados que parece impossível de teste de unidade na sua forma actual. Eu não quero jogar fora o outro aluno co-op com nenhum conhecimento de qualquer destes conceitos por refatoração do código além overnight reconhecimento. Então, quais os passos que devo tomar para puxar lentamente o código para a unidade-testability? Devo primeiro implementar um padrão de fábrica e deixar a outra familiarizar-se com estudante que antes de avançar?

As minhas desculpas se o meu conhecimento é falho e não deve haver nenhum qualquer problema. Eu sou novo para isso:)

Foi útil?

Solução

trabalhar efetivamente com legacy Code por Michael Feathers

É difícil saber se a implementação de um padrão de fábrica vai fazer nenhum bem, depende do que o código está fazendo:)

Outras dicas

trabalhar efetivamente com Legacy Code por Michael Feathers (também disponível no Safari Se você tiver uma assinatura) é um excelente recurso para a sua tarefa. O autor define código legado como código sem testes de unidade, e ele dá orientações práticas de muitos de conservadores técnicas necessárias porque você está trabalhando sem uma rede de segurança, para trazer código sob teste. Sumário:

  • Parte: I A Mecânica de Mudança
    • Capítulo 1. Alterar Software
      • Quatro razões para mudar Software
      • Alterar Risky
    • Capítulo 2. Trabalhando com comentários
      • O que é o Teste Unitário?
      • Nível Superior Testing
      • Revestimentos de teste
      • A mudança do algoritmo Legacy Code
    • Capítulo 3. Detecção e Separação
      • Faking Colaboradores
    • Capítulo 4. O Modelo Seam
      • A Folha enorme de Texto
      • Costuras
      • Tipos Seam
    • Capítulo 5. Ferramentas
      • Automated refatoração Ferramentas
      • Mock Objects
      • arneses teste de unidade
      • Gerais equipamentos de teste
  • Parte: II Software Alterar
    • Capítulo 6. Eu não tenho muito tempo e eu tenho de mudá-la
      • Método Sprout
      • Sprout Class
      • Método de Wrap
      • Enrole Class
      • Resumo
    • Capítulo 7. ele leva uma eternidade para fazer uma mudança
      • Entendimento
      • intervalo de tempo
      • Quebra Dependências
      • Resumo
    • Capítulo 8. Como faço para adicionar um recurso?
      • Test-Driven Development (TDD)
      • Programação por Diferença
      • Resumo
    • Capítulo 9. Posso not Get Esta classe em um equipamento de teste
      • O Caso do Irritante Parâmetro
      • O Caso da Dependência Invisível
      • O Caso do Blob Construção
      • O Caso do Irritante global Dependência
      • O Caso do Horrível Incluir Dependências
      • O Caso do Onion Parâmetro
      • O Caso do Aliased Parâmetro
    • Capítulo 10. I Can not Run esse método em um equipamento de teste
      • O caso do método Invisível
      • O caso do "útil" Language Feature
      • O Caso do Undetectable Side Effect
    • Capítulo 11. Eu preciso fazer uma mudança. Que métodos devo testar?
      • Raciocínio Sobre Efeitos
      • Raciocínio Atacante
      • Efeito de propagação
      • Ferramentas para efeito de raciocínio
      • Aprendizagem de Análise Effect
      • Simplificar Efeito Sketches
    • Capítulo 12. Eu preciso fazer muitas mudanças em uma área. Eu tenho que quebram as dependências para todas as classes envolvido?
      • Intercepção Pontos
      • A julgar projeto com pontos de aperto
      • Aperte Ponto Traps
    • Capítulo 13. Eu preciso fazer uma mudança, mas eu não sei o que os testes para escrever testes de caracterização
      • Classes Caracterizando
      • alvejado Testing
      • A Heurística para a escrita Caracterização Testes
    • Capítulo 14. Dependências em bibliotecas estão matando-me
    • Capítulo 15. A minha aplicação é Todas as chamadas de API
    • Capítulo 16. Eu não entendo o Código Bem suficiente para mudar-se
      • Notas / Desenhando
      • Listagem Markup
      • Risco Refactoring
      • Excluir não utilizado Código
    • Capítulo 17. Meu aplicativo não tem estrutura
      • Contar a história do Sistema
      • Nu CRC
      • Conversation Escrutínio
    • Capítulo 18. O código de teste é no Caminho
      • Classe Convenções de nomenclatura
      • Teste de Localização
    • Capítulo 19. Meu projeto não é Object Oriented. Como posso fazer seguro Alterações?
      • um caso fácil
      • A Hard Case
      • Adicionar Novo Comportamento
      • Aproveitando-se de Orientação a Objetos
      • É tudo Object Orientada
    • Too Big Capítulo 20. Esta classe é e eu não quero isso para ficar maior
      • Vendo Responsabilidades
      • Outras técnicas
      • Moving Forward
      • Depois Extract Class
    • Capítulo 21. Eu estou mudando o mesmo código em todo o lugar
      • Primeiros Passos
    • Capítulo 22. Preciso mudar um monstro Método e posso testes não escreve para Ele
      • Variedades de Monstros
      • Monstro Tackling com suporte automatizado Refactoring
      • O Manual Refactoring Desafio
      • Estratégia
    • Capítulo 23. Como eu sei que eu não sou quebrar nada?
      • HyperAware Edição
      • Single-Goal Edição
      • Preserve Signatures
      • Lean on a Compiler
    • Capítulo 24. Nós sentir-se oprimido. Não vai ficar melhor
  • Parte: III Dependência de quebra Técnicas
    • Técnicas Capítulo 25. Dependência de quebra
      • Adaptar Parâmetro
      • Break Método Fora objeto
      • Definição Conclusão
      • Referências Encapsulate globais
      • Expor Método estático
      • Extrair e Substituir Chamada
      • Extrair e Substituir Factory Method
      • Extrair e Substituir Getter
      • Extrato Implementer
      • Extract Interface
      • Apresente Instância Delegator
      • Apresente estática Setter
      • Fazer a ligação Substituição
      • Parametrização Construtor
      • Método Parametrização
      • Primitivize Parâmetro
      • Pull Up Característica
      • empurrar para baixo Dependência
      • Função Substituir com ponteiro Função
      • Substitua Referência global com Getter
      • subclasse e Substituir Método
      • Substituir o Instância Variable
      • Template Redefinição
      • Redefinição Texto
  • Apêndice: Refactoring
    • Extract Method

É muito difícil começar novo práticas de desenvolvimento a meio caminho através de um projeto. No passado, quando eu trabalhei em projetos que não tenham sido testadas unidade desde o início, uma abordagem bom tomar é estabelecer a regra de que 'o novo código deve ter testes de unidade', mas não colocar pressão sobre os testes de unidade sendo escrito para o código antigo.

Claro que, mesmo isso é difícil quando a estrutura do projeto não é adequado para a capacidade de teste.

Meu melhor recomendação seria levá-lo em pequenos passos.

Comece criando o teste de unidade de montagem, (ou projeto ou qualquer outro), sem testes na mesma. Em seguida, encontrar uma única área pequena de código que é muito bem definidos e separados, e escrever alguns testes de unidade para essa área. Obtenha seu co-codificador para dar uma olhada também e começar a receber alguns 'melhores práticas' que vão, como o funcionamento da unidade testa cada vez que qualquer código é verificado em (automaticamente, se possível).

Depois de ter esse trabalho, você pode lentamente começar a adicionar mais.

A chave é lentamente. E como eu disse, é mais fácil de fazer código antigo isentar do teste para começar. Você pode sempre voltar a ele mais tarde uma vez que sua equipe tenha compreendido a idéia de teste de unidade e tornou-se melhor em escrevê-los.

Como sobre a escrita de uma série de testes de caixa-preta em torno de grandes pedaços de funcionalidade em seu código? Desde que você mencionar que é um projeto ASP.NET, você pode usar um quadro como WaitN ou Selenium para automatizar um navegador web. Isto dá-lhe um conjunto básico de funcionalidades que deve permanecer constante, não importa o quanto as alterações de código.

Uma vez que você tem um número confortável de testes testar a funcionalidade de alto nível do seu projeto, eu, em seguida, começar a mergulhar no código, e como Simon P. Stevens menciona, trabalho devagar . Pegue um (! Livre) cópia do Refactor! para Visual Basic, assim você será capaz de executar automaticamente algumas refatoração básica, como Extract Method. Você pode aumentar drasticamente a capacidade de teste sem alterar qualquer funcionalidade apenas dividir grandes blocos de código em pedaços menores, mais testáveis.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top