JUnit 4 vs TestNG - Cập nhật 2013 - 2014 [đã đóng cửa]

JUnit 4 và TestNG từng được so sánh với nhau. Ưu và nhược điểm của hai khung thử nghiệm là gì?

Tôi đã so sánh TestNG và JUnit4 ngày hôm nay và lợi thế chính mà tôi có thể chỉ ra với kinh nghiệm hạn chế của mình trong các khuôn khổ thử nghiệm là TestNG có cách xử lý các bài kiểm tra tham số thanh lịch hơn với khái niệm nhà cung cấp dữ liệu.

Theo như tôi có thể nói với JUnit4, bạn phải tạo một lớp thử nghiệm riêng biệt cho từng bộ thông số bạn muốn thử nghiệm (chạy với @RunWith(Parameterized.class)). Với TestNG, bạn có thể có nhiều nhà cung cấp dữ liệu trong một lớp kiểm tra, vì vậy bạn cũng có thể giữ tất cả các bài kiểm tra của mình cho một lớp trong một lớp kiểm tra duy nhất.

Cho đến nay, đó là điều duy nhất mà tôi có thể chỉ ra là lợi ích của TestNG so với JUnit4.

Intellij IDEA bao gồm hỗ trợ TestNG và JUnit ngay lập tức. Tuy nhiên, Eclipse chỉ hỗ trợ JUnit bên ngoài và cần cài đặt plugin TestNG để nó hoạt động.

Tuy nhiên, một vấn đề khó chịu hơn mà tôi gặp phải với TestNG là các lớp kiểm tra của bạn cần phải mở rộng PowerMockTestCasenếu bạn đang sử dụng PowerMock để giả lập các phụ thuộc trong các bài kiểm tra của mình. Rõ ràng có nhiều cách để cấu hình đối tượng-nhà máy mà khung thử nghiệm của bạn cần biết khi sử dụng PowerMock thông qua một phương pháp đặc biệt hoặc thông qua testng.xmlđịnh nghĩa bộ, nhưng những cách đó dường như đã bị hỏng vào lúc này. Tôi không thích có các lớp thử nghiệm mở rộng các lớp khung công tác thử nghiệm, có vẻ hơi khó.

Nếu bạn không sử dụng PowerMock, đây không phải là vấn đề tất nhiên, nhưng nhìn chung, tôi có ấn tượng rằng JUnit4 được hỗ trợ tốt hơn.

Dựa trên kinh nghiệm của tôi với cả hai framework, testng có một vài tính năng tiện lợi mà nhóm JUnit đã từ chối triển khai trong vài năm. Tôi thích nó hơn JUnit vì lý do này. Chuyển đổi sang testng rất dễ dàng vì về cơ bản nó hỗ trợ khá nhiều thứ trong JUnit (thậm chí có cả plugin chuyển đổi cho eclipse), việc chuyển đổi trở lại JUnit không quá tuyệt vời vì những tính năng bị thiếu này.

• Trong testng, @BeforeClasscác phương thức không tĩnh và thực thi trước khi các bài kiểm tra trong lớp đó chạy hơn là khi lớp kiểm tra được tải (hành vi JUnit). Tôi đã từng có một dự án JUnit trong đó tất cả các bài kiểm tra cơ sở dữ liệu (vài chục) đều khởi tạo cơ sở dữ liệu ngay khi bắt đầu, đó là một hành vi khá ngu ngốc. Đã có rất nhiều tranh luận về và chống lại điều này trong cộng đồng JUnit. Ý chính của nó là mọi phương pháp thử nghiệm nên có bộ cố định thử nghiệm riêng của nó và do đó bạn không nên có phương thức beforeAll kiểu không tĩnh vì điều đó sẽ cho phép bạn lén lút đặt một biến thể hiện một lần và sau đó sử dụng nó trong tất cả các thử nghiệm của bạn. Hợp lệ, nhưng thực sự khó chịu cho các bài kiểm tra tích hợp. TestNG cung cấp cho người dùng sự lựa chọn ở đây. Theo thiết kế, Junit không gây khó chịu.

• Các nhà cung cấp dữ liệu Testng linh hoạt hơn một chút so với JUnit tương đương. Bạn có thể chỉ định mỗi lần kiểm tra mà phương thức của nhà cung cấp dữ liệu sẽ cung cấp đầu vào thay vì có một kích thước phù hợp với tất cả các phương pháp tiếp cận cho toàn bộ lớp như trong JUnit. Vì vậy, bạn có thể có các nhà cung cấp dữ liệu trường hợp tích cực và tiêu cực cho các bài kiểm tra của bạn trong một lớp. Rất vui khi có.

• Bạn có thể đánh dấu một lớp bằng @Testtrong testng, có nghĩa là: mọi phương thức public đều là một bài kiểm tra. Trong Junit, bạn cần sao chép / dán @Testtrên mọi phương thức.

Một điều khó chịu với cả hai là cách hamcrest được đóng gói với JUnit và cách JUnit được đóng gói với testng. Có những lọ thay thế trong maven không có vấn đề này.

Lo lắng lớn của tôi với cả hai khuôn khổ là cả hai dường như đã ngừng phát triển. Các bản phát hành ngày càng ít thường xuyên hơn và có xu hướng ngày càng có ít tính năng đáng chú ý hơn. Ví dụ, toàn bộ phong trào BDD dường như có ít tác động đến cả hai khuôn khổ. Ngoài ra, JUnit có thể đơn giản đã áp dụng hầu hết những gì tôi đã liệt kê ở trên. Không có lý do kỹ thuật chính xác tại sao JUnit không thể thực hiện bất kỳ điều nào trong số này; những người đứng sau JUnit chỉ chọn không triển khai những điều này. Cả hai dự án dường như cũng thiếu tầm nhìn về định hướng tương lai và họ có vẻ rất vui khi chỉ thực hiện những chỉnh sửa nhỏ trong vài năm qua.

Tôi đang tìm lý do chính đáng để chuyển TestNG qua JUnit và tôi thấy trang trình bày này của Tomek Kaczanowski giải quyết câu hỏi này rất tốt. Tomek là tác giả của cuốn sách Kiểm tra đơn vị thực tế, cuốn sách này dường như rất được các nhà phát triển và kiểm thử viên tôn trọng.

Nếu bạn làm việc trên dự án Java / Scala và Gradle là công cụ xây dựng mà bạn lựa chọn, hãy nhớ rằng ScalaTestkhung công tác chỉ JUnitRunnerđể chạy các bài kiểm tra scala của bạn. Nói cách khác, bạn có quyền lựa chọn:

• Java JUnit tests + Scala Tests chạy với JUnitRunner => Tích hợp Gradle tốt hơn
• Kiểm tra Java testNG + Kiểm tra Scala chạy với Scala Runner => Tích hợp Gradle kém, vì trình chạy kiểm tra scala là một nhiệm vụ hàng loạt theo quan điểm của Gradle.

Bạn có thể sử dụng Mockito làm khuôn khổ chế nhạo của mình. Nó tích hợp độc đáo với TestNG. Bạn không phải mở rộng bất kỳ lớp nào để sử dụng Mockito với TestNG. Theo cách này, mã thử nghiệm của bạn ít được ghép nối hơn và nếu vì bất kỳ lý do gì bạn cần sử dụng các khuôn khổ chế tạo khác, bạn có thể dễ dàng làm như vậy.

Tóm lại ..

Nếu phạm vi của bạn bị giới hạn trong các bài kiểm tra đơn vị chi tiết tốt mà không có sự phụ thuộc nào giữa chúng thì JUnit có thể được sử dụng.

Nếu phạm vi của bạn yêu cầu kiểm tra chức năng có thể / không yêu cầu phụ thuộc và chia sẻ dữ liệu (tham số) giữa các thử nghiệm thì hãy chọn TestNG. Ngoài ra, TestNG có thể thực hiện kiểm thử đơn vị tương tự như JUnit. VẬY bạn có thể có một bộ kiểm tra đơn vị và một bộ kiểm tra chức năng.