Có bao nhiêu bài kiểm tra cho mỗi phương pháp?
Vâng, mức tối đa lý thuyết và không thực tế cao là độ phức tạp N-Path (giả sử tất cả các thử nghiệm bao gồm các cách khác nhau thông qua mã;)). Tối thiểu là MỘT!. Theo phương thức công khai , anh ta không kiểm tra chi tiết triển khai, chỉ các hành vi bên ngoài của một lớp (trả về giá trị & gọi các đối tượng khác).
Bạn trích dẫn:
* Và ý nghĩ thử nghiệm từng phương pháp của bạn bằng phương pháp thử nghiệm riêng (trong mối quan hệ 1-1) sẽ rất buồn cười. *
và sau đó hỏi:
Vì vậy, nếu việc tạo một bài kiểm tra cho mỗi phương pháp là 'đáng cười', làm thế nào / khi nào bạn chọn những gì bạn viết bài kiểm tra?
Nhưng tôi nghĩ bạn đã hiểu nhầm tác giả ở đây:
Ý tưởng có one test methodper one method in the class to testlà cái mà tác giả gọi là "buồn cười".
(Ít nhất là đối với tôi) Nó không phải là về 'ít' mà là về 'nhiều hơn'
Vì vậy, hãy để tôi nói lại như tôi hiểu anh ấy:
Và ý nghĩ thử nghiệm từng phương pháp của bạn với CHỈ MỘT PHƯƠNG PHÁP (phương pháp thử nghiệm riêng của nó trong mối quan hệ 1-1) sẽ rất buồn cười.
Để trích dẫn lại trích dẫn của bạn:
Khi bạn nhận ra rằng đó là tất cả về việc chỉ định hành vi và không viết bài kiểm tra, quan điểm của bạn sẽ thay đổi.
Khi bạn thực hành TDD, bạn không nghĩ :
Tôi có một phương pháp calculateX($a, $b);và nó cần một bài kiểm tra kiểm testCalculcateXtra MỌI THỨ về phương pháp đó.
Những gì TDD nói với bạn là suy nghĩ về những gì mã của bạn NÊN LÀM :
Tôi cần tính toán giá trị lớn hơn của hai giá trị ( trường hợp thử nghiệm đầu tiên! ) Nhưng nếu $ a nhỏ hơn 0 thì sẽ tạo ra lỗi ( trường hợp thử nghiệm thứ hai! ) Và nếu $ b nhỏ hơn 0 thì nên .... ( trường hợp thử nghiệm thứ ba! ) và như vậy.
Bạn muốn kiểm tra các hành vi, không chỉ các phương thức đơn lẻ mà không có ngữ cảnh.
Bằng cách đó, bạn nhận được một bộ kiểm tra là tài liệu cho mã của mình và THỰC SỰ giải thích những gì nó dự kiến sẽ làm, thậm chí có thể tại sao :)
Làm thế nào để bạn đi về việc quyết định đoạn mã nào bạn tạo ra các bài kiểm tra đơn vị?
Vâng tất cả mọi thứ kết thúc trong kho lưu trữ hoặc bất cứ nơi nào gần sản xuất đều cần một bài kiểm tra. Tôi không nghĩ rằng tác giả của các trích dẫn của bạn sẽ không đồng ý với điều đó khi tôi cố gắng nêu ở trên.
Nếu bạn không có bài kiểm tra cho việc thay đổi mã sẽ khó hơn (tốn kém hơn), đặc biệt nếu đó không phải là bạn thực hiện thay đổi.
TDD là một cách để đảm bảo rằng bạn có các bài kiểm tra cho MỌI THỨ nhưng miễn là bạn VIẾT các bài kiểm tra thì không sao. Thường thì viết chúng vào cùng một ngày sẽ giúp ích vì bạn sẽ không làm điều đó sau này, phải không? :)
Phản hồi ý kiến:
một số lượng lớn các phương thức không thể được kiểm tra trong một bối cảnh cụ thể vì chúng phụ thuộc hoặc phụ thuộc vào các phương thức khác
Vâng, có ba điều mà các phương thức có thể gọi:
Phương pháp công khai của các lớp khác
Chúng ta có thể giả định các lớp khác vì vậy chúng ta đã xác định trạng thái ở đó. Chúng tôi đang kiểm soát bối cảnh để đó không phải là vấn đề ở đó.
* Các phương thức được bảo vệ hoặc riêng tư trên cùng *
Mọi thứ không phải là một phần của API công khai của một lớp thường không được kiểm tra trực tiếp.
Bạn muốn kiểm tra hành vi và không thực hiện và nếu một lớp thực hiện tất cả thì nó hoạt động theo một phương thức công khai lớn hoặc trong nhiều phương thức được bảo vệ nhỏ hơn được gọi là triển khai . Bạn muốn có thể THAY ĐỔI các phương pháp được bảo vệ đó mà KHÔNG chạm vào các bài kiểm tra của bạn. Bởi vì các bài kiểm tra của bạn sẽ bị hỏng nếu mã của bạn thay đổi hành vi! Đó là những gì bài kiểm tra của bạn dành cho, để cho bạn biết khi bạn phá vỡ một cái gì đó :)
Phương thức công khai trên cùng một lớp
Điều đó không xảy ra rất thường xuyên phải không? Và nếu nó giống như trong ví dụ sau, có một vài cách xử lý việc này:
$stuff = new Stuff();
$stuff->setBla(12);
$stuff->setFoo(14);
$stuff->execute();
Rằng các setters tồn tại và không phải là một phần của chữ ký phương thức thực thi là một chủ đề khác;)
Những gì chúng ta có thể kiểm tra ở đây là nếu các lệnh thực thi nổ tung khi chúng ta đặt các giá trị sai. Điều đó setBlađưa ra một ngoại lệ khi bạn vượt qua một chuỗi có thể được kiểm tra riêng nhưng nếu chúng tôi muốn kiểm tra hai giá trị được phép đó (12 & 14) thì không hoạt động TOGETHER (vì bất kỳ lý do gì) so với một trường hợp kiểm tra.
Nếu bạn muốn có một bộ kiểm tra "tốt", bạn có thể, trong php, có thể (!) Thêm một @covers Stuff::executechú thích để đảm bảo bạn chỉ tạo phạm vi bảo hiểm mã cho phương thức này và các công cụ khác chỉ cần thiết lập phải được kiểm tra riêng (một lần nữa, nếu bạn muốn thứ kia).
Vì vậy, vấn đề là: Có thể bạn cần tạo ra một số thế giới xung quanh trước tiên nhưng bạn sẽ có thể viết các trường hợp thử nghiệm có ý nghĩa thường chỉ bao gồm một hoặc có thể hai chức năng thực (setters không được tính ở đây). Phần còn lại có thể bị chế nhạo ether hoặc được kiểm tra trước và sau đó dựa vào (xem @depends)
* Lưu ý: Câu hỏi được di chuyển từ SO và ban đầu là về PHP / PHPUnit, đó là lý do tại sao mã mẫu và tài liệu tham khảo đến từ thế giới php, tôi nghĩ rằng điều này cũng có thể áp dụng cho các ngôn ngữ khác vì phpunit không khác nhiều so với xUnit khác khung kiểm tra.