Nunit vs. Mbunit vs. Mstest vs. Xunit.net [폐쇄

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

문제

.NET에는 많은 단위 테스트 프레임 워크가 있습니다. 이 작은 기능 비교를 찾았습니다. http://xunit.github.io/docs/comparisons.html

이제 나는 우리에게 가장 좋은 것을 선택해야합니다. 하지만 어떻게? 그게 그렇게 중요한 건가? 어느 것이 가장 미래의 증거이며 그 뒤에 괜찮은 추진력이 있습니까? 기능에 관심을 가져야합니까? Xunit은 가장 현대적이고 .NET을 위해 특별히 설계된 것처럼 보이지만 Nunit은 다시 널리 받아 들여지는 것 같습니다. MSTEST는 다시 이미 Visual Studio에 통합되었습니다 ...

도움이 되었습니까?

해결책

나는 이것이 오래된 스레드라는 것을 알고 있지만, 나는 투표를 게시 할 것이라고 생각했다. xunit.net. 언급 된 다른 테스트 프레임 워크의 대부분은 거의 동일하지만 xunit.net은 단위 테스트에 매우 독특하고 현대적이며 유연한 접근 방식을 취했습니다. 용어가 변경되므로 더 이상 TestFixtures 및 테스트를 정의하지 않습니다. 코드에 대한 사실과 이론을 지정하여 TDD/BDD 관점에서 테스트의 개념과 더 잘 통합됩니다.

xunit.net도 매우 확장 가능합니다. 사실 및 Traitattribute 속성 클래스는 밀봉되지 않았으며, 해당 속성이 장식 해야하는 방법을 많이 제어 할 수있는 우발적 인 기본 방법을 제공합니다. 기본 형식의 xunit.net을 사용하면 테스트 방법으로 Nunit 테스트 비품과 유사한 테스트 클래스를 작성할 수 있지만 이러한 형태의 단위 테스트에 전혀 국한되지 않습니다. 묘사 된대로 BDD 스타일의 관심사/컨텍스트/관찰 사양을 지원하기 위해 프레임 워크를 자유롭게 확장 할 수 있습니다. 여기.

XUNIT.NET은 또한 이론 속성과 해당 데이터 속성으로 상자에서 직접 맞춤형 테스트를 지원합니다. 적합 입력 데이터는 Excel, 데이터베이스 또는 Word 문서 (기본 데이터 속성을 확장하여)와 같은 사용자 정의 데이터 소스에서로드 될 수 있습니다.이를 통해 단위 테스트 및 통합 테스트를위한 단일 테스트 플랫폼을 활용할 수 있습니다. 제품 의존성을 줄이고 필요한 교육을 줄일 수 있습니다.

xunit.net을 사용하여 테스트에 대한 다른 접근법도 구현 될 수 있습니다. 가능성은 꽤 무한합니다. 또 다른 매우 미래 지향적 인 조롱 프레임 워크와 결합하여 모크, 두 사람은 자동 테스트를 구현하기위한 매우 유연하고 확장 가능하며 강력한 플랫폼을 만듭니다.

다른 팁

Nunit은 아마도 타사 도구에서 가장 지원하는 것일 것입니다. 또한 다른 세 가지보다 더 길었습니다.

나는 개인적으로 단위 테스트 프레임 워크에 대해별로 신경 쓰지 않으며, 조롱 라이브러리는 훨씬 더 중요합니다. 그냥 골라서 고수하십시오.

나는 Mstest와 함께 가지 않을 것입니다. 아마도 Microsoft 뒤에있는 프레임 워크의 가장 미래의 증거 일 것입니다. 해킹 없이는 혼자서 실행되지 않습니다. 따라서 Visual Studio를 설치하지 않고 TFS 이외의 빌드 서버에서 실행하는 것은 어렵습니다. Visual Studio Test-Runner는 실제로 TestDriven.NET + 다른 프레임 워크보다 느리게 진행됩니다. 그리고이 프레임 워크의 릴리스는 비주얼 스튜디오의 릴리스와 관련이 있기 때문에 업데이트가 적으며 구형 대와 함께 작업 해야하는 경우 이전 MSTEST와 묶여 있습니다.

나는 그것이 당신이 사용하는 다른 프레임 워크 중 어느 것이 중요하다고 생각하지 않습니다. 서로로 전환하는 것은 정말 쉽습니다.

나는 동료의 선호에 따라 개인적으로 xunit.net 또는 nunit을 사용합니다. Nunit이 가장 표준입니다. xunit.net은 가장 희박한 프레임 워크입니다.

MSTEST를 다른 테스트 프레임 워크로 보충하고 교체하지 않는 것을 고려하십시오. 보다 완전한 기능을 갖춘 테스트 프레임 워크의 이점을 얻는 동시에 Visual Studio Mstest 통합을 유지할 수 있습니다.

예를 들어, 나는 mstest와 함께 Xunit을 사용합니다. xunit.dll 어셈블리에 대한 참조를 추가하고 이와 같은 일을하십시오. 놀랍게도, 그것은 단지 작동합니다!

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);
        }
    }
}

소규모/개인 규모는 큰 문제는 아니지만 더 큰 규모로 빠르게 더 큰 거래가 될 수 있습니다. 저의 고용주는 큰 Microsoft 상점이지만 여러 가지 이유로 팀 시스템/TFS를 구입할 수 없습니다. 우리는 현재 Subversion + Orcas + Mbunit + TestDriven.net을 사용하고 있으며 잘 작동하지만 Td.net을 얻는 것은 큰 번거 로웠습니다. MBUNIT + TESTDRIVEN.NET의 버전 민감도는 또한 큰 번거 로움이며, 법적으로 검토하고 처리하고 관리하기위한 합법적 인 상업적인 것 (TD.NET)을 보유하고있는 것은 사소한 일이 아닙니다. 많은 회사와 마찬가지로 우리 회사는 MSDN 구독 모델에 뚱뚱하고 만족하며 수백 명의 개발자를위한 조달을 처리하는 데 사용되지 않습니다. 다시 말해서, 완전히 통합 된 MS 제안은 항상 가장 좋은 것은 아니지만 제 생각에는 중요한 부가 가치입니다.

나는 그것이 작동하고 우리가 이미 작동하고 우리는 이미 조직적으로 혹을 극복했기 때문에 우리의 현재 단계를 유지할 것이라고 생각하지만, MS 가이 공간에 설득력있는 제안을했기 때문에 우리는 Dev 스택을 약간 통합하고 단순화 할 수 있기를 바랍니다.

Nunit은 C ++의 Mixed-Mode 프로젝트에서 잘 작동하지 않으므로 떨어 뜨려야했습니다.

큰 문제가 아니며, 그들 사이를 전환하는 것은 매우 쉽습니다. MSTEST가 통합되는 것도 큰 문제가 아닙니다.

이전 사람이 조롱 프레임 워크를 선택했다고 말했듯이, 지금 내가 가장 좋아하는 것은 Moq입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top