NUnit 대 MbUnit 대 MSTest 대 xUnit.net [닫힘]


390

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

이제 우리에게 가장 좋은 것을 선택해야합니다. 그러나 어떻게? 그게 그렇게 중요한 건가? 어느 것이 가장 미래의 증거이며 그 뒤에 적절한 추진력이 있습니까? 기능에 관심을 가져야합니까? xUnit은 가장 현대적이고 .NET 용으로 특별히 설계된 것처럼 보이지만 NUnit은 다시 널리 인정되는 것으로 보입니다. MSTest는 이미 Visual Studio에 통합되었습니다 ...


11
그 비교표는 오래되었습니다. 예를 들어 NUnit에는 Assert.Throws 등이 있으며 Assertions 테이블의 모든 항목은 이전 API입니다. 새로운 Assert.That (..., Is ....) 유창한 구문이 훨씬 더 좋으며 지금까지도 좋았습니다.
Jim Cooper

11
최신 테이블이 있습니까?
bitbonk

1
2013 년 후반, xUnit.net => NUnit에서 옮겨졌습니다. 또한 xUnit.NET (프로젝트)! = xUnit (NUnit이 구성원 인 범주)
DeepSpace101

3
@SID가 xUnity.net => NUnit에서 이동 한 이유는 무엇입니까?
Alexander Logger

2
비슷한 문제는 2014 년에 질문 NUnit과 대 비주얼 스튜디오 2013 MSTEST
마이클 Freidgeim

답변:


197

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

xUnit.NET은 매우 확장 가능합니다. FactAttribute 및 TraitAttribute 속성 클래스는 봉인되지 않으며 무시할 수있는 기본 메소드를 제공하여 해당 속성이 장식되는 메소드의 실행 방법을 제어 할 수 있습니다. 기본 형식의 xUnit.NET을 사용하면 테스트 방법으로 NUnit 테스트 픽스처와 유사한 테스트 클래스를 작성할 수 있지만이 형식 테스트에 전혀 국한되지는 않습니다. 여기에 설명 된대로 BDD 스타일 문제 / 컨텍스트 / 관찰 사양을 지원하도록 프레임 워크를 자유롭게 확장 할 수 있습니다 .

또한 xUnit.NET은 이론 속성 및 해당 데이터 속성을 사용하여 상자에서 바로 맞춤 스타일 테스트를 지원합니다. 맞춤 입력 데이터는 기본 데이터 속성을 확장하여 Excel 문서, 데이터베이스 또는 Word 문서와 같은 사용자 지정 데이터 소스에서로드 할 수 있습니다. 이렇게하면 단위 테스트 및 통합 테스트 모두에 대해 단일 테스트 플랫폼을 활용할 수 있습니다. 제품 의존성과 교육을 줄이는 데 큰 도움이 될 수 있습니다.

테스트에 대한 다른 접근 방식은 xUnit.NET으로도 구현할 수 있습니다. 가능성은 무한합니다. 미래 지향적 인 모의 프레임 워크 인 Moq 와 결합 된 이 둘은 자동화 된 테스트를 구현할 수있는 매우 유연하고 확장 가능하며 강력한 플랫폼을 만듭니다.


35
이것은 1 년 전 사실이지만 NUnit은 문제의 대부분을 추가했습니다. NUnit에서는 테스트를 어느 쪽이든 작성할 수 있습니다.
Mark Levison

8
사용 가능한 속성에 대한 것이 아니라 사용 방법에 대해 설명합니다. xUnit.NET은 처음부터 특정 테스트 방법에 종속되지 않은 매우 유연하고 확장 가능한 프레임 워크로 설계되었으며 최신 기능을 얻기 위해 정기적으로 코어 프레임 워크를 업데이트하지 않아도됩니다.
jrista

9
1. 속성에서 이름이 눈에 띄게 다른 것은 중요하지 않습니다. 2. NUnit은 확장 가능했으며 계속 확장 가능합니다. 3. 테스트를위한 데이터 행 매개 변수는 nunit에서 지원됩니다. 얼마 전 그들은 확장 프로그램에서 지원되었습니다 :) 4. Moq와 결합 된 Nunit도 같은 것을 만듭니다. 5. BDD의 경우 많은 단위 테스트 프레임 워크와 쉽게 통합되는 specflow라고합니다.
graffic

8
나는 xUnit의 소리를 좋아하지만, zilch documentation이 있습니다 :(
Panic Panic

10
xUnit에는 문서가 없습니다! 예 : Trait실제로 무엇을하는지 또는 단일 부모 테스트 내에서 다른 테스트를 그룹화 할 수 있는지 (예 : 모두 teststestfixture) 찾아보십시오. nUnit은 xUnit의 평면 테스트보기 대신 훌륭한 계층보기를 만듭니다. 게다가 명명법은 의미가 없습니다-사실과 이론? 현실적으로! 그것들을 테스트와 데이터라고합니다.
DeepSpace101

134

NUnit은 타사 도구에서 가장 많이 지원됩니다. 또한 다른 세 개보다 오래되었습니다.

나는 개인적으로 단위 테스트 프레임 워크에 관심이 없으며 모의 라이브러리는 훨씬 더 중요합니다 (더 많은 것을 잠그십시오). 하나만 골라 붙이십시오.


3
최고의 모의 도서관 선택은 무엇입니까?
2009 년

31
나는 Moq를 좋아하고 RhinoMocks도 좋습니다.
Alexander Kojevnikov 2012 년

5
Pex와 Moles를 확인하는 것도 가치가 있습니다. Moles 부분은 특히 조롱에 유용합니다.
Charles Prakash Dasari

4
FakeItEasy가 포함 된 MSPec ... 테스트 사례를 더 읽기 쉽게하기
Robie

5
NSubstitute 및 AutoFixture가 포함 된 MSpec을 선택했습니다.
Daniel Hilgarth

108

나는 MSTest와 함께 가지 않을 것이다. 아마도 Microsoft와의 프레임 워크에 대한 가장 미래의 증거 일지 모르지만 가장 유연한 솔루션은 아닙니다. 해킹 없이는 단독으로 실행되지 않습니다. 따라서 Visual Studio를 설치하지 않고 TFS 이외의 빌드 서버에서 실행하는 것은 어렵습니다. Visual Studio 테스트 러너는 실제로 Testdriven.Net + 다른 프레임 워크보다 느립니다. 그리고이 프레임 워크의 릴리스는 Visual Studio 릴리스와 연결되어 있기 때문에 업데이트가 적으며 이전 VS로 작업해야하는 경우 이전 MSTest에 연결됩니다.

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

동료의 선호도에 따라 XUnit.Net 또는 NUnit을 개인적으로 사용합니다. NUnit이 가장 표준입니다. XUnit.Net은 가장 간단한 프레임 워크입니다.


36
나는 똑같은 결론에 차고 비명을 질렀다. Visual Studio와의 통합으로 인해 MSTest를 사용하고 싶었지만 그 단점도 있습니다. Microsoft 이외의 빌드 서버에서 테스트를 실행해야하며 Visual Studio를 설치하는 방법은 없습니다. 마이크로 소프트가 훌륭한 툴을 만들어 거의 달성 할 수 없게 만드는 것은 부끄러운 일이다.
Tim Long

11
MSTest라는 끔찍함을 불러 일으키기 위해 +1. 마지막 날, MSTest가 아닌 한 어떤 단위 테스트 프레임 워크를 사용하든 상관 없습니다.
Mike Mooney

21

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

이 기술은 NUnit, MBUnit 또는 다른 답변에 언급 된 다른 테스트 프레임 워크에서도 작동 할 수 있지만 시도하지는 않았습니다.
매트 크라우치

1
이 접근 방식으로 MSTest와 함께 작동하기 위해 매개 변수화 된 테스트를받을 수 있다고 생각합니까?
DevDave

@DevDave No. 그의 예제에서 그는 다른 어셈블리의 클래스를 사용했습니다. 파라미터 화 된 테스트를 원한다면 MSTest를 확장하기 위해 특별히 구축 된 다른 테스트 프레임 워크가 필요합니다.
zoran404 2016 년

3
Suprisingly, it just works!다른 어셈블리에서 정적 함수를 호출했습니다. 왜 작동하는지 놀랐습니까? 또한 당신이 그것을 위해 특별히 만든 어셈블리를 사용하지 않는 주장이 필요하다면?
zoran404

9

Nunit은 C ++의 혼합 모드 프로젝트와 잘 작동하지 않으므로 삭제해야했습니다.


3
나는이 답변을 자랑스럽게 생각하지 않지만 해당 프로젝트에 대한 단위 테스트를 중단했습니다. 오류의 런타임 감지를 위해 많은 검증 절차를 작성했습니다
Eric

2
혼합 모드에서 NUnit을 사용하고 싶었지만 적절하지 않은 것으로 나타났습니다. 결국 훌륭한 C ++ 단위 테스트 프레임 워크이며 설정하기 쉬운 googletest를 방문했습니다.
chillitom

8

소규모 / 개인 규모로는 큰 문제가 아니지만 더 큰 규모에서는 빠르게 큰 거래가 될 수 있습니다. 내 고용주는 대규모 Microsoft 상점이지만 여러 가지 이유로 Team System / TFS에 구매하거나 구매할 수 없습니다. 우리는 현재 Subversion + Orcas + MBUnit + TestDriven.NET을 사용하고 있지만 잘 작동하지만 TD.NET을 얻는 것은 번거로운 일이었습니다. MBUnit + TestDriven.NET의 버전 민감도는 큰 번거 로움이며 법적으로 검토하고 조달하여 처리 및 관리 할 수있는 추가적인 상업적인 것 (TD.NET)을 갖는 것이 결코 쉬운 일이 아닙니다. 많은 회사와 마찬가지로 제 회사는 MSDN Subscription 모델에 만족하고 있으며 수백 명의 개발자를 위해 일회성 조달을 처리하는 데 사용되지 않습니다. 다시 말해, 완전히 통합 된 MS 제품은 항상 최고라는 것은 아니지만 제 생각에는 중요한 부가 가치입니다.

나는 우리가 현재 단계를 계속 유지할 것이라고 생각합니다. 왜냐하면 우리는 이미 조직적으로 혹을 극복했습니다. 그러나 MS 가이 공간에서 매력적인 제품을 제공하여 우리의 스택을 통합하고 단순화 할 수 있기를 바랍니다.


2
ReSharper는이 공간에서 매력적인 제품을 제공합니다!
다람쥐

7
당신의 대답은 호기심이 많고 자기 모순적인 것 같습니다. 당신은 큰 Microsoft 상점이라고 말하지만 TFS를 사용하지 않으며 (이것은 수직 통합의 이점이 없으면 수직 통합의 이점을 얻지 못할 것입니다) MSDN 구독 모델을 사용하지만 -MS 접근. 나는 정직하기 위해 길을 잃었다. 불행히도 오래된 답변입니다.
nicodemus13

6

큰 문제는 아니며 서로 전환하기가 쉽습니다. 통합되는 MSTest도 큰 문제가되지 않으며 testdriven.net 만 가져 오십시오.

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.