JUnit vs TestNG [đã đóng]

Tại nơi làm việc, chúng tôi hiện vẫn đang sử dụng JUnit 3 để chạy thử nghiệm. Chúng tôi đã xem xét chuyển sang JUnit 4 cho các bài kiểm tra mới được viết nhưng tôi đã để mắt đến TestNG một thời gian rồi. Tất cả các bạn đã có kinh nghiệm gì với JUnit 4 hoặc TestNG, và dường như hoạt động tốt hơn cho số lượng thử nghiệm rất lớn? Có sự linh hoạt trong các bài kiểm tra viết cũng rất quan trọng đối với chúng tôi vì các bài kiểm tra chức năng của chúng tôi bao quát một khía cạnh rộng và cần được viết theo nhiều cách khác nhau để có kết quả.

Các bài kiểm tra cũ sẽ không được viết lại vì chúng làm tốt công việc của mình. Những gì tôi muốn thấy trong các thử nghiệm mới là sự linh hoạt trong cách viết thử nghiệm, các xác nhận tự nhiên, nhóm và thực hiện thử nghiệm phân phối dễ dàng.

Tôi đã sử dụng cả hai, nhưng tôi phải đồng ý với Justin Standard rằng bạn không thực sự nên xem xét việc viết lại các bài kiểm tra hiện tại của mình sang bất kỳ định dạng mới nào. Bất kể quyết định, nó là khá tầm thường để chạy cả hai. TestNG cố gắng để có cấu hình cao hơn nhiều so với JUnit, nhưng cuối cùng cả hai đều hoạt động tốt như nhau.

TestNG có một tính năng gọn gàng trong đó bạn có thể đánh dấu các bài kiểm tra là một nhóm cụ thể và sau đó dễ dàng chạy tất cả các bài kiểm tra của một nhóm cụ thể hoặc loại trừ các bài kiểm tra của một nhóm cụ thể. Do đó, bạn có thể đánh dấu các bài kiểm tra chạy chậm như trong nhóm "chậm" và sau đó bỏ qua chúng khi bạn muốn có kết quả nhanh. Một gợi ý từ tài liệu của họ là đánh dấu một số tập hợp con là kiểm tra "đăng ký" sẽ được chạy bất cứ khi nào bạn kiểm tra tệp mới. Tôi chưa bao giờ thấy một tính năng như vậy trong JUnit, nhưng sau đó, nếu bạn không có nó, bạn không ' T THỰC SỰ nhớ nó.

Đối với tất cả các yêu cầu về cấu hình cao của nó, tôi đã gặp phải một vụ án ở góc cách đây vài tuần, nơi tôi không thể làm những gì tôi muốn làm ... Tôi ước tôi có thể nhớ nó là gì, nhưng tôi muốn đưa nó lên để bạn biết rằng nó không hoàn hảo.

Ưu điểm lớn nhất mà TestNG có là chú thích ... mà JUnit đã thêm vào trong phiên bản 4.

Đầu tiên tôi sẽ nói, đừng viết lại tất cả các bài kiểm tra của bạn chỉ cho phù hợp với mốt mới nhất. Junit3 hoạt động hoàn toàn tốt và việc giới thiệu các chú thích trong 4 không mua cho bạn rất nhiều (theo ý kiến ​​của tôi). Điều quan trọng hơn nhiều là các bạn viết bài kiểm tra, và có vẻ như bạn làm.

Sử dụng bất cứ điều gì có vẻ tự nhiên nhất và giúp bạn hoàn thành công việc của mình.

Tôi không thể nhận xét về TestNG b / c Tôi chưa sử dụng nó. Nhưng tôi muốn giới thiệu unitils , một trình bao bọc tuyệt vời cho JUnit / TestNG / DBUnit / EasyMock, bất kể bạn đi theo con đường nào. (Nó hỗ trợ tất cả các hương vị được đề cập ở trên)

Thẻ rút thăm lớn nhất của TestNG đối với tôi bao gồm các nhóm thử nghiệm hỗ trợ và quan trọng hơn - phụ thuộc nhóm thử nghiệm (đánh dấu một thử nghiệm là phụ thuộc vào nhóm khiến các thử nghiệm đơn giản bỏ qua khi chạy khi nhóm phụ thuộc thất bại).

Các thẻ rút thăm lớn khác của TestNG đối với tôi bao gồm các thông số kiểm tra, nhà cung cấp dữ liệu, máy biến áp chú thích và hơn bất cứ thứ gì - cộng đồng người dùng sôi động và nhạy bén.

Mặc dù trên bề mặt, người ta có thể không nghĩ rằng tất cả các tính năng của TestNG ở trên có thể không cần thiết, một khi bạn bắt đầu hiểu được tính linh hoạt mang lại cho các bài kiểm tra của mình, bạn sẽ tự hỏi làm thế nào bạn đối phó với JUnit.

(từ chối trách nhiệm - Tôi hoàn toàn không sử dụng JUnit 4.x, vì vậy tôi không thể thực sự nhận xét về các tiến bộ hoặc tính năng mới ở đó).

Khoảng một năm trước, chúng tôi đã có cùng một vấn đề. Đôi khi tôi đã cân nhắc xem động thái nào tốt hơn và cuối cùng chúng tôi nhận ra rằng TestNG không có 'tính năng sát thủ'. Thật tuyệt, và có một số tính năng mà JUnit 4 không có, nhưng chúng tôi không cần chúng.
Chúng tôi không muốn mọi người cảm thấy khó chịu khi viết bài kiểm tra khi làm quen với TestNG vì chúng tôi muốn họ tiếp tục viết nhiều bài kiểm tra.
Ngoài ra, JUnit gần như là tiêu chuẩn thực tế trong thế giới Java. Không có công cụ tử tế nào không hỗ trợ nó từ hộp, bạn có thể tìm thấy rất nhiều trợ giúp trên web và họ đã thêm rất nhiều tính năng mới trong năm qua cho thấy nó còn sống.

Chúng tôi quyết định gắn bó với JUnit và không bao giờ nhìn lại.

Chúc mừng tất cả những điều trên. Một số thứ khác mà cá nhân tôi thấy tôi thích hơn ở TestNG là:

1. Việc @BeforeClasskiểm tra diễn ra sau khi tạo lớp, do đó bạn không bị hạn chế khi chỉ có thể gọi các phương thức tĩnh của lớp trong đó.

2. Các bài kiểm tra song song và tham số hóa, có thể tôi không đủ sức sống ... nhưng tôi chỉ nhận được một cú đá viết một bộ bài kiểm tra Selenium, chấp nhận tên trình điều khiển làm tham số. Sau đó, xác định 3 nhóm thử nghiệm song song, mỗi nhóm 1 trình điều khiển IE, FF và Chrome và xem cuộc đua! Ban đầu tôi đã làm 4, nhưng quá nhiều trang tôi đã làm việc để phá vỡ HtmlUnittrình điều khiển vì lý do này hay lý do khác.

Vâng, có lẽ cần phải tìm cuộc sống đó. ;)

Tôi muốn chia sẻ một trong những tôi gặp ngày hôm nay. Tôi thấy trình chạy Parameterized tích hợp khá thô trong Junit4 so với TestNG (Tôi biết mỗi khung có điểm mạnh nhưng vẫn còn). Chú thích Junit4 @parameter được giới hạn trong một bộ tham số. Tôi đã gặp vấn đề này trong khi kiểm tra hành vi hợp lệ và không hợp lệ cho chức năng trong cùng một lớp kiểm tra. Vì vậy, phương thức công khai, chú thích tĩnh đầu tiên mà nó tìm thấy sẽ được sử dụng, nhưng nó có thể tìm thấy chúng theo bất kỳ thứ tự nào. Điều này khiến chúng ta viết các lớp khác nhau một cách không cần thiết. Tuy nhiên, TestNG cung cấp cách thức rõ ràng để cung cấp loại nhà cung cấp dữ liệu khác nhau cho mỗi và mọi phương thức. Vì vậy, chúng ta có thể kiểm tra cùng một đơn vị mã với cách hợp lệ và không hợp lệ trong cùng một lớp kiểm tra đặt riêng dữ liệu hợp lệ / không hợp lệ. Tôi sẽ đi với TestNG.

Ngoài ra một ưu điểm nữa của TestNG là hỗ trợ thử nghiệm song song. Trong kỷ nguyên đa lõi của chúng tôi, nó quan trọng, tôi nghĩ vậy.

Tôi cũng đã sử dụng cả hai khung. Nhưng tôi sử dụng hamcrest để khẳng định. Hamcrest cho phép bạn dễ dàng viết phương pháp khẳng định của riêng bạn. Vì vậy, thay vì

assertEquals(operation.getStatus(), Operation.Status.Active);

Bạn có thể viết

assertThat(operation, isActive());

Điều đó cho bạn cơ hội sử dụng mức độ trừu tượng cao hơn trong các bài kiểm tra của bạn. Và điều này làm cho bài kiểm tra của bạn mạnh mẽ hơn.

JUnit 4 Vs TestNG - So sánh bởi mkyong.com (cập nhật năm 2013).

Kết luận: Tôi đề nghị sử dụng TestNG làm khung thử nghiệm đơn vị cốt lõi cho dự án Java, bởi vì TestNG tiến bộ hơn trong thử nghiệm tham số hóa, thử nghiệm phụ thuộc và thử nghiệm bộ (khái niệm nhóm).

TestNG có nghĩa là để kiểm tra chức năng, kiểm tra mức độ cao và kiểm tra tích hợp phức tạp. Tính linh hoạt của nó đặc biệt hữu ích với các bộ thử nghiệm lớn.

Ngoài ra, TestNG cũng bao gồm toàn bộ chức năng JUnit4 cốt lõi . Không còn lý do gì để tôi sử dụng JUnit nữa.

Nói một cách đơn giản, TestNG = JUnit + nhiều hơn nữa. Vì vậy, tại sao tranh luận? đi và lấy TestNG :-)

Bạn có thể tìm thấy so sánh chi tiết hơn ở đây .

Một vài bổ sung cho câu trả lời của Mike Stone:

1) Điều thường xuyên nhất tôi sử dụng các nhóm của TestNG là khi tôi muốn chạy một phương thức thử nghiệm duy nhất trong bộ thử nghiệm. Tôi chỉ cần thêm bài kiểm tra này vào nhóm "phil" và sau đó chạy nhóm này. Khi tôi đang sử dụng JUnit 3, tôi sẽ nhận xét các mục cho tất cả các phương thức nhưng phương thức tôi muốn chạy trong phương thức "bộ", nhưng sau đó thường sẽ quên bỏ ghi chú chúng trước khi đăng ký. Với các nhóm, tôi không còn gặp phải vấn đề này nữa.

2) Tùy thuộc vào độ phức tạp của các thử nghiệm, việc di chuyển các thử nghiệm từ JUnit3 sang TestNG có thể được thực hiện một cách tự động với sed và tạo một lớp cơ sở để thay thế TestCase mà nhập tĩnh tất cả các phương thức khẳng định TestNG.

Tôi có thông tin về việc di chuyển từ JUnit sang TestNG tại đây và đây .

Tại sao chúng tôi sử dụng TestNG thay vì JUnit?

1. Khai báo @BeforeClassvà @AfterClassphương thức phải tĩnh trong JUnit trong khi đó, TestNG có tính linh hoạt hơn trong khai báo phương thức, nó không có các ràng buộc này.

2. Trong TestNG, chúng tôi có thể kiểm tra tham số bằng 2 cách . Chú thích @Parameter hoặc @DataProvider.

   i) @Parameter cho các trường hợp đơn giản, trong đó yêu cầu ánh xạ giá trị khóa. (dữ liệu được cung cấp qua tệp xml)

   ii) @DataProvider cho các trường hợp phức tạp. Sử dụng mảng 2 chiều, Nó có thể cung cấp dữ liệu.

3. Trong TestNG, do phương thức @DataProvider không cần phải tĩnh, chúng tôi có thể sử dụng nhiều phương thức cung cấp dữ liệu trong cùng một lớp kiểm tra.

4. Kiểm tra phụ thuộc: Trong TestNG, nếu thử nghiệm ban đầu không thành công, thì tất cả các thử nghiệm phụ thuộc tiếp theo sẽ bị bỏ qua, không được đánh dấu là thất bại. Nhưng JUnit đã đánh dấu nó thất bại.

5. Phân nhóm: Các thử nghiệm đơn có thể thuộc nhiều nhóm và sau đó chạy trong các bối cảnh khác nhau (như thử nghiệm chậm hoặc nhanh). Một tính năng tương tự tồn tại trong Danh mục JUnit nhưng thiếu các chú thích @B Beforegroup / @Aftergroup TestNG cho phép khởi tạo thử nghiệm / xé nó.

6. Tính song song: Nếu bạn muốn chạy cùng một bài kiểm tra song song trên nhiều luồng, TestNG sẽ cung cấp cho bạn một chú thích đơn giản để sử dụng trong khi JUnit không cung cấp một cách đơn giản để làm điều đó ra khỏi hộp.

7. TestNG @DataProvider cũng có thể hỗ trợ XML để cung cấp dữ liệu, CSV hoặc thậm chí các tệp văn bản thuần túy.

8. TestNG cho phép bạn khai báo các phụ thuộc giữa các thử nghiệm và bỏ qua chúng nếu thử nghiệm phụ thuộc không vượt qua.

@Test (DepOnMethods = {"DepOnS Something"})

Chức năng này không tồn tại trong JUnit

9. Báo cáo:

Các báo cáo TestNG được tạo theo mặc định cho thư mục đầu ra thử nghiệm bao gồm các báo cáo HTML với tất cả dữ liệu thử nghiệm, được truyền / không thành công / bỏ qua, chúng chạy trong bao lâu, đầu vào nào được sử dụng và nhật ký kiểm tra hoàn chỉnh. Ngoài ra, nó cũng xuất mọi thứ sang tệp XML có thể được sử dụng để xây dựng mẫu báo cáo của riêng bạn.

Ở mặt trước JUnit, tất cả các dữ liệu này cũng có sẵn thông qua XML, nhưng không có báo cáo ngoài hộp và bạn cần phải dựa vào các bổ trợ.

Liên kết tài nguyên:

1. So sánh nhanh JUnit vs TestNG
2. JUnit so với TestNG: Bạn nên chọn khung kiểm tra nào?

Một sự khác biệt tốt được đưa ra trong hướng dẫn này cạnh nhau: TestNG Vs JUnit: Sự khác biệt là gì?

Câu hỏi của bạn dường như gấp hai lần với tôi. Một mặt bạn muốn so sánh hai khung kiểm tra, mặt khác bạn muốn thực hiện các thử nghiệm dễ dàng, có các xác nhận tự nhiên, v.v ...

Ok, trước tiên, JUnit đã chơi trò đuổi bắt với TestNG về chức năng, họ đã thu hẹp khoảng cách một số thứ với v4, nhưng theo tôi thì không đủ. Những thứ như chú thích và bảng dữ liệu vẫn tốt hơn nhiều trong TestNG. Ngoài ra, họ linh hoạt hơn về mặt thực hiện kiểm tra, vì TestNG có sự phụ thuộc kiểm tra, nhóm và đặt hàng.

JUnit vẫn yêu cầu một số phương thức trước / sau nhất định là tĩnh, điều này giới hạn những gì bạn có thể làm trước khi chạy thử nghiệm, TestNG không bao giờ gặp phải vấn đề này.

TBH, chủ yếu là sự khác biệt giữa hai khung không có ý nghĩa gì nhiều, trừ khi bạn tập trung vào thử nghiệm tích hợp / tự động hóa. JUnit từ kinh nghiệm của tôi được xây dựng từ cơ sở để thử nghiệm đơn vị và hiện đang được đẩy lên các cấp độ thử nghiệm cao hơn, IMO làm cho nó trở thành công cụ sai cho công việc. TestNG làm tốt công việc kiểm tra đơn vị và nhờ khả năng xử lý dữ liệu mạnh mẽ và khả năng thực thi thử nghiệm tuyệt vời, hoạt động thậm chí còn tốt hơn ở cấp độ thử nghiệm tích hợp / tự động hóa.

Bây giờ đối với những gì tôi tin là một vấn đề riêng biệt, làm thế nào để viết các bài kiểm tra có cấu trúc tốt, dễ đọc và có thể duy trì. Hầu hết điều này tôi chắc chắn bạn biết, nhưng những thứ như Mô hình nhà máy , Mẫu lệnh và PageObjects (nếu trang web thử nghiệm của bạn) rất quan trọng, điều rất quan trọng là phải có một lớp trừu tượng giữa thử nghiệm của bạn (SUT) và thử nghiệm thực tế là (khẳng định logic kinh doanh). Để có các xác nhận đẹp hơn nhiều, bạn có thể sử dụng Hamcrest . Sử dụng kế thừa / giao diện javas để giảm sự lặp lại và thực thi tính phổ biến.

Hầu như quên, cũng sử dụng Mẫu Trình tạo dữ liệu thử nghiệm , kết hợp này với chú thích dữ liệu của TestNG là rất hữu ích.

Ý kiến ​​của tôi về những gì làm cho TestNG thực sự mạnh mẽ hơn nhiều:

1.  JUnit still requires the before/after class methods to be static, which limits
    what you can do prior to the running of tests, TestNG never has this issue.

2.  TestNG @Configuration methods can all take an optional argument to their 
    annotated methods in the form of a ITestResult, XmlTest, Method, or 
    ITestContext.  This allows you to pass things around that JUnit wouldn't 
    provide you.  JUnit only does this in listeners and it is limited in use.

3.  TestNG comes with some pre-made report generation classes that you can copy
     and edit and make into your own beautiful test output with very little 
     effort. Just copy the report class into your project and add a listener 
     to run it.  Also, ReportNG is available.

4.  TestNG has a handful of nice listeners that you can hook onto so you can do
     additional AOP style magic at certain phases during testing.