C# – Excluindo testes unitários da versão de lançamento do seu projeto

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

Pergunta

Como você costuma fazer separando sua base de código e testes de unidade associados?Conheço pessoas que criam um projeto separado para testes unitários, o que pessoalmente considero confuso e difícil de manter.Por outro lado, se você misturar código e seus testes em um único projeto, você acabará com binários relacionados ao seu framework de testes unitários (seja NUnit, MbUnit ou qualquer outro) e seus próprios binários lado a lado.

Isso é bom para depuração, mas depois de construir um versão de lançamento, eu realmente não quero que meu código faça referência à estrutura de teste de unidade não mais.

Uma solução que encontrei é incluir todos os seus testes de unidade nas diretivas #if DEBUG - #endif:quando nenhum código faz referência a um assembly de teste de unidade, o compilador é inteligente o suficiente para omitir a referência no código compilado.

Existem outras opções (possivelmente mais confortáveis) para atingir um objetivo semelhante?

Foi útil?

Solução

Eu definitivamente defender separando seus testes para um projeto separado. É o único caminho a percorrer na minha opinião.

Sim, como Gary diz, também obriga a um comportamento de teste através de métodos públicos em vez de jogar sobre com as entranhas de suas classes

Outras dicas

Como os outros apontam, um projeto de teste separado (para cada projeto normal) é uma boa maneira de fazê-lo. Eu costumo espelhar os namespaces e criar uma classe de teste para cada classe normal com 'test' anexado ao nome. Isto é suportado diretamente no IDE se você tiver Visual Studio Team System que pode gerar automaticamente classes de teste e métodos em outro projeto.

Uma coisa a lembrar se você quiser classes de teste e métodos com o acessor 'interna' é adicionar a seguinte linha para o arquivo AssemblyInfo.cs para cada projeto a ser testado: 

[assembly: InternalsVisibleTo("UnitTestProjectName")]

O framework .Net após v2 possui um recurso útil onde você pode marcar uma reunião com o atributo InternalsVisibleTo que permite a montagem a ser acessado por outro.
Uma espécie de recurso tunneling montagem.

No entanto, outra alternativa ao uso de diretivas de compilador em um arquivo ou criar um projeto separado é apenas para criar arquivos de cs adicionais em seu projeto.

Com um pouco de magia no próprio arquivo de projeto, você pode ditar que:

  1. DLLs nunit.framework só são referenciados em uma compilação de depuração, e
  2. seus arquivos de teste só são incluídos no compilações de depuração

Exemplo .csproj trecho: 

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   ...

   <Reference Include="nunit.framework" Condition=" '$(Configuration)'=='Debug' ">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\debug\nunit.framework.dll</HintPath>
   </Reference>

   ...

   <Compile Include="Test\ClassTest.cs" Condition=" '$(Configuration)'=='Debug' " />

   ...
</Project>

Eu recomendaria um projeto separado para testes de unidade (e ainda mais projetos para testes de integração, testes funcionais etc.). Eu tentei misturar código e os testes no mesmo projeto e achei muito menos sustentável do que separando-os em projetos separados.

Manter namespaces paralelas e usando uma convenção de nomenclatura sensata para testes (por exemplo. MyClass e MyClassTest) irá ajudá-lo a manter a base de código sustentável.

Enquanto os testes estão em um projeto independente, os testes podem fazer referência a base de código, mas a base de código nunca tem de referenciar os testes. Eu tenho que perguntar, o que está confuso sobre a manutenção de dois projetos? Você pode mantê-los na mesma solução para a organização.

A parte complicada, é claro, é quando a empresa tem 55 projetos na solução e 60% deles são testes. Considerar-se sortudo.

Eu coloquei os testes em um projeto separado, mas na mesma solução. Concedido, em soluções grandes, pode haver um monte de projetos, mas o explorador solução é boa o suficiente em separá-los e se você dar tudo razoável nomes Eu realmente não acho que é um problema.

Para cada projeto há um projeto .test correspondente que contém testes nele.

por exemplo. para a montagem chamado, dizer "Acme.BillingSystem.Utils", haveria um teste de montagem chamada "Acme.BillingSystem.Utils.Test".

excluí-lo da versão de envio do seu produto, não enviando que dll.

Eu sempre manter meus testes de unidade em um projeto separado para que ele compila para a sua própria montagem.

Uma coisa ainda a ser considerado é versões do VisualStudio antes de 2005 não permitia EXE montagem projectos a ser referenciado a partir de outros projetos. Então, se você está trabalhando em um projeto legado no VS.NET suas opções seria:

  • Coloque testes de unidade no mesmo projeto e usar compilação condicional para excluí-los de compilações.
  • Mover tudo para dll assembleias para que o seu exe é apenas um ponto de entrada.
  • contornar o IDE cortando o arquivo de projeto em um editor de texto.

Dos três compilação condicional é o menos propenso a erros.

Eu definitivamente concordo com todos os outros que você deve separar os testes de seu código de produção. Se você insistir em não, no entanto, você deve definir uma constante comiplation condicional chamado TEST, e envolva todas as suas classes de teste de unidade com um 

#if TEST
#endif

primeiro para garantir que o código de teste não compila em um cenário de produção. Uma vez feito isto, você deverá ser capaz de excluir as DLLs de teste da sua implantação de produção, ou ainda melhor (mas a manutenção superior), criar um NAnt ou MSBuild para a produção que compila sem as referências às dlls de teste.

Eu sempre criar um projeto Acme.Stuff.Test separado que é compilado separadamente.

O argumento inverso é: Por que você quer para fazer os testes fora? Por que não entregar o teste? Se você entregar os testes junto com um corredor de teste você tem algum nível de teste de aceitação e auto-teste entregue com o produto.

Já ouvi esse argumento algumas vezes e pensei sobre isso, mas eu, pessoalmente, ainda manter os testes em um projeto separado.

Se a tag # if (debug) permite uma versão limpa "release", por que você precisa de um projeto separado para testes. O nunit LibarryA / B exemplo (sim, eu sei que é um exemplo) faz isso. Atualmente lutando com o cenário. Tinha vindo a utilizar um projeto separado, mas este parece possivelmente permitir algumas melhorias de produtividade. Ainda hummin e hawin.

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