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

  • Người tạo chủ đề Người tạo chủ đề TrungNgaoNgo
  • Ngày bắt đầu Ngày bắt đầu
Pepe.The.Frog đã nói:
Vẫn câu hỏi trên, hỏi thím kia nhưng chưa đc trả lời:

"Thế làm sao đảm bảo data lưu xuống database tables đúng?" Ví dụ gọi EmployeeRepo.Save(emp); EmployeeRepo.GetAll();..

Lỡ trong table employee có constraint not null, unique này nọ.. thì sao? Mock SQL để test code chay trên repo để làm gì khi mà cái quan trọng là phải insert record vào dc database.
Nhấp để mở rộng...

Cái này là phạm trù intergration test rồi. Mấy kiểu này thì khi deploy lên test server rồi tự mở lòng vòng là lòi bug ngay chứ gì đâu. Hệ thống bự thì trên CI họ chạy cả unit test, integration test, e2e test, durable test, stress test... tá lả.

Khi viết unit test mình chỉ quan tâm mấy cái unit mình đang làm, và assume là những unit khác đều chạy như expected. Tôi dùng chữ expected vì có thể mình muốn "unit khác" trả về kết quả đúng, hay kết quả sai, hay throw exception này nọ...

Sent from Samsung SM-G973F using vozFApp
 
tdat00 đã nói:
Cái này là phạm trù intergration test rồi. Mấy kiểu này thì khi deploy lên test server rồi tự mở lòng vòng là lòi bug ngay chứ gì đâu. Hệ thống bự thì trên CI họ chạy cả unit test, integration test, e2e test, durable test, stress test... tá lả.

Khi viết unit test mình chỉ quan tâm mấy cái unit mình đang làm, và assume là những unit khác đều chạy như expected. Tôi dùng chữ expected vì có thể mình muốn "unit khác" trả về kết quả đúng, hay kết quả sai, hay throw exception này nọ...

Sent from Samsung SM-G973F using vozFApp
Nhấp để mở rộng...

Ở đây tôi ko bàn định nghĩa UT là gì vì mấy cái đó ai cũng biết cả.

Tôi bàn cách viết test trong DỰ ÁN THỰC TẾ sao cho ít tốn effort nhất và đạt dc hiệu quả cao nhất là code nó ko lỗi.

Những cái lý thuyết mà các anh học dc và đọc trong sách đa phần là không áp dụng triệt để trong DỰ ÁN THỰC TẾ dc.

Chán với các anh trẻ đời học dc vài ba cái test rồi vào dự án nhao nhao làm cho đúng như trong trường dạy. Có unlimited resources và timeline thì các anh làm gì chả được. Bây giờ viết test 4 tầng xem, nó đổi logic 1 phát mấy anh dev cuốn cuồng chạy theo deadline chứ ở đó mà ngồi fix UT cho cả 4 tầng. Còn đòi setup test server các kiểu… hơi xa xỉ quá. 90% các dự án ko có dc thứ xa xỉ đó đâu a. :feel_good:

via theNEXTvoz for iPhone
 
Pepe.The.Frog đã nói:
Ở đây tôi ko bàn định nghĩa UT là gì vì mấy cái đó ai cũng biết cả.

Tôi bàn cách viết test trong DỰ ÁN THỰC TẾ sao cho ít tốn effort nhất và đạt dc hiệu quả cao nhất là code nó ko lỗi.

Những cái lý thuyết mà các anh học dc và đọc trong sách đa phần là không áp dụng triệt để trong DỰ ÁN THỰC TẾ dc.

Chán với các anh trẻ đời học dc vài ba cái test rồi vào dự án nhao nhao làm cho đúng như trong trường dạy. Có unlimited resources và timeline thì các anh làm gì chả được. Bây giờ viết test 4 tầng xem, nó đổi logic 1 phát mấy anh dev cuốn cuồng chạy theo deadline chứ ở đó mà ngồi fix UT cho cả 4 tầng. Còn đòi setup test server các kiểu… hơi xa xỉ quá. 90% các dự án ko có dc thứ xa xỉ đó đâu a. :feel_good:

via theNEXTvoz for iPhone
Nhấp để mở rộng...

Tôi làm thợ code cũng ngót 10 năm rồi, công ty cỡ trung cũng được 4 nơi rồi, và cái tôi nói ở trên là thực tế đó. Anh tin hay không thì tùy.

Sent from Samsung SM-G973F using vozFApp
 
tdat00 đã nói:
Tôi làm thợ code cũng ngót 10 năm rồi, công ty cỡ trung cũng được 4 nơi rồi, và cái tôi nói ở trên là thực tế đó. Anh tin hay không thì tùy.

Sent from Samsung SM-G973F using vozFApp
Nhấp để mở rộng...

quanth_2987 đã nói:
TÔi phải viết UN khá nhiều (dự án hiện tại 1 site commerce của 1 khách hàng cũng tầm cỡ thế giới) coverage phải trên 80%. Nhưng cũng ko phải viết UN cho mấy cái connect vào db, đo là phần Integration test như cậu gì trên kia bảo. Thực tế thì UN thì bọn tôi chỉ dùng để test logic.
Thông thường code ngon, sáng sủa thì 1 task thời gian code và viết UN sẽ là 50-50. Nếu mà viết UN tốn nhiều quá thì phải xem lại code
Nhấp để mở rộng...

OK. Hỏi 1 câu thật lòng là các dự án mà các a chỉ viết UT logic thôi còn mấy cái connect db thì mặc kệ (ko tính các dự án có integration test như test server đẹp đẽ) thì số bugs các anh gặp có giảm hơn rất nhiều so với effort bỏ ra để viết UT ko?

=> Chính cái máy móc apply kiểu UT là phải độc lập hoàn toàn như vậy dẫn tới mặc dù test coverage rất cao > 80% mà khi chạy thật dính tới db là văng lỗi.

Tất nhiên trải nghiệm của các anh và tôi khác nhau vì có thể a may mắn vào toàn dự án ngon, đã dc setup đẹp đẽ...còn tôi vào toàn phải hốt sh*t nên thời gian làm features mới còn ko có trong khi lại có yêu cầu dựng setup UT cho cái đống rác đó. Code nhiều chổ nó còn ko testable dc kìa...
HzrdQkW.png

 
Sửa lần cuối:
Pepe.The.Frog đã nói:
OK. Hỏi 1 câu thật lòng là các dự án mà các a chỉ viết UT logic thôi còn mấy cái connect db thì mặc kệ (ko tính các dự án có integration test như test server đẹp đẽ) thì số bugs các anh gặp có giảm hơn rất nhiều so với effort bỏ ra để viết UT ko?

Tất nhiên trải nghiệm của các anh và tôi khác nhau vì có thể a may mắn vào toàn dự án ngon, đã dc setup đẹp đẽ...còn tôi vào toàn phải hốt sh*t nên thời gian làm features mới còn ko có trong khi lại có yêu cầu dựng setup UT cho cái đống rác đó. Code nhiều chổ nó còn ko testable dc kìa...
HzrdQkW.png

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

Bug tôi gặp thường là mấy cái chua lòm không bắt được từ unit test. Kiểu như sequence requests không đúng thứ tự, duplicated records vì request bị retry nhiều lần, server bị high load...

Tôi ít gặp mấy cái bug phổ thông kiểu như sai requirement, sót edge case, breaking change... Chắc do nhờ unit test trên 80% coverage nên giảm được mấy cái bug đó đấy.

Sent from Samsung SM-G973F using vozFApp
 
tdat00 đã nói:
Bug tôi gặp thường là mấy cái chua lòm không bắt được từ unit test. Kiểu như sequence requests không đúng thứ tự, duplicated records vì request bị retry nhiều lần, server bị high load...

Tôi ít gặp mấy cái bug phổ thông kiểu như sai requirement, sót edge case, breaking change... Chắc do nhờ unit test trên 80% coverage nên giảm được mấy cái bug đó đấy.

Sent from Samsung SM-G973F using vozFApp
Nhấp để mở rộng...

OK. Vậy giờ trường hợp ko có điều kiện để dựng 1 cái integration tests, test server các kiểu nhưng vẫn muốn cover dc các case dính tới db.. duplicated records, dính tới retry request nhiều lần thì làm sao?
2y9npcU.png
 
Head First Java đã nói:
anh có thể nói rõ hơn được không? và tại sao tester ko phải làm unit test nhỉ?
Nhấp để mở rộng...
vì người cần phải viết Unit test là developer chứ ko phải tester

UT tức là test những thành phần nhỏ nhất, ở đây là các function, để đảm bảo là các function này chạy đúng theo ý đồ/mục đích được viết ra.

còn tester sẽ test theo view người dùng, tức là test theo luồng hoặc usecase, thông qua UI
 
tdat00 đã nói:
Anh hỏi cùn nhỉ. Cover được thì đã không còn bug.

Sent from Samsung SM-G973F using vozFApp
Nhấp để mở rộng...

Cover được nếu như a viết test trực tiếp từ controller/services mà deck mock gì hết. Generate 1 chục requests rồi check trực tiếp db luôn. Đó là cái tôi muôn nói.

Quan trọng là test sao cho ko có bugs. Về lý thuyết là test ở tầng cao hơn, rộng hơn sẽ cover tầng thấp hơn, thậm chí bỏ luôn việc test tầng thấp hơn cũng dc.

Ví dụ:
User Manually tests -> Automation Test (Selenium..) -> Integration tests (giả lập requests/gọi services..) -> unit test từng layers...

2 cái đầu là QC/Test team làm rồi tôi ko bàn. Ở dev thì nắm thằng Controllers viết test trực tiếp deck mock gì hết thì effort bỏ ra chắc chắn xứng đáng và cover hết các cases như a nói..
0FFPAjM.png


p/s: Về mặt tên gọi thì gọi đúng là tôi đang viết Integration tests 1 cách tự động bằng các Unit Test framework...
 
Pepe.The.Frog đã nói:
Cover được nếu như a viết test trực tiếp từ controller/services mà deck mock gì hết. Generate 1 chục requests rồi check trực tiếp db luôn. Đó là cái tôi muôn nói.

Quan trọng là test sao cho ko có bugs. Về lý thuyết là test ở tầng cao hơn, rộng hơn sẽ cover tầng thấp hơn, thậm chí bỏ luôn việc test tầng thấp hơn cũng dc.

Ví dụ:
User Manually tests -> Automation Test (Selenium..) -> Integration tests (giả lập requests/gọi services..) -> unit test từng layers...

2 cái đầu là QC/Test team làm rồi tôi ko bàn. Ở dev thì nắm thằng Controllers viết test trực tiếp deck mock gì hết thì effort bỏ ra chắc chắn xứng đáng và cover hết các cases như a nói..
0FFPAjM.png
Nhấp để mở rộng...

Con lạy mợ, mợ làm như thế thì đuối là phải rồi. Mấy cái rare bug kia nó quá hiếm để tốn công sức viết automation test cho nó. Đó là lý do các công ty thường chỉ dừng ở unit test, một số ít yêu cầu thêm e2e test và rất hiếm công ty chạy thêm stress test.

Chưa kể lên prod nó còn nhiều server instance, nhiều db replicate, caching, message broker các kiểu. Nên viết automation test theo ý mợ nói nó không có ý nghĩa. Test server còn chưa được xài 2 server instances nữa là CI

Sent from Samsung SM-G973F using vozFApp
 
Pepe.The.Frog đã nói:
Cover được nếu như a viết test trực tiếp từ controller/services mà deck mock gì hết. Generate 1 chục requests rồi check trực tiếp db luôn. Đó là cái tôi muôn nói.

Quan trọng là test sao cho ko có bugs. Về lý thuyết là test ở tầng cao hơn, rộng hơn sẽ cover tầng thấp hơn, thậm chí bỏ luôn việc test tầng thấp hơn cũng dc.

Ví dụ:
User Manually tests -> Automation Test (Selenium..) -> Integration tests (giả lập requests/gọi services..) -> unit test từng layers...

2 cái đầu là QC/Test team làm rồi tôi ko bàn. Ở dev thì nắm thằng Controllers viết test trực tiếp deck mock gì hết thì effort bỏ ra chắc chắn xứng đáng và cover hết các cases như a nói..
0FFPAjM.png


p/s: Về mặt tên gọi thì gọi đúng là tôi đang viết Integration tests 1 cách tự động bằng các Unit Test framework...
Nhấp để mở rộng...
Anh này cùn bỏ mẹ. Việc các anh code UT quá take time hoặc là ko viết UT là tại các anh dev ngu, code thối. Tại gì cả UN. Bản thân các project có yêu cầu UN, thì ngay từ đầu mindset của dev là code phải testable rồi.
Anh đang đưa expect của mình về mặt Integration tests để chửi cái UnitTest là ko chính xác. UN là để cover các khả năng có thể xảy ra trong 1 method nên nó cần mock data, để a có thể fake dc nhiều case 1 cách linh động, ko cần phải lôi data thật ra mà test.
Còn đúng là ko phải project nào cũng có điều kiện viết UN, việc viết UN là balance giữa nhiều yếu tố, nhưng có thời gian điều kiện thì nên làm. Anh toàn chơi bài đánh lận các khái niệm UT, SIT các thứ xong rồi quay sang chửi cái UT là mất thời gian thì rất buồn cười
 
À tôi ko chửi UT nhé, ngược lại tôi ủng hộ viết UT.

Còn project thực tế để cân bằng giữa viết test và hiệu quả thu được thì tôi nghĩ như này:

1. Viết unit test cho controller có mock service.
2. Viết integration test cho service để test xuống db luôn, cứ commit/rollback để setup/teardown.

via theNEXTvoz for iPhone
 
Công ty mình đang yêu cầu coverage > 85%.
Như vậy UnitTest cực kỳ quan trọng, nhất là khi bạn thay đổi 1 phần nhỏ trong code mà không chắc là nó có ảnh hưởng đến những phần khác.
Bây giờ ngta đang chuyển qua quy trình viết UnitTest trước rồi mới code theo hoặc viết test 1 bước rồi code để sửa cái test đó. (TDD thì phải.).
UT cực kỳ quan trọng. nếu bạn thấy nó chưa quan trọng thì có thể là bạn đang chưa hiểu gì về UT hoặc đang UT chưa đúng.
 
Pepe.The.Frog đã nói:
$1 Ở đây tôi ko bàn định nghĩa UT là gì vì mấy cái đó ai cũng biết cả.

$2 Tôi bàn cách viết test trong DỰ ÁN THỰC TẾ sao cho ít tốn effort nhất và đạt dc hiệu quả cao nhất là code nó ko lỗi.

$3 Những cái lý thuyết mà các anh học dc và đọc trong sách đa phần là không áp dụng triệt để trong DỰ ÁN THỰC TẾ dc.

Chán với các anh trẻ đời học dc vài ba cái test rồi vào dự án nhao nhao làm cho đúng như trong trường dạy. $4 Có unlimited resources và timeline thì các anh làm gì chả được. Bây giờ viết test 4 tầng xem, nó đổi logic 1 phát mấy anh dev cuốn cuồng chạy theo deadline chứ ở đó mà ngồi fix UT cho cả 4 tầng. Còn đòi setup test server các kiểu… hơi xa xỉ quá. $5 90% các dự án ko có dc thứ xa xỉ đó đâu a. :feel_good:

via theNEXTvoz for iPhone
Nhấp để mở rộng...

Pepe.The.Frog đã nói:
Cover được nếu như a viết test trực tiếp từ controller/services mà deck mock gì hết. Generate 1 chục requests rồi check trực tiếp db luôn. Đó là cái tôi muôn nói.

$6 Quan trọng là test sao cho ko có bugs. Về lý thuyết là test ở tầng cao hơn, rộng hơn sẽ cover tầng thấp hơn, thậm chí bỏ luôn việc test tầng thấp hơn cũng dc.

Ví dụ:
User Manually tests -> Automation Test (Selenium..) -> Integration tests (giả lập requests/gọi services..) -> unit test từng layers...

2 cái đầu là QC/Test team làm rồi tôi ko bàn. Ở dev thì nắm thằng Controllers viết test trực tiếp deck mock gì hết thì effort bỏ ra chắc chắn xứng đáng và cover hết các cases như a nói..
0FFPAjM.png


p/s: Về mặt tên gọi thì gọi đúng là tôi đang viết Integration tests 1 cách tự động bằng các Unit Test framework...
Nhấp để mở rộng...
$1 tôi nghĩ là anh không biết đâu :) vì nếu anh nắm rõ lý tưởng của nó thì anh đã không ngồi nói vớ vẩn thế :)
$3 vớ vẩn. tại vì anh không hiểu rõ về nó nên anh mới không áp dụng được chứ anh đừng đánh đồng là người khác không áp dụng được
$4 nguỵ biện. tôi tin là anh chẳng bao giờ có thời gian cả đâu :) và kể cả có thời gian thì chưa chắc anh đã làm được :)
$5 lại nguỵ biện. số liệu anh lấy ở đâu ra thế? từ miệng giếng của anh à pepe the fog :)
$2 $6 cái cách anh bảo mix mấy cái test lại với nhau cho nó đỡ tốn effort nó giống như code toàn bộ 1 proj vào 1 class cho nó vừa gọn, vừa tiết kiệm bộ nhớ, vừa đỡ mất công tìm class này component kia ấy :) "quan trọng là code sao cho chạy thôi mà" nhỉ? :)

chốt lại: tôi thấy tại vì anh không hiểu bản chất nhiều thứ và lý do tại sao người ta lại tách ra nhiều thứ riêng biệt cụ thể thế để làm gì nên anh hay đánh tráo khái niệm loạn xí ngầu cả lên
khuyên: lúc biết thêm 1 cái gì mới nên dùng cái đầu mở để tiếp nhận. người ta sáng tạo ra 1 cái gì đấy đều có lý do của nó, hãy cố gắng tìm hiểu tại sao người ta lại phải đẻ ra cái đấy trước đã, đừng vì chữ tiện và nhanh mà đánh mất nhiều thứ khác.
 
phongkyanh đã nói:
$1 tôi nghĩ là anh không biết đâu :) vì nếu anh nắm rõ lý tưởng của nó thì anh đã không ngồi nói vớ vẩn thế :)
$3 vớ vẩn. tại vì anh không hiểu rõ về nó nên anh mới không áp dụng được chứ anh đừng đánh đồng là người khác không áp dụng được
$4 nguỵ biện. tôi tin là anh chẳng bao giờ có thời gian cả đâu :) và kể cả có thời gian thì chưa chắc anh đã làm được :)
$5 lại nguỵ biện. số liệu anh lấy ở đâu ra thế? từ miệng giếng của anh à pepe the fog :)
$2 $6 cái cách anh bảo mix mấy cái test lại với nhau cho nó đỡ tốn effort nó giống như code toàn bộ 1 proj vào 1 class cho nó vừa gọn, vừa tiết kiệm bộ nhớ, vừa đỡ mất công tìm class này component kia ấy :) "quan trọng là code sao cho chạy thôi mà" nhỉ? :)

chốt lại: tôi thấy tại vì anh không hiểu bản chất nhiều thứ và lý do tại sao người ta lại tách ra nhiều thứ riêng biệt cụ thể thế để làm gì nên anh hay đánh tráo khái niệm loạn xí ngầu cả lên
khuyên: lúc biết thêm 1 cái gì mới nên dùng cái đầu mở để tiếp nhận. người ta sáng tạo ra 1 cái gì đấy đều có lý do của nó, hãy cố gắng tìm hiểu tại sao người ta lại phải đẻ ra cái đấy trước đã, đừng vì chữ tiện và nhanh mà đánh mất nhiều thứ khác.
Nhấp để mở rộng...

Khi cái mới mà a nói + a đã trải nghiệm qua nhiều lần + thấy đc điểm yếu của nó thì a mới “ngộ” ra được anh ạ.

Ko phải tự nhiên người ta phát triển từ procedure programming tới oop rồi giờ lại quay ra functional programming. Hay từ monolithic + 3 layers lại đẽ ra clean architecture, micro services..

Đôi khi anh cũng nên xuống giếng chơi để thấy dc con ếch ở dưới đó biết đâu lụm dc bí kiếp võ công.

Khuyên: a cũng nên mở đầu ra khi thấy tư tưởng khác, đi ngc lại những gì a dc học. Đó là lúc mà một cái gì mới hơn sắp dc sáng tạo ra đó.
EcV5PPL.gif


via theNEXTvoz for iPhone
 
Sửa lần cuối:
À riêng vụ thời gian thì tôi có thừa nhé. Tôi lo cho mấy a e dev thôi chứ tôi rảnh lên Voz cãi nhau giờ hành chính thì a hiểu tôi thừa thời gian rồi.
zFNuZTA.gif


via theNEXTvoz for iPhone
 
Pepe.The.Frog đã nói:
À tôi ko chửi UT nhé, ngược lại tôi ủng hộ viết UT.

Còn project thực tế để cân bằng giữa viết test và hiệu quả thu được thì tôi nghĩ như này:

1. Viết unit test cho controller có mock service.
2. Viết integration test cho service để test xuống db luôn, cứ commit/rollback để setup/teardown.

via theNEXTvoz for iPhone
Nhấp để mở rộng...
thế cái case update db fail thì phải retry 3 lần anh định integration test kiểu gì ? nói tôi nghe thử
 
Bạn phải đăng nhập hoặc đăng ký để trả lời tại đây.
AD · 970×250

Chủ đề tương tự

potay001
thảo luận [K10s - TUI] Dành cho những người não cá vàng khi vận hành Kubernetes
Trả lời
4
Lượt xem
1K
potay001
potay001
ChatGPT AI
Grab áp dụng chiết khấu như thế nào ở các nước Đông Nam Á?
2
Trả lời
25
Lượt xem
2K
potter.nguyen
potter.nguyen
annd22
khoe App quản lý chi tiêu tự viết, có mục vàng bạc - các thím ném gạch giúp
2 3 4
Trả lời
64
Lượt xem
2K
annd22
annd22
M
Từ hán việt đồng âm khác nghĩa trong tiếng Việt
Trả lời
15
Lượt xem
1K
cppcoder
cppcoder
L
kiến thức API CODEX — AI AGENT HOẠT ĐỘNG NHƯ THẾ NÀO?
Trả lời
0
Lượt xem
207
luisinosaghi
L

Thống kê chủ đề

Ngày tạo
TrungNgaoNgo,
Người trả lời cuối
vozphongtrao1,
Trả lời
180
Lượt xem
29.197

Chia sẻ trang này

Quay lại
Lên đầu trang