Tôi đã đọc rất nhiều điều về TDD nhưng tôi vẫn nghi ngờ. Ví dụ, tôi có các sơ đồ lớp này:
Đó là một ví dụ đơn giản, chỉ để tìm hiểu về TDD và các đối tượng giả.
Bài kiểm tra nào tôi nên viết trước? Sản phẩm , sau đó Line và cuối cùng, Đặt hàng ? Nếu tôi làm điều đó, tôi nên sử dụng Line và Product để kiểm tra Đơn hàng hay tôi nên sử dụng Mock Object? Khi nào tôi nên sử dụng Mock Object? Tôi có nên sử dụng UML với XP và TDD không?
Tôi chưa nhận được những điều này.
Câu trả lời:
Đánh giá từ sơ đồ, Sản phẩm là một lớp dữ liệu câm, không có chức năng để kiểm tra. Vì vậy, tôi sẽ bắt đầu viết các bài kiểm tra cho (và triển khai, kiểu TDD) Dòng đầu tiên và sau đó Đặt hàng, lên thang phụ thuộc. Thông thường có thể kiểm tra các lớp cấp thấp hơn của bạn trước khi bắt đầu làm việc với các lớp cấp cao hơn (nghĩa là phụ thuộc vào cấp thấp hơn). Điều này làm cho việc bắt lỗi hiệu quả hơn.
Việc bạn có cần sử dụng các đối tượng giả hay không phụ thuộc vào các phụ thuộc thực tế của lớp được kiểm tra. Nếu đây là các lớp đơn giản mà bạn có thể dễ dàng khởi tạo và thiết lập với bất kỳ dữ liệu / trạng thái mong muốn nào cần thiết cho các bài kiểm tra của mình, bạn không cần phải giả. (Đây có vẻ là trường hợp thiết kế ví dụ của bạn ở đây.) Tuy nhiên, nếu bất kỳ phụ thuộc nào khó khởi tạo / có phụ thuộc rộng rãi / có tác dụng phụ không mong muốn / phụ thuộc vào tài nguyên bên ngoài như DB, thì nó có ý nghĩa để sử dụng một đối tượng giả thay thế.
Tôi không thấy nhiều nhu cầu cho các đối tượng giả ở đây. Như được chỉ ra bởi những người khác, bạn cần những thứ đó nếu hầu như khó thiết lập.
Ví dụ: chúng tôi đã sử dụng chúng với các dự án Ruby on Rails khi chúng tôi kiểm tra các bộ điều khiển và cần đăng nhập người dùng sẽ yêu cầu một cuộc gọi đến bộ điều khiển khác và lưu trữ một phần thông tin của nó trong cookie. Trong trường hợp này, thật hữu ích khi giả định người dùng đã đăng nhập trả về đúng, khi được hỏi về một đặc quyền truy cập nhất định.
Thông thường để kiểm tra bạn muốn cách ly hệ thống / đối tượng đang thử nghiệm, vì vậy bạn sẽ chế giễu bất cứ thứ gì nằm ngoài điều đó. Vì vậy, bằng cách sử dụng sơ đồ lớp của bạn, khi kiểm tra một đối tượng thứ tự, hãy sử dụng một giả cho đối tượng đường. Khi kiểm tra Line, hãy sử dụng bản giả cho Đơn hàng và Sản phẩm. Khi thử nghiệm sản phẩm, sử dụng giả cho Line.
"TDD chủ yếu là một kỹ thuật thiết kế với tác dụng phụ là đảm bảo rằng mã nguồn của bạn được kiểm tra kỹ lưỡng đơn vị" - Scott W. Ambler
Ý tưởng là tìm thiết kế bằng cách viết bài kiểm tra đơn vị. Trong trường hợp của bạn, có vẻ như bạn đã có thiết kế tại chỗ, điều này đánh bại mục đích của TDD (giả sử thiết kế của bạn là cuối cùng).
Về chế giễu. Nếu bạn muốn giả, tôi khuyên bạn nên thử Sản phẩm khi viết bài kiểm tra cho Line và giả Line khi kiểm tra Đơn hàng. Nhưng nó có thể là quá mức cần thiết ở đây. Cá nhân tôi cố gắng hạn chế chế nhạo càng nhiều càng tốt và sử dụng nó để tách rời các phụ thuộc vào các lớp bên ngoài (chẳng hạn như các trường hợp cơ sở dữ liệu).