mori kogoro
Junior Member
Bữa đi phỏng vấn fresher. Họ cho đề làm 1 cái form crud react redux. Cho 2 câu thuật toán với 2 câu viết unit test. Fresher mà yêu cầu nhiều quá. Không biết unit test em bỏ luôn
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
FrozenAshe
Senior Member
Out source mà ko có unit test thì phá sản sớm
kusoipro
Đã tốn tiền
OS cũng tùy budget khách hàng thôi fen, cần release nhanh thì làm gì có time viết UTOut source mà ko có unit test thì phá sản sớm
Project phải code đẹp thì mới viết unit test chạy đúng ý nghĩa đc, chứ mà code bầy nhầy thì ko ai muốn unit test cho codd đó cả, và nhiều khi cũng ko viết nổi chứ ko phải ko muốn viết. Mà code đẹp thì phải code tới đâu unit test tới đó, chứ code xong 1 đống rồi mới viết UT sau thì khó lắm
quinnm
Senior Member
Vãi cả thím nói UT là vô dụng, ví dụ thím code 1 cái lib enc/dec cho dự án, đến lúc update 1 trường nào đó mà nằm trong nhiều bản tin, thím ko chạy lại UT xem có ảnh hưởng ko đến lúc lỗi ra lại đi mò.
Debug thì System.out chỉ debug nhỏ nhỏ thôi chứ cả flow mà ngồi in ra thì in chỗ nọ thiếu chỗ kia chắc chắn chậm hơn dùng debugger.
midnight_sun
Senior Member
code go viết test bao phê, và đang cố gắng để viết test nhất có thể, dù project ko yêu cầu đã từng gặp mấy ông code TDD, phân tích usecase xong các ô viết unit test trc, xong ms implement , ko biết bao giờ mới đến cảnh giới này
đã từng gặp mấy ông code TDD, phân tích usecase xong các ô viết unit test trc, xong ms implement , ko biết bao giờ mới đến cảnh giới này
snake_case
Senior Member
Công nhận Go nó tích hợp sẵn chạy test. Chắc vì lý do ấy Rust cũng nổi dần nhờ tích hợp test. Còn C++, Java, Node toàn phải cài thêm dependencies.code go viết test bao phê, và đang cố gắng để viết test nhất có thể, dù project ko yêu cầu
dark_matter
Senior Member
Unit Test là cần thiết. Developer phải biết viết Unit Test.
Không viết đủ Unit Test, sau này release ra production có lỗi thì còn tốn gấp trăm lần thời gian viết test. Nhất là nó không dừng lại khi có lỗi mà lại chạy sai (logic error)
Bên mình test coverage dưới 70% thì manager vào giải trình trước khi release. Thường developer đảm bảo tối thiểu 80% code coverage. (Viết nhiều hơn lúc sau refactor code với logic thì phải refactor Unit Test cũng mất thời gian.)
Tất nhiên Unit Test không bảo đảm không có lỗi trên production nhưng ít nhất nó cũng test được khá khá.
Gần đây bên mình dính quả khách hàng gửi file có hedge ratio format scientific notation kiểu 1.2345E-3, software đọc không ra hiểu thành 1.2345, có tầm 30k dòng như thế này, hedge nhầm -> lỗ tầm 5m USD. Source code không có Unit Test đầy đủ nhưng last updated 2 năm về trước nên may quá túm đầu QA ra đổ tội chung.
Từ đấy trở đi đứa nào không viết đủ Unit Test, khi raise Pull Request bị declined hết
. Sai lầm nào cũng phải trả giá bằng tiền 
Không viết đủ Unit Test, sau này release ra production có lỗi thì còn tốn gấp trăm lần thời gian viết test. Nhất là nó không dừng lại khi có lỗi mà lại chạy sai (logic error)
Bên mình test coverage dưới 70% thì manager vào giải trình trước khi release. Thường developer đảm bảo tối thiểu 80% code coverage. (Viết nhiều hơn lúc sau refactor code với logic thì phải refactor Unit Test cũng mất thời gian.)
Tất nhiên Unit Test không bảo đảm không có lỗi trên production nhưng ít nhất nó cũng test được khá khá.
Gần đây bên mình dính quả khách hàng gửi file có hedge ratio format scientific notation kiểu 1.2345E-3, software đọc không ra hiểu thành 1.2345, có tầm 30k dòng như thế này, hedge nhầm -> lỗ tầm 5m USD. Source code không có Unit Test đầy đủ nhưng last updated 2 năm về trước nên may quá túm đầu QA ra đổ tội chung.
Từ đấy trở đi đứa nào không viết đủ Unit Test, khi raise Pull Request bị declined hết
. Sai lầm nào cũng phải trả giá bằng tiền 
billy_don
Senior Member
Bác cho em hỏi unit test thế nào gọi là đủ ạ? test coverage lớn hơn 80%?
Ngoài ra phần code nào nên đầu tư unit test nhiều nhất? Phần nào có thể bỏ qua?
Với cả những phần code hiển nhiên có thể chắc chắn nó đúng thì có cần phải test không bác?
Sửa lần cuối:
qk_pro
Member
Unit test đâu có giúp gì trong trường hợp này nhỉ?
qk_pro
Member
https://github.com/keycloak/keycloak/tree/main/core/src/test/java/org/keycloake chưa từng thấy unit test nên cũng ko hình dung dc là unit test nó đc code ntn và chạy ra làm s lun
UT viết có khó ko mấy bác, e thấy mấy tin tuyển dụng tầm Mid trở lên là thường có "có exp với UT là 1 lợi thế r"
Ví dụ ở đây fen
B.G.F
(●´ω｀●)
Tks bác, cuối tuần e xem thử có dễ hiểu ko :v
TungDeTien24
Senior Member
Đơn giản là dùng testcontainer là được mà
Gửi từ Thợ code, lương vài đồng đông dương bằng vozFApp
dark_matter
Senior Member
Không test đủ hết các number format supported.
qk_pro
Member
Khi developent team từ trong đầu đã không có format đấy thì có UT cũng không có ai nhận ra được để mà approve hay không approve PR
Theo tôi hiểu thì sai lầm đã lặp đi lặp lại hàng ngàn lần thì nó đã là 1 case đã ngoài nhận thức của dev team rồi.
dark_matter
Senior Member
100% thì tốt.
Phần Service/BusinessService cần test nhiều nhất (thường check code complexity thì các method trong này sẽ có complexity cao nhất).
"Phần code hiển nhiên" -> Nó hiển nhiên lúc này nhưng không hiển nhiên lúc khác, và cũng tuỳ dev. Nên test hết.
Lúc này bạn có hỏi Repository có test không (ko hiểu sao xoá)
, thì nếu chỉ là interface extends JpaRepository thì không cần test, nếu có custom query thì nên test (vd dùng liquibase + h2 database + @DataJpaTest )
dark_matter
Senior Member
Lúc mới code, lại chưa có enforce phải có UT cho tất cả các method, nên dev viết ra để QA test, QA test ko có lỗi là được => Vì thế nên mới có lỗi trên production sau hơn 1 năm, và dev may cũng ko bị sao (đổ qua cho QA
). Nhưng giờ thì khác rồi cả Dev lẫn QA đều phải test nhiều hơn.
billy_don
Senior Member
Cảm ơn bác, qua đến nay lục lại voz những cmt của bác, giống như vừa khám phá ra một chân trời mới.100% thì tốt.
Phần Service/BusinessService cần test nhiều nhất (thường check code complexity thì các method trong này sẽ có complexity cao nhất).
"Phần code hiển nhiên" -> Nó hiển nhiên lúc này nhưng không hiển nhiên lúc khác, và cũng tuỳ dev. Nên test hết.
Lúc này bạn có hỏi Repository có test không (ko hiểu sao xoá)
Em còn một chút thắc mắc nữa, mong bác giải đáp giúp em.
Đối với adapter trong hexagonal thì thường bác sẽ test như thế nào nhỉ? (Ví dụ như message queue...v.v).
Ngoài ra nếu requirement thay đổi liên tục, thì viết test như thế nào để ít bị ảnh hưởng nhất ( ý em là production code thay đổi không làm thay đổi test)
Chủ đề tương tự
