NUnit so với MbUnit so với MSTest so với xUnit.net [đã đóng]

Có khá nhiều khung công tác không mong muốn cho .NET. Tôi tìm thấy so sánh tính năng nhỏ này: http://xunit.github.io/docs/comparisons.html

Bây giờ tôi là để chọn một trong những tốt nhất cho chúng tôi. Nhưng bằng cách nào? Có vấn đề gì không? Cái nào là bằng chứng trong tương lai nhất và có một động lực tốt đằng sau nó? Tôi có nên quan tâm đến các tính năng? Trong khi xUnit dường như là hiện đại nhất và được thiết kế riêng cho .NET, NUnit lại dường như là một thứ được chấp nhận rộng rãi. MSTest một lần nữa đã được tích hợp vào Visual Studio ...

Tôi biết đây là một chủ đề cũ, nhưng tôi nghĩ tôi sẽ đăng một phiếu bầu cho xUnit.NET . Trong khi hầu hết các khung thử nghiệm khác được đề cập đều khá giống nhau, xUnit.NET đã thực hiện một cách tiếp cận khá độc đáo, hiện đại và linh hoạt để thử nghiệm đơn vị. Nó thay đổi thuật ngữ, do đó bạn không còn xác định TestFixenses và Tests ... bạn chỉ định Sự kiện và Lý thuyết về mã của mình, tích hợp tốt hơn với khái niệm thử nghiệm là gì từ phối cảnh TDD / BDD.

xUnit.NET cũng có thể mở rộng TUYỆT VỜI. Các lớp thuộc tính FactAttribution và TraitAttribution của nó không được niêm phong và cung cấp các phương thức cơ sở có thể ghi đè cung cấp cho bạn nhiều quyền kiểm soát về cách các phương thức mà các thuộc tính trang trí nên được thực thi. Mặc dù xUnit.NET ở dạng mặc định cho phép bạn viết các lớp kiểm tra tương tự như các bài kiểm tra NUnit với các phương thức kiểm tra của chúng, nhưng bạn hoàn toàn không bị giới hạn trong hình thức kiểm tra đơn vị này. Bạn có thể mở rộng khung để hỗ trợ các thông số kỹ thuật Quan tâm / Bối cảnh / Quan sát theo kiểu BDD, như được mô tả ở đây .

xUnit.NET cũng hỗ trợ kiểm tra kiểu phù hợp trực tiếp với hộp thuộc tính Lý thuyết và thuộc tính dữ liệu tương ứng. Dữ liệu đầu vào phù hợp có thể được tải từ excel, cơ sở dữ liệu hoặc thậm chí là nguồn dữ liệu tùy chỉnh như tài liệu Word (bằng cách mở rộng thuộc tính dữ liệu cơ sở.) Điều này cho phép bạn tận dụng một nền tảng thử nghiệm duy nhất cho cả kiểm tra đơn vị và kiểm tra tích hợp, trong đó kiểm tra đơn vị có thể rất lớn trong việc giảm sự phụ thuộc sản phẩm và đào tạo cần thiết.

Các cách tiếp cận khác để kiểm tra cũng có thể được thực hiện với xUnit.NET ... khả năng là vô hạn. Kết hợp với một khung mô phỏng rất mong đợi khác, Moq , cả hai tạo ra một nền tảng rất linh hoạt, có thể mở rộng và mạnh mẽ để thực hiện thử nghiệm tự động.

NUnit có lẽ được hỗ trợ nhiều nhất bởi các công cụ của bên thứ 3. Nó cũng tồn tại lâu hơn ba người kia.

Cá nhân tôi không quan tâm nhiều đến các khung kiểm tra đơn vị, các thư viện chế giễu là IMHO quan trọng hơn nhiều (và khóa bạn nhiều hơn nữa). Chỉ cần chọn một và gắn bó với nó.

Tôi sẽ không đi với MSTest. Mặc dù đây có lẽ là bằng chứng tương lai nhất về các khuôn khổ với Microsoft đằng sau nó không phải là giải pháp linh hoạt nhất. Nó sẽ không chạy một mình mà không có một số hack. Vì vậy, chạy nó trên một máy chủ xây dựng khác ngoài TFS mà không cài đặt Visual Studio là khó. Trình chạy thử nghiệm phòng thu trực quan thực sự chậm hơn Testdriven.Net + bất kỳ khuôn khổ nào khác. Và vì các bản phát hành của khung này được gắn với các bản phát hành của Visual Studio nên có ít cập nhật hơn và nếu bạn phải làm việc với một VS cũ hơn, bạn sẽ bị ràng buộc với MSTest cũ hơn.

Tôi không nghĩ nó quan trọng lắm với những khuôn khổ khác mà bạn sử dụng. Thật dễ dàng để chuyển từ cái này sang cái khác.

Cá nhân tôi sử dụng XUnit.Net hoặc NUnit tùy theo sở thích của đồng nghiệp. NUnit là tiêu chuẩn nhất. XUnit.Net là khung gầy nhất.

Xem xét bổ sung, không thay thế, MSTest với một khung thử nghiệm khác. Bạn có thể duy trì tích hợp Visual Studio MSTest trong khi nhận được các lợi ích của khung thử nghiệm đầy đủ tính năng hơn.

Ví dụ, tôi sử dụng xUnit với MSTest. Thêm một tham chiếu đến hội đồng xUnit.dll và chỉ cần làm một cái gì đó như thế này. Đáng ngạc nhiên, nó chỉ hoạt động!

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 không hoạt động tốt với các dự án chế độ hỗn hợp trong C ++ nên tôi đã phải bỏ nó

Nó không phải là một vấn đề lớn ở quy mô nhỏ / cá nhân, nhưng nó có thể trở thành một thỏa thuận lớn hơn một cách nhanh chóng trên quy mô lớn hơn. Chủ nhân của tôi là một cửa hàng lớn của Microsoft, nhưng sẽ không / không thể mua vào Team System / TFS vì một số lý do. Chúng tôi hiện đang sử dụng Subversion + Orcas + MBUnit + TestDriven.NET và nó hoạt động tốt, nhưng để có được TD.NET là một rắc rối lớn. Độ nhạy phiên bản của MBUnit + TestDriven.NET cũng là một rắc rối lớn và có thêm một điều thương mại (TD.NET) để xem xét và mua sắm hợp pháp để xử lý và quản lý, không phải là chuyện nhỏ. Công ty của tôi, giống như nhiều công ty, béo và hài lòng với mô hình Đăng ký MSDN và nó không được sử dụng để xử lý một lần mua sắm cho hàng trăm nhà phát triển. Nói cách khác, ưu đãi MS tích hợp đầy đủ, trong khi chắc chắn không phải lúc nào cũng tốt nhất, theo ý kiến ​​của tôi.

Tôi nghĩ rằng chúng tôi sẽ ở lại với bước hiện tại của mình vì nó hoạt động và chúng tôi đã vượt qua được cái bướu có tổ chức, nhưng tôi chắc chắn rằng MS muốn có một đề nghị hấp dẫn trong không gian này để chúng tôi có thể hợp nhất và đơn giản hóa nhà phát triển của chúng tôi một chút.

Nó không phải là một vấn đề lớn, nó khá dễ dàng để chuyển đổi giữa chúng. MSTest được tích hợp cũng không phải là một vấn đề lớn, chỉ cần lấy testdriven.net.

Giống như người trước đã nói chọn một khung chế giễu, yêu thích của tôi tại thời điểm này là Moq.