thắc mắc cách tạo bộ test case cho unit test

Tiện hỏi các thím là các thím viết unit test trước hay sau khi code?
Hỏi câu chán đời thế fen, cứ hiểu unitest là fen viết hàm code một chức năng gì đó trước , rồi sau đó qua 1 class unitest để viết test cho hàm chức năng đó. Còn không muốn viết unitest thì qua viết script automation hệ thống như tôi nè.
 
Last edited:
automation như selenium đó bạn

Thì như tôi nói đấy, 2 cái đó không thay thế mà bổ sung cho nhau. Trong đó unit test là tối quan trọng và bất kì product nào cũng phải có unit test với 80% code coverage.

Sent from Samsung SM-A528B using vozFApp
 
Thì như tôi nói đấy, 2 cái đó không thay thế mà bổ sung cho nhau. Trong đó unit test là tối quan trọng và bất kì product nào cũng phải có unit test với 80% code coverage.

Sent from Samsung SM-A528B using vozFApp
Đúng rồi fen, tôi thấy tester họ viết automation test và dev viết unitest họ đi theo 2 hướng khác nhau hoàn toàn. Không phải là thay thế nhau, mà bổ sung cho nhau để sản phẩm trở nên hoàn thiện. Dev chủ yếu test mấy cái hàm do mình viết ra trong source project, còn tester họ test trên giao diện những thứ mà họ có thể thấy đc.
 
Last edited:
Đúng rồi fen, tôi thấy tester họ viết automation test và dev viết unitest họ đi theo 2 hướng khác nhau hoàn toàn. Không phải là thay thế nhau, mà bổ sung cho nhau để sản phẩm trở nên hoàn thiện. Dev chủ yếu test mấy cái hàm do mình viết ra trong source project, còn tester họ test trên giao diện những thứ mà họ có thể thấy đc.

Chính xác rồi đấy thím.

Sent from Samsung SM-A528B using vozFApp
 
sau, viết trước làm gề nhỉ
nếu cty áp dụng TDD thì phải viết trước.
Thực tế mấy năm đầu đi làm, đa phần viết unit test toàn cover những happy cases hoặc viết xà quần gì đó để tăng tỷ lệ coverage > 90% để deploy thôi nên ưu điểm của việc viết unit test gần như không có
 
Chính xác rồi đấy thím.

Sent from Samsung SM-A528B using vozFApp
Tôi thì không phải dân dev thực thụ nhưng tôi hiểu viết unitest nó giúp người viết hiểu mình đang viết cái gì. Hiểu sâu hơn về code, và tôi ớn nhất là viết unitest cho mấy cái hàm của mấy ông làm về AI, data vì mấy ổng dùng thuật toán, mảng data này nọ để viết tuy ngắn gọn đẹp đẻ nhưng để hiểu đc hàm đó dùng để làm gì thì mò đến vỡ não.
 
Last edited:
nếu cty áp dụng TDD thì phải viết trước.
Thực tế mấy năm đầu đi làm, đa phần viết unit test toàn cover những happy cases hoặc viết xà quần gì đó để tăng tỷ lệ coverage > 90% để deploy thôi nên ưu điểm của việc viết unit test gần như không có

TDD là cái lý thuyết vớ vẩn thôi, thực tế thì code xong mà viết test được là thành công lắm rồi đấy.

Sent from Samsung SM-A528B using vozFApp
 
TDD là cái lý thuyết vớ vẩn thôi, thực tế thì code xong mà viết test được là thành công lắm rồi đấy.

Sent from Samsung SM-A528B using vozFApp
vớ vẩn là do người áp dụng thôi fen. cái gì hợp lý thì sẽ tồn tại, cái gì vẫn còn tồn tại thì ắt hẳn nó phải hợp lý. mình chưa hiểu ý fen chỗ thành công đó nghĩa là gì? chứ cty hiện tại của mình thì code, test nó mới ở giai đoạn đầu của flow thôi
 
vớ vẩn là do người áp dụng thôi fen. cái gì hợp lý thì sẽ tồn tại, cái gì vẫn còn tồn tại thì ắt hẳn nó phải hợp lý. mình chưa hiểu ý fen chỗ thành công đó nghĩa là gì? chứ cty hiện tại của mình thì code, test nó mới ở giai đoạn đầu của flow thôi

Thì như tôi nói là thực tế đó mai fen. Tôi cũng làm vài công ty product lớn có nhỏ có và hầu hết đều cũng chỉ TDD được 1 giai đoạn ngắn mà thôi.

Sent from Samsung SM-A528B using vozFApp
 
Vậy nên ae mới khuyên lúc mới đi làm thì nên vào cty product đó thím :)))
có nhiều nơi làm product không test mà
3vNFzBP.gif
 
Thì như tôi nói là thực tế đó mai fen. Tôi cũng làm vài công ty product lớn có nhỏ có và hầu hết đều cũng chỉ TDD được 1 giai đoạn ngắn mà thôi.

Sent from Samsung SM-A528B using vozFApp
TDD thì anh nên dùng nó như là một lời nhắc nhở để khi thiết kế một hàm nào đó, hoặc một đoạn mã bất kì nào đó thì anh cũng có thể viết test cho nó được. Ví dụ cùng một việc chỉnh màu chỉnh font anh có thể viết trực tiếp ở chỗ render giao diện, nhưng mà vậy sao test được, nên anh sẽ phải tách cái đó ra thành 1 cái lớp trung gian mà ở đó tuỳ theo đầu vào thế nào rồi anh trả ra màu sắc font chữ tương ứng. Rồi viết unit test cho cái lớp đó.
Edit: typo
 
Thì như tôi nói là thực tế đó mai fen. Tôi cũng làm vài công ty product lớn có nhỏ có và hầu hết đều cũng chỉ TDD được 1 giai đoạn ngắn mà thôi.

Sent from Samsung SM-A528B using vozFApp
thank bác, vậy bác có thể chia sẻ nốt câu hỏi của em là làm thế nào cover hết toàn bộ case có thể có của 1 chức năng, em lấy ví dụ cái API ở đầu bài của em đi/ cái post đầu tiên ạ.
 
sau, viết trước làm gề nhỉ

Hỏi câu chán đời thế fen, cứ hiểu unitest là fen viết hàm code một chức năng gì đó trước , rồi sau đó qua 1 class unitest để viết test cho hàm chức năng đó. Còn không muốn viết unitest thì qua viết script automation hệ thống như tôi nè.

Vì mình thấy một số thím viết unit test trước, ở trên cũng có thím viết trước kìa, nên mình thắc mắc không biết triển khai viết test như thế nào.
 
Tạo testcase thì tạo theo spec của hàm cần test. Hàm đó nhiệm vụ là gì, đầu vào, đầu ra. Thớt thử với những hàm đơn giản trước, rồi cứ thế triển khai. Trước tiên thì thử với hàm cộng 2 (truyền vào a, b đầu ra là tổng của a và b) số xem có triển được không?
 
thank bác, vậy bác có thể chia sẻ nốt câu hỏi của em là làm thế nào cover hết toàn bộ case có thể có của 1 chức năng, em lấy ví dụ cái API ở đầu bài của em đi/ cái post đầu tiên ạ.

Tôi nhắc lại Unit Test không phải test chức năng, mà chỉ test từng unit nhỏ như hàm, class... thôi.
Khi thím đặt tên hàm, class thì tự nghĩ đến các test case tương ứng.
Ví dụ như thím tạo hàm Employee get_youngest_employee(List<Employee> employees) để tìm ra nhân viên trẻ nhất thì có thể có các trường hợp sau:
  • danh sách employees bị null hoặc rỗng
  • 1 employee có date_of_birth bị null.
  • hàm không được thay đổi số lượng employee trong danh sách.
  • hàm không được thay đổi bất kỳ thông tin nào của các employee
...
 
bình thường viết test và test là mặc định chứ nhỉ bác. Junit, mockito thì quan tâm đến input, output của function, nếu mock thì quan tâm đến hành vi của function đó. Ngoài coverage hết line of code thì quan tâm đến điều kiện rẽ nhánh trong function nữa
 
Unit test, bản thân tên loại test đã nói lên ý nghĩa của nó, đó là test các unit. Vậy thế nào là 1 unit?
Trong coding, unit là 1 đơn vị thực hiện nghiệp vụ, thường là function. Đương nhiên, 1 function không thể bao quát toàn bộ nghiệp vụ, nên thường có các function con, sau đó function cha gọi vào. Lúc này các function con là các unit nhỏ hơn, và các function cha là các unit lớn. Mỗi function nên có các unit test của riêng nó.
Vậy làm sao test được tính đúng đắn của function cha khi nó phụ thuộc vào kết quả của function con như vậy? Người ta sinh ra khái niệm mock. Mock bản chất chính là bản giả lập lại behavior của function thực, nhưng trả ra tập kết quả mong muốn từ trước để phục vụ việc unit test ở các caller. Việc sử dụng interface trong coding ngoài việc đảm bảo DI, bla bla... còn để phục vụ việc mock giữa các layer dễ dàng, giúp unit test ở các function sử dụng interface dễ dàng hơn.
Thím chủ thớt tìm hiểu rõ thêm phần mock là sẽ hiểu viết unit test ntn, và code ntn để viết unit test dễ nhất.
 
Last edited:
Back
Top