“Dev là đấng sáng tạo ra phần mềm, tạo ra những feature hay ho thì tester là đội tìm cách phá phách nó” =))
Việc của ae dev là viết ra feature, phát triển phần mềm, vì ae là con người nên k tránh khỏi sai sót, thường xuyền cài cắm bug vào trong feature và luôn tin tưởng tuyệt đối đống code ae viết ra là đúng là chân ái. Còn việc của ce (thường là chị iem) là kéo ae xuống mặt đất, trở về với thực tại, là lôi 1 đống bug ra cho ae fix, chỉ ra là phần mềm như cc, code đầu cá gì toàn bug, chưa test đã dẹo .v.v, và làm giảm performance của ae mỗi kỳ review lương =))
Đặc thù công việc hơi trái ngược nhau nên ace thường xuyên combat, ẩu đả, cãi vã .v.v nhưng đều có 1 mục đích chung là đảm bảo “chất lượng và độ tin cậy của sản phẩm”
Vì vậy tư duy test cũng rất quan trọng với ae dev,
Giúp ae nhìn ra những case gây lỗi và bổ sung code cho những case đó, tránh để tester log bug mới update code như vậy sẽ mất nhiều thời gian (tiết kiệm thời gian cho cả dev và tester)
Giúp ae cấu trúc code tốt hơn (code xịn thì dễ viết code test hơn) như vậy nâng cao chất lượng code
Phân loại “test”
white box: hộp trắng nghĩa là ta có thể nhìn từ bên ngoài thấy được nội dung bên trong của hộp, test kiểu này nghĩa là chúng ta biết về source code dưới góc nhìn của dev, test nhằm mục đích kiểm tra code có chạy đúng hay không
black box: ngược lại với white bock, tester k biết gì về source code, dưới góc nhìn của người dùng kiểm tra xem feature có chạy đúng hay k
hoặc có thể phân biệt theo cách thứ 2 là:
manual test: automation chạy bằng cơm, con người test, tester trực tiếp sử dụng phần mềm, kiểm tra hệ thống có hoạt động đúng hay k
automation: viết code để test phần mềm, với đầu vào và kiểm tra kết quả đầu ra với kỳ vọng ban đầu
Thường thì luồng làm việc của ae dev sẽ như sau
ae sẽ thấy vấn đề trong mô hình ở trên:
một số feature việc self test mất rất nhiều thời gian, nếu ae code có nhiều bug thì lại mất rất nhiều thời gian để self test để đảm bảo bug đã được fix và k tạo ra siêu phẩm “fix bug này sinh ra bug khác”, hoặc “fix bug này gây bug cũ đã được tester verify”
1 case nữa là khi cần refactor code thì làm thế nào đảm bảo feature vẫn hoạt động như ban đầu => tự self test lại hết các case
vậy làm thế nào? mở bài khá dài dòng nhỉ =)) câu trả lời ở cái tiêu đề bài viết này (trong khuôn khổ bài viết này mình nói về php – laravel)
Lúc trước người anh béo tóc hói của mình có làm 1 buổi sharing về feature trong laravel, k biết còn bao nhiêu ae nhớ được buổi hôm ấy, chứ chưa nói về nội dung của nó là gì =))
gợi nhớ lại cho ae thì 1 số keyword a Quân có nhắc tới nhiều trong buổi sharing là “xanh” và “đỏ”, chắc a chơi cổ hay xem chart =))
đây nhá:
buổi sharing đó rất có ý nghĩa, và truyền cảm hứng cho mình tiếp tục phát triển thêm đề tài này
Unit test và feature test đều thuộc white box test đây là 2 loại test mà dev thường sử dụng trong quá trình làm việc
nhưng trước khi giới thiệu về feature test, mình nghĩ ae cần biết unit test trước
vậy câu hỏi là unit test là gì? tại sao lại cần unit test?
ae search thì k thiếu kết quả cho các câu hỏi này, dưới góc nhìn của mình, unit là đơn vị, unit test là test đơn vị, đảm bảo rằng mỗi 1 đơn vị trong source code đều hoạt động đúng mong đợi.
unit test là độc lập k ảnh hưởng tới các unit khác, dễ triển khai, tiết kiệm thời gian và tái sử dụng
Trong doc của laravel thì k nhắc đến unit test, nhưng laravel đã tích hợp sẵn
để tạo 1 file unit test mới:
giả sử class User có nội dung như sau
có 1 function tính tổng 2 tham số truyền vào
flow với unit test như sau:
thiết lập môi trường, tham số đầu vào -> giả định kết quả đầu ra -> chạy code test -> so sánh kết quả đầu ra và giả định (cũng tương tự flow các luồng test khác như feature test)
b1: thiết lập môi trường: tạo đối tượng User: new User
tham số đầu vào: 1 và 2 chạy qua hàm total: $user->total(1,2);
b2: giả định kết quả đầu ra: là 3
b3: chạy code test: $result = $user->total(1,2);
b4: so sánh đầu ra và giả định ban đầu: $this->assertEquals(3,$result);
vậy cần test function total, update code file UserTest.php như sau
sau đó chạy: php artisan test
hoặc php artisan test path_file_test
kết quả sẽ như sau:
đây là 1 case khá đơn giản trong unit test nhưng cũng đủ giúp ae hiểu được luồng thực hiện 1 unit test, hẹn ae trong các bài viết tiếp theo trong series “laravel testing code”
