vozphongtrao1
Senior Member
Sau khi tìm hiểu về tư tưởng của TDD, tôi nghĩ ae nên sử dụng UN một cách thực dụng hơn. Như nhiều ae đề cập, UN không chỉ đơn giản là để đảm bảo logic code của ae chạy ko lỗi, nó sẽ đóng vài trò vừa là 1 document cho code base của mình sau này, vừa là 1 cái quality gate để đảm bảo việc thay đổi, mở rộng code base của mình hay bất kỳ ai sau này vẫn sẽ đảm bảo các bussiness logic của component đó không bị thay đổi.
Như trong TDD, việc viết test trước giống như trong quá trình phát triển một tính năng, mình sẽ phải liệt kê được tất cả các use case, behavior của tính năng đó tới người dùng. Nếu việc yêu cầu những use case của tính năng trên là việc của BA/PM, thì UN giống như cách dev diễn giải những yêu cầu đó vào code base của mình. Nên trong thời gian phát triển tính năng có hạn, UN nên tập trung cho những use case phía BA sẽ yêu cầu, từ đó khi phát triển dev khi chạy test cũng sẽ biết mình đang thiếu những case nào từ phía BA. Việc viết UN như thế vừa đảm bảo thời gian cho UN ko quá lớn (dev có thể vừa tìm hiểu về y/c, vừa viết UN dựa trên chúng), vừa đảm bảo sản phẩm mình được test.
Như trong TDD, việc viết test trước giống như trong quá trình phát triển một tính năng, mình sẽ phải liệt kê được tất cả các use case, behavior của tính năng đó tới người dùng. Nếu việc yêu cầu những use case của tính năng trên là việc của BA/PM, thì UN giống như cách dev diễn giải những yêu cầu đó vào code base của mình. Nên trong thời gian phát triển tính năng có hạn, UN nên tập trung cho những use case phía BA sẽ yêu cầu, từ đó khi phát triển dev khi chạy test cũng sẽ biết mình đang thiếu những case nào từ phía BA. Việc viết UN như thế vừa đảm bảo thời gian cho UN ko quá lớn (dev có thể vừa tìm hiểu về y/c, vừa viết UN dựa trên chúng), vừa đảm bảo sản phẩm mình được test.