Bài 33.5: Bài tập thực hành test suite

Khi xây dựng ứng dụng web Front-end phức tạp, việc kiểm thử trở nên cực kỳ quan trọng để đảm bảo chất lượng và độ tin cậy của code. Tuy nhiên, khi số lượng bài kiểm thử tăng lên, việc quản lý chúng có thể trở nên lộn xộn và khó theo dõi. Đây chính là lúc Test Suite (Bộ kiểm thử) phát huy sức mạnh của mình.

Test Suite, về bản chất, là một tập hợp có tổ chức các bài kiểm thử có liên quan chặt chẽ với nhau. Thay vì viết hàng trăm bài kiểm thử riêng lẻ rải rác, chúng ta nhóm chúng lại thành các "bộ" dựa trên chức năng, component, hoặc module mà chúng đang kiểm thử. Điều này giúp chúng ta:

Dễ đọc và hiểu: Nhìn vào cấu trúc Test Suite, bạn biết ngay bộ kiểm thử này đang tập trung vào phần nào của ứng dụng.
Dễ quản lý: Khi cần chạy lại hoặc chỉnh sửa các bài kiểm thử cho một chức năng cụ thể, bạn chỉ cần làm việc với Test Suite tương ứng.
Báo cáo rõ ràng hơn: Các báo cáo kết quả kiểm thử thường hiển thị kết quả theo từng Test Suite, giúp bạn nhanh chóng xác định khu vực nào đang gặp vấn đề.
Kiểm soát việc chạy kiểm thử: Bạn có thể dễ dàng chọn chỉ chạy một Test Suite hoặc một nhóm Test Suite nhất định.

Trong hầu hết các framework kiểm thử JavaScript phổ biến như Jest, Mocha, Jasmine, cấu trúc của Test Suite được định nghĩa bằng hàm describe().

Cấu trúc cơ bản của một Test Suite (`describe`)

Hàm describe() được dùng để tạo ra một khối (block) nhóm các bài kiểm thử lại với nhau. Nó nhận hai đối số:

Một chuỗi mô tả: Đây là tên của bộ kiểm thử, thường nói rõ chức năng hoặc đơn vị code đang được kiểm thử.
Một hàm callback: Bên trong hàm này, bạn sẽ định nghĩa các bài kiểm thử riêng lẻ bằng hàm it() hoặc test().

Ví dụ đơn giản:

// Sử dụng Jest hoặc Mocha
describe('Mô tả chung cho nhóm các bài kiểm thử này', () => {
  // Các bài kiểm thử (test cases) riêng lẻ sẽ nằm ở đây
  // Mỗi bài kiểm thử được định nghĩa bằng 'it' hoặc 'test'
});

Bài kiểm thử riêng lẻ (`it` hoặc `test`)

Bên trong một describe block (Test Suite), chúng ta định nghĩa các bài kiểm thử cụ thể. Mỗi bài kiểm thử tập trung vào một trường hợp sử dụng (use case) hoặc một tình huống (scenario) cụ thể của chức năng đang được kiểm thử. Hàm it() (hoặc test() trong Jest) được sử dụng cho mục đích này.

Tương tự như describe(), it() cũng nhận hai đối số:

Một chuỗi mô tả: Diễn tả điều gì bài kiểm thử này nên làm (thường bắt đầu bằng "should..." hoặc "nên...").
Một hàm callback: Chứa logic kiểm thử thực tế, bao gồm việc gọi code cần kiểm thử và các khẳng định (assertions) để kiểm tra kết quả.

Ví dụ kết hợp describe và it:

// Giả sử chúng ta có một hàm tiện ích đơn giản
function multiply(a, b) {
  return a * b;
}

// Viết Test Suite cho hàm multiply
describe('Hàm multiply()', () => {

  // Bài kiểm thử 1: Nhân hai số dương
  it('nên trả về tích đúng của hai số dương', () => {
    const result = multiply(2, 3);
    // Khẳng định: Kết quả mong đợi là 6
    expect(result).toBe(6);
  });

  // Bài kiểm thử 2: Nhân với số 0
  it('nên trả về 0 khi nhân với số 0', () => {
    const result = multiply(5, 0);
    expect(result).toBe(0);
  });

  // Bài kiểm thử 3: Nhân với số âm
  it('nên trả về tích đúng khi có số âm', () => {
    const result = multiply(4, -2);
    expect(result).toBe(-8);
  });

});

Giải thích code:

Chúng ta có hàm multiply đơn giản.
describe('Hàm multiply()', ...) tạo ra một Test Suite dành riêng cho việc kiểm thử hàm multiply. Tên suite mô tả rõ ràng đối tượng kiểm thử.
Bên trong suite này, chúng ta có ba bài kiểm thử riêng lẻ, mỗi bài được định nghĩa bằng it().
Mỗi bài kiểm thử it() có một mô tả chi tiết về trường hợp đang kiểm thử (hai số dương, nhân với 0, có số âm).
Bên trong mỗi it(), chúng ta gọi hàm multiply với các giá trị đầu vào khác nhau và sử dụng expect(...).toBe(...) để khẳng định rằng kết quả trả về đúng như mong đợi.

Việc nhóm các bài kiểm thử cho multiply vào cùng một describe block giúp chúng ta dễ dàng thấy được tất cả các trường hợp mà chúng ta đã kiểm thử cho hàm này. Khi chạy kiểm thử, báo cáo sẽ hiển thị kết quả của "Hàm multiply()" suite, cho biết bao nhiêu test pass/fail trong nhóm này.

Test Suite lồng nhau

Đối với các module hoặc component phức tạp hơn, bạn có thể cần tổ chức các Test Suite theo cấp bậc bằng cách lồng describe blocks vào nhau. Điều này giúp tạo ra cấu trúc kiểm thử phản ánh cấu trúc của code.

Ví dụ: Kiểm thử một module xử lý người dùng, có thể có các chức năng con như tạo, đọc, cập nhật, xóa (CRUD).

// Giả sử bạn có một service xử lý người dùng
// import * as userService from './userService';

describe('User Service Module', () => {

  // Test Suite con cho chức năng tạo người dùng
  describe('Chức năng tạo người dùng (createUser)', () => {
    it('nên tạo người dùng mới với dữ liệu hợp lệ', () => {
      // Code kiểm thử tạo người dùng hợp lệ
      // expect(...)
    });

    it('nên báo lỗi nếu dữ liệu không hợp lệ', () => {
      // Code kiểm thử tạo người dùng không hợp lệ
      // expect(...)
    });
  });

  // Test Suite con cho chức năng đọc người dùng
  describe('Chức năng đọc người dùng (getUser)', () => {
    it('nên trả về thông tin người dùng theo ID', () => {
      // Code kiểm thử đọc người dùng tồn tại
      // expect(...)
    });

    it('nên trả về null hoặc lỗi nếu người dùng không tồn tại', () => {
      // Code kiểm thử đọc người dùng không tồn tại
      // expect(...)
    });
  });

  // ... các describe khác cho update, delete

});

Giải thích code:

describe('User Service Module', ...) là Test Suite cấp cao nhất, đại diện cho toàn bộ module xử lý người dùng.
Bên trong đó, chúng ta có các describe lồng vào nhau ('Chức năng tạo người dùng', 'Chức năng đọc người dùng'). Mỗi suite con tập trung vào một chức năng cụ thể trong module.
Mỗi suite con lại chứa các bài kiểm thử it() chi tiết cho các trường hợp khác nhau của chức năng đó.

Cấu trúc lồng nhau này mang lại sự rõ ràng tuyệt vời trong báo cáo kiểm thử và giúp bạn dễ dàng xác định chính xác phần nào của code đang gặp lỗi khi một bài kiểm thử thất bại.

Thực hành xây dựng Test Suite

Bài tập thực hành của chúng ta là áp dụng kiến thức về Test Suite để tổ chức các bài kiểm thử. Hãy chọn một module nhỏ hoặc một component đơn giản trong dự án hiện tại của bạn (hoặc tạo mới một file .js/.ts với vài hàm tiện ích).

Các bước thực hiện:

Chọn đối tượng kiểm thử: Quyết định bạn muốn kiểm thử hàm nào, component nào hoặc module nào.
Tạo file kiểm thử: Tạo một file mới bên cạnh file code gốc, thường theo quy ước đặt tên như tenFile.test.js hoặc tenComponent.test.jsx.

Định nghĩa Test Suite cấp cao nhất: Sử dụng describe() để tạo suite chính cho đối tượng bạn chọn. Đặt tên mô tả rõ ràng.

// Ví dụ cho một component 'LoginButton'
describe('Component LoginButton', () => {
  // ... các test suite con hoặc it tests
});

// Ví dụ cho một utility file 'stringUtils.js'
describe('Utility functions in stringUtils', () => {
   // ... các test suite con cho từng hàm
});

Xác định các chức năng/trường hợp con: Nghĩ xem đối tượng kiểm thử có những chức năng phụ nào hoặc bạn cần kiểm thử những nhóm trường hợp nào.

Định nghĩa các Test Suite con (nếu cần): Sử dụng describe() lồng nhau để nhóm các bài kiểm thử cho từng chức năng/trường hợp con đã xác định ở bước 4.

describe('Utility functions in stringUtils', () => {

   describe('function capitalize()', () => {
     // it tests for capitalize
   });

   describe('function truncate()', () => {
     // it tests for truncate
   });

});

Viết các bài kiểm thử it(): Bên trong các describe (suite chính hoặc suite con), viết các bài kiểm thử it() chi tiết cho từng trường hợp cụ thể. Nhớ viết mô tả rõ ràng cho mỗi it.
Thêm assertions: Sử dụng các hàm expect() và matchers phù hợp (như toBe, toEqual, toHaveBeenCalled, toBeInTheDocument, v.v. tùy thuộc vào framework và thư viện bạn dùng) để kiểm tra kết quả.

Gợi ý các đối tượng thực hành:

Một hàm tiện ích xử lý chuỗi (ví dụ: định dạng ngày, cắt chuỗi, kiểm tra email).
Một hàm tính toán đơn giản.
Logic của một React Hook tùy chỉnh.
Một component React đơn giản (chỉ kiểm thử logic hoặc rendering cơ bản).

Lợi ích khi thực hành với Test Suite

Việc dành thời gian tổ chức các bài kiểm thử vào Test Suite ngay từ đầu mang lại những lợi ích lâu dài:

Codebase sạch sẽ hơn: Files kiểm thử được tổ chức gọn gàng, dễ dàng điều hướng.
Bảo trì dễ dàng hơn: Khi code gốc thay đổi, bạn biết chính xác Test Suite nào cần được cập nhật.
Kiểm thử có mục tiêu: Bạn có thể chạy riêng một Test Suite cụ thể trong quá trình phát triển để nhanh chóng kiểm tra thay đổi của mình.
Hiệu quả làm việc nhóm: Các thành viên trong nhóm dễ dàng hiểu được phạm vi kiểm thử và đóng góp thêm bài kiểm thử mới theo cấu trúc đã có.

Bằng cách áp dụng cấu trúc Test Suite (describe) kết hợp với các bài kiểm thử riêng lẻ (it), bạn không chỉ viết code kiểm thử mà còn tạo ra một tài liệu sống động về cách hoạt động của ứng dụng của mình.

Hãy bắt tay vào thực hành ngay bài tập này. Chọn một phần nhỏ trong project của bạn và thử nhóm các bài kiểm thử liên quan lại với nhau bằng describe. Bạn sẽ thấy quy trình kiểm thử trở nên hiệu quả và dễ quản lý hơn rất nhiều.

Comments

There are no comments at the moment.