단위 테스트를위한 NUnit 대 Visual Studio 2008의 테스트 프로젝트? [닫은]

직장에서 새 프로젝트를 시작하고 단위 테스트를 시작하려고합니다. 우리는 VS 2008, C # 및 ASP.NET MVC를 사용할 것입니다. VS2008이 가지고있는 NUnit 또는 내장 테스트 프로젝트를 사용하려고하지만 다른 제안을 연구 할 수 있습니다. 한 시스템이 다른 시스템보다 낫거나 다른 시스템보다 사용 / 이해하기 쉬울까요? 앞으로이 개발 노력을위한 "모범 사례"로이 프로젝트를 시작하려고합니다.

도움과 제안에 감사드립니다 !!

Daok 는 VS2008 테스트 프로젝트의 모든 프로를 지명했습니다. 여기 NUnit의 프로가 있습니다.

• NUnit에는 조롱 프레임 워크가 있습니다.
• NUnit은 IDE 외부에서 실행될 수 있습니다. CC.Net과 같은 비 MS 빌드 서버에서 테스트를 실행하려는 경우 유용 할 수 있습니다.
• NUnit에는 Visual Studio보다 더 많은 버전이 있습니다. 새 버전이 나올 때까지 기다릴 필요가 없으며 새 기능을 사용하기 위해 새 버전의 IDE를 설치할 필요가 없습니다.
• 행 테스트 등과 같은 NUnit 용으로 개발 된 확장이 있습니다.
• 어떤 이유로 Visual Studio 테스트를 시작하는 데 시간이 오래 걸립니다. 이것은 2008 년에 더 좋지만 여전히 내 취향에 비해 너무 느립니다. 무언가를 깨지 않았는지 확인하기 위해 빠르게 테스트를 실행하면 시간이 오래 걸릴 수 있습니다. IDE에서 테스트를 실행하기 위해 Testdriven.Net과 같은 NUnit이 실제로 훨씬 빠릅니다. 특히 단일 테스트를 실행할 때.
  Kjetil Klaussen에 따르면 Visual Studio testrunner로 인해 TestDriven.Net에서 MSTest 테스트를 실행하면 MSTest 성능이 NUnit과 비슷해집니다.

단위 테스트 프레임 워크는 실제로 별 문제가되지 않습니다. 테스트 클래스를 별도의 프로젝트 파일과 조건부 컴파일 (예 : VS-> NUnit)로 변환 할 수 있기 때문입니다.

 #if! NUNIT
  Microsoft.VisualStudio.TestTools.UnitTesting 사용;
 #그밖에
  NUnit.Framework 사용;
  Using TestClass = NUnit.Framework.TestFixtureAttribute;
  TestMethod 사용 = NUnit.Framework.TestAttribute;
  TestInitialize 사용 = NUnit.Framework.SetUpAttribute;
  TestCleanup 사용 = NUnit.Framework.TearDownAttribute;
  TestContext 사용 = System.String;
  Using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #endif

TestDriven.Net 플러그인은 훌륭하고 비싸지 않습니다 ... 일반 VS2008 만 있으면 테스트 클래스 또는 테스트 목록에서 테스트를 찾아야합니다. TestDriven.Net을 사용하면 테스트중인 클래스에서 직접 테스트를 실행할 수 있습니다. 결국, 단위 테스트는 유지 관리하기 쉽고 개발자와 가까운 곳에 있어야합니다.

VS2008 내장 단위 테스트 프레임 워크의 장점 / 변경

1. 2008 버전은 현재 전문가 용 버전으로 구입할 수 있습니다 (고가의 VS 버전이 필요하기 전에 개발자 단위 테스트 용임). 많은 개발자가 개방 / 외부 테스트 프레임 워크를 선택할 수있게되었습니다.
2. 단일 회사에서 지원하는 API 내장.
3. 동일한 도구를 사용하여 테스트를 실행하고 작성하십시오 (MSTest도 명령 행을 사용하여 실행할 수 있음).
4. 단순한 디자인 (Mock 프레임 워크는 없었지만 이것은 많은 프로그래머에게 훌륭한 출발점입니다)
5. 장기 지원이 부여되었습니다 (nDoc에 발생한 일을 여전히 기억합니다. 5 년 동안 지원되지 않을 수있는 테스트 프레임 워크에 전념하고 싶지 않지만 nUnit을 훌륭한 프레임 워크로 간주합니다.)
6. 팀 기반 서버를 백엔드로 사용하는 경우 실패한 테스트 데이터로 간단한 방법으로 작업 항목 또는 버그를 작성할 수 있습니다.

나는 2 년간 NUnit을 사용해왔다. VS의 Unit 시스템은 Gui 내부에 있으며 더 이상 혼란없이 개인 기능을 테스트 할 수 있기 때문에 꽤 좋습니다. 또한 VS의 Unit Testing을 사용하면 NUnit만으로는 할 수없는 것들과 다른 것들을 다룰 수 있습니다.

Visual Studio의 테스트 프레임 워크에 대한 약간의 불편 함은 프로젝트 디렉토리를 혼란스럽게 만드는 많은 테스트 실행 파일을 생성한다는 것입니다.

또한 TestDriven.NET과 같은 플러그인이없는 경우 내장 된 Microsoft VS 테스트 프레임 워크에서와 같이 Visual Studio 환경 내에서 NUnit (또는 MbUnit, xUnit 등) 단위 테스트를 디버그 할 수 없습니다.

약간의 주제를 벗어난 주제이지만 NUnit을 사용하는 경우 ReSharper를 사용하는 것이 좋습니다. UI에 몇 가지 단추를 추가하여 IDE 내에서 테스트를 훨씬 쉽게 실행하고 디버그 할 수 있습니다.

이 리뷰는 약간 오래된 내용이지만 자세한 내용은 다음과 같습니다.

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

XUnit은 그린 필드 프로젝트의 또 다른 가능성입니다. 아마도 더 직관적 인 구문이 있지만 다른 프레임 워크와 실제로 호환되지는 않습니다.

http://www.codeplex.com/xunit

NUnit에 대한 VS 단위 테스트의 나의 주요 소는 VS 테스트 생성이 개인 멤버 액세스를 위해 생성 된 코드를 많이 주입하는 경향이 있다는 것입니다.

일부는 자신의 개인 메소드를 테스트하고 싶을 수도 있고 그렇지 않을 수도 있습니다.

내가 걱정하는 것은 단위 테스트를 작성할 때 테스트가 무엇인지 정확히 테스트하는 방법을 알기 위해 극도로 제어되어야합니다. 자동 생성 코드가 있으면 그 소유권 중 일부를 잃어 버립니다.

나는 둘 다를 사용하여 약간의 TDD를 수행했으며 (어쩌면 조금 바보 스럽다) nUnit은 나에게 훨씬 빠르고 간단하게 사용되는 것으로 보인다. 그리고 내가 많이 말할 때, 나는 많은 것을 의미합니다.

MS Test에는 너무 많은 속성이 있습니다. 실제 테스트를 수행하는 코드는 여기 저기 읽을 수있는 작은 줄입니다. 큰 혼란. nUnit에서 테스트를 수행하는 코드는 속성을 지배합니다.

또한 nUnit에서는 실행하려는 테스트 (단 하나, 클래스를 다루는 모든 테스트, 어셈블리, 솔루션) 만 클릭하면됩니다. 한 번의 클릭. 그리고 창은 명확하고 큽니다. 초록색과 빨간색 표시등이 선명하게 나타납니다. 당신은 정말로 한 눈에 무슨 일이 일어나는지 알고 있습니다.

VSTS에서는 테스트 목록이 화면 하단에 걸렸으며 작고보기 흉합니다. 무슨 일이 있었는지 알아야 두 번 봐야합니다. 그리고 당신은 단 하나의 테스트를 실행할 수 없습니다 (글쎄, 나는 아직 찾지 못했습니다!).

그러나 물론 틀릴 ​​수도 있습니다. "VSTS를 사용하여 간단한 TDD를 수행하는 방법"에 대한 약 21 개의 블로그 게시물을 읽었습니다. 더 읽어야했는데, 네 말이 맞아

nUnit의 경우 하나를 읽습니다. 그리고 나는 같은 날 TDDing했다. 재미있게 요

그건 그렇고, 나는 보통 Microsoft 제품을 좋아합니다. Visual Studio는 실제로 개발자가 구매할 수있는 최고의 도구입니다. 그러나 Visual Studio Team System의 TDD 및 작업 항목 관리는 정말 짜증납니다.

모두 제일 좋다. 실뱅.

"NUnit 파일 구조가 VSTest보다 풍부합니다"라는 메시지가 표시됩니다. 물론 NUnit 파일 구조를 선호하는 경우이 솔루션을 다음과 같이 다른 방법으로 사용할 수 있습니다 (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

또는 다른 변환 ... :-) 여기에 사용하는 것은 컴파일러의 별칭입니다.

먼저 잘못된 문장을 수정하고 싶습니다. 명령 줄을 사용하여 Visual Studio 외부에서 msTest를 실행할 수 있습니다. TeamCity와 같은 여러 CI 도구가 NUnit을 더 잘 지원하지만 msTest가 대중화되면 변경 될 수 있습니다. 현재 프로젝트에서 우리는 둘 다를 사용하고 우리가 발견 한 유일한 차이점은 mstest는 항상 32 비트로 실행되는 반면 NUnit은 32 비트 또는 64 비트 테스트로 실행되며 코드는 32/64에 의존하는 네이티브 코드를 사용하는 경우에만 중요합니다.

MSTest로 시작했지만 한 가지 간단한 이유로 전환했습니다. MSTest는 다른 어셈블리의 테스트 메서드 상속을 지원하지 않습니다.

나는 같은 테스트를 여러 번 작성한다는 생각을 싫어했다. 특히 테스트 방법이 100 개의 테스트를 쉽게 실행할 수있는 대규모 프로젝트에서 특히 그렇습니다.

NUnit은 내가 필요한 것을 정확하게 수행합니다. NUnit에서 누락 된 유일한 것은 각 테스트의 빨강 / 녹색 상태 (VSTS와 유사)를 표시 할 수있는 Visual Studio Addin입니다.

.NET Testing Framework Advice 및 .NET Unit Testing 패키지? .

MSTest 또는 nUnit을 고려하고 있다면 mbUnit을 보는 것이 좋습니다. 내 이유는

1. TestDriven.Net 호환성. 키보드 조합에 TestDriven.Net.ReRunWithDebugger가 바인딩 된 비트는 없습니다.
2. Gallio 프레임 워크. Gallio는 nUnits와 같은 테스트 러너입니다. 유일한 차이점은 테스트를 nUnit, msTest, xUnit 또는 mbUnit으로 작성했는지 상관하지 않습니다. 그들은 모두 도망칩니다.
3. nUnit과의 호환성. nUnit의 모든 기능은 mbUnit에서 지원됩니다. 나는 당신이 당신의 속성을 바꿀 필요가 없다고 (그것을 확인해야 할 것입니다), 단지 당신의 참조와 사용.
4. 컬렉션 주장. mbUnit에는 CollectionAssert 클래스를 포함하여 더 많은 Assert 사례가 있습니다. 기본적으로 더 이상 두 컬렉션이 동일한 지 확인하기 위해 자체 테스트를 작성할 필요가 없습니다.
5. 조합 테스트. 두 세트의 데이터를 제공하고 모든 데이터 조합에 대한 테스트를받을 수 있다면 멋지지 않습니까? mbUnit에 있습니다.

원래 [RowTest ....] 기능으로 인해 mbUnit을 선택했는데 한 가지 이유를 찾지 못했습니다. 모든 활성 테스트 스위트를 nUnit에서 옮기고 다시는 돌아 보지 않았습니다. 그 이후로 두 개의 서로 다른 개발 팀을 이점으로 전환했습니다.

내가 아는 한 요즘 .NET으로 단위 테스트를 위해 사용할 수있는 네 가지 프레임 워크가 있습니다.

• N 단위
• MbUnit
• MSTest
• x 단위

NUnit은 항상 앞에 있었지만 작년 쯤에 그 격차는 사라졌습니다. 나는 여전히 NUnit을 선호합니다. 특히 유창한 인터페이스를 잠시 추가하여 테스트를 쉽게 읽을 수있게합니다.

단위 테스트를 시작한 경우 큰 차이가 없을 것입니다. 속도가 빨라지면 어떤 프레임 워크가 가장 적합한 지 판단 할 수있는 더 나은 위치에있게됩니다.

VS 내장 테스트 프레임 워크는 테스트하는 프로젝트의 일부로 테스트를하는 대신 별도의 프로젝트를 만들어야하기 때문에 좋아하지 않습니다.

MSTest는 본질적으로 NUnit이 약간 재 작업되었으며, 몇 가지 새로운 기능 (예 : 조명기 및 테스트 수준이 아닌 어셈블리 설정 및 분해)과 일부 새로운 비트 (예 : 2.4 제약 구문)가 누락되었습니다. NUnit은 더욱 성숙해졌으며 다른 공급 업체로부터 더 많은 지원을 받고 있습니다. 물론 항상 무료이기 때문에 (MSTest는 2008 년 Professional 버전으로 만 비싸기 전에는 더 비싼 SKU를 사용하기 만 했음) 대부분의 ALT.NET 프로젝트에서 사용합니다.

그러나 Microsoft 레이블이없는 제품, 특히 OSS 코드를 사용하는 것을 매우 꺼려하는 회사가 있습니다. 따라서 공식 MS 테스트 프레임 워크를 갖추는 것은 해당 회사가 테스트를 받아야하는 동기 일 수 있습니다. 솔직히 말하면 사용하는 도구가 아니라 중요한 테스트입니다 ( 위 의 Tuomas Hietanen 코드를 사용 하면 테스트 프레임 워크를 거의 교환 할 수 있습니다).

Code Contracts 시스템 의 .NET 4.0 릴리스 와 정적 검사기 의 가용성으로 인해 이론적으로 더 적은 테스트 사례를 작성해야하며 Pex 와 같은 도구 가 이러한 사례를 식별하는 데 도움이됩니다. 계약 내용이 테일을 다루고 있기 때문에 단위 테스트로 더 적은 일을해야한다면, 관리에 대한 의존성이 적기 때문에 내장 된 부분을 사용하는 것이 어떻습니까? 요즘 나는 단순함에 관한 것입니다. :-)

또한보십시오:

• Microsoft Pex – 자동화 된 단위 테스트
• Visual Studio 2010 및 C # 4.0을 사용하여 Pex를 사용한 단위 테스트 생성

나는 MS의 작은 테스트 프레임 워크를 사용하는 것을 선호하지만 지금은 NUnit을 고수하고 있습니다. MS의 문제는 일반적으로 (나에게)

• 공유해야하는 공유 "테스트"파일 (무의미한) 유지
• 테스트 목록은 여러 개발자 / VCS와 충돌을 일으킴
• 불완전한 통합 UI-혼란스러운 설정, 부담스러운 테스트 선택
• 외부 주자 없음

주의 사항-aspx 사이트를 테스트하는 경우 분명히 MS의를 사용 - 나는 솔로 개발한다면, 또한 MS 괜찮을 것 - 나는 기술을 제한 한 경우와 할 수없는 구성 NUnit과 :)

테스트를 작성하고 NUnitGUI 또는 다른 프론트 엔드 중 하나를 실행하는 것이 훨씬 쉽다는 것을 알았습니다 (testDriven은 훨씬 비싸다). 커맨드 라인 버전으로 디버깅을 설정하는 것도 매우 쉽습니다.