Có quá nhiều xác nhận mã mùi?

Tôi thực sự yêu thích thử nghiệm đơn vị và TDD - Tôi đang thử nghiệm bị nhiễm bệnh.

Tuy nhiên, kiểm tra đơn vị thường được sử dụng cho các phương pháp công cộng. Đôi khi, mặc dù tôi cũng phải kiểm tra một số giả định - các xác nhận trong các phương thức riêng tư, bởi vì một số trong số chúng là "nguy hiểm" và tái cấu trúc không thể giúp gì thêm. (Tôi biết, các khung kiểm tra cho phép thử nghiệm các phương thức riêng tư).

Vì vậy, nó trở thành một thói quen của tôi rằng dòng đầu tiên và dòng cuối cùng của một phương thức riêng tư đều là các xác nhận.

Tuy nhiên, tôi nhận thấy rằng tôi có xu hướng sử dụng các xác nhận trong các phương thức công khai (cũng như riêng tư) chỉ "để chắc chắn". Đây có thể là "trùng lặp thử nghiệm" vì các giả định phương thức công khai được kiểm tra từ bên ngoài bởi khung thử nghiệm đơn vị không?

Ai đó có thể nghĩ về quá nhiều khẳng định là một mùi mã?

Những xác nhận đó thực sự hữu ích để kiểm tra các giả định của bạn, nhưng chúng cũng phục vụ một mục đích thực sự quan trọng khác: tài liệu. Bất kỳ người đọc phương pháp nào cũng có thể đọc các xác nhận để nhanh chóng xác định các điều kiện trước và sau mà không cần phải xem bộ kiểm tra. Vì lý do này, tôi khuyên bạn nên giữ những khẳng định đó vì lý do tài liệu, thay vì lý do kiểm tra. Về mặt kỹ thuật, bạn đang sao chép các xác nhận, nhưng chúng phục vụ hai mục đích khác nhau và rất hữu ích trong cả hai.

Giữ chúng như những khẳng định tốt hơn là sử dụng bình luận, bởi vì chúng chủ động kiểm tra các giả định bất cứ khi nào chúng được chạy.

Có vẻ như bạn đang cố gắng thực hiện Thiết kế theo hợp đồng bằng tay.

Làm DbC là một ý tưởng tốt, nhưng ít nhất bạn nên xem xét chuyển sang ngôn ngữ hỗ trợ ngôn ngữ đó (chẳng hạn như Eiffel ) hoặc ít nhất sử dụng khung hợp đồng cho nền tảng của bạn (ví dụ: Hợp đồng mã Microsoft cho .NETlà khá đẹp, được cho là khung hợp đồng tinh vi nhất ngoài kia, thậm chí còn mạnh hơn cả Eiffel). Bằng cách đó, bạn có thể tận dụng tốt hơn sức mạnh của hợp đồng. Ví dụ: bằng cách sử dụng khung hiện có, bạn có thể hiển thị các hợp đồng trong tài liệu của mình hoặc IDE (ví dụ: Hợp đồng mã cho .NET được hiển thị trong IntelliSense và, nếu bạn có VS Ultimate, thậm chí có thể được kiểm tra tĩnh bởi trình cung cấp định lý tự động trong thời gian biên dịch bạn gõ, tương tự, nhiều khung hợp đồng Java có các tài liệu JavaDoc sẽ tự động trích xuất các hợp đồng vào tài liệu API JavaDoc của bạn).

Và ngay cả khi nó chỉ ra rằng trong tình huống của bạn không có cách nào khác để thực hiện thủ công, thì bây giờ bạn ít nhất cũng biết nó được gọi là gì và có thể đọc về nó.

Vì vậy, tóm lại: nếu bạn thực sự đang làm DbC, ngay cả khi bạn không biết điều đó, thì những khẳng định đó là hoàn toàn tốt.

Bất cứ khi nào bạn không có toàn quyền kiểm soát các tham số đầu vào của mình, bạn nên kiểm tra trước các lỗi đơn giản. Thất bại trên null chẳng hạn.

Đây không phải là bản sao của các thử nghiệm của bạn, vì chúng nên kiểm tra rằng mã không phù hợp với các tham số đầu vào xấu, và sau đó ghi lại điều đó .

Tôi không nghĩ bạn nên khẳng định các tham số trả về (trừ khi bạn rõ ràng có một bất biến mà bạn muốn người đọc hiểu). Đây cũng là công việc của những người không lành mạnh.

Cá nhân tôi không thích assertcâu lệnh trong Java, vì chúng có thể bị tắt và sau đó nó là một bảo mật sai.

Tôi nghĩ rằng việc sử dụng các xác nhận trong các phương thức công cộng thậm chí còn quan trọng hơn, vì ở đó bạn không kiểm soát các đầu vào và có thể có nhiều khả năng bị giả định bị phá vỡ.

Kiểm tra các điều kiện đầu vào nên được thực hiện trong tất cả các phương pháp công cộng và được bảo vệ. Nếu các đầu vào được truyền trực tiếp đến một phương thức riêng tư, thì việc kiểm tra các đầu vào của nó có thể là dự phòng.

Kiểm tra các điều kiện đầu ra (ví dụ trạng thái đối tượng hoặc giá trị trả về đó! = Null) nên được thực hiện trong các phương thức bên trong (ví dụ: phương thức riêng). Nếu các đầu ra được truyền trực tiếp từ phương thức riêng sang đầu ra của phương thức công khai mà không tính toán bổ sung hoặc thay đổi trạng thái bên trong, thì việc kiểm tra các điều kiện đầu ra của phương thức công khai có thể là dự phòng.

Tôi đồng ý với Oleksi, tuy nhiên, sự dư thừa có thể làm tăng khả năng đọc và nó cũng có thể tăng khả năng bảo trì (nếu việc chuyển nhượng trực tiếp hoặc trả lại không còn là vấn đề trong tương lai).

Thật khó để không biết ngôn ngữ về vấn đề này, vì các chi tiết về cách xác nhận và xử lý lỗi / xử lý ngoại lệ 'đúng' được thực hiện có liên quan đến câu trả lời. Đây là 0,02 đô la của tôi, dựa trên kiến ​​thức về Java & C ++ của tôi.

Các xác nhận trong các phương thức riêng tư là một điều tốt, giả sử bạn không quá nhiệt tình và đặt chúng ở mọi nơi . Nếu bạn đang đặt chúng vào các phương thức thực sự đơn giản hoặc liên tục kiểm tra những thứ như các trường không thay đổi, thì bạn sẽ làm lộn xộn mã không cần thiết.

Khẳng định trong các phương pháp công cộng thường được tránh tốt nhất. Bạn vẫn nên làm những việc như kiểm tra xem hợp đồng phương thức không bị vi phạm, nhưng nếu đúng thì bạn nên đưa ra các ngoại lệ được gõ phù hợp với các thông điệp có ý nghĩa, hoàn nguyên trạng thái có thể, v.v. (cái mà @rwong gọi là "đầy đủ xử lý lỗi thích hợp ").

Nói chung, bạn chỉ nên sử dụng khẳng định để giúp bạn phát triển / gỡ lỗi. Bạn không thể cho rằng bất cứ ai sử dụng API của bạn thậm chí sẽ kích hoạt các xác nhận khi họ sử dụng mã của bạn. Mặc dù chúng có một số ứng dụng trong việc giúp ghi lại mã, nhưng thường có những cách tốt hơn để ghi lại những điều tương tự (ví dụ: tài liệu phương thức, ngoại lệ).

Thêm vào danh sách (hầu hết) các câu trả lời đặc biệt, một lý do khác cho rất nhiều khẳng định và trùng lặp, là bạn không biết làm thế nào, khi nào hoặc bởi ai mà lớp sẽ được sửa đổi trong suốt thời gian tồn tại. Nếu bạn đang viết mã vứt đi sẽ chết trong một năm, không phải là một mối quan tâm. Nếu bạn đang viết mã sẽ được sử dụng trong hơn 20 năm, nó sẽ trông khá khác biệt - và một giả định bạn đưa ra có thể không còn hiệu lực. Anh chàng thực hiện thay đổi đó sẽ cảm ơn bạn vì những lời khẳng định.

Ngoài ra, không phải tất cả các lập trình viên đều hoàn hảo - một lần nữa, các khẳng định có nghĩa là một trong những "cú trượt" đó sẽ không lan truyền quá xa.

Đừng đánh giá thấp hiệu quả của những khẳng định này (và các kiểm tra khác về các giả định) sẽ có trong việc giảm chi phí bảo trì.

Có các xác nhận trùng lặp không phải là sai mỗi se, nhưng có các xác nhận "chỉ để đảm bảo" không phải là tốt nhất. Nó thực sự nắm bắt chính xác những gì mỗi bài kiểm tra đang cố gắng thực hiện. Chỉ khẳng định những gì là hoàn toàn cần thiết. Nếu một thử nghiệm sử dụng Moq để xác minh một phương thức được gọi, thì thực sự không có vấn đề gì xảy ra sau khi phương thức đó được gọi, thử nghiệm chỉ liên quan đến việc đảm bảo phương thức được gọi.

Nếu mọi bài kiểm tra đơn vị có cùng một tập hợp các xác nhận, ngoại trừ một hoặc hai, thì khi bạn cấu trúc lại một chút, tất cả các bài kiểm tra có thể thất bại vì cùng một lý do, thay vì cho bạn thấy tác động thực sự của bộ tái cấu trúc. Bạn có thể rơi vào tình huống bạn chạy tất cả các bài kiểm tra, tất cả đều thất bại vì mọi bài kiểm tra đều có cùng một khẳng định, bạn sửa lỗi đó, chạy lại các bài kiểm tra, chúng thất bại vì một lý do khác, bạn sửa lỗi đó. Lặp lại cho đến khi hoàn thành.

Cũng xem xét việc duy trì dự án thử nghiệm của bạn. Điều gì xảy ra khi bạn thêm một tham số mới, hoặc đầu ra được điều chỉnh từng chút một, bạn sẽ phải quay lại qua một loạt các thử nghiệm và thay đổi một xác nhận hoặc thêm một xác nhận? Và, tùy thuộc vào mã của bạn, cuối cùng bạn có thể phải thiết lập nhiều hơn chỉ để đảm bảo tất cả các xác nhận đều vượt qua.

Tôi có thể hiểu được sức hấp dẫn của việc muốn bao gồm các xác nhận trùng lặp trong bài kiểm tra đơn vị, nhưng nó thực sự là quá mức cần thiết. Tôi đã đi xuống cùng một con đường với dự án thử nghiệm đầu tiên của tôi. Tôi đã đi xa nó bởi vì sự bảo trì một mình đã khiến tôi phát điên.

Tuy nhiên, thử nghiệm đơn vị được sử dụng cho các phương pháp công cộng.

Nếu khung thử nghiệm của bạn cho phép người truy cập, thì phương pháp thử nghiệm đơn vị cũng là một ý tưởng tốt (IMO).

Ai đó có thể nghĩ về quá nhiều khẳng định là một mùi mã?

Tôi làm. Các xác nhận là ổn, nhưng mục tiêu đầu tiên của bạn là làm cho nó để kịch bản thậm chí không thể thực hiện được ; không chỉ là nó không xảy ra

Đó là thực tế xấu.

Bạn không nên thử phương pháp công khai / riêng tư. Bạn nên kiểm tra toàn bộ lớp học. Chỉ cần chắc chắn rằng bạn có bảo hiểm tốt.

Nếu bạn đi theo cách riêng (nguyên thủy) để kiểm tra riêng từng phương thức như một quy tắc chung, bạn sẽ thấy rất khó để cấu trúc lại lớp của mình trong tương lai. Và đó là một trong những điều tốt nhất TDD cho phép bạn làm.

Bên cạnh đó, nó là sự trùng lặp. Hơn nữa, nó gợi ý rằng người viết mã không thực sự biết anh ta đang làm gì. Và điều buồn cười là, bạn làm .

Một số người đối xử với các xét nghiệm của họ với sự chăm sóc ít hơn so với mã sản xuất của họ. Họ không nên. Nếu bất cứ điều gì, kinh nghiệm của tôi đề nghị thậm chí xử lý các xét nghiệm cẩn thận hơn. Họ đáng giá nó.