Até onde ir com testes de unidade

Uma pergunta feita muitas vezes antes, mas com um desenvolvimento específico inclinado twds mvc.

Eu fui um garoto muito bom e codifiquei todas as minhas ações de controlador com testes de unidade correspondentes, o que tem sido ótimo (se um pouco [leia MUITO] repetitivo às vezes). Para ser sincero, na verdade eu criei um pequeno modelo T4 para escrever a maioria dos ossos dos testes unitários iniciais e, em seguida, aprimorei conforme apropriado conforme o uso. Admito não ter muita certeza de como lidar com testes em visualizações que contêm visualizações parciais - mas isso é uma história para outra pergunta.

Agora, a parte difícil para eu decidir é quão profunda deve ser a cobertura na minha camada de serviço. A razão é que alguns dos meus métodos de serviço (para melhor ou para pior) realmente executam uma variedade de consultas linq que fornecem informações discretas para a lógica subsequente dentro do método. Eu sei que eu poderia (deveria ??) quebrar esses métodos para chamar apenas a lógica necessária para cada instrução linq e aplicá-los no método. No entanto, em muitos casos, nunca há reutilização das 'funções' do linq e, portanto, parece que isso refatoraria o código muito longe.

O que estou perguntando é que, com lógica complexa ocorrendo dentro de um método, é "bom o suficiente" ter um método de teste que simplesmente afirme o resultado necessário e / ou erro esperado, ou todas as linhas lógicas devem ser simultâneas e testadas também. do jeito que estou vendo, para fazer o teste corretamente, a lógica do método (linha por linha) também deve estar recebendo algum tipo de cobertura. Isso, no entanto (na minha opinião ingênua), poderia levar a um ciclo interminável de tentar manter o teste e o método implementado tão intimamente alinhados (que eu sei que deveriam ser) a ponto de criar uma indústria caseira nos próprios testes.

Eu sei que minha pergunta pode ofender alguns dos devotos do TDD que verão isso como um acéfalo. Não estar no campo de TDD, este é um 'sim' para mim, daí a questão.

btw - havia verificado isso em busca de idéias:

http://dotnetslackers.com/articles/aspnet/Built-in-Unit-Test-for-ASP-NET-MVC-3-in-Visual-Studio-2010-Part-1.aspx

olhando para a frente para os votos constantes agora :)

[editar] - para o benefício do eleitor único (bem, no momento único!) encerra. esta questão não é subjetiva. Estou à procura de consenso sobre um assunto muito focado. Não estou tentando despertar paixões negativas, não pretendo expor falhas na tecnologia - sou um grande fã. Portanto, envie um comentário educado para meu benefício, se a votação for encerrada, pois isso pode me ajudar a reestruturar a pergunta, se houver ambiguidade ou desinformação. esta pergunta poderia beneficiar grande parte da população de mvc.

obrigado!!

jim

Primeiro, o que você está falando não soa como TDD. O TDD implica em uma primeira abordagem de teste, que consiste em conduzir o design do seu sistema, seguindo o padrão de Teste-> Código-> Refatorar . Então, talvez o seu primeiro problema seja o objetivo de seus testes, você os está escrevendo enquanto codifica? Nesse caso, eu esperaria que praticamente toda a lógica do seu teste esteja relacionada a algum teste de unidade. A alta cobertura do código é, portanto, um resultado indireto da aplicação do TDD.

Ao fazer TDD, você escreve código de teste suficiente para motivar o código que deseja escrever. Você também garante que o teste falhe primeiro. Basicamente, pergunte a si mesmo o que esse método precisa fazer. Então você codifica, mas apenas o suficiente para fazer o teste passar, se não for o que você está procurando, então você escreve testes adicionais e depois refatora o método.

A cobertura do código após o fato não é um método eficaz de medir sua adesão ao TDD, embora você normalmente encontre uma cobertura de código muito alta no código escrito usando TDD, pois o fato de todo o código ter sido motivado por algum teste.

Os testes TDD servem para conduzir o design e o documento e explicar o design para outras pessoas em linguagem simples (portanto, como você nomeia seus testes é muito importante).

No entanto, nada disso divagam realmente responde diretamente à sua pergunta, então vou apenas dizer que você deve procurar uma cobertura de código de serviço bastante alta (não-UI), especialmente onde houver lógica não-trival, e ainda melhor se os testes forem escrito primeiro ;-). O fato é (embora alguns possam discordar) que mais testes geralmente são melhores. Muitos projetos de código aberto de alta qualidade têm muito mais código de teste do que código em execução.

Além disso, os testes devem ser escritos sempre que:

1. Você está escrevendo um novo código, os testes devem orientar e documentar seu design e explicar suas suposições sobre o que o código deve fazer. O deve ser escrito antes do código.

2. Você encontrou um erro, um teste que falhou deve demonstrar o erro. Quando o erro é corrigido, o teste deve passar.

3. Você altera o código de uma maneira que altera a natureza do que um método ou classe faz (embora muitos testes falhem quando uma área do código muda, isso pode indicar testes frágeis). Isso mantém os testes documentando o código corretamente.

Pessoalmente, descobri que aprender TDD é um desafio interessante e leva tempo para desenvolver um bom "pressentimento" para ele. Prática, prática, prática tem sido a melhor maneira de aprender para mim. Isso e lendo o código de teste de projetos de código aberto e agora também contribuindo para eles enquanto escrevia novos testes com minhas alterações.

É óbvio que testar apenas o valor de retorno de um método é menos poderoso do que testar todas as ramificações dentro dele. Entradas alternativas não terão garantia de comportamento correto.

Por outro lado, você pode não ter tempo ou paciência suficiente para testar tudo.

O que você pode fazer é decidir quanto do código você deseja cobrir com os testes (80-90% ou o que for) e aplicá-lo usando ferramentas automatizadas que verificam isso.
Um "ciclo interminável" de testes de gravação ocorrerá apenas se o ciclo de gravação de código também nunca terminar :)

Quão certo você deseja que seu código funcione corretamente? O teste de unidade é simplesmente uma ferramenta na bolsa do programador para ajudar a verificar se sua implementação faz o que a especificação diz que precisa fazer. Você provavelmente não precisa de 100% de cobertura, mas deve escrever testes de unidade para cobrir as partes mais críticas do seu código. É sempre bom garantir que seus métodos funcionem bem juntos, não apenas sozinhos, e, portanto, você deve tentar escrever alguns testes que cubram algumas de suas "linhas lógicas" mais críticas.

A execução de testes de unidade com a cobertura de código ativada no Visual Studio deve fornecer uma boa indicação (e gráfica) de quão bem seu código é coberto.

Se você não estiver usando a estrutura MSTest embutida, talvez seja necessário procurar um produto de cobertura de código de terceiros para trabalhar com o NUnit ou siga as instruções aqui: /programming/2665799/does-vs2010-code -coverage-support-nunit