JUnit là một khung thử nghiệm đơn vị mã nguồn mở của bên thứ ba. Dự án được bắt đầu bởi Kent Beck và Erich Gamma vào cuối năm 1995. Nó nhanh chóng thu hút được sự quan tâm của cộng đồng các nhà phát triển, những người đặc biệt kinh doanh phát triển theo hướng thử nghiệm. JUnit ban đầu được giới thiệu với Smalltalk, nhưng sau đó đã được chuyển sang Java, điều này nhanh chóng được chọn làm tiêu chuẩn de-facto của thử nghiệm đơn vị. Sự phổ biến của JUnit đã phát triển đến mức, để đáp ứng nhu cầu của nhiều ngôn ngữ hiện đại khác như C #, Perl, Python, PHP, Ruby, Visual Basic, C ++, v.v., một khuôn khổ xUnit chung đã được phát triển. 'x' được thay thế bằng chữ cái đầu tiên của ngôn ngữ, chẳng hạn như JUnit cho Java, RUnit cho Ruby, v.v. Bài viết này cung cấp tổng quan về khung này như được sử dụng bởi tiêu chuẩn de-facto của kiểm thử đơn vị Java.
Tổng quan về Thử nghiệm
Kiểm thử là một giai đoạn quan trọng trong vòng đời của sự phát triển ứng dụng. Mục đích chính của kiểm thử là đánh giá một chương trình trên cơ sở các thông số kỹ thuật được yêu cầu. Mục tiêu là tạo ra một số trường hợp thử nghiệm nhất định có lỗi, lỗ hổng, bất kỳ sự khác biệt nào hoặc kết quả không mong muốn, càng nhiều càng tốt. Khái niệm đơn giản này có một số quy trình phức tạp đi kèm với nó. Tuy nhiên, nói một cách ngắn gọn, nó được thực hiện ở ba cấp độ. Khi thử nghiệm được thực hiện ở cấp thành phần rất chi tiết hoặc riêng lẻ, nó được gọi là Thử nghiệm đơn vị ; khi chúng được kết hợp để kiểm tra giao diện giữa các thành phần so với thiết kế phần mềm, nó được gọi là Kiểm tra tích hợp ; và cuối cùng, khi hệ thống hoàn chỉnh được tích hợp và quá trình thử nghiệm được thực hiện để xác minh rằng toàn bộ hệ thống đáp ứng yêu cầu được chỉ định, thì nó được gọi là Kiểm tra hệ thống .
Kiểm tra đơn vị
Tóm lại, thực hiện kiểm thử đơn vị là một cách để kiểm tra hành vi của một đơn vị mã riêng biệt. Trong Java, một đơn vị mã có thể có nghĩa là một phương thức hoặc một lớp hoặc thậm chí một mô-đun, tùy theo ngữ cảnh. Ví dụ:nếu đó là một phương thức, trọng tâm của bài kiểm tra là đánh giá đúng tham chiếu đối tượng được phép gọi phương thức, loại tham số và giá trị có thể chấp nhận, phạm vi giá trị nguyên thủy, kiểu trả về và giá trị, v.v. Ý tưởng là làm cho phương pháp này trở nên đủ mạnh để xử lý vấn đề một cách khéo léo và loại bỏ những vấn đề nằm ngoài phạm vi của nó ngoài việc hoàn thành hợp đồng của nó.
Do đó, kiểm thử đơn vị tạo thành khối xây dựng cơ bản của bất kỳ đánh giá chương trình nào. Trên thực tế, mọi lập trình viên đều thực hiện một số loại kiểm thử đơn vị như một người viết mã để kiểm tra kết quả của mã với một số dữ liệu / trường hợp giả. Do đó, kiểm tra đơn vị là một trạng thái chính thức được cấp cho bộ sưu tập các bài kiểm tra cô lập đó. Điều cực kỳ quan trọng là mã phải trải qua nhiều giai đoạn thử nghiệm khác nhau. Kiểm thử đơn vị, ngoài tầm quan trọng của nó, nó cũng rất phổ biến. Những người như Kent Beck và Erich Gamma đã nghĩ đến việc tạo ra một khuôn khổ cho nó để các lập trình viên có được một môi trường có cấu trúc và có thể tự động hóa nhiều công việc này. Rốt cuộc, đây là những gì một khuôn khổ dành cho. Thông thường, nó cung cấp một cấu trúc chương trình nhất quán có thể tái sử dụng và chia sẻ trên các ứng dụng. Một lập trình viên có thể kết hợp chúng vào một ứng dụng hiện có và mở rộng chúng theo nhu cầu cụ thể của nó.
Một ví dụ nhanh
Một mã kiểm tra đơn vị đơn giản để kiểm tra một phương pháp duy nhất trong Nhiệt độ lớp không sử dụng khung JUnit như sau:
package org.mano.unittest.examples;
public class Circle {
double area(double radius) {
returnMath.PI* radius * radius;
}
}
Bây giờ, hãy viết mã để kiểm tra đơn vị khu vực phương pháp.
package org.mano.unittest.examples;
public class CircleTest {
public int errCounter= 0;
public void testCircleArea() {
Circle circle = new Circle();
double area = circle.area(12);
if (area < 452 && area > 453) {
throw new IllegalStateException("Wrong calculation!: "
+ area);
}
}
public static void main(String[] args) {
TestCircle test = new TestCircle();
try {
test.testCircleArea();
} catch (Throwable e) {
test.errCounter++;
e.printStackTrace();
}
if (test.errCounter> 0) {
throw new IllegalStateException("There were "
+ test.errCounter+ " error(s)");
}
}
}
Đây là một ví dụ thô sơ, nhưng cung cấp cho bạn ý tưởng về cách kiểm thử đơn vị có thể được thực hiện mà không cần sử dụng bất kỳ khuôn khổ nào.
Khung thử nghiệm JUnit
Sử dụng khung công tác JUnit để kiểm thử đơn vị có một số lợi thế. Nó cung cấp nhiều chú thích giúp dễ dàng viết và chạy mã thử nghiệm trong Java:
- Về cơ bản, nó phân tách mối quan tâm của kiểm thử đơn vị khỏi mã dự án thực tế bằng cách cho phép người ta tạo phiên bản lớp thử nghiệm và bộ tải lớp cho mỗi thử nghiệm đơn vị. Những mã này "miễn dịch" với mã hiện có khỏi các tác dụng phụ không cần thiết của thử nghiệm.
- Các chú thích do JUnit cung cấp — chẳng hạn như @Before, @After, @BeforeClass, @AfterClass —Có các phương thức cho cả khởi tạo tài nguyên và cải tạo tài nguyên.
- Có nhiều phương pháp xác nhận để xác minh kết quả của một bài kiểm tra.
- Trong những năm qua, JUnit đã trở nên phổ biến đến mức nhiều công cụ Java, chẳng hạn như Ant và Maven ; và các IDE phổ biến, chẳng hạn như Eclipse , NetBeans , IntelliJ Ý TƯỞNG và tương tự, đi kèm với tích hợp sẵn của JUnit.
Để sử dụng Khung kiểm tra JUnit trong một dự án Java, người ta phải thêm tệp JUnit JAR vào đường dẫn lớp dự án. Điều này được yêu cầu rõ ràng nếu IDE không được tích hợp với thư viện JUnit. Quá trình này rất đơn giản. Tải xuống tệp JAR và thêm nó vào đường dẫn lớp của dự án.
Dưới đây là một số liên kết quan trọng đến khung công tác JUnit.
- Trang web chính thức của JUnit
- JUnit Java API
- Hướng dẫn sử dụng JUnit
- Mã nguồn JUnit trong GitHub
Không giống như JUnit 4 và những người tiền nhiệm của nó, JUnit 5 đã mang đến một số thay đổi đáng kể. Ngoài nhiều tính năng mới được bổ sung &mdahs; như hỗ trợ lambda, chú thích mới và chèn tham số phương pháp thử nghiệm — kiến trúc cốt lõi có một số sửa đổi đáng kể. JUnit 5 hiện là một kiến trúc tổng hợp của ba mô-đun khác nhau:JUnit Jupiter, JUnit Vintage và JUnit Platform. Tuy nhiên, các nhà phát triển trường hợp thử nghiệm không cần phải bận tâm về sự phức tạp của các thay đổi. Những thay đổi chủ yếu có nghĩa là hỗ trợ công cụ tốt hơn, tính nhất quán và API sạch hơn. Trên hết, nó hoàn toàn tương thích ngược với JUnit 4. Vì vậy, bạn cũng đừng lo lắng. Tham khảo hướng dẫn sử dụng JUnit 5 để biết thêm chi tiết.
Một ví dụ nhanh
Dưới đây là một ví dụ rất đơn giản để có cái nhìn thoáng qua về cách kiểm thử đơn vị có thể được thực hiện với khung công tác JUnit. Chúng tôi sử dụng Nhân viên lớp cho bài kiểm tra đơn vị và tạo một lớp kiểm tra để đưa ra ý tưởng về hoạt động của nó. Ví dụ này còn thô sơ đến mức viết chương trình ‘Hello World’. Các trường hợp kiểm thử trong thế giới thực, hoặc thậm chí là một ví dụ điển hình về kiểm thử đơn vị, yêu cầu một lượng mã tốt. Có thể chúng tôi sẽ thử điều đó trong một số bài viết khác.
package org.mano.unittest.examples;
public class Employee {
private final String name;
private final double basicPay;
public Employee(String name, double basicPay) {
this.name=name;
this.basicPay=basicPay;
}
public String getName() {
return name;
}
public double getBasicPay() {
return basicPay;
}
}
package org.mano.unittest.examples;
import org.junit.Test;
import static org.junit.Assert.*;
public class EmployeeTest {
@Test
public void constructorInitTest(){
Employee emp=new Employee("Odin", 2300);
assertEquals("Odin", emp.getName());
assertEquals(2300, emp.getBasicPay(), 0.001);
}
}
package org.mano.unittest.examples;
public class EmployeeTestMain {
public static void main(String[] args){
EmployeeTest et=new EmployeeTest();
et.constructorInitTest();
}
}
Quan sát rằng lớp Employee là không thay đổi chỉ với hai trường được thiết lập bởi hàm tạo. Bởi vì chỉ có phương pháp cấu trúc mới đáng thử nghiệm, chúng tôi sẽ chỉ thử nghiệm phương pháp đó.
Lớp kiểm tra có tên là EmployeeTest theo quy ước. Chú thích @Test cho phép JUnit chỉ định một phương pháp làm phương pháp thử nghiệm. Có nhiều phương pháp xác nhận trong Khẳng định lớp. Ở đây, chúng tôi chỉ sử dụng khẳng địnhEquals .
Có nhiều cách để chạy một bài kiểm tra được viết bằng JUnit. Thông thường, sau khi chạy các trường hợp thử nghiệm, nó sẽ in ra một bản tóm tắt. Tuy nhiên, nó có thể khác nhau tùy thuộc vào cách chạy thử nghiệm. Nó có thể chạy qua các IDE như Eclipse hoặc IntelliJ hoặc các công cụ như Maven, Gradle, v.v. Đôi khi, thông tin duy nhất nhận được sau khi kiểm tra là nó đã không đạt hoặc đã đạt.
Kết luận
Có một số khuôn khổ khác để kiểm thử đơn vị. JUnit là một khung kiểm thử đơn vị phổ biến trong Cộng đồng Java. Thử nghiệm như một giai đoạn kỹ thuật hệ thống có nhiều quy trình hơn liên quan đến nó. Thử nghiệm đơn vị chỉ là một phần của nó và thú vị là rất nhiều thử nghiệm chơi được thực hiện bởi nhà phát triển có thể được gọi là thử nghiệm đơn vị. JUnit, như một khung thử nghiệm, làm tăng thêm giá trị cho nó. Các chú thích và các API do JUnit cung cấp tự động hóa nhiều tác vụ và làm cho cuộc sống của các nhà phát triển thử nghiệm đơn vị trở nên dễ dàng hơn rất nhiều.
