Tôi nên lưu trữ dữ liệu kiểm tra ở đâu?

Tôi có các bài kiểm tra đơn vị nhỏ hơn sử dụng các đoạn nhỏ từ các tập dữ liệu thực. Tôi cũng muốn kiểm tra chương trình của mình dựa trên các bộ dữ liệu đầy đủ vì nhiều lý do. Vấn đề duy nhất là một bộ dữ liệu thực duy nhất có dung lượng khoảng ~ 5GB. Tôi chưa tìm thấy bất kỳ con số khó khăn nào cho những gì kho Git có thể lưu trữ nhưng dường như quá nhiều.

Theo bài viết của Lập trình viên này, tôi nên giữ tất cả dữ liệu cần thiết để kiểm tra dự án trong kho lưu trữ.

Giải pháp mà nhóm của tôi đã áp dụng là dự án có một tệp chứa đường dẫn đến hệ thống tệp đính kèm mạng chứa dữ liệu thử nghiệm của chúng tôi. Các tập tin được bỏ qua Git.

Tôi cảm thấy như đây là một giải pháp không hoàn hảo vì hai lý do. Khi NAS không hoạt động, chậm hoặc chậm hơn chúng ta không thể chạy thử nghiệm đầy đủ. Lý do thứ hai là khi ai đó lần đầu tiên nhân bản một kho lưu trữ, các bài kiểm tra đơn vị không thành công nên họ phải tìm ra cách gắn kết mọi thứ với một tên nhất định và cú pháp được sử dụng để xây dựng tệp đường dẫn thử nghiệm.

Vì vậy, câu hỏi của tôi là hai lần. Có bao nhiêu dữ liệu là quá nhiều dữ liệu để lưu trữ trong kiểm soát sửa đổi?

Một cách tốt hơn để xử lý một lượng lớn dữ liệu thử nghiệm là gì?

Cách xử lý tệp lớn trong chuỗi xây dựng

Tôi thích sử dụng một công cụ xây dựng để quản lý phụ thuộc - chẳng hạn như maven hoặc gradle. Các tệp được lưu trữ trong kho lưu trữ web và công cụ sẽ tự động tải xuống và lưu vào bộ nhớ cache khi gặp phải sự phụ thuộc. Nó cũng loại bỏ thiết lập bổ sung (cấu hình NAS) cho những người muốn chạy thử nghiệm. Và nó làm cho dữ liệu làm mới khá đau (phiên bản này).

Cái gì quá lớn để đưa vào kiểm soát sửa đổi

Có một khu vực màu xám lớn. Và nếu bạn quyết định thứ gì đó không thuộc về RCS, thì lựa chọn thay thế của bạn là gì? Đó là một quyết định dễ dàng hơn nếu bạn giới hạn các lựa chọn giữa RCS và repo nhị phân (kiểu maven).

Lý tưởng nhất là bạn chỉ muốn những thứ RCS có thể chỉnh sửa được, có thể chỉnh sửa được hoặc là nơi bạn muốn theo dõi lịch sử. Bất cứ thứ gì là sản phẩm của một bản dựng hoặc một loại tự động hóa khác chắc chắn không thuộc về nơi đó. Kích thước là một hạn chế, nhưng không phải là chính - một tệp nguồn khổng lồ (thực tiễn xấu) chắc chắn thuộc về kiểm soát nguồn. Một nhị phân biên dịch nhỏ không.

Hãy sẵn sàng thỏa hiệp để thuận tiện cho nhà phát triển.

Khi NAS không hoạt động, chậm hoặc chậm hơn chúng ta không thể chạy thử nghiệm đầy đủ.

Rõ ràng, điều này chỉ có thể được giải quyết bằng cách sao chép 5GB từ NAS vào ổ đĩa cục bộ của bạn. Nhưng không cần phải làm điều này bằng tay.

Lý do thứ hai là khi ai đó lần đầu tiên nhân bản một kho lưu trữ, các bài kiểm tra đơn vị không thành công nên họ phải tìm ra cách gắn kết mọi thứ với một tên nhất định và cú pháp được sử dụng để xây dựng tệp đường dẫn thử nghiệm.

Bạn có thể cung cấp một tập lệnh shell đơn giản thực hiện chính xác điều này - gắn NAS với một tên nhất định và sao chép dữ liệu vào ổ đĩa cục bộ của bạn khi nó chưa có hoặc khi tập dữ liệu tại NAS mới hơn tập dữ liệu cục bộ. Đảm bảo tập lệnh sẽ tự động chạy trong giai đoạn khởi tạo các bài kiểm tra đơn vị của bạn.

Tất nhiên, khi không chỉ có một trong các tập dữ liệu đó, mà cả một loạt các phụ thuộc vào các tệp bên ngoài bên ngoài kho lưu trữ mã nguồn của bạn, thì một công cụ như các tệp được đề cập bởi @ptyx có thể là giải pháp tốt hơn.

... Khi ai đó lần đầu tiên nhân bản một kho lưu trữ, các bài kiểm tra đơn vị không thành công nên họ phải tìm ra cách gắn kết mọi thứ với một tên nhất định và cú pháp được sử dụng để xây dựng tệp đường dẫn thử nghiệm.

Đầu tiên, chỉ cần có một thuật ngữ nhất quán: Loại thử nghiệm này (phụ thuộc bên ngoài lớn, dữ liệu thực) thường không được coi là thử nghiệm đơn vị, mà là thử nghiệm tích hợp hoặc hệ thống .

Trên một lưu ý thực tế: Tôi thấy đó là một cách thực hành tốt để tách riêng các bài kiểm tra đơn vị và tích hợp , bởi vì chúng có những điểm mạnh và điểm yếu khác nhau.

• tách hai loại thử nghiệm trong mã (quy ước đặt tên, dự án riêng, ...)
• cung cấp một cách để chỉ chạy một trong hai bộ thử nghiệm
• chỉ chạy các bài kiểm tra đơn vị trong các bản dựng thông thường
• chạy thử nghiệm tích hợp theo yêu cầu và trên máy chủ CI (tích hợp liên tục)

Bằng cách đó, các bản dựng cục bộ rất nhanh và đáng tin cậy (ít / không phụ thuộc bên ngoài) và các kiểm tra tích hợp được xử lý bởi máy chủ CI mạnh mẽ. Điều này tránh được vấn đề bạn mô tả.

Làm thế nào để giữ dữ liệu:

Một lựa chọn tốt là một số loại quản lý giả tạo như câu trả lời của ptyx 'mô tả. Một cách khác là đưa dữ liệu thử nghiệm vào một kho lưu trữ riêng . Dữ liệu không được phát hành cùng với bản dựng chính và có một repo riêng để tránh buộc mọi người phải lấy dữ liệu thử nghiệm cùng với mã nguồn. Nói cách khác, sử dụng repo thứ hai làm quản lý artifacdt của bạn :-).