Software Testing: Đảm bảo Chất lượng Phần mềm

Trả lời: Để đảm bảo code chạy đúng như mong đợi, phát hiện lỗi sớm khi thay đổi code (regressions), và giúp code dễ bảo trì hơn.

Trả lời: Là việc kiểm thử một đơn vị nhỏ nhất của mã nguồn (thường là một hàm hoặc một class) một cách cô lập.

Trả lời: Là framework kiểm thử phổ biến nhất cho PHP, được Laravel tích hợp sẵn để viết và chạy các bộ test.

Trả lời:

• Unit Test: Chỉ test logic của code, không khởi động Laravel framework (nhanh).
• Feature Test: Test một tính năng hoàn chỉnh, có gửi request HTTP và khởi động framework (chậm hơn nhưng bao quát hơn).

Trả lời: Là câu lệnh khẳng định kết quả mong đợi. Ví dụ: assertEquals(10, $sum) nghĩa là tôi mong đợi biến $sum phải bằng 10.

Trả lời: Quy trình: Viết test lỗi -> Viết code cho test qua -> Refactor (Red-Green-Refactor).

Trả lời: Dùng lệnh php artisan test hoặc ./vendor/bin/phpunit.

Trả lời: Là việc tạo ra một object “giả” để thay thế cho một service thực tế (như API bên thứ 3) nhằm mục đích kiểm soát kết quả trả về trong lúc test.

Trả lời: Để tránh làm hỏng dữ liệu thực tế (Production/Dev) và đảm bảo môi trường test luôn sạch sẽ, có thể dự đoán được.

Trả lời: Phần trăm mã nguồn đã được thực thi bởi các bộ test. Tuy nhiên, coverage cao không đồng nghĩa với việc không có bug.

Trả lời: Integration Test kiểm tra sự tương tác giữa nhiều thành phần (ví dụ: Controller gọi Service gọi Database) thay vì chỉ kiểm tra từng phần riêng lẻ.

Trả lời:

• Stub: Chỉ trả về dữ liệu cố định.
• Mock: Kiểm tra xem object đó có được gọi với tham số đúng và số lần đúng hay không.

Trả lời: Dùng method $this->actingAs($user) để giả lập một user đã đăng nhập trước khi thực hiện request.

Trả lời: Nó sẽ chạy lại toàn bộ migrations trước mỗi lần chạy test để đảm bảo cấu trúc DB luôn mới nhất và sạch sẽ.

Trả lời: Vì nó gây ra sự phụ thuộc cứng nhắc (Hard dependency), khiến bạn không thể thay thế (Mock) object đó khi viết Unit Test. Nên dùng Dependency Injection.

Trả lời: Dùng Mail::fake() hoặc Event::fake(). Laravel sẽ chặn việc gửi thật và cho phép bạn assert xem chúng có được gọi không.

Trả lời: Là cách nhóm các file test lại với nhau (ví dụ: nhóm Unit và nhóm Feature) để chạy riêng biệt trong file phpunit.xml.

Trả lời: Cho phép bạn định nghĩa các trạng thái khác nhau của dữ liệu mẫu (ví dụ: User trạng thái admin hoặc suspended) để tái sử dụng trong test.

Trả lời: Dùng $this->artisan('command:name')->expectsOutput('...')->assertExitCode(0).

Trả lời: assertTrue kiểm tra giá trị là true. assertSame kiểm tra cả giá trị và kiểu dữ liệu (strict comparison) giữa hai biến.

Trả lời: Ưu tiên viết nhiều Unit Tests (nhanh, rẻ), ít Integration Tests hơn, và ít nhất là End-to-End (E2E) Tests (chậm, đắt).

Trả lời: Dùng Queue::fake(). Bạn có thể assert xem một Job cụ thể có được đẩy vào queue với dữ liệu đúng hay không.

Trả lời: Dùng để đảm bảo sự tương thích giữa API Provider và API Consumer. Nếu một bên thay đổi cấu trúc dữ liệu, test sẽ báo lỗi ngay lập tức.

Trả lời: Dùng Carbon::setTestNow($fixedDate) để “đóng băng” thời gian tại một thời điểm cụ thể, giúp kết quả test luôn ổn định.

Trả lời: Tự động thay đổi logic code (ví dụ đổi > thành <) và chạy lại test. Nếu test vẫn pass, nghĩa là bộ test của bạn chưa đủ tốt để phát hiện lỗi logic.

Trả lời: Dusk khởi động trình duyệt thật (Chrome) để thực hiện các thao tác như click, nhập liệu, và kiểm tra giao diện như một người dùng thật.

Trả lời: Khiến test quá phụ thuộc vào cấu trúc code bên trong (implementation details). Khi refactor code, test sẽ bị hỏng dù logic vẫn đúng.

Trả lời: Dùng các công cụ như phpbench hoặc viết test assert thời gian thực thi của một tác vụ không được vượt quá ngưỡng X ms.

Trả lời: Sử dụng lệnh php artisan test --parallel để tận dụng nhiều nhân CPU chạy nhiều bộ test cùng lúc, giúp giảm thời gian chờ đợi đáng kể.

Trả lời: Dùng $this->withoutExceptionHandling() để Laravel throw lỗi thật ra thay vì trả về view lỗi, giúp bạn debug trực tiếp trong terminal khi test fail.

Trả lời: Sử dụng Github Actions/Gitlab CI. Chạy test tự động mỗi khi có Pull Request. Dùng các công cụ như Codecov để kiểm tra và chặn merge nếu không đạt chỉ số.

Trả lời: Kết hợp: 1. Unit test cho từng service. 2. Contract test cho giao tiếp giữa các service. 3. End-to-End test cho các luồng nghiệp vụ quan trọng nhất.

Trả lời: Hiện tượng thay đổi kiến trúc code chỉ để làm cho nó dễ test hơn (ví dụ biến mọi thứ thành public). Architect cần cân bằng giữa tính dễ test và tính đóng gói của code.

Trả lời: Không thể migration toàn bộ. Dùng “In-memory database” cho logic tests. Dùng “Partial production data snapshot” (anonymized) cho integration tests.

Trả lời: TDD rất tốt cho logic phức tạp nhưng có thể làm chậm quá trình prototype. Cần linh hoạt: TDD cho core logic, Feature test cho UI/Flow.

Xử lý: 1. Chạy Parallel testing. 2. Mock các API/Service chậm. 3. Dùng In-memory DB (SQLite). 4. Tách các test E2E/Dusk ra chạy riêng.

Xử lý: 1. Viết một test case tái hiện đúng bug đó (test sẽ fail). 2. Sửa code để test pass. 3. Deploy code kèm theo test case đó để đảm bảo bug không quay lại.