gaconkute
Member
sau, viết trước làm gề nhỉTiện hỏi các thím là các thím viết unit test trước hay sau khi code?
sau, viết trước làm gề nhỉTiện hỏi các thím là các thím viết unit test trước hay sau khi code?
Hỏi câu chán đời thế fen, cứ hiểu unitest là fen viết hàm code một chức năng gì đó trước , rồi sau đó qua 1 class unitest để viết test cho hàm chức năng đó. Còn không muốn viết unitest thì qua viết script automation hệ thống như tôi nè.Tiện hỏi các thím là các thím viết unit test trước hay sau khi code?
automation như selenium đó bạn
Đúng rồi fen, tôi thấy tester họ viết automation test và dev viết unitest họ đi theo 2 hướng khác nhau hoàn toàn. Không phải là thay thế nhau, mà bổ sung cho nhau để sản phẩm trở nên hoàn thiện. Dev chủ yếu test mấy cái hàm do mình viết ra trong source project, còn tester họ test trên giao diện những thứ mà họ có thể thấy đc.Thì như tôi nói đấy, 2 cái đó không thay thế mà bổ sung cho nhau. Trong đó unit test là tối quan trọng và bất kì product nào cũng phải có unit test với 80% code coverage.
Sent from Samsung SM-A528B using vozFApp
Đúng rồi fen, tôi thấy tester họ viết automation test và dev viết unitest họ đi theo 2 hướng khác nhau hoàn toàn. Không phải là thay thế nhau, mà bổ sung cho nhau để sản phẩm trở nên hoàn thiện. Dev chủ yếu test mấy cái hàm do mình viết ra trong source project, còn tester họ test trên giao diện những thứ mà họ có thể thấy đc.
nếu cty áp dụng TDD thì phải viết trước.sau, viết trước làm gề nhỉ
Tôi thì không phải dân dev thực thụ nhưng tôi hiểu viết unitest nó giúp người viết hiểu mình đang viết cái gì. Hiểu sâu hơn về code, và tôi ớn nhất là viết unitest cho mấy cái hàm của mấy ông làm về AI, data vì mấy ổng dùng thuật toán, mảng data này nọ để viết tuy ngắn gọn đẹp đẻ nhưng để hiểu đc hàm đó dùng để làm gì thì mò đến vỡ não.Chính xác rồi đấy thím.
Sent from Samsung SM-A528B using vozFApp
nếu cty áp dụng TDD thì phải viết trước.
Thực tế mấy năm đầu đi làm, đa phần viết unit test toàn cover những happy cases hoặc viết xà quần gì đó để tăng tỷ lệ coverage > 90% để deploy thôi nên ưu điểm của việc viết unit test gần như không có
vớ vẩn là do người áp dụng thôi fen. cái gì hợp lý thì sẽ tồn tại, cái gì vẫn còn tồn tại thì ắt hẳn nó phải hợp lý. mình chưa hiểu ý fen chỗ thành công đó nghĩa là gì? chứ cty hiện tại của mình thì code, test nó mới ở giai đoạn đầu của flow thôiTDD là cái lý thuyết vớ vẩn thôi, thực tế thì code xong mà viết test được là thành công lắm rồi đấy.
Sent from Samsung SM-A528B using vozFApp
vớ vẩn là do người áp dụng thôi fen. cái gì hợp lý thì sẽ tồn tại, cái gì vẫn còn tồn tại thì ắt hẳn nó phải hợp lý. mình chưa hiểu ý fen chỗ thành công đó nghĩa là gì? chứ cty hiện tại của mình thì code, test nó mới ở giai đoạn đầu của flow thôi
có nhiều nơi làm product không test màVậy nên ae mới khuyên lúc mới đi làm thì nên vào cty product đó thím ))
TDD thì anh nên dùng nó như là một lời nhắc nhở để khi thiết kế một hàm nào đó, hoặc một đoạn mã bất kì nào đó thì anh cũng có thể viết test cho nó được. Ví dụ cùng một việc chỉnh màu chỉnh font anh có thể viết trực tiếp ở chỗ render giao diện, nhưng mà vậy sao test được, nên anh sẽ phải tách cái đó ra thành 1 cái lớp trung gian mà ở đó tuỳ theo đầu vào thế nào rồi anh trả ra màu sắc font chữ tương ứng. Rồi viết unit test cho cái lớp đó.Thì như tôi nói là thực tế đó mai fen. Tôi cũng làm vài công ty product lớn có nhỏ có và hầu hết đều cũng chỉ TDD được 1 giai đoạn ngắn mà thôi.
Sent from Samsung SM-A528B using vozFApp
thank bác, vậy bác có thể chia sẻ nốt câu hỏi của em là làm thế nào cover hết toàn bộ case có thể có của 1 chức năng, em lấy ví dụ cái API ở đầu bài của em đi/ cái post đầu tiên ạ.Thì như tôi nói là thực tế đó mai fen. Tôi cũng làm vài công ty product lớn có nhỏ có và hầu hết đều cũng chỉ TDD được 1 giai đoạn ngắn mà thôi.
Sent from Samsung SM-A528B using vozFApp
sau, viết trước làm gề nhỉ
Hỏi câu chán đời thế fen, cứ hiểu unitest là fen viết hàm code một chức năng gì đó trước , rồi sau đó qua 1 class unitest để viết test cho hàm chức năng đó. Còn không muốn viết unitest thì qua viết script automation hệ thống như tôi nè.
ặc, sao mình không tự nghĩ test case rồi ném cho bọn QAThường mình viết testcase theo test case của QA.
thank bác, vậy bác có thể chia sẻ nốt câu hỏi của em là làm thế nào cover hết toàn bộ case có thể có của 1 chức năng, em lấy ví dụ cái API ở đầu bài của em đi/ cái post đầu tiên ạ.
Employee get_youngest_employee(List<Employee> employees)
để tìm ra nhân viên trẻ nhất thì có thể có các trường hợp sau:employees
bị null
hoặc rỗngdate_of_birth
bị null
.