NUnit x MbUnit x MSTest x xUnit.net [fechado]

Existem muitas estruturas pouco testadas disponíveis para o .NET. Encontrei essa pequena comparação de recursos: http://xunit.github.io/docs/comparisons.html

Agora devo escolher o melhor para nós. Mas como? Isso importa? Qual é a prova mais futura e tem um momento decente por trás disso? Devo me preocupar com os recursos? Enquanto o xUnit parece ser o mais moderno e projetado especificamente para o .NET, o NUnit novamente parece ser o amplamente aceito. O MSTest novamente já está integrado ao Visual Studio ...

Sei que esse é um tópico antigo, mas pensei em postar um voto no xUnit.NET . Enquanto a maioria das outras estruturas de teste mencionadas é praticamente a mesma, o xUnit.NET adotou uma abordagem bastante única, moderna e flexível ao teste de unidade. Ele muda a terminologia, para que você não defina TestFixtures e Tests ... você especifica Facts and Theories sobre seu código, o que se integra melhor ao conceito do que é um teste na perspectiva de TDD / BDD.

O xUnit.NET também é EXTREMAMENTE extensível. Suas classes de atributo FactAttribute e TraitAttribute não são seladas e fornecem métodos básicos substituíveis que oferecem muito controle sobre como os métodos que esses atributos decoram devem ser executados. Embora o xUnit.NET em sua forma padrão permita escrever classes de teste semelhantes aos equipamentos de teste NUnit com seus métodos de teste, você não está confinado a essa forma de teste de unidade. Você é livre para estender a estrutura para oferecer suporte às especificações de preocupação / contexto / observação no estilo BDD, conforme mostrado aqui .

O xUnit.NET também suporta testes de estilo de ajuste diretamente prontos para uso com seu atributo Teoria e atributos de dados correspondentes. Os dados de entrada de ajuste podem ser carregados do Excel, banco de dados ou até mesmo uma fonte de dados personalizada, como um documento do Word (estendendo o atributo de dados base.) Isso permite que você capitalize em uma única plataforma de teste para testes de unidade e testes de integração, que pode ser enorme na redução das dependências do produto e do treinamento necessário.

Outras abordagens para teste também podem ser implementadas com o xUnit.NET ... as possibilidades são bastante ilimitadas. Combinados com outra estrutura de zombaria muito avançada, o Moq , os dois criam uma plataforma muito flexível, extensível e poderosa para implementar testes automatizados.

O NUnit é provavelmente o mais suportado pelas ferramentas de terceiros. Também existe há mais tempo que os outros três.

Pessoalmente, não me importo muito com estruturas de teste de unidade, as bibliotecas de zombaria são muito mais importantes (e prendem você a muito mais). Basta escolher um e ficar com ele.

Eu não iria com o MSTest. Embora seja provavelmente a prova mais futura das estruturas da Microsoft, não é a solução mais flexível. Não funcionará sozinho sem alguns hacks. Portanto, é difícil executá-lo em um servidor de compilação que não seja o TFS sem instalar o Visual Studio. O executor de teste do visual studio é realmente mais lento que o Testdriven.Net + qualquer uma das outras estruturas. E como os lançamentos dessa estrutura estão vinculados aos lançamentos do Visual Studio, há menos atualizações e, se você precisar trabalhar com um VS mais antigo, estará vinculado a um MSTest mais antigo.

Eu não acho que importa muito qual das outras estruturas você usa. É realmente fácil mudar de um para outro.

Eu pessoalmente uso o XUnit.Net ou NUnit, dependendo da preferência de meus colegas de trabalho. NUnit é o mais padrão. XUnit.Net é a estrutura mais enxuta.

Considere complementar, e não substituir, o MSTest por outra estrutura de teste. Você pode manter a integração do Visual Studio MSTest enquanto obtém os benefícios de uma estrutura de teste mais completa.

Por exemplo, eu uso o xUnit com o MSTest. Adicione uma referência ao assembly xUnit.dll e faça algo assim. Surpreendentemente, ele simplesmente funciona!

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = Xunit.Assert;  // <-- Aliasing the Xunit namespace is key

namespace TestSample
{
    [TestClass]
    public class XunitTestIntegrationSample
    {
        [TestMethod]
        public void TrueTest()
        {
            Assert.True(true);  // <-- this is the Xunit.Assert class
        }

        [TestMethod]
        public void FalseTest()
        {
            Assert.False(true);
        }
    }
}

A unidade não funciona bem com projetos de modo misto em C ++, então tive que descartá-la

Não é grande coisa em pequena escala / pessoal, mas pode se tornar um grande negócio rapidamente em uma escala maior. Meu empregador é uma grande loja da Microsoft, mas não pode / não pode comprar o Team System / TFS por vários motivos. Atualmente, usamos o Subversion + Orcas + MBUnit + TestDriven.NET e funciona bem, mas obter o TD.NET foi um grande aborrecimento. A sensibilidade da versão do MBUnit + TestDriven.NET também é um grande aborrecimento, e ter uma coisa comercial adicional (TD.NET) para revisão legal e compras para manipular e gerenciar, não é trivial. Minha empresa, como muitas empresas, é gorda e satisfeita com o modelo de assinatura do MSDN, e não está acostumada a lidar com compras únicas para centenas de desenvolvedores. Em outras palavras, a oferta de MS totalmente integrada, embora definitivamente nem sempre seja a melhor opção, é um valor agregado significativo na minha opinião.

Acho que continuaremos com nossa etapa atual, porque ela funciona e já superamos a questão organizacional, mas com certeza desejo que a MS tenha uma oferta atraente nesse espaço para que possamos consolidar e simplificar um pouco a nossa pilha de desenvolvimento.

Não é grande coisa, é muito fácil alternar entre eles. O MSTest sendo integrado também não é grande coisa, basta pegar o testdriven.net.

Como a pessoa anterior disse, escolha uma estrutura de zombaria, o meu favorito no momento é o Moq.