thắc mắc Các bác viết unit test thế nào ạ.

Code Vì Đam Mê · 20/1/22

Mình đã từng dev một proj khá lớn. Và mình nhận ra UT và AT (Acceptance test) là dùng để giúp người mới viết feature mới mà ko làm sai lệch những feature cũ.
Hơn nữa UT cũng giúp bạn refactor code một cách tự tin mà ko sợ break function.

1 vd UT về test một cái API get user chẳng hạn

API thì nó gồm 1 controller, 1 cái service. Thường thì bạn sẽ phải unittest cái service đó, cách test như sau:
_Tạo class test, tạo mock các dependency của service cần dùng.
_Tạo mock data: ở đây là tạo 1 instance User
_Khởi tạo service cần test.
_Viết hàm test, ở đây là hàm test_GetUser. Mock cái instance kia vào service, thường là mock vào 1 cái method getUserFromDB của service, sau đó assert kết quả trả về của service đó có equal cái instance mình bỏ vào ko.

Thường là khi test service như vậy phải viết tối thiểu 3 case, 1 là case bt, 2 là null, 3 là exception.

P/S: Lâu qúa ko viết UT nên nhớ mang máng là vậy. Hồi đó có 1 dạo phải đi tăng coverage cho cái app nên còn phải UT cho mấy cái equal, hashcode, toString nữa cơ :shame:

Pepe.The.Frog · 20/1/22

Code Vì Đam Mê đã nói:
Mình đã từng dev một proj khá lớn. Và mình nhận ra UT và AT (Acceptance test) là dùng để giúp người mới viết feature mới mà ko làm sai lệch những feature cũ.
Hơn nữa UT cũng giúp bạn refactor code một cách tự tin mà ko sợ break function.

1 vd UT về test một cái API get user chẳng hạn

API thì nó gồm 1 controller, 1 cái service. Thường thì bạn sẽ phải unittest cái service đó, cách test như sau:
_Tạo class test, tạo mock các dependency của service cần dùng.
_Tạo mock data: ở đây là tạo 1 instance User
_Khởi tạo service cần test.
_Viết hàm test, ở đây là hàm test_GetUser. Mock cái instance kia vào service, thường là mock vào 1 cái method getUserFromDB của service, sau đó assert kết quả trả về của service đó có equal cái instance mình bỏ vào ko.

Thường là khi test service như vậy phải viết tối thiểu 3 case, 1 là case bt, 2 là null, 3 là exception.

P/S: Lâu qúa ko viết UT nên nhớ mang máng là vậy. Hồi đó có 1 dạo phải đi tăng coverage cho cái app nên còn phải UT cho mấy cái equal, hashcode, toString nữa cơ

Đi ngang qua đây nên sẵn tiện hỏi luôn. Khi viết unit test cho service thì có nên mock data access layer (repository) hoặc dbContext ko? Hay viết thẳng luôn xem như integration test cho cả service và data access layer. Chạy test xong có data save vào database luôn rồi lúc assert phải get lên lại để so sánh.

via theNEXTvoz for iPhone

LightYear · 20/1/22

Pepe.The.Frog đã nói:
Đi ngang qua đây nên sẵn tiện hỏi luôn. Khi viết unit test cho service thì có nên mock data access layer (repository) hoặc dbContext ko? Hay viết thẳng luôn xem như integration test cho cả service và data access layer. Chạy test xong có data save vào database luôn rồi lúc assert phải get lên lại để so sánh.

via theNEXTvoz for iPhone

UT thì không đụng vào DB nhé, thay vào đó là mock data sau đó kiểm tra xem service có xử lý đúng với input mình cho vào không

Pepe.The.Frog · 20/1/22

LightYear đã nói:
UT thì không đụng vào DB nhé, thay vào đó là mock data sau đó kiểm tra xem service có xử lý đúng với input mình cho vào không

Thế khi nào test cho database? Và khi test thì save xuống rồi lấy lên query để get lên lại?

Cái này tuỳ mình thôi. Nếu muốn mock luôn cả Data Access Layer thì phải thêm 1 class nữa để test thằng này. Còn đơn giản thì test 2 chổ (Controller + Service có bao gồm luôn DAL) vì thực tế đa số service toàn CRUD nên logic thật sự nằm ở DAL nhiều hơn.

LightYear · 20/1/22

Pepe.The.Frog đã nói:
Thế khi nào test cho database? Và khi test thì save xuống rồi lấy lên query để get lên lại?

Test đụng đến DB là integration test, coi như lên kịch bản một user vào thêm sửa xoá

Pepe.The.Frog · 20/1/22

LightYear đã nói:
Test đụng đến DB là integration test, coi như lên kịch bản một user vào thêm sửa xoá

Thì đấy, đàng nào chả phải viết test, thế thì viết 1 cái unit test cho thằng service nhưng ko mock thằng DAL cho nhanh mà lại an toàn, vì đảm bảo cái service chạy đúng cả chổ lưu vào db.

Theo tôi nên viết unit test 2 chổ thôi 1 là controller (mock service) 2 là service (ko móc DAL) test thẳng từ service -> database luôn như vậy dc ko? Vừa đảm bảo đủ code coverage + ít tốn công sức

DoubleH2 · 4/2/22

Bình thường mình test cứ làm theo 3 bước AAA (Arrange, Act, Assert), chủ yếu là code logic ms viết unit test còn cái nào dính DB thì dùng mock (fake dữ liệu DB trả về).

Lucianz · 5/2/22

Head First Java đã nói:
thím cho em hỏi nghiêm túc tí: (nếu thím có chơi liên minh)
thường khi chơi liên minh, em rất hay chơi kiểu kì dị ví dụ như tướng đi rừng mang ra lane, tướng đi lane mang đi rừng hay tướng support đi mid hay mang tướng đi mid support....bla bla bla...
thỉnh thoảng rất hay thọt nhưng vài trường hợp hiệu quả vô cùng và em hay đi trước xu hướng meta mọi người hay chơi. kiểu như sau này mới có người chơi giống như vậy.
Tương tự, như thím nói những test case kì dị mà dev éo bao giờ nghĩ ra. giống như những con tướngđã bịápđặt số phận truyền thống mà em lại làmđều ngược lại.
với tố chất như vậy thì em có phù hợp làm QC/QA không? thực sự em cũng rất đam mê và tìm hiểu cũng nhiều về mảng này.
thêm nữa: tại em thấy em lập trình ko có gì nổi trội so với đám đông. nên muốn tìm hướng đi phù hợp hơn. giống như chơi liên minh có 5 vai trò khác nhau. nhưng nếu mình làm tốt 1 vai trò mà ít ai làm được thì sẽ lên rank nhanh hơn. không ai ép buộc được mình phải đi vài trò này vai trò kia. Hay là phải đi theo đám đông mới thành công được. Mind set em khá dị! Thím có thấy em như vậy ko?

Cứ thử. Chỗ tôi dev thì hàng xóm QA

) bên đó chỉ có châm ngôn là đã test là phải có lỗi. Không lỗi thì là code cũ

))

Gửi từ Xiaomi Redmi Note 9S bằng vozFApp

Lucianz · 5/2/22

daydreamm đã nói:
em xem chanel EasyFrontend thấy nói FE ít khi phải viết unit test, đa số bên BE.

Nhưng em mới vô dự án thấy được giao viết test, trong khi code base còn chưa nắm. Rồi component nào cũng phải test, trong khi đọc blog thì không phải component nào cũng cần test.

Viết test cho code người khác nữa , thực sự điên đầu

FE thì js vẫn có thư viện test js mà nhỉ. Nói chung nên test. Để xem asset load có ổn dịnh không

)

Gửi từ Xiaomi Redmi Note 9S bằng vozFApp

Vinh69 · 5/2/22

Pepe.The.Frog đã nói:
Thì đấy, đàng nào chả phải viết test, thế thì viết 1 cái unit test cho thằng service nhưng ko mock thằng DAL cho nhanh mà lại an toàn, vì đảm bảo cái service chạy đúng cả chổ lưu vào db.

Theo tôi nên viết unit test 2 chổ thôi 1 là controller (mock service) 2 là service (ko móc DAL) test thẳng từ service -> database luôn như vậy dc ko? Vừa đảm bảo đủ code coverage + ít tốn công sức

Không được đâu fen , bản chất tách ra service vs repository là để dễ unit test cho từng phần , fen lại viết unit test chạy 1 luồn như vậy lun là đi ngược lại design rồi :shame:

.Project hiện tại mình đang làm bọn nó viết unit test cho repo kiểu tạo connection đến database local rồi CRUD thẳng trên database đó lun sau đó revert changes lại , k biết có bác nào đang dùng như vậy k :shame:

Pepe.The.Frog · 5/2/22

Vinh69 đã nói:
Không được đâu fen , bản chất tách ra service vs repository là để dễ unit test cho từng phần , fen lại viết unit test chạy 1 luồn như vậy lun là đi ngược lại design rồi .Project hiện tại mình đang làm bọn nó viết unit test cho repo kiểu tạo connection đến database local rồi CRUD thẳng trên database đó lun sau đó revert changes lại , k biết có bác nào đang dùng như vậy k

Với kinh nghiệm của tôi thì đó là cách tốt nhất để đảm bảo thằng repo work đúng. Đối với repo thì nên viết integration test như vậy luôn chứ tách ra rồi lúc code thật chạy trên production thì lại văng lỗi.

À mà hiện tại xài ORM rồi nên tôi ko hiểu mấy anh viết thêm repository để làm cái quái gì nữa.

Xài 2 layer. Controller và Services là đủ rồi.

Như đã nói ở trên. Code CRUD thì logic chính nằm ở data access. Ko biết mấy anh làm 3 layer thì lúc tách ra viết unit test cho services để làm chi trong khi đa phần services nó wrap repo.

via theNEXTvoz for iPhone

rauma01 · 5/2/22

Unit test là kiểm thử cho từng đơn vị nhỏ nhất. Thường thấy là test cho các function. Thông thường sẽ không có lý do gì để bạn phải commit thay đổi cho unit test của service.login function khi bạn đổi cấu trúc db. Việc chuẩn bị dữ liệu trong db để cover các test case ở service cũng tương đối mất thời gian. Về logic thì service chỉ cần gọi đúng hàm ở repo với đúng params là ok, đó là unit test. Hơn nữa trong trường hợp test của bạn không kết nối được tới db làm test bị fail, thì đó không phải thứ mà unit test không hướng tới. Bạn chạy ut 1000 lần thì phải nhận được kết quả như nhau. Việc kết nối tới db bạn có thể cover bằng cách viết intergration hoặc e2e. Với mình, ut còn để lưu lại spec cho từng func, càng rõ ràng, càng độc lập càng tốt. Mình cũng chưa bao giờ viết ut cho repo layer, trong đó không có logic chỉ có các câu quẻy.

via theNEXTvoz for iPhone

Pepe.The.Frog · 5/2/22

rauma01 đã nói:
Unit test là kiểm thử cho từng đơn vị nhỏ nhất. Thường thấy là test cho các function. Thông thường sẽ không có lý do gì để bạn phải commit thay đổi cho unit test của service.login function khi bạn đổi cấu trúc db. Việc chuẩn bị dữ liệu trong db để cover các test case ở service cũng tương đối mất thời gian. Về logic thì service chỉ cần gọi đúng hàm ở repo với đúng params là ok, đó là unit test. Hơn nữa trong trường hợp test của bạn không kết nối được tới db làm test bị fail, thì đó không phải thứ mà unit test không hướng tới. Bạn chạy ut 1000 lần thì phải nhận được kết quả như nhau. Việc kết nối tới db bạn có thể cover bằng cách viết intergration hoặc e2e. Với mình, ut còn để lưu lại spec cho từng func, càng rõ ràng, càng độc lập càng tốt. Mình cũng chưa bao giờ viết ut cho repo layer, trong đó không có logic chỉ có các câu quẻy.

via theNEXTvoz for iPhone

Chưa bao giờ viết UT cho repo thế thì làm sao đảm bảo data được lưu xuống database đúng? Hoặc lúc save xuống table ko bị lỗi?

via theNEXTvoz for iPhone

onitake92 · 5/2/22

Project mình yêu cầu ut cho feature. Ok đồng ý có ut cover method mượt vl, nhưng đm đã kêu ut còn dí deadline thì ut cái cc :canny:

thanhtplxag · 5/2/22

Đang làm project có ut mỗi lần đổi business có khi phải sửa mấy trăm cái test case ngán thực sự :ah:

được cái mỗi lần refactor thấy tự tin hẵn :confident:

Messii · 6/2/22

thanhtplxag đã nói:
Đang làm project có ut mỗi lần đổi business có khi phải sửa mấy trăm cái test case ngán thực sự được cái mỗi lần refactor thấy tự tin hẵn

thì upgrade function lên v2 thôi quý anh :shame:

via theNEXTvoz for iPhone

xoanmen · 6/2/22

Pepe.The.Frog đã nói:
Với kinh nghiệm của tôi thì đó là cách tốt nhất để đảm bảo thằng repo work đúng. Đối với repo thì nên viết integration test như vậy luôn chứ tách ra rồi lúc code thật chạy trên production thì lại văng lỗi.

À mà hiện tại xài ORM rồi nên tôi ko hiểu mấy anh viết thêm repository để làm cái quái gì nữa.

Xài 2 layer. Controller và Services là đủ rồi.

Như đã nói ở trên. Code CRUD thì logic chính nằm ở data access. Ko biết mấy anh làm 3 layer thì lúc tách ra viết unit test cho services để làm chi trong khi đa phần services nó wrap repo.

via theNEXTvoz for iPhone

Mấy cái ORM sẵn có đôi khi nó gây ra cơ số tác hại về performance, mấy anh em dev tôi toàn kêu custom gần hết cái đống của nợ đấy. Code nhiều quen tay sau ko custom lại thấy nhớ :v

Donald Trump USA_No1 · 6/2/22

Đi làm gần 2 năm nhưng chưa viết Unit Test bao giờ.

Các thím cho e hỏi giả sử 90% logic viết trong store ở DB, thì việc Unit Test gần như vô dụng đúng ko nhỉ?

Pepe.The.Frog · 6/2/22

Donald Trump USA_No1 đã nói:
Đi làm gần 2 năm nhưng chưa viết Unit Test bao giờ.

Các thím cho e hỏi giả sử 90% logic viết trong store ở DB, thì việc Unit Test gần như vô dụng đúng ko nhỉ?

Có thể viết UT bằng SQL cho stored procedure nhưng như vậy bỏ effort ra ko cần thiết so với lợi ích thu lại.

Cách đơn giản nhất là viết integration test thẳng từ service xuống database để lúc gọi stored procedure đảm bảo nó thêm data hoặc trả data đúng ko.

Như đã nói ở trên, app CRUD thì logic nặng ở tầng DAL hoặc thậm chí ở tầng database luôn. Tôi vẫn ko prefer cách mock database vì ko thể đảm bảo code chạy đúng khi lên production.

Ví dụ: database có constraints not null, unique, hoặc table thiếu 1 column..v.v.. nếu mock database thì mặc dù code phía trên test coverage 90% cũng ko sure là lúc insert record vào ko văng exception.

Donald Trump USA_No1 · 6/2/22

Pepe.The.Frog đã nói:
Có thể viết UT bằng SQL cho stored procedure nhưng như vậy bỏ effort ra ko cần thiết so với lợi ích thu lại.

Cách đơn giản nhất là viết integration test thẳng từ service xuống database để lúc gọi stored procedure đảm bảo nó thêm data hoặc trả data đúng ko.

Như đã nói ở trên, app CRUD thì logic nặng ở tầng DAL hoặc thậm chí ở tầng database luôn. Tôi vẫn ko prefer cách mock database vì ko thể đảm bảo code chạy đúng khi lên production.

Ví dụ: database có constraints not null, unique, hoặc table thiếu 1 column..v.v.. nếu mock database thì mặc dù code phía trên test coverage 90% cũng ko sure là lúc insert record vào ko văng exception.

E k viết UT bh nhưng mà có principle viết UT là không động đến db thật, ut chỉ viết trên logic code bác ạ

thắc mắc Các bác viết unit test thế nào ạ.

Junior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Member

Senior Member

Senior Member

Member

Senior Member

Đã tốn tiền

Senior Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này