thaiviptn1201
Member
Nhưng em gà anh ơi, trình độ tầm fresher thôi.
thắc mắc Các bác viết unit test thế nào ạ.
- Người tạo chủ đề TrungNgaoNgo
- Ngày bắt đầu
the_ruler
Đã tốn tiền
Testting đúng là một thứ rất rất thú vị với dev.
Mình từng làm ở một số bên, một số project, bé bé cũng có, gần tỉ đô cũng có.
Có vài điều hay ho:
Okay. Còn về chuyện học test. Cách tốt nhất là xin tester tài liệu và học theo họ. Càng biết nhiều thì phải làm ít đi thôi.
Edit: F91 có vẻ sạch sẽ hơn, chắc rảnh mình sẽ làm một post về việc dev viết unittest như nào thì tốt. Tìe cách tư duy sao cho đúng tới việc cần làm gì cho đủ
via theNEXTvoz for iPhone
Mình từng làm ở một số bên, một số project, bé bé cũng có, gần tỉ đô cũng có.
Có vài điều hay ho:
- Unittest đều viết như hạch, ngay cả dự án tỉ đô mình join cũng viết như hạch. Vì sao? Trade off thôi mà. Có ba cái luôn cần tính tới của sản phẩm: thời gian, độ hiệu quả mà nó mang lại và chi phí bỏ ra. PO sẽ phải cân đối nó và thường cái gì trước mắt sẽ được ưu tiên, unittest là cái vô hình nên việc không ưu tiên nó là bình thường. PO/PM nào mà chẳng thuộc lòng việc muốn đi đường dài thì phải test tốt. Nhưng có đúng 100% hay không?
- Những người viết test nhiều nhất thì đều ở tầm mid. Mấy ông gà ít viết test vì họ không biết viết sao cho đúng, cho đủ. Mấy ông giỏi quá thì ít viết vì các ông ấy thấy đổi yêu cầu đi sửa test mệt thấy bà. PO thì cứ bắt coverage cao nhưng PO có code éo đâu. Mình từng làm với mấy anh google (sen gg nhảy ra) code thì đúng là kinh hoàng luôn, nhưng chắc trừ khi viết lib hoặc bị dí viết test còn không thì ...
- Unittest ngon phải chăng tốn ít tiền hơn? Lý thuyết mình không nói nha, với bản thân mình thì có hai dự án khá lớn, đều chạy 5,7 năm. Một con thì mình ước rằng đừng có unittest, một con thì PO cũng ước như vậy. Trong cái thời đại này khi business nó chạy nhanh x10 lần dev thì việc test sâu còn cần hay không? À tất nhiên vẫn có những phần bọn mình phải test rất sâu và cố gắng đưa nó thành sandbox để bên bảo mật họ tin tưởng
Okay. Còn về chuyện học test. Cách tốt nhất là xin tester tài liệu và học theo họ. Càng biết nhiều thì phải làm ít đi thôi.
Edit: F91 có vẻ sạch sẽ hơn, chắc rảnh mình sẽ làm một post về việc dev viết unittest như nào thì tốt. Tìe cách tư duy sao cho đúng tới việc cần làm gì cho đủ
via theNEXTvoz for iPhone
Sửa lần cuối:
candylove3979
Senior Member
mình làm FE nhưng cũng viết UT, dự án có yêu cầu khá thấp nhưng cũng cố gắng cover 70% 
tiengdonhoarira
Senior Member
viết unit test cho ngôn ngữ nào em
nếu dùng nodejs thì có thư viện supertest, mocha, jest
nếu muốn thì pm gửi cho một cái đơn giản trên github làm ví dụ
unit test khá là ok. khi sửa code, thêm chức năng thì test thử xem chương trình có chạy vẫn ok không
nếu dùng nodejs thì có thư viện supertest, mocha, jest
nếu muốn thì pm gửi cho một cái đơn giản trên github làm ví dụ
unit test khá là ok. khi sửa code, thêm chức năng thì test thử xem chương trình có chạy vẫn ok không
Still Waiting....
Đã tốn tiền
Đã từng làm một con dự án hoàn toàn mới, yc coverage > 80% nhưng business thay đổi chóng mặt qua từng sprint. Mỗi lần thay đổi thời gian fix vs update unit test nhiều gấp nhiều lần thời gian code haiz.
via theNEXTvoz for iPhone
via theNEXTvoz for iPhone
Tôi đồng ý. Mấy thằng lí thuyết hão bị nhồi sọ toàn vào tinh tướng, cứ như có unit test là gì thượng đẳng lắm vậy. Tôi éo phục. Nếu có thể generate tự động đám unit test đó thì dại gì không làm, còn bắt con người viết đám đó thì là một kiểu bóc lột, éo nói nhiều.
180cm-20cm-4k
Senior Member
Lâu lâu mới gặp 1 người coder thật sự. Voz toàn trẻ trâu.Testting đúng là một thứ rất rất thú vị với dev.
Mình từng làm ở một số bên, một số project, bé bé cũng có, gần tỉ đô cũng có.
Có vài điều hay ho:
- Unittest đều viết như hạch, ngay cả dự án tỉ đô mình join cũng viết như hạch. Vì sao? Trade off thôi mà. Có ba cái luôn cần tính tới của sản phẩm: thời gian, độ hiệu quả mà nó mang lại và chi phí bỏ ra. PO sẽ phải cân đối nó và thường cái gì trước mắt sẽ được ưu tiên, unittest là cái vô hình nên việc không ưu tiên nó là bình thường. PO/PM nào mà chẳng thuộc lòng việc muốn đi đường dài thì phải test tốt. Nhưng có đúng 100% hay không?
- Những người viết test nhiều nhất thì đều ở tầm mid. Mấy ông gà ít viết test vì họ không biết viết sao cho đúng, cho đủ. Mấy ông giỏi quá thì ít viết vì các ông ấy thấy đổi yêu cầu đi sửa test mệt thấy bà. PO thì cứ bắt coverage cao nhưng PO có code éo đâu. Mình từng làm với mấy anh google (sen gg nhảy ra) code thì đúng là kinh hoàng luôn, nhưng chắc trừ khi viết lib hoặc bị dí viết test còn không thì ...
- Unittest ngon phải chăng tốn ít tiền hơn? Lý thuyết mình không nói nha, với bản thân mình thì có hai dự án khá lớn, đều chạy 5,7 năm. Một con thì mình ước rằng đừng có unittest, một con thì PO cũng ước như vậy. Trong cái thời đại này khi business nó chạy nhanh x10 lần dev thì việc test sâu còn cần hay không? À tất nhiên vẫn có những phần bọn mình phải test rất sâu và cố gắng đưa nó thành sandbox để bên bảo mật họ tin tưởng
Okay. Còn về chuyện học test. Cách tốt nhất là xin tester tài liệu và học theo họ. Càng biết nhiều thì phải làm ít đi thôi.
Edit: F91 có vẻ sạch sẽ hơn, chắc rảnh mình sẽ làm một post về việc dev viết unittest như nào thì tốt. Tìe cách tư duy sao cho đúng tới việc cần làm gì cho đủ
via theNEXTvoz for iPhone
Đồng ý là có 1 số dự án đặc thù thì ut code apply ko thích hợp. Nhưng mình nghĩ đa số các trường hợp là nên apply.
Dev viết code thì kiểu gì cũng phải test code mình. UT code là 1 cách để làm cái bước đó thôi.
Nếu cái tư tưởng đã thông thì việc viết ut sẽ khá nhàn, ko tốn thời gian như mọi người nghĩ. Khi viết code, dev sẽ có cố gắng viết code để có thể test được bằng ut code.
Cuối cùng: Mình đã apply TDD lâu năm, và cảm giác rằng nó giúp cho việc coding NHANH HƠN so với ko viết ut.
Still Waiting....
Đã tốn tiền
Nhanh hơn trong trường hợp bác tự viết test cho chính code bác viết ra. Khi viết code trong đầu bác đã luôn có tư tưởng là viết code ngoài đúng function ra thì còn phải viết sao cho dễ viết unit test. Nhưng thực tế là bác còn phải viết và update cho cả những thằng khác nữa khi mà trình độ lẫn kinh nghiệm của cno là chưa đủ. Thì lúc đó cứ phải gọi là cực hình vcl. Vừa đọc code cno viết gì để hiểu vừa phải đọc code unit test xem cno viết cái gì nữa. Và nhiều thằng còn d biết viết unit test đến mức code test của cno d có giá trị gì.
Mình làm vs hầu hết dự án team size lớn nên cũng hiểu sức mạnh của unit test nhưng nói thật là để maintain đống đó khá là mệt.
via theNEXTvoz for iPhone
daydreamm
Senior Member
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
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
Doan Minh Trung
Senior Member
Đối với bác nào thường xuyên refactoring code thì sẽ thấy công dụng của UT lớn như nào. Có UT sẽ đảm bảo được 1 phần nào đó chức năng của bạn chạy ổn định.
Tuy nhiên cũng có trường hợp business thay đổi, developer trước sửa function nhưng quên không sửa UT (trường hợp của mình vài hôm trước sửa gần 100 cái UT sml). Thì đến lúc bạn hốt phải đống đấy thì bạn sẽ bối rối không biết rằng UT bị sai, hay code của mình bị sai nên phải điều tra lại từ đầu.
Về cách viết UT thì mình phải biết được input và output của function là gì. Để viết được 1 UT đẹp thì phải biết cách so sánh output với expected.
Mình lấy ví dụ. Một số bạn test hàm trả về là 1 object. Bạn ý chỉ assert là object đó khác NULL là done UT. Trong trường hợp này thì UT nó không có ý nghĩa, mình phải kiểm tra xem dữ liệu trả về có đúng hay không.
Ví dụ tiếp nữa là làm search trả về 1 list. Có bạn chỉ assert length bằng bao nhiêu đấy, trường hợp này cũng đúng nhưng để được gọi là 1 UT đẹp thì mình phải kiểm tra nội dung từng phần tử list xem có khớp với giá trị mình mong muốn hay không.
Về việc nên có UT trong dự án hay không, theo mình thì là có, kể cả dự án lớn hay nhỏ. Sau này dự án mở rộng thì UT có rất có ích trong việc kiểm tra regression bug. Tối thiểu thì cũng phải viết được 1 2 case UT (1 case happy case và 1 case failed)
Tuy nhiên cũng có trường hợp business thay đổi, developer trước sửa function nhưng quên không sửa UT (trường hợp của mình vài hôm trước sửa gần 100 cái UT sml). Thì đến lúc bạn hốt phải đống đấy thì bạn sẽ bối rối không biết rằng UT bị sai, hay code của mình bị sai nên phải điều tra lại từ đầu.
Về cách viết UT thì mình phải biết được input và output của function là gì. Để viết được 1 UT đẹp thì phải biết cách so sánh output với expected.
Mình lấy ví dụ. Một số bạn test hàm trả về là 1 object. Bạn ý chỉ assert là object đó khác NULL là done UT. Trong trường hợp này thì UT nó không có ý nghĩa, mình phải kiểm tra xem dữ liệu trả về có đúng hay không.
Ví dụ tiếp nữa là làm search trả về 1 list. Có bạn chỉ assert length bằng bao nhiêu đấy, trường hợp này cũng đúng nhưng để được gọi là 1 UT đẹp thì mình phải kiểm tra nội dung từng phần tử list xem có khớp với giá trị mình mong muốn hay không.
Về việc nên có UT trong dự án hay không, theo mình thì là có, kể cả dự án lớn hay nhỏ. Sau này dự án mở rộng thì UT có rất có ích trong việc kiểm tra regression bug. Tối thiểu thì cũng phải viết được 1 2 case UT (1 case happy case và 1 case failed)
broke.the.rule
Senior Member
Ưu nhược điểm thì các thím nói hết rồi, tôi mạn phép tổng hợp lại như dưới đây.
Có 2 điều kiện để việc viết unit test ko trở thành cực hình, 1 là yêu cầu về phần mềm đã ổn định, ít thay đổi, 2 là có đủ tiền và thời gian.
Nếu ko đáp ứng được 2 yêu cầu này thì sẽ chẳng có dev nào muốn viết unit test cả.
Có 2 điều kiện để việc viết unit test ko trở thành cực hình, 1 là yêu cầu về phần mềm đã ổn định, ít thay đổi, 2 là có đủ tiền và thời gian.
Nếu ko đáp ứng được 2 yêu cầu này thì sẽ chẳng có dev nào muốn viết unit test cả.
wslwsl
Senior Member
Viết unit test bên FE rất cực. Căn bản project nat, design tệ thì đổi UI như lá mùa thu. BE nhiều khi core ít chọc ngoáy nên cực lúc đầu nhàn về sau hơn FE. FE cứ 6 tháng 1 năm lại đổi UI.
Nếu startup hay cty prod nhỏ mà muốn đảm bảo FE logic ko sai thì nên viết e2e tốt hơn.
Yurisha
Senior Member
maintain code có ut sướng hơn nhiều chứ nhỉ? Đầu tiên là éo cần đọc code nó viết cái gì, nhìn ut là có thể hình dung được câu chuyện
duyzeza
Junior Member
Mình viết unit test cũng nhiều, có 1 số project đòi hỏi phải 80% test coverage, viết thì cũng tự tin thật nhưng mock vs expose function ra để test hay ngồi troubleshoot cái unit test environment cũng cực.
Cá nhân thì thấy viết lib thì viết unit test tiện hơn vì có thể rewrite được sang v2,v3... . Chứ viết cho cái app nhiều business lằng nhằng + đổi liên tục thì lười quá, ngày hnay viết ngày mai đập bỏ(do cấp trên thử nghiệm feature) thì lười quá.
App đang chạy feature chắc chỉ có stress test/load test là dễ viết. Còn trong giai đoạn maintain/fix bug thì e2e tiện hơn
Cá nhân thì thấy viết lib thì viết unit test tiện hơn vì có thể rewrite được sang v2,v3... . Chứ viết cho cái app nhiều business lằng nhằng + đổi liên tục thì lười quá, ngày hnay viết ngày mai đập bỏ(do cấp trên thử nghiệm feature) thì lười quá.
App đang chạy feature chắc chỉ có stress test/load test là dễ viết. Còn trong giai đoạn maintain/fix bug thì e2e tiện hơn
LuuKienMinh
Đã tốn tiền
Giờ cứ thử sửa một func hay module có logic phức tạp mà không có sẵn ut để chạy lại thì mấy người dám sửa. Sửa xong nó không chạy được yêu cầu mới còn yêu cầu cũ fail thì thế nào. Chưa kể ut còn có thể test nhưng trường hợp hiếm gặp mà khó test bằng system test hay không thể test bằng system test.
Chưa kể bug đc phát hiện bởi dev thì sẽ tiết kiệm được nhiều thời gian và tiền bạc hơn là phát hiện bởi tester.
Sent from Xiaomi M2007J20CG using vozFApp
Chưa kể bug đc phát hiện bởi dev thì sẽ tiết kiệm được nhiều thời gian và tiền bạc hơn là phát hiện bởi tester.
Sent from Xiaomi M2007J20CG using vozFApp
Messii
Member
Vozer cấp tiến
Member
Viết unit test là viết xong cái gì thì viết luôn unit test cái đó à các thím? Mình chưa viết unit test bao giờ. Viết unit test là viết test đầu vào đầu ra của function hay là tất cả như giao diện, class, interface,... thế? Mình xem ví dụ họ ví dụ mỗi 1 + 2 = 3.
snake_case
Senior Member
Cái này đúng, mịa startup với outsource cần nhanh và biz thay đổi liên tục mà mỗi cái mấy chục test case thì sửa vỡ mồm.
Chủ đề tương tự
