Projetos de teste do NUnit vs Visual Studio 2008 para teste de unidade? [fechadas]

Vou iniciar um novo projeto no trabalho e quero entrar em testes de unidade. Usaremos o VS 2008, C # e o material do ASP.NET MVC. Estou pensando em usar o NUnit ou os projetos de teste integrados que o VS2008 possui, mas estou aberto a pesquisar outras sugestões. Um sistema é melhor que o outro ou talvez mais fácil de usar / entender que o outro? Eu estou procurando que esse projeto seja configurado como o tipo de "melhor prática" para nossos esforços de desenvolvimento daqui para frente.

Obrigado por qualquer ajuda e sugestões !!

Daok nomeou todos os profissionais do VS2008, aqui estão os profissionais da NUnit.

• O NUnit possui uma estrutura de simulação.
• O NUnit pode ser executado fora do IDE, isso pode ser útil se você quiser executar testes em um servidor de compilação não-MS como o CC.Net
• O NUnit tem mais versões lançadas do que o visual studio. Você não precisa esperar anos por uma nova versão E não precisa instalar uma nova versão do IDE para obter novos recursos.
• Existem extensões sendo desenvolvidas para o NUnit, como testes de linha etc.
• Os testes do Visual Studio levam muito tempo para serem iniciados por algum motivo. Isso é melhor em 2008, mas ainda é muito lento para o meu gosto. A execução rápida de um teste para ver se você não quebrou algo pode demorar muito. NUnit com algo como Testdriven.Net para executar testes a partir do IDE é realmente muito mais rápido. especialmente ao executar testes únicos.
  De acordo com Kjetil Klaussen, isso é causado pelo testrunner do Visual Studio, a execução de testes MSTest no TestDriven.Net torna o desempenho do MSTest comparável ao NUnit.

A estrutura de teste de unidade não importa muito, porque você pode converter classes de teste com arquivos de projeto separados e compilação condicional (como esta, VS-> NUnit):

 #if! NUNIT
  using Microsoft.VisualStudio.TestTools.UnitTesting;
 #outro
  using NUnit.Framework;
  using TestClass = NUnit.Framework.TestFixtureAttribute;
  using TestMethod = NUnit.Framework.TestAttribute;
  using TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  using TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #fim se

O plug-in TestDriven.Net é bom e não é muito caro ... Com apenas o VS2008, você precisa encontrar o teste na sua classe ou lista de testes. Com TestDriven.Net, você pode executar seu teste diretamente da classe que está testando. Afinal, o teste de unidade deve ser fácil de manter e próximo ao desenvolvedor.

Benefícios / alterações da estrutura de teste de unidade integrada do VS2008

1. A versão 2008 agora está disponível em edições profissionais (antes de exigir versões caras do VS, isso é apenas para testes de unidade de desenvolvedor). Isso deixou muitos desenvolvedores com a única opção de estruturas de teste abertas / externas.
2. API incorporada suportada por uma única empresa.
3. Use as mesmas ferramentas para executar e criar testes (você pode executá-los usando a linha de comando também MSTest)
4. Design simples (sem estrutura Mock, mas este é um excelente ponto de partida para muitos programadores)
5. Suporte a longo prazo concedido (ainda me lembro do que aconteceu com o nDoc, não quero me comprometer com uma estrutura de teste que pode não ser suportada em 5 anos, mas ainda considero a nUnit uma ótima estrutura.)
6. Se você estiver usando o Team Foundation Server como seu back-end, poderá criar itens de trabalho ou bugs com os dados de teste com falha de uma maneira simples.

Uso o NUnit há 2 anos. Está tudo bem, mas devo dizer que o sistema Unit no VS é muito bom porque está dentro do Gui e pode mais facilmente fazer testes para funções privadas sem ter que mexer. Além disso, o Teste de unidade do VS permite que você faça cobertura e outras coisas que o NUnit sozinho não pode fazer.

Um pequeno aborrecimento da estrutura de teste do Visual Studio é que ele criará muitos arquivos de execução de teste que tendem a desorganizar o diretório do projeto - embora isso não seja tão importante.

Além disso, se você não tiver um plug-in como o TestDriven.NET, não poderá depurar os testes de unidade NUnit (ou MbUnit, xUnit etc.) no ambiente do Visual Studio, como na estrutura de teste do Microsoft VS, que é incorporada.

Ligeiramente fora de tópico, mas se você optar pelo NUnit, posso recomendar o uso do ReSharper - ele adiciona alguns botões à interface do usuário do VS que facilitam muito a execução e depuração de testes no IDE.

Esta revisão está um pouco desatualizada, mas explica isso com mais detalhes:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

XUnit é outra possibilidade para um projeto greenfield. Talvez tenha uma sintaxe mais intuitiva, mas não é realmente compatível com as outras estruturas.

http://www.codeplex.com/xunit

Minha principal carne com testes de unidade VS sobre NUnit é a criação de teste VS tende a injetar um monte de código gerado para acesso de membros privados.

Alguns podem querer testar seus métodos particulares, outros não, esse é um tópico diferente.

Minha preocupação é que, quando estou escrevendo testes de unidade, eles devem ser extremamente controlados, para que eu saiba exatamente o que estou testando e exatamente como estou testando. Se houver código gerado automaticamente, estou perdendo parte dessa propriedade.

Eu fiz um TDD usando ambos e (talvez eu seja um pouco burro) o nUnit parece ser muito mais rápido e mais simples de usar para mim. E quando digo muito, quero dizer muito.

No MS Test, existem muitos atributos em todos os lugares - o código que faz os testes reais são as pequenas linhas que você pode ler aqui e ali. Uma grande bagunça. No nUnit, o código que faz o teste apenas domina os atributos, como deveria.

Além disso, no nUnit, basta clicar nos testes que deseja executar (apenas um? Todos os testes que cobrem uma classe? Uma montagem? A solução?). Um clique. E a janela é clara e grande. Você recebe luzes verdes e vermelhas claras. Você realmente sabe o que acontece à uma vista.

No VSTS, a lista de testes está congestionada na parte inferior da tela, é pequena e feia. Você precisa procurar duas vezes para saber o que aconteceu. E você não pode executar apenas um teste (bem, eu ainda não descobri!).

Mas posso estar errado, é claro - acabei de ler cerca de 21 posts no blog sobre "Como fazer TDD simples usando o VSTS". Eu deveria ter lido mais, você está certo.

Para nUnit, eu li um. E eu estava no TDD no mesmo dia. Com diversão.

A propósito, eu geralmente amo produtos da Microsoft. O Visual Studio é realmente a melhor ferramenta que um desenvolvedor pode comprar - mas o gerenciamento de TDD e Item de Trabalho no Visual Studio Team System é realmente péssimo.

Muito bem sucedida. Sylvain.

Recebi mensagens de que "a estrutura do arquivo NUnit é mais rica que o VSTest" ... É claro que se você preferir a estrutura do arquivo NUnit, poderá usar esta solução de outra maneira, como esta (NUnit-> VS):

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

Ou qualquer outra conversão ... :-) Este uso aqui é apenas um alias para o compilador.

Primeiro, quero corrigir uma declaração errada: você pode executar o msTest fora do visual studio usando a linha de comando. Embora várias ferramentas de IC, como o TeamCity, tenham melhor suporte ao NUnit (provavelmente mudaria à medida que o msTest se tornasse mais popular). No meu projeto atual, usamos as duas e a única grande diferença que encontramos é que o mstest sempre é executado como 32 bits, enquanto o NUnit é executado como teste de 32 ou 64 bits, o que só importa se o seu código usa código nativo que depende de 32/64.

Comecei com o MSTest, mas mudei por um simples motivo. O MSTest não oferece suporte à herança de métodos de teste de outros assemblies.

Eu odiava a ideia de escrever o mesmo teste várias vezes. Especialmente em um projeto grande, onde os métodos de teste podem ser facilmente executados em centenas de testes.

NUnit faz exatamente o que eu preciso. A única coisa que falta no NUnit é um suplemento do Visual Studio que pode exibir o status Vermelho / Verde (como o VSTS) de cada teste.

Pacotes de consultoria para o .NET Testing Framework e .NET Unit Testing? .

Se você está considerando o MSTest ou o nUnit, recomendamos que você veja o mbUnit. Minhas razões são

1. Compatibilidade com TestDriven.Net. Nada melhor que TestDriven.Net.ReRunWithDebugger vinculado a uma combinação de teclado.
2. A estrutura Gallio. Gallio é um corredor de teste como o nUnits. A única diferença é que não importa se você escreveu seus testes no nUnit, msTest, xUnit ou mbUnit. Todos eles são executados.
3. Compatibilidade com nUnit. Todos os recursos do nUnit são suportados pelo mbUnit. Eu acho que você nem precisa alterar seus atributos (terá que verificar isso), apenas sua referência e usos.
4. A coleção afirma. mbUnit tem mais casos de Assert, incluindo a classe CollectionAssert. Basicamente, você não precisa mais escrever seus próprios testes para ver se duas coleções são iguais.
5. Testes combinatórios. Não seria legal se você pudesse fornecer dois conjuntos de dados e fazer um teste para todas as combinações de dados. Está em mbUnit.

Originalmente, peguei o mbUnit por causa de sua funcionalidade [RowTest ....] e não encontrei um único motivo para voltar. Mudei todas as minhas suítes de teste ativas do nUnit e nunca olhei para trás. Desde então, converti duas equipes de desenvolvimento diferentes para os benefícios.

Até onde eu sei, existem quatro estruturas disponíveis para testes de unidade com o .NET atualmente.

• NUnit
• MbUnit
• MSTest
• xUnit

O NUnit sempre esteve na frente, mas a lacuna diminuiu no último ano. Eu ainda prefiro o NUnit, especialmente porque eles adicionaram uma interface fluente há algum tempo, o que torna os testes muito legíveis.

Se você está apenas começando a testar a unidade, provavelmente não faz muita diferença. Quando estiver pronto, estará em uma posição melhor para julgar qual estrutura é melhor para suas necessidades.

Eu não gosto da estrutura de teste integrada do VS porque força você a criar um projeto separado, em vez de ter seus testes como parte do projeto que você está testando.

O MSTest é essencialmente NUnit ligeiramente reformulado, com alguns novos recursos (como configuração e desmontagem da montagem, não apenas nível de fixação e teste) e faltando alguns dos melhores bits (como a nova sintaxe da restrição 2.4). O NUnit é mais maduro e há mais suporte de outros fornecedores; e, é claro, como sempre foi gratuito (enquanto o MSTest só chegou à versão Professional de 2008, antes era de SKUs muito mais caras), a maioria dos projetos do ALT.NET o usa.

Dito isto, existem algumas empresas que são incrivelmente relutantes em usar algo que não possui o rótulo da Microsoft, especialmente o código OSS. Portanto, ter uma estrutura de teste oficial do EM pode ser a motivação que essas empresas precisam para fazer o teste; e, sejamos honestos, é o teste que importa, não a ferramenta que você usa (e usando o código de Tuomas Hietanen acima, você quase pode tornar sua estrutura de teste intercambiável).

Com o lançamento no .NET 4.0 do sistema Code Contracts e a disponibilidade de um verificador estático , você precisará escrever teoricamente menos casos de teste e uma ferramenta como o Pex ajudará a identificar esses casos. Relacionando isso à discussão em questão, se você precisar fazer menos com seus testes de unidade porque seus contratos estão cobrindo sua cauda, ​​por que não seguir em frente e usar as peças internas, já que essa é uma dependência a menos para gerenciar. Hoje em dia, eu me refiro à simplicidade. :-)

Veja também:

• Microsoft Pex - Teste de unidade automatizado
• Geração de testes de unidade com Pex usando o Visual Studio 2010 e C # 4.0

Eu preferiria usar a pequena estrutura de teste do MS, mas por enquanto estou usando o NUnit. Os problemas com os EM são geralmente (para mim)

• Arquivo "testes" compartilhado (sem sentido) que deve ser mantido
• As listas de testes causam conflitos com vários desenvolvedores / VCS
• Interface de usuário integrada ruim - configuração confusa, seleção de testes onerosa
• Nenhum bom corredor externo

Advertências - Se eu estivesse testando um site aspx, definitivamente usaria o MS - Se estivesse desenvolvendo solo, também o MS seria bom - Se eu tivesse habilidades limitadas e não pudesse configurar o NUnit :)

Acho muito mais fácil escrever meus testes e iniciar o NUnitGUI ou um dos outros front-ends (testDriven está muito longe demais). Configurar a depuração com a versão da linha de comando também é bastante fácil.