Các bài kiểm tra đơn vị nên được lưu trữ trong kho lưu trữ?

Tôi là một lập trình viên đang phát triển, người cuối cùng đã đưa thử nghiệm đơn vị vào thực tế cho một thư viện mà tôi đang lưu trữ trên GitHub.

Nó xảy ra với tôi rằng tôi có thể bao gồm các bộ thử nghiệm trong repo, nhưng khi tôi nhìn xung quanh các dự án khác, việc đưa vào các thử nghiệm có vẻ như là trúng hoặc bỏ lỡ.

Đây có được coi là hình thức xấu? Có phải ý tưởng rằng người dùng chỉ quan tâm đến mã làm việc và họ sẽ kiểm tra trong khuôn khổ của riêng họ không?

Bạn chắc chắn nên đặt các bài kiểm tra của bạn vào kho lưu trữ. Các xét nghiệm theo ý kiến ​​của tôi là một phần của mã và có thể giúp người khác hiểu được nó (nếu được viết tốt). Bên cạnh đó, họ có thể giúp đỡ người khác khi thay đổi hoặc đóng góp cho cơ sở mã của bạn. Các bài kiểm tra tốt có thể mang lại cho bạn sự tự tin rằng những thay đổi của bạn không vô tình phá vỡ bất cứ điều gì.

Mã kiểm tra nên được tách biệt tốt với mã sản xuất, mặc dù. Maven chẳng hạn đạt được điều này bằng cách đặt mã sản xuất và kiểm tra vào các thư mục khác nhau. Câu hỏi "là tập tin này là một phần của sản xuất hoặc của mã kiểm tra" không bao giờ nên phát sinh.

Cá nhân tôi không viết các bài kiểm tra đơn vị cho các thư viện được sử dụng trong mã của riêng tôi. Tôi hy vọng chúng sẽ hoạt động (ít nhất là khi tôi sử dụng phiên bản phát hành, mặc dù lỗi rõ ràng có thể xuất hiện). Nó nhận được một số phạm vi kiểm tra trong các thử nghiệm tích hợp, nhưng điều đó là không đủ.

Nếu bạn không bao gồm các bài kiểm tra đơn vị trong mã nguồn đã đăng ký, thì:

• Làm thế nào một người tải xuống và xây dựng bản sao mã của riêng họ sẽ xác minh rằng nó hoạt động theo cách nó được dự định? Lỗi trình biên dịch và thư viện rất hiếm và lỗi dữ liệu (đặc biệt là lỗi không thể biên dịch mã nguồn) thậm chí còn hiếm hơn, nhưng chúng chắc chắn có thể gây ra , đặc biệt là khi bạn không thể đưa ra môi trường xây dựng ở mức độ sử dụng lao động có thể ra lệnh những công cụ được sử dụng.
• Làm thế nào bạn sẽ có được các bài kiểm tra trở lại nếu có điều gì đó xảy ra với bản sao mã nguồn địa phương của bạn?
• Làm thế nào là một nhà phát triển mới sẽ xác minh rằng những thay đổi của họ không phá vỡ bất cứ điều gì trong cơ sở mã hiện tại?

Tóm lại, tôi sẽ coi việc không bao gồm bất kỳ bài kiểm tra đơn vị nào được viết trong kho mã nguồn chính thức là một điều rất tồi tệ.

Tất nhiên, bạn nên đặt các bài kiểm tra đơn vị vào kho lưu trữ, vì một số lý do:

• thật dễ dàng để trở lại phiên bản trước
• những người khác làm việc trong dự án cũng có quyền truy cập vào các bài kiểm tra đơn vị
• một số người coi các bài kiểm tra đơn vị là một phần của tài liệu (TDD và BDD)

Nếu có bất kỳ cơ hội để chạy chúng trên một máy tính khác, chắc chắn bao gồm chúng. Chúng nên được xây dựng riêng biệt, vì vậy người dùng không cần phải có, và họ có thể có thêm phụ thuộc, nhưng chúng chắc chắn nên được bao gồm.

Tôi cực kỳ nghi ngờ hầu hết các dự án không bao gồm các thử nghiệm trong kho lưu trữ đơn giản là không có dự án nào.

Có thể có một lý do để có các thử nghiệm dưới dạng mô-đun riêng biệt, vì vậy bạn có thể dễ dàng chạy thử nghiệm mới đối với mã cũ hơn. Nó sẽ hữu ích cho các thư viện ổn định API hoặc kiểm tra hộp đen thông qua dòng lệnh; tính hữu ích cho các ngôn ngữ được biên dịch trong đó các bài kiểm tra mới có thể sẽ không được biên dịch với mã cũ hơn.

Chắc chắn rồi. Điểm thưởng thêm ở đây nằm ở khả năng theo dõi phiên bản X của tệp nguồn đi với phiên bản Y của bài kiểm tra. Nói cách khác, bạn cần có thể quay lại phiên bản trước và thực hiện các bài kiểm tra phù hợp được thiết kế cho phiên bản đó (trong trường hợp thay đổi API hoặc somesuch).

Tôi vừa đọc xong "Phát triển ứng dụng Brownfield trong .Net" và điều này cung cấp một số lời khuyên tuyệt vời về cấu trúc của một ứng dụng, bao gồm kiểm soát nguồn và nơi / làm thế nào / tại sao để bao gồm các bài kiểm tra đơn vị (đặc biệt là trong lĩnh vực Tích hợp liên tục) . Nếu bạn là nhà phát triển .Net, tôi khuyên bạn nên dùng nó.