karina hart
Member
TDD cho dữ tới lúc bị dí cũng kemeno mà ignore hết 
thảo luận Chia sẻ về Unit Testing và TDD
- Người tạo chủ đề potholer54-fanboy
- Ngày bắt đầu
Nepgear.
Member
Lý thuyết này đâu ra thế, QA vẫn cần đứng ra để test từ manual cho tới automation để đạt high trust, QA là chốt chặn cuối trc khi lên production.
TDD/Unit testing là từ dev viết và nó đem lại confident cho dev, chứ QA ko liên quan gì ở đây.
Tất nhiên là TDD tùy projects mà apply, vd như banking, fintech,... có apply TDD lại chả tăng trust nhiều hơn là ko viết.
servuskevin
Senior Member
potholer54-fanboy
Senior Member
Bác cứ thử nói "Không", sếp chửi thì kiếm cty khác, giờ ngành IT mà lo thiếu việc àTDD cho dữ tới lúc bị dí cũng kemeno mà ignore hết
potholer54-fanboy
Senior Member
Cái này tuỳ team thôi, chỗ tôi ngay từ đầu không có team QA vì quan điểm là dev phải chịu trách nhiệm với chất lượng code của mình. Thêm thông tin là số bug nhảm cực kì ít, có bug chỉ là edge cases. Sau này khi phát triển mạnh lên mới setup team QA và nhiệm vụ chính của họ là end2end tests chớ không phải là manual/acceptance test.
potholer54-fanboy
Senior Member
Tôi không làm front-end nên không rành lắm, chỉ thấy bọn nó viết test kiểu này:
- Nếu nhận được dữ liệu A thì show component A', nếu nhận được dữ liệu B thì show component B'
- Assert call endpoint X với param "abc" nếu như click vào button A, call endpoint X với param "xyz" nếu click vào button B
- Assert phải cancel request nếu double click vào nút A hay đang request mà nó click chỗ component X.
Cái này tôi không rành, để ai pro FE vào giải thích rõ hơn. Với lại FE thì follow BDD hơn là TDD
thanhlocgp
Member
nguyên 1 page mà 1 component á??? Thấy gì đó sai sai.
Nhiều component gộp lại thành 1 page chứ.
karina hart
Member
ko lo, nhưng cứ bị dí deadline là nghỉ việc thì chắc 1 năm e làm chục cty mấtBác cứ thử nói "Không", sếp chửi thì kiếm cty khác, giờ ngành IT mà lo thiếu việc à
potholer54-fanboy
Senior Member
Cái này tuỳ sếp có tâm hay không và văn hoá team nữa. Chỗ tôi chỉ cần giải thích rõ ràng lý do vì sao missed deadline, goal, sẽ làm gì để improve là sếp ok (sếp biết sếp ép là a e nghỉko lo, nhưng cứ bị dí deadline là nghỉ việc thì chắc 1 năm e làm chục cty mất
)Edit: Moé mới sáng nên chưa tỉnh ngủ. Chuyện dí thì mình cứ capacity bao nhiêu thì nhận bấy nhiêu thôi, có number rõ ràng chả ai ép được
via theNEXTvoz for iPhone
toi5
Senior Member
Xàm vừa thôi, TDD ko phải thần thánh mà ko capture hết bug, logic code lúc TDD thì có thể phát hiện ra sớm hơn khi test trực tiếp trên UI, hay E2E nhưng TDD cũng méo thể thay thế dc việc testing để đảm bảo quality
thevirginman
Đã tốn tiền
testing front-end mình thấy có hai loại ( theo những gì mình thấy, hồi trước làm fullstack hơn một năm xong nhảy qua đội data-infra )
logic testing: các thuật toán hay hàm dùng để xử lý dữ liệu từ dạng này sang dạng khác, hoặc làm các công vụ không liên quan đến UI, có thể dùng jest/mocha
UI test: render các component riêng rẽ, rồi test xem nó trông thế nào dựa vào các props/state khác nhau
Có thể dùng story book: https://storybook.js.org/docs/react/workflows/testing-with-storybook
mình sai hay thiếu gì các bác chỉ dạy nhé
potholer54-fanboy
Senior Member
Hồi xưa mình viết react cũng test tương tự vậy, mấy cái như selector, reducer thì là pure logic nên dễ test, component thì như bác nói. Nhưng giờ kiến thức đó outdate rồi, nhà nhà giờ xài hook với query mình chưa làm nên k dám ý kiến.
via theNEXTvoz for iPhone
XiangLiang
Member
Bác nào cho xin mã nguồn của integrate và unit test vó partern full với. Chứ gõ tìm thì toàn ra mấy cái test a+ b = c??? What??
Project thực tế phải test đc CRUD, đc bussiness với các service liên kêtz vs nhau, chứ tại sao lại unit test assert xem số a + số b có bằng C không đọc phát chán mà k áp dụng đc j cả.
Project thực tế phải test đc CRUD, đc bussiness với các service liên kêtz vs nhau, chứ tại sao lại unit test assert xem số a + số b có bằng C không đọc phát chán mà k áp dụng đc j cả.
potholer54-fanboy
Senior Member
Mấy open source đa số có test mà. Nếu không thấy bác cứ mạnh dạn thử 1 feature full tests, từ integration tới unit. Xài tool biết nó cover bao nhiêu %. Cố cover hết các case, branch là hình dung được thôi.
via theNEXTvoz for iPhone
Ishihara Nozomi
Senior Member
Mình cũng đang làm một project trên cloud. Cũng lần đầu apply TDD, phải nghỉ ra các test cases sau khi design rồi mới code.
Tính ra thời gian code ngắn lại, ít bugs tào lao hơn.
Có điều mình test với db, một test case ứng với một lần tạo db rồi xóa nên lâu kinh.
Ai có kinh nghiệm cho mình hỏi cách nào reuse db cho nhiều test cases được không.
Tính ra thời gian code ngắn lại, ít bugs tào lao hơn.
Có điều mình test với db, một test case ứng với một lần tạo db rồi xóa nên lâu kinh.
Ai có kinh nghiệm cho mình hỏi cách nào reuse db cho nhiều test cases được không.
QTQTQT
Member
After all thì cleanup cái mình tạo ra đi.
cái test với DB thì gọi là integration test,
cái test với chỉ logic không mới gọi là unit test.
cái test có sử dụng các nghiệp vụ thì nó gọi là BDD.
Nên là đang không rõ mọi người nói về TDD bên trên là cụ thể nói về loại nào.
potholer54-fanboy
Senior Member
Nếu bác xài RDBM thì cho cái test vào transaction ở setUp nhưng đừng commit transaction đó. Còn xài NoSQL thì seed db rồi delete cả db cho khoẻ. Cái Seed cũng quan trọng, bác đầu tư phần này đáng lắm.
Edit: kinh nghiệm là không nên re-use db cho nhiều test cases. Tôi đoán bác đang xài No-SQL nên gặp vấn đề này, 1 db cùng lắm nên xài cho 1 test suite, đừng nên xài chung quá nhiều. Có 2 lý do:
- DB là lưu state, trong khi test nên là stateless, nếu lưu db mà không xoá sẽ có nhiều side-effect và maybe là flaky tests.
- Tách db để run test multi-thread -> deploy nhanh hơn.
Chủ đề tương tự
