Các dự án thử nghiệm của NUnit vs Visual Studio 2008 để thử nghiệm đơn vị? [đóng cửa]

Tôi sẽ bắt đầu một dự án mới trong công việc và muốn tham gia thử nghiệm đơn vị. Chúng tôi sẽ sử dụng VS 2008, C # và công cụ ASP.NET MVC. Tôi đang xem xét sử dụng NUnit hoặc các dự án thử nghiệm tích hợp mà VS2008 có, nhưng tôi sẵn sàng nghiên cứu các đề xuất khác. Là một hệ thống tốt hơn hệ thống kia hoặc có lẽ dễ sử dụng / hiểu hơn hệ thống kia? Tôi đang tìm cách để dự án này được thiết lập như một loại "thực tiễn tốt nhất" cho những nỗ lực phát triển của chúng tôi trong tương lai.

Cảm ơn vì sự giúp đỡ và gợi ý !!

Daok đặt tên cho tất cả các pro của các dự án thử nghiệm VS2008, đây là pro của NUnit.

• NUnit có một khung mô phỏng.
• NUnit có thể được chạy bên ngoài IDE, điều này có thể hữu ích nếu bạn muốn chạy thử nghiệm trên máy chủ không xây dựng MS như CC.Net
• NUnit có nhiều phiên bản sắp ra mắt hơn studio hình ảnh. Bạn không phải đợi hàng năm để có phiên bản mới Và bạn không phải cài đặt phiên bản IDE mới để có các tính năng mới.
• Có các tiện ích mở rộng đang được phát triển cho NUnit như kiểm tra hàng, v.v.
• Các thử nghiệm Visual Studio mất nhiều thời gian để khởi động vì một số lý do. Điều này tốt hơn trong năm 2008 nhưng vẫn quá chậm so với khẩu vị của tôi. Nhanh chóng chạy thử nghiệm để xem nếu bạn không phá vỡ một cái gì đó có thể mất quá nhiều thời gian. NUnit với một cái gì đó như Testdriven.Net để chạy thử nghiệm từ IDE thực sự nhanh hơn nhiều. đặc biệt là khi chạy thử nghiệm đơn.
  Việc kết hợp với Kjetil Klaussen là do trình kiểm tra Visual Studio gây ra, việc chạy các thử nghiệm MSTest trong TestDriven.Net làm cho hiệu suất MSTest tương đương với NUnit.

Khung kiểm thử đơn vị thực sự không quan trọng lắm, bởi vì bạn có thể chuyển đổi các lớp kiểm tra với các tệp dự án riêng biệt và biên dịch có điều kiện (như thế này, VS-> NUnit):

 #if! NUNIT
  sử dụng Microsoft.VisualStudio.TestTools.UnitTesting;
 #else
  sử dụng NUnit.Framework;
  sử dụng TestClass = NUnit.Framework.TestFixtureAttribution;
  sử dụng TestMethod = NUnit.Framework.TestAttribution;
  sử dụng TestInitialize = NUnit.Framework.SetUpAttribution;
  sử dụng TestCleanup = NUnit.Framework.TearDownAttribution;
  sử dụng TestContext = System.String;
  sử dụng DeploymentItem = NUnit.Framework.DescripAttribution;
 #endif

Plugin TestDriven.Net rất đẹp và không quá đắt ... Chỉ với VS2008 đơn giản, bạn phải tìm bài kiểm tra từ lớp kiểm tra hoặc danh sách kiểm tra của mình. Với TestDriven.Net, bạn có thể chạy thử nghiệm trực tiếp từ lớp mà bạn đang kiểm tra. Rốt cuộc, kiểm tra đơn vị phải dễ bảo trì và gần nhà phát triển.

Lợi ích / thay đổi của Khung thử nghiệm đơn vị tích hợp VS2008

1. Phiên bản 2008 hiện đã có phiên bản chuyên nghiệp (trước khi nó yêu cầu các phiên bản đắt tiền của VS, phiên bản này chỉ dành cho thử nghiệm đơn vị nhà phát triển.) Khiến nhiều nhà phát triển chỉ có lựa chọn khung thử nghiệm mở / bên ngoài.
2. API tích hợp được hỗ trợ bởi một công ty duy nhất.
3. Sử dụng các công cụ tương tự để chạy và tạo các bài kiểm tra (bạn có thể chạy chúng bằng dòng lệnh MSTest)
4. Thiết kế đơn giản (không có khung Mock, nhưng đây là điểm khởi đầu tuyệt vời cho nhiều lập trình viên)
5. Hỗ trợ dài hạn được cấp (Tôi vẫn nhớ những gì đã xảy ra với nDoc, tôi không muốn cam kết với một khung thử nghiệm có thể không được hỗ trợ trong 5 năm, nhưng tôi vẫn coi nUnit là một khung tuyệt vời.)
6. Nếu sử dụng máy chủ nền tảng nhóm làm phụ trợ, bạn có thể tạo các mục công việc hoặc lỗi với dữ liệu thử nghiệm thất bại theo cách đơn giản.

Tôi đã sử dụng NUnit được 2 năm. Tất cả đều ổn nhưng tôi phải nói rằng hệ thống Đơn vị trong VS khá đẹp vì nó nằm trong Gui và có thể dễ dàng kiểm tra chức năng riêng tư hơn mà không phải loay hoay. Ngoài ra, Kiểm tra đơn vị của VS cho phép bạn thực hiện các công việc khác và những thứ khác mà NUnit không thể làm được.

Một phiền toái nhỏ trong khung thử nghiệm của Visual Studio là nó sẽ tạo ra nhiều tệp chạy thử có xu hướng làm lộn xộn thư mục dự án của bạn - mặc dù điều này không phải là vấn đề lớn.

Ngoài ra, nếu bạn thiếu một plugin như TestDriven.NET, bạn không thể gỡ lỗi các bài kiểm tra đơn vị NUnit (hoặc MbUnit, xUnit, v.v.) của mình trong môi trường Visual Studio, như bạn có thể làm với khung kiểm tra Microsoft VS, được tích hợp sẵn.

Hơi lạc đề, nhưng nếu bạn sử dụng NUnit, tôi có thể khuyên bạn nên sử dụng ReSharper - nó thêm một số nút vào giao diện người dùng VS giúp cho việc chạy và gỡ lỗi các bài kiểm tra từ bên trong IDE trở nên dễ dàng hơn rất nhiều.

Đánh giá này hơi lỗi thời, nhưng giải thích điều này chi tiết hơn:

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

XUnit là một khả năng khác cho một dự án greenfield. Có lẽ nó có một cú pháp trực quan hơn, nhưng không thực sự tương thích với các khung công tác khác.

http://www.codeplex.com/xunit

Thịt bò chính của tôi với các bài kiểm tra đơn vị VS qua NUnit là việc tạo kiểm tra VS có xu hướng tiêm một loạt mã được tạo để truy cập thành viên riêng.

Một số có thể muốn thử nghiệm các phương pháp riêng tư của họ, một số có thể không, đó là một chủ đề khác.

Mối quan tâm của tôi là khi tôi viết bài kiểm tra đơn vị, chúng nên được kiểm soát cực kỳ để tôi biết chính xác những gì tôi đang kiểm tra và chính xác cách tôi đang kiểm tra nó. Nếu có mã được tạo tự động, tôi sẽ mất một số quyền sở hữu đó.

Tôi đã thực hiện một số TDD bằng cách sử dụng cả hai và (có lẽ tôi hơi ngu ngốc) nUnit dường như nhanh hơn và đơn giản hơn để sử dụng cho tôi. Và khi tôi nói nhiều, tôi có ý rất nhiều.

Trong MS Test, có quá nhiều thuộc tính, ở khắp mọi nơi - mã thực hiện các bài kiểm tra thực tế là các dòng nhỏ bạn có thể đọc ở đây và ở đó. Một mớ hỗn độn. Trong nUnit, mã thực hiện kiểm tra chỉ chiếm ưu thế các thuộc tính, như nó nên làm.

Ngoài ra, trong nUnit, bạn chỉ cần nhấp vào các bài kiểm tra bạn muốn chạy (chỉ có một? Tất cả các bài kiểm tra bao gồm một lớp? Một hội đồng? Giải pháp?). Một cú nhấp chuột. Và cửa sổ rõ ràng và lớn. Bạn có được đèn xanh và đỏ rõ ràng. Bạn thực sự biết những gì xảy ra trong một tầm nhìn.

Trong VSTS, danh sách kiểm tra bị kẹt ở phía dưới màn hình, nó nhỏ và xấu. Bạn phải nhìn hai lần để biết chuyện gì đã xảy ra. Và bạn không thể chạy chỉ một bài kiểm tra (tốt, tôi chưa tìm ra!).

Nhưng tôi có thể sai, tất nhiên - tôi chỉ đọc khoảng 21 bài đăng trên blog về "Cách thực hiện TDD đơn giản bằng VSTS". Tôi nên đọc thêm, bạn đã đúng.

Đối với nUnit, tôi đọc một. Và tôi đã TDDing cùng ngày. Với niềm vui.

Nhân tiện, tôi thường yêu thích các sản phẩm của Microsoft. Visual Studio thực sự là công cụ tốt nhất mà nhà phát triển có thể mua - nhưng thực sự quản lý TDD và Work Item trong Visual Studio Team System.

Tất cả tốt nhất. Sylvain.

Tôi nhận được thông báo rằng "Cấu trúc tệp NUnit phong phú hơn VSTest" ... Tất nhiên nếu bạn thích cấu trúc tệp NUnit, bạn có thể sử dụng giải pháp này theo cách khác, như thế này (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

Hoặc bất kỳ chuyển đổi nào khác ... :-) Việc sử dụng ở đây chỉ là bí danh cho trình biên dịch.

Đầu tiên tôi muốn sửa một câu lệnh sai: bạn có thể chạy msTest bên ngoài studio hình ảnh bằng cách sử dụng dòng lệnh. Mặc dù một số công cụ CI như TeamCity có hỗ trợ tốt hơn cho NUnit (có thể sẽ thay đổi khi msTest trở nên phổ biến hơn). Trong dự án hiện tại của tôi, chúng tôi sử dụng cả hai và sự khác biệt lớn duy nhất mà chúng tôi tìm thấy là mstest luôn chạy ở mức 32 bit trong khi NUnit chạy dưới dạng thử nghiệm 32 bit hoặc 64 bit, chỉ quan trọng nếu mã của bạn sử dụng mã gốc phụ thuộc 32/64.

Tôi bắt đầu với MSTest nhưng chuyển sang một lý do đơn giản. MSTest không hỗ trợ Kế thừa các Phương thức kiểm tra từ các tổ hợp khác.

Tôi ghét ý tưởng viết cùng một bài kiểm tra nhiều lần. Đặc biệt là trong một dự án lớn, nơi các phương pháp thử nghiệm có thể dễ dàng chạy vào 100 thử nghiệm.

NUnit không chính xác những gì tôi cần. Thứ duy nhất còn thiếu với NUnit là Visual Studio Addin có thể hiển thị trạng thái Đỏ / Xanh lục (Giống như VSTS) của mỗi thử nghiệm.

Tư vấn .NET Framework Tư vấn và gói .NET Unit tests? .

Nếu bạn đang xem xét MSTest hoặc nUnit, thì tôi khuyên bạn nên xem mbUnit. Lý do của tôi là

1. Khả năng tương thích TestDriven.Net. Không có nhịp đập nào có TestDriven.Net.ReRunWithDebugger ràng buộc với một tổ hợp bàn phím.
2. Khung Gallio. Gallio là một người chạy thử nghiệm như nUnits. Sự khác biệt duy nhất là nó không quan tâm nếu bạn đã viết các bài kiểm tra của mình bằng nUnit, msTest, xUnit hoặc mbUnit. Tất cả đều được chạy.
3. Khả năng tương thích với nUnit. Tất cả các tính năng trong nUnit đều được hỗ trợ bởi mbUnit. Tôi nghĩ bạn thậm chí không cần thay đổi thuộc tính của mình (sẽ phải kiểm tra điều đó), chỉ cần tham khảo và sử dụng của bạn.
4. Bộ sưu tập khẳng định. mbUnit có nhiều trường hợp Assert hơn, bao gồm cả lớp CollectionAssert. Về cơ bản, bạn không còn cần phải viết các bài kiểm tra của riêng mình để xem 2 bộ sưu tập có giống nhau không.
5. Xét nghiệm kết hợp. Sẽ không hay chút nào nếu bạn có thể cung cấp hai bộ dữ liệu và kiểm tra tất cả các kết hợp dữ liệu. Đó là trong mbUnit.

Ban đầu tôi đã chọn mbUnit vì chức năng [RowTest ....] của nó và tôi không tìm thấy một lý do nào để quay lại. Tôi đã chuyển tất cả các bộ thử nghiệm hoạt động của mình từ nUnit và không bao giờ nhìn lại. Kể từ đó, tôi đã chuyển đổi hai nhóm phát triển khác nhau sang các lợi ích.

Theo như tôi biết, có bốn khung có sẵn để thử nghiệm đơn vị với .NET hiện nay

• Không
• MbUnit
• MSTest
• xUnit

NUnit luôn luôn ở phía trước nhưng khoảng cách đã đóng lại trong năm ngoái hoặc lâu hơn. Bản thân tôi vẫn thích NUnit hơn, đặc biệt là khi họ đã thêm một giao diện lưu loát trở lại, điều này làm cho các bài kiểm tra rất dễ đọc.

Nếu bạn chỉ mới bắt đầu với thử nghiệm đơn vị thì có lẽ nó không tạo ra nhiều khác biệt. Khi bạn đã tăng tốc, bạn sẽ ở vị trí tốt hơn để đánh giá khung nào phù hợp nhất với nhu cầu của bạn.

Tôi không thích khung thử nghiệm tích hợp của VS vì nó buộc bạn phải tạo một dự án riêng thay vì có các thử nghiệm của bạn như một phần của dự án mà bạn đang thử nghiệm.

MSTest về cơ bản là NUnit được làm lại một chút, với một vài tính năng mới (chẳng hạn như thiết lập lắp ráp và phá vỡ, không chỉ là vật cố và mức kiểm tra), và thiếu một số bit tốt nhất (như cú pháp ràng buộc 2.4 mới). NUnit đã trưởng thành hơn và có nhiều hỗ trợ hơn từ các nhà cung cấp khác; và tất nhiên vì nó luôn miễn phí (trong khi MSTest chỉ đưa nó vào phiên bản Chuyên nghiệp năm 2008, trước đó, theo cách đó, SKU đắt hơn), hầu hết các dự án ALT.NET đều sử dụng nó.

Phải nói rằng, có một số công ty vô cùng miễn cưỡng sử dụng thứ gì đó không có nhãn Microsoft trên đó và đặc biệt là mã OSS. Vì vậy, có một khung kiểm tra MS chính thức có thể là động lực mà các công ty đó cần để thử nghiệm; và hãy trung thực, đó là thử nghiệm quan trọng, không phải bạn sử dụng công cụ nào (và sử dụng mã Tuomas Hietanen ở trên, bạn gần như có thể làm cho khung thử nghiệm của bạn có thể hoán đổi cho nhau).

Với bản phát hành .NET 4.0 của hệ thống Hợp đồng mã và tính khả dụng của trình kiểm tra tĩnh , về mặt lý thuyết bạn sẽ cần viết ít trường hợp kiểm thử hơn và một công cụ như Pex sẽ giúp xác định các trường hợp đó. Liên quan đến vấn đề này trong cuộc thảo luận, nếu bạn cần làm ít hơn với các bài kiểm tra đơn vị của mình vì các hợp đồng của bạn đang che giấu cái đuôi của bạn, vậy thì tại sao không tiếp tục và sử dụng các phần dựng sẵn vì đó là một sự phụ thuộc ít hơn để quản lý. Những ngày này, tôi là tất cả về đơn giản. :-)

Xem thêm:

• Microsoft Pex - Kiểm tra đơn vị tự động
• Tạo thử nghiệm đơn vị với Pex bằng Visual Studio 2010 và C # 4.0

Tôi muốn sử dụng khung kiểm tra nhỏ của MS, nhưng hiện tại tôi đang gắn bó với NUnit. Các vấn đề với MS thường là (đối với tôi)

• Tệp "kiểm tra" được chia sẻ (vô nghĩa) phải là duy trì
• Danh sách kiểm tra gây ra xung đột với nhiều nhà phát triển / VCS
• Giao diện người dùng tích hợp kém - thiết lập khó hiểu, lựa chọn kiểm tra nặng nề
• Không có người chạy bên ngoài tốt

Hãy cẩn thận - Nếu tôi đang thử nghiệm một trang web aspx, tôi chắc chắn sẽ sử dụng MS - Nếu tôi đang phát triển solo, thì MS cũng sẽ ổn - Nếu tôi có kỹ năng hạn chế và không thể định cấu hình NUnit :)

Tôi thấy dễ dàng hơn nhiều khi chỉ cần viết các bài kiểm tra của mình và kích hoạt NUnitGUI hoặc một trong những giao diện khác (testDriven là quá xa so với giá quá cao). Thiết lập gỡ lỗi với phiên bản dòng lệnh cũng khá dễ dàng.