NUnit vs Projetos de Teste do Visual Studio 2008 para Teste Unitário?

Eu vou começar um novo projeto no trabalho e quero entrar em testes unitários. Nós estaremos usando o VS 2008, C # e o material da ASP.NET MVC. Eu estou olhando para usar o NUnit ou os projetos de teste internos que o VS2008 tem, mas estou aberto para pesquisar outras sugestões. Um sistema é melhor que o outro ou talvez mais fácil de usar / entender do que o outro? Eu estou olhando para obter este projeto criado como uma espécie de “melhor prática” para os nossos esforços de desenvolvimento daqui para frente.

Obrigado por qualquer ajuda e sugestões !!

Daok nomeou todos os profissionais dos projetos de teste do VS2008, aqui estão os profissionais do NUnit.

  • NUnit tem um quadro de zombaria.
  • NUnit pode ser executado fora do IDE, isso pode ser útil se você deseja executar testes em um servidor de compilation não MS como o CC.Net
  • O NUnit tem mais versões 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 resources.
  • Existem extensões sendo desenvolvidas para o NUnit, como testes de linha, etc.
  • Os testes do Visual Studio demoram muito tempo para serem iniciados por algum motivo. Isso é melhor em 2008, mas ainda é muito lento para o meu gosto. Executar rapidamente um teste para ver se você não quebrou alguma coisa pode demorar muito. NUnit com algo como Testdriven.Net para executar testes do IDE é realmente muito mais rápido. especialmente ao executar testes únicos.
    O fato de o Kjetil Klaussen ter sido causado pelo testrunner do Visual Studio, executando testes do 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 classs de teste com arquivos de projeto separados e compilation condicional (assim, VS-> NUnit):

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

O plugin TestDriven.Net é legal e não é muito caro … Com apenas o VS2008 simples você precisa encontrar o teste da sua class de teste ou lista de teste. Com TestDriven.Net você pode executar seu teste diretamente da class que você está testando. Afinal, o teste unitário deve ser de fácil manutenção e próximo ao desenvolvedor.

Benefícios / alterações do Framework de Testes Unitários do VS2008

  1. A versão 2008 agora está disponível em edições profissionais (antes de requerer versões caras do VS, isto é apenas para testes unitários de desenvolvedores) que deixaram muitos desenvolvedores com a única opção de frameworks de testes abertos / externos.
  2. Construído em API suportado 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 (não possui framework Mock, mas este é um ótimo ponto de partida para muitos programadores)
  5. Suporte a longo prazo concedido (ainda me lembro do que aconteceu com nDoc, não quero me comprometer com uma estrutura de teste que pode não ser suportada em 5 anos, mas ainda considero nUnit uma ótima estrutura).
  6. Se estiver usando o servidor da equipe como seu back-end, você poderá criar itens de trabalho ou bugs com os dados de teste com falha de maneira simples.

Eu tenho usado o NUnit por 2 anos. Tudo está bem, mas eu tenho que dizer que o sistema de Unidades no VS é muito bom porque está dentro do Gui e pode mais facilmente testar para funções privadas sem ter que mexer. Além disso, os Testes Unitários do VS permitem cobrir e outras coisas que o NUnit sozinho não pode fazer.

Um pequeno incômodo da estrutura de testes do Visual Studio é que ele criará muitos arquivos de execução de teste que tendem a confundir o diretório do projeto – embora isso não seja tão grande coisa.

Além disso, se você não tiver um plug-in como o TestDriven.NET, não será possível depurar seus testes unitários NUnit (ou MbUnit, xUnit, etc.) no ambiente do Visual Studio, como é possível com a estrutura de testes do Microsoft VS, incorporada.

Um pouco fora do tópico, mas se você usar o 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 a debugging 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

O XUnit é outra possibilidade para um projeto greenfield. Talvez tenha uma syntax mais intuitiva, mas não é realmente compatível com os outros frameworks.

http://www.codeplex.com/xunit

Minha principal vantagem com os testes unitários do VS sobre o NUnit é que a criação do teste do VS tende a injetar um monte de código gerado para o access de membros privados.

Alguns podem querer testar seus methods privados, alguns podem não, esse é um tópico diferente.

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

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

No MS Test, há 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. Em nUnit, o código que faz o teste apenas domina os atributos, como deveria fazer.

Além disso, no nUnit, você só precisa clicar nos testes que deseja executar (apenas um – todos os testes cobrindo uma class? Uma assembly? A solução?). Um clique. E a janela é clara e grande. Você obtém luzes verdes e vermelhas claras. Você realmente sabe o que acontece de uma só vez.

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

Mas posso estar errado, claro – acabei de ler cerca de 21 posts sobre “Como fazer TDD simples usando o VSTS”. Eu deveria ter lido mais, você está certo.

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

By the way, eu geralmente amo produtos da Microsoft. 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 é uma droga, na verdade.

Muito bem sucedida. Sylvain.

Eu tenho mensagens que “estrutura de arquivos NUnit é mais rica do que VSTest” … Claro que se você preferir a estrutura de arquivos NUnit, você pode usar essa solução para o outro lado, como este (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 … 🙂 Esta usando aqui é apenas um alias para o compilador.

Primeiro, quero corrigir uma declaração errada: você pode executar msTest fora do visual studio usando a linha de comando. Embora várias ferramentas de CI como o TeamCity tenham melhor suporte para o NUnit (provavelmente mudariam à medida que o msTest se tornasse mais popular). No meu projeto atual nós usamos ambos e a única grande diferença encontrada é que o mstest sempre roda 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 é 32/64 dependente.

Comecei com o MSTest, mas mudei por um motivo simples. MSTest não oferece suporte a inheritance de methods de teste de outros assemblies.

Eu odiava a ideia de escrever o mesmo teste várias vezes. Especialmente em um projeto grande em que os methods de teste podem facilmente ser executados em centenas de testes.

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

.NET Testing Framework Advice e .NET Unit Testing packages? .

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

  1. Compatibilidade TestDriven.Net. Nada melhor do que TestDriven.Net.ReRunWithDebugger ligado a uma combinação de teclado.
  2. O quadro de Gallio. Gallio é um corredor de testes como nUnits. A única diferença é que não importa se você escreveu seus testes em nUnit, msTest, xUnit ou mbUnit. Todos eles saem correndo.
  3. Compatibilidade com nUnit. Todos os resources no nUnit são suportados pelo mbUnit. Eu acho que você nem precisa mudar seus atributos (terá que verificar isso), apenas sua referência e usos.
  4. Coleção confirma. mbUnit tem mais casos de Assert, incluindo a class CollectionAssert. Basicamente, você não precisa mais escrever seus próprios testes para ver se duas collections 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á no mbUnit.

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

Tanto quanto eu sei, há quatro estruturas disponíveis para testes unitários com o .NET atualmente

  • NUnit
  • MbUnit
  • MSTest
  • xUnit

A NUnit sempre esteve na frente, mas a lacuna foi fechada no último ano. Eu ainda prefiro o NUnit, especialmente quando eles adicionaram uma interface fluente um tempo atrás, o que torna os testes muito legíveis.

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

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

MSTest é essencialmente NUnit ligeiramente reformulado, com alguns novos resources (como setup e desassembly de assembly, não apenas em fixture e test level), e faltando alguns dos melhores bits (como a nova syntax de restrição 2.4). O NUnit é mais maduro e há mais suporte para ele de outros fornecedores; e, claro, uma vez que sempre foi gratuito (enquanto o MSTest só entrou na versão Professional de 2008, antes era SKUs mais caros), a maioria dos projetos do ALT.NET o usam.

Dito isto, existem algumas empresas que são incrivelmente relutantes em usar algo que não tem o label da Microsoft, e especialmente o código OSS. Então, ter uma estrutura de teste oficial de MS pode ser a motivação que essas empresas precisam para fazer o teste; e vamos ser honestos, é o teste que importa, não a ferramenta que você usa (e usando o código de Tuomas Hietanen acima, você pode quase fazer com que seu framework de teste seja intercambiável).

Com o lançamento no .NET 4.0 do sistema Code Contracts e a disponibilidade de um verificador estático , você precisaria teoricamente escrever menos casos de teste e uma ferramenta como o Pex ajudará a identificar esses casos. Relacionando isso com a discussão em questão, se você precisa fazer menos com seus testes de unidade porque seus contratos estão cobrindo o seu limite, então por que não ir em frente e usar as partes integradas, já que essa é uma dependência a menos para gerenciar. Hoje em dia, sou toda sobre 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 o framework de teste do MS, mas por enquanto estou com o NUnit. Os problemas com MS são geralmente (para mim)

  • Arquivo “testes” compartilhado (sem sentido) que deve ser mantido
  • Listas de testes causam conflitos com vários desenvolvedores / VCSs
  • Interface de usuário integrada deficiente – configuração confusa, seleção de teste onerosa
  • Nenhum bom corredor externo

Advertências – Se eu estivesse testando um site aspx, eu definitivamente usaria o MS – Se eu estivesse desenvolvendo sozinho, também o MS estaria bem – Se eu tivesse habilidade limitada e não pudesse configurar o NUnit 🙂

Acho muito mais fácil apenas escrever meus testes e ativar o NUnitGUI ou um dos outros front ends (testDriven está muito longe de ser muito caro). Configurar a debugging com a versão de linha de comando também é bem fácil.