12/08/2018, 00:43

Part 1: Giới thiệu về mã nguồn mở TestNG dành cho kiểm thử phần mềm

Testing Framework... Đối với các lập trình viên Java, liên tưởng đầu tiên khi đề cập tới cụm từ "Testing Framework" đều là "JUnit". Tuy nhiên, nhắc tới "Testing Framework" không chỉ có Junit mà hiện còn có "TestNG". Vậy "TestNG" là gì? "TestNG" là một Testing Framework đang được đánh giá rất ...

Testing Framework...

Đối với các lập trình viên Java, liên tưởng đầu tiên khi đề cập tới cụm từ "Testing Framework" đều là "JUnit". Tuy nhiên, nhắc tới "Testing Framework" không chỉ có Junit mà hiện còn có "TestNG". Vậy "TestNG" là gì? "TestNG" là một Testing Framework đang được đánh giá rất cao và đang dần củng cố và khẳng định vị thế là một testing framework hữu ích và dễ dàng sử dụng. Điển hình như JBoss Seam hiện đang cung cấp Testing Framework tích hợp dựa trên nền tảng TestNG.

Trong khuôn khổ bài viết này, chúng tôi sẽ đưa ra cho các bạn một cái nhìn tổng quát nhất về TestNG (từ những khái niệm cơ bản về TestNG cho tới hướng dẫn chi tiết cách sử dụng TestNG) để các bạn có thể nắm được những nguyên tắc, nguyên lí cơ bản khi sử dụng TestNG trong một dự án phát triển phần mềm.

Picture 1.jpg

JUnit thì đã quá quen thuộc với các bạn lập trình viên Java rồi. Vậy, JUnit và TestNG giống và khác nhau như thế nào? Tại sao TestNG lại được đánh giá cao như vậy? Phân tích sau đây sẽ giúp các bạn hiểu và biết được một số thế mạnh của TestNG so với JUnit.

5 hạn chế của JUnit3

JUnit hiện có 2 phiên bản phổ biến là Junit3 (phiên bản đầu tiên) và Junit4 (phiên bản dựa trên nền tảng các chỉ dẫn Anomation dành cho Java SE 5.0). Do TestNG được release trước cả JUnit 4 nên để có thể hiểu được tổng quan về TestNG thì trước hết cần phải biết được những điểm hạn chế tiềm tàng của JUnit3.

Hạn chế 1: Cố định tên của Test Method

Ở JUnit3, tên Test Method đều bắt đầu bằng chữ "test". Do đó, nếu không thực hiện Test Method nào đó thì bắt buộc phải chuyển Method name đó từ "testAdd" thành "_testAdd". Giả dụ nếu như trong TestClass nào đó có tới 20 TestMethod nhưng chỉ thực hiện 10 TestMethod thì phải chuyển Method name của 10 TestMethod còn lại sang "_testAdd". Điều đó rất dễ gây khó chịu và phiền hà cho người sử dụng

Hạn chế 2: Không cho truyền Argument vào TestMethod

JUnit3 không cho truyền Argument vào TestMethod. Việc sử dụng Argument trong Java là điều cơ bản và đương nhiên phải thế. Do đó, nếu có thể truyền giá trị Argument vào TestMethod thì có thể nâng cao chất lượng xử lý check validation thông qua việc thay đổi giá trị Argument.

Hạn chế 3: Exception test phức tạp

Nếu muốn test xem liệu method có throw đúng Exception cần throw hay không thì cần phải add thêm đoạn code sau:

public void testException() {
    Target target = new Target();
    try {
        target.throwException();
        fail("Không phát sinh Exception");
    } catch (RuntimeException expected) {
        assertTrue(true);
    }
}

TestMethod này sẽ thực hiện kiểm chứng xem có phát sinh RuntimeException khi call method throwException() method hay không. Nếu phát sinh Exception thì tức là Test thành công.

Trong đoạn code này, chúng ta thấy có gán thêm "expected" vào tên biến Exeption, nếu không phát sinh Exception thì sẽ call method fail() và kiểm thử là thất bại.

Hạn chế 4: Khá ít xử lý check validate cho xử lý trước sau

JUnit 3 sử dụng 2 phương thức là setUp() và tearDown() giúp chúng ta tránh được việc trùng mã khi nhiều test cùng chia sẻ nhau ở phần khởi tạo và dọn dẹp các biến. Tuy nhiên, 2 phương thức này lại được gọi ở trước và sau các phương thức test. Trong lúc xử lý khởi tạo thì chỉ gọi 1 lần theo đơn vị TestClass chứ không phải theo TestMethod.

Picture 2.jpg

Figure1 TestFlow of JUit3

**Hạn chế 5: Chỉ tạo instance tương ứng với số lượng TestMethod **

Đây không phải là vấn đề gì quá to tát nhưng nó là một concept quan trọng của JUnit. Ở cả 2 phiên bản JUnit3 và JUnit4 đều sẽ tạo ra instance cho từng TestMethod. Điều đó có nghĩa là nếu một TestClass nào đó mà có 5 TestMethod thì nó sẽ tạo ra 5 instances cho 5 TestMethod đó.

Picture 3.jpg

Figure2 Chỉ tạo instance tương ứng với số lượng TestMethod

Tại sao lại có cơ chế như vậy? Điều này là bắt nguồn từ suy nghĩ là "Cần phải tiến hành test độc lập". Bằng cách tạo ra các testcase cho từng TestMethod bạn luôn có thể chạy kiểm thử được trong cùng một tình trạng tương tự nhau. Và tùy vào trạng thái của các instance để không ảnh hưởng tới việc thành công hay thất bại của các lần kiểm thử. Tuy nhiên, dù có sử dụng ngôn ngữ chỉ hướng đối tượng hay không thì cũng có lúc rất bất tiện nếu đối tượng không có trạng thái.

**TestNG là gì? **

TestNG là một testing framework được xây dựng dựa trên cảm hứng từ JUnit và NUnit. TestNG không chỉ giải quyết được 5 hạn chế nêu trêu của Junit3 mà còn cung cấp các chỉ dẫn Annotation từ Java SE 5.0 để mô tả về cách kiểm thử.

Trong từ TestNG có từ "NG" có nghĩa là Next Generation, do vậy, nó không phải là biến thể của JUnit và Nunit Người tạo dựng lên công cụ TestNG này là Cedric Beust, một kĩ sư lập trình của Google.

TestNG có 5 tính năng nổi bật sau đây:

  1. Mô tả các thiết lập khác nhau khi kiểm thử bằng file XML
  2. Cung cấp các chỉ dẫn Annotation-based để nhận diện phương thức test
  3. Xác lập cụ thể thời điểm cho các xử lý trước và sau
  4. Phân nhóm kiểm thử
  5. Tạo mối quan hệ ràng buộc lẫn nhau giữa các module

Các yêu cầu hệ thống và cài đặt môi trường cho TestNG, các bạn có thể tham khảo tại đây: http://testng.org/doc/. Sau khi download về, các bạn chỉ cần giải nén archive và add thêm file "testng-X.X-jdk15.jar" vào ClassPath là xong.

Vì TestNG cung cấp chỉ dẫn Annotation từ Java SE 5.0 nên yêu cầu Java version phải từ 5.0 trở lên.

(tobe continued...)

Read more: Part 2: https://viblo.asia/tran.thi.kim.thuy/posts/n7prv3onvKod

0