Orientações de testes de unidade

Question

Alguém sabe de onde encontrar as diretrizes de teste de unidade e recomendações? Eu gostaria de ter algo que aborda os seguintes tipos de temas (por exemplo):

• Os testes devem estar no mesmo projeto como lógica da aplicação?
• Eu deveria ter classes de teste para espelhar minhas aulas de lógica ou devo ter apenas como muitas classes de teste como eu sinto que preciso de ter?
• Como devo nomear minhas classes de teste, métodos e projectos (se eles vão em diferentes projetos)
• deve privada, protegida e métodos internos ser testado, ou apenas aqueles que são acessíveis ao público?
• testes de unidade e de integração devem ser separados?
• Existe um boa razão para não ter cobertura de teste de 100%?

O que não estou perguntando sobre que eu deveria ser?

Um recurso on-line seria melhor.

Answer 1

Eu recomendaria livro Kent Beck em TDD.

Além disso, você precisa ir para o site Martin Fowler. Ele tem um monte de boas informações sobre o teste também.

Estamos bastante grande em TDD por isso vou responder às perguntas em que a luz.

Os testes devem estar no mesmo projeto como lógica da aplicação?

Normalmente mantemos nossos testes na mesma solução, mas nós quebramos testes em separado DLL / Projetos que espelham do DLL / Projetos eles estão testando, mas manter namespaces com os testes sendo em uma sub namespace. Exemplo: Common / Common.Tests

Eu deveria ter classes de teste para espelhar minhas aulas de lógica ou devo ter apenas como muitas classes de teste como eu sinto que preciso de ter?

Sim, os testes devem ser criadas antes de quaisquer classes são criadas, e por definição só deve testar uma única unidade em isolamento. Portanto, você deve ter uma classe de teste para cada classe em sua solução.

Como devo nomear minhas classes de teste, métodos e projectos (se eles vão em diferentes projetos)

Eu gostaria de enfatizar que o comportamento é o que está sendo testado para que eu normalmente nomear classes de teste após a SUT. Por exemplo, se eu tivesse uma classe de usuário gostaria de citar a classe de teste assim:

public class UserBehavior

Métodos deve ser nomeado para descrever o comportamento que você espera.

public void ShouldBeAbleToSetUserFirstName()

Os projetos podem ser nomeado como quiser, mas geralmente você quer que ele seja bastante óbvio que projetá-lo está testando. Ver resposta anterior sobre organização do projeto.

deve, protegidas e métodos internos privados ser testado, ou apenas aqueles que são acessíveis ao público?

Mais uma vez você quer testes ao comportamento assert esperado como se você fosse uma terceira consumidor partido dos objetos que estão sendo testados. Se você testar detalhes de implementação interna, em seguida, seus testes será frágil. Você quer que seu teste para dar-lhe a liberdade para refatorar sem se preocupar em quebrar a funcionalidade existente. Se o seu teste de saber sobre detalhes de implementação, então você vai ter que mudar seus testes se esses detalhes mudança.

testes de unidade e de integração devem ser separados?

Sim, testes de unidade precisa ser isolado de testes de aceitação e integração. Separação de interesses aplica-se a testes também.

Existe uma razão boa para não ter cobertura de teste de 100%?

Eu não iria começar a se pendurado na coisa cobertura de código 100%. 100% de cobertura de código tende a implicar um certo nível de qualidade nos testes, mas que é um mito. Você pode ter testes terríveis e ainda obter uma cobertura de 100%. Eu sim contar com um bom primeiro teste mentalidade. Se você sempre escrever um teste antes de escrever uma linha de código, em seguida, você irá garantir uma cobertura de 100% para que se torne um ponto discutível.

Em geral, se você se concentrar em descrever o escopo comportamental completo da classe, em seguida, você não terá nada para se preocupar. Se você fizer a cobertura de código de métricas programadores, em seguida, preguiçosos simplesmente fazer apenas o suficiente para atender a essa marca e você ainda terá testes de baixa qualidade. Em vez disso dependem fortemente de avaliações pelos pares, onde os testes são revistos também.

Answer 2

É uma boa pergunta. Nós crescemos nosso próprio organicamente, e eu suspeito que a melhor maneira é apenas isso. Há um pouco "Depende ..." lá dentro.

Nós colocamos os testes no mesmo projeto, em uma sub-namespace chamado "UnitTes"

Nossas aulas teste do espelho da classe lógica, a fim de manter o controle simplificado de onde os testes são em relação ao que eles estão testando

As classes são nomeadas como a classe lógica eles estão testando, os métodos são nomeados para o cenário que está testando.

apenas testes de gravação para o público e métodos internos (teste estão no mesmo projeto), e apontar para uma cobertura de 95% da classe.

Eu prefiro não fazer a distinção entre "unidade" e "intergation". Para muito tempo será gasto tentando descobrir qual é qual ... saco isso! Um teste é um teste.

100% é muito difícil de alcançar o tempo todo. Temos como objectivo para 95%. Há também retornos decrescentes sobre quanto tempo vai demorar para obter esse final de 5% eo que vai realmente pegar.

Isso nós e que ambiente fora adequado eo ritmo é. Você é milhagem pode variar. Pense no seu envivonment nad as personalidades que estão envolvidos.

Estou ansioso para ver o que os outros têm a dizer sobre este!

Answer 3

A resposta de Josh está certo sobre - apenas um ponto de esclarecimento:

A razão de eu separar testes de unidade de testes de integração e aceitação é a velocidade. Eu uso TDD. Eu preciso fechar a feedback instantâneo sobre a linha de código que acabou de criar / modificado. Não consigo que, se eu estou correndo suites completas de integração e / ou testes de aceitação -. Testes que atingiram discos reais, verdadeiras redes e sistemas externos realmente lentos e imprevisíveis

Não cruze as vigas. coisas ruins vão acontecer se você fizer.

Answer 4

Eu insistentemente recomendo que você leia Desenvolvimento Test Driven: Por Exemplo Test-Driven Development: Um Guia Prático é demais perguntas para tema único

Answer 5

Com relação à sua última pergunta, na minha experiência, a "boa" razão para não insistir sobre a cobertura do teste de 100% é que leva uma quantidade desproporcional de esforço para obter os últimos pontos percentuais, particularmente em bases de código maiores. Como tal, é uma questão de decidir se quer ou não vale a pena o seu tempo uma vez que você chegar a esse ponto de retornos decrescentes.

Answer 6

Em ordem:

• Não, é geralmente melhor para incluí-los em um projeto separado; a menos que você quer ser capaz de executar diagnósticos em tempo de execução.
• O ideal é 100% de cobertura de código, o que significa que cada linha de código em cada rotina em cada classe.
• Eu vou com ClassnameTest, ClassnameTest.MethodNameTestnumber
• Tudo.
• Eu diria que sim, como testes de integração não precisa ser executado se testes de unidade falhar.
• Propriedades simples que apenas definir e obter um campo não precisa ser testado.

Answer 7

Os testes devem estar no mesmo projeto como lógica da aplicação?

Depende. Há trade-offs de qualquer forma.

Mantendo-o em um projeto requer largura de banda adicional para distribuir seu projeto, tempo de compilação extra e aumenta a pegada de instalação, e torna mais fácil para fazer o erro de ter lógica de produção que depende de código de teste.

Por outro lado, manter projetos separados pode tornar mais difícil a testes de gravação envolvendo métodos / classes (dependendo linguagem de programação) privadas, e provoca dificuldades de administração menores, tais como tornar a criação de um novo ambiente de desenvolvimento (por exemplo, quando um novo desenvolvedor se junta ao projeto) mais difícil.

Quanto estes diferentes custos importa varia de acordo com projeto, então não há nenhuma resposta universal.

Eu deveria ter classes de teste para espelhar minhas aulas de lógica ou devo ter apenas como muitas classes de teste como eu sinto que preciso de ter?

Não.

Você deve ter classes de teste que permitem o código de teste bem-consignado (ou seja, a duplicação mínima, clara intenção, etc).

A vantagem óbvia de espelhar diretamente as classes de lógica em suas classes de teste é que ele torna mais fácil encontrar os testes correspondentes a uma parte específica do código. Há outras maneiras de resolver este problema sem restringir a flexibilidade do código de teste. convenções de nomenclatura simples para testar módulos e classes é geralmente suficiente.

Como devo nomear minhas classes de teste, métodos e projectos (se eles vão em diferentes projetos)

Você deve nomeá-los de modo que:

• cada método de classe de teste e teste tem um objetivo claro, e
• para que alguém olhando para um teste particular (ou para testes sobre uma determinada unidade) pode encontrá-lo facilmente.

deve, protegido, e os métodos internos e privados ser testado, ou apenas aqueles que são acessíveis ao público?

Muitas vezes os métodos não-públicos devem ser testados. Depende se você tem confiança suficiente de apenas testando a interface pública, ou se a unidade que você realmente quer ser o teste não é publicamente acessível.

testes de unidade e de integração devem ser separados?

Isso depende da sua escolha de testar-quadro (s). Faça o que funciona melhor com o seu framework de teste (s) e faz com que:

• ambos os testes de unidade e integração relativos a um pedaço de código são fáceis de encontrar,
• é fácil de executar apenas os testes de unidade,
• é fácil de executar apenas o teste de integração,
• é fácil de executar todos os testes.

Existe uma razão boa para não ter cobertura de teste de 100%?

Sim, há uma boa razão. Estritamente falando “cobertura de teste 100%” significa todas as situações possíveis em seu código seja exercido e testado. Isto é simplesmente impraticável para quase qualquer projeto de alcançar.

Se você simplesmente tomar “cobertura de teste 100%” significa que cada linha de código fonte é exercido pelo conjunto de testes em algum momento, então esta é uma boa meta, mas às vezes há apenas um par de linhas em locais de difícil acesso que são difíceis de alcançar com os testes automatizados. Se o custo de verificar manualmente essa funcionalidade periodicamente é menor que o custo de passar por contorções para chegar a esses últimos cinco linhas, em seguida, que é uma boa razão para não ter cobertura de 100%.

Ao invés de uma regra simples que você deve ter cobertura de linha 100%, incentivar seus desenvolvedores para descobrir qualquer falhas no teste, e encontrar maneiras de corrigir essas lacunas, ou o número de linhas “ coberto”melhora. Em outras palavras, se você medir linhas coberto, em seguida, você irá melhorar o seu coverge linha - mas o que você realmente quer é a melhoria da qualidade. Então não se esqueça que a cobertura de linha é apenas uma aproximação muito grosseira de qualidade.