thảo luận Chia sẻ về Unit Testing và TDD

anh lập trình viên 1996 đã nói:

startup nên cả frontend lẫn backend đều ko có test ))

Nhấp để mở rộng...

Love U So Much đã nói:

đời cha ăn mặn đời con khát nước , thế hệ dev f3 f4 sẽ ko để các anh yên nghỉ

Nhấp để mở rộng...

EmBeBongBong123 đã nói:

trong tất cả các công ty, chỉ có một số lượng nhất định công ty/dự án có viết test. Trong những công ty có viết test đó, tìm được những dự án viết test một cách có tâm nhất lại càng khó hơn Nhiều dự án có viết test nhưng chủ yếu chỉ đối phó, code xong rồi viết test để cover hết if else exception (unit test chỉ để làm cho có chứ không đóng góp gì vào việc tìm bug ) . Đúng là cái TDD này sinh ra để counter lại chuyện đó, mà có làm hay không cũng phải do ý thức con người
Một vài người còn sửa code CHỈ ĐỂ viết đc unit test thì nó còn lệch lạc hơn nữa

Nhấp để mở rộng...

• UT apply TDD để docs lại requirement là quá tuyệt vời, sau refactor cũng đỡ sợ
• Tình hình ở vn là ép chạy sml nên mình chỉ UT 1 số case mình nghĩ ra ngay lập tức lúc đó. Này có lợi là sẽ note lại cho dev sau và note lại cho bản thân mình ngay khi chưa viết code implement. Trong quá trình implement sẽ lòi ra vài case nữa nên sẽ nhét vô để note lại, implement xong chạy lại case mới phát sinh đó.
• Kết hợp integration test bằng postman
• Kết hợp team QA test

qkhanhpro1 đã nói:

Tôi nghĩ #39 nói rất đúng. Thật sự tôi không rõ định nghĩa Unit Test của mỗi người là như thế nào để chúng ta có thể thảo luận được một cách tử tế về chủ đề này

(1) Nếu Unit Test nhắm tới các khối code nhỏ nhất như #1 nói đến hoặc như nhiều người "preach" thì đúng... nó sẽ rất "dễ" ... dễ đến mức Unit Testing không còn ý nghĩa gì nữa ?
Để có được mức độ Isolation như vậy thì Unit Test này phải test các khối code rất nhỏ, các phép toán như createSaltedPassword() hay CustomGraphGetNodeByPropertyValue()

(2) Tôi tin phần lớn các test chúng ta viết rơi vào trường hơp "Integration Test / Integration Unit Test" khi đã có đủ các thể loại ban bệ (dependency) trong source code của bạn. Giả sử bạn có 1 hàm như thế này - từ Jellyfin

private StreamInfo BuildVideoItem(MediaSourceInfo item, VideoOptions options)

Nhìn thì có vẻ rất đơn giản - chỉ có 2 parameter. Tuy nhiên mỗi object được gửi vào có một tấn property và bản thân hàm này cũng cho ra 1 tấn các kết quả khác nhau. Vậy chúng ta làm gì với nó?

• Mock tất cả mọi thứ và test tất cả mọi thứ? ... well nhắc đến mock thì nó lại là một ổ sâu khác
• Không test nó?
• "Hàm trên chưa được viết tốt, khi chúng ta đã phân chia công việc một cách tử tế / đủ nhỏ để unit test thì sẽ không bao giờ xảy ra trường hợp như thế này, bản thân các hàm khác nhỏ hơn được hàm này gọi đã được test thì chúng ta sẽ không bao giờ gặp trường hợp như thế này" - Tôi nghĩ lập luận này là cứt bò. Nếu đập tất cả mọi thứ nhỏ đến mức có thể làm một cái "unit test" hoàn toàn độc lập, nhỏ đến mức trivial như ở điểm (1) thì cái chúng ta có sẽ là x10 số lượng hàm ( Để giảm độ phức tạp từng hàm?) , x10 số lượng class (Để giảm số property trên mỗi class?) , x10 độ sâu call stack ( Hậu quả của việc xẻ nhỏ hàm) và x100 LOC mà không mang lại giá trị gì thật sự cả

Nhận định cá nhân: Nếu một developer thực sự nghĩ trước khi implement một thứ gì trong cùng một lượng thời gian với một developer dùng thời gian đó để nghĩ và viết unit test thì tôi tin tưởng nhiều hơn vào chất lượng của người nghĩ và không viết unit test. Thứ mà unit test mang lại là nó ép developer phải nghĩ. Chất lượng code tốt hơn vì developer đó đã nghĩ kỹ trước khi implement, không phải vì bản thân việc viết Unit Test
Điểm tốt khác là sớm phát hiện breaking changes. Cái này thực sự là một điểm + lớn, không phải bàn cãi

Nhấp để mở rộng...