CÓ TUYỆT VỜI với TDD (và với một vài ngoại lệ)
Tranh cãi không sao, nhưng tôi cho rằng bất cứ ai trả lời 'không' cho câu hỏi này đều thiếu một khái niệm cơ bản về TDD.
Đối với tôi, câu trả lời là có, nếu bạn theo TDD. Nếu bạn không thì không có câu trả lời hợp lý.
DDD trong TDD
TDD thường được trích dẫn là có lợi ích chính.
- Phòng thủ
- Đảm bảo mã có thể thay đổi nhưng không phải là hành vi của nó .
- Điều này cho phép thực hành tái cấu trúc rất quan trọng .
- Bạn có đạt được TDD này hay không.
- Thiết kế
- Bạn chỉ định những gì nên làm, làm thế nào nó nên hành xử trước khi thực hiện nó.
- Điều này thường có nghĩa là quyết định thực hiện nhiều thông tin hơn .
- Tài liệu
- Bộ thử nghiệm phải đóng vai trò là tài liệu đặc tả (yêu cầu).
- Sử dụng các thử nghiệm cho mục đích như vậy có nghĩa là tài liệu và việc thực hiện luôn ở trạng thái nhất quán - thay đổi cái này có nghĩa là thay đổi cái khác. So sánh với các yêu cầu giữ và thiết kế trên tài liệu từ riêng biệt.
Trách nhiệm riêng biệt với việc thực hiện
Là những lập trình viên, sẽ rất hấp dẫn khi nghĩ về các thuộc tính như một thứ gì đó có ý nghĩa và getters và setter như một loại chi phí nào đó.
Nhưng các thuộc tính là một chi tiết triển khai, trong khi setters và getters là giao diện hợp đồng thực sự làm cho các chương trình hoạt động.
Điều quan trọng hơn nhiều là đánh vần rằng một đối tượng nên:
Cho phép khách hàng của mình thay đổi trạng thái
và
Cho phép khách hàng truy vấn trạng thái của nó
sau đó làm thế nào trạng thái này thực sự được lưu trữ (trong đó một thuộc tính là phổ biến nhất, nhưng không phải là cách duy nhất).
Một bài kiểm tra như
(The Painter class) should store the provided colour
rất quan trọng đối với phần tài liệu của TDD.
Thực tế là việc thực hiện cuối cùng là tầm thường (thuộc tính) và không mang lại lợi ích phòng thủ nên bạn không biết khi viết bài kiểm tra.
Thiếu kỹ thuật khứ hồi ...
Một trong những vấn đề chính trong thế giới phát triển hệ thống là thiếu kỹ thuật khứ hồi 1 - quá trình phát triển của một hệ thống bị phân mảnh thành các quy trình phụ rời rạc, các tạo phẩm trong đó (tài liệu, mã) thường không nhất quán.
1 Brodie, Michael L. "John Mylopoulos: may hạt giống của mô hình khái niệm." Mô hình hóa khái niệm: Nền tảng và ứng dụng. Springer Berlin Heidelberg, 2009. 1-9.
... và cách TDD giải quyết nó
Đây là phần tài liệu của TDD đảm bảo rằng các thông số kỹ thuật của hệ thống và mã của nó luôn nhất quán.
Thiết kế trước, thực hiện sau
Trong TDD, chúng tôi viết bài kiểm tra chấp nhận thất bại trước, chỉ sau đó viết mã cho phép chúng vượt qua.
Trong BDD cấp cao hơn, chúng tôi viết các kịch bản trước, sau đó làm cho chúng vượt qua.
Tại sao bạn nên loại trừ setters và getter?
Về lý thuyết, hoàn toàn có thể trong TDD cho một người viết bài kiểm tra và một người khác thực hiện mã làm cho nó vượt qua.
Vì vậy, hãy tự hỏi:
Người viết bài kiểm tra cho một lớp có đề cập đến getters và setter không.
Vì getters và setters là một giao diện chung cho một lớp, câu trả lời rõ ràng là có , hoặc sẽ không có cách nào để thiết lập hoặc truy vấn trạng thái của một đối tượng.
Rõ ràng, nếu bạn viết mã trước, câu trả lời có thể không rõ ràng lắm.
Ngoại lệ
Có một số trường hợp ngoại lệ rõ ràng cho quy tắc này - các chức năng là chi tiết triển khai rõ ràng và rõ ràng không phải là một phần của thiết kế hệ thống.
Chẳng hạn, một phương thức cục bộ 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
Hoặc chức năng riêng tư square()ở đây:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Hoặc bất kỳ chức năng nào khác không phải là một phần của publicgiao diện cần đánh vần trong thiết kế của thành phần hệ thống.