TDD để xử lý hàng loạt: Làm thế nào để làm điều đó?

Tôi thích "đỏ / xanh / tái cấu trúc" cho RoR, v.v.

Công việc hàng ngày của tôi liên quan đến việc xử lý hàng loạt các tệp rất lớn từ bên thứ ba trong python và các công cụ tùy chỉnh khác.

Việc thay đổi thuộc tính của các tệp này là cao, do đó, có rất nhiều bản sửa lỗi / cải tiến được áp dụng khá thường xuyên.

Kiểm tra hồi quy thông qua một cơ thể dữ liệu kiểm tra đã biết với kết quả dự kiến ​​không tồn tại. Điều gần nhất là chạy với đợt cuối cùng với các trường hợp thử nghiệm mới được mã hóa bằng tay, đảm bảo nó không nổ tung, sau đó áp dụng kiểm tra tại chỗ và kiểm tra thống kê để xem liệu dữ liệu có còn ổn không.

Q >> Làm thế nào để đưa các nguyên tắc TDD vào loại môi trường này?

Chỉ là một FYI: Kiểm tra đơn vị không tương đương với TDD. TDD là một quá trình trong đó kiểm thử đơn vị là một yếu tố.

Như đã nói, nếu bạn đang muốn thực hiện thử nghiệm đơn vị thì có một số điều bạn có thể làm:

Tất cả các mã / cải tiến mới được thử nghiệm

Bằng cách này, bạn không phải trải qua và kiểm tra đơn vị mọi thứ đã tồn tại, do đó, khối lượng ban đầu của việc thực hiện kiểm thử đơn vị nhỏ hơn nhiều.

Kiểm tra từng mẩu dữ liệu

Kiểm tra một cái gì đó có thể chứa một lượng lớn dữ liệu có thể dẫn đến nhiều trường hợp cạnh và khoảng trống trong phạm vi kiểm tra. Thay vào đó, hãy xem xét tùy chọn 0, 1, nhiều. Kiểm tra một 'lô' với 0 phần tử, 1 phần tử và nhiều phần tử. Trong trường hợp 1 phần tử, hãy kiểm tra các hoán vị khác nhau mà dữ liệu cho phần tử đó có thể nằm trong.

Từ đó, kiểm tra các trường hợp cạnh (giới hạn trên với kích thước của các phần tử riêng lẻ và số lượng phần tử trong lô). Nếu bạn chạy thử nghiệm thường xuyên và bạn có các thử nghiệm chạy dài (lô lớn?), Hầu hết những người chạy thử nghiệm đều cho phép phân loại để bạn có thể chạy các trường hợp thử nghiệm đó một cách riêng biệt (hàng đêm?).

Điều đó sẽ cung cấp cho bạn một cơ sở mạnh mẽ.

Sử dụng dữ liệu thực tế

Cung cấp dữ liệu 'thực tế' được sử dụng trước đây như bạn đang làm bây giờ không phải là ý tưởng tồi. Chỉ cần bổ sung nó với dữ liệu thử nghiệm được hình thành tốt để bạn biết ngay các điểm thất bại cụ thể. Khi không thể xử lý dữ liệu thực tế, bạn có thể kiểm tra kết quả của quy trình lô, tạo ra một bài kiểm tra đơn vị để sao chép lỗi và sau đó bạn quay lại màu đỏ / xanh / tái cấu trúc với các trường hợp hồi quy hữu ích.

Nó giống như bất kỳ môi trường khác.

Tách logic thành mức độ chi tiết nhỏ nhất của nó. Điều này sẽ cung cấp cho bạn một bộ quy tắc cho quy trình, mỗi quy tắc sẽ bao gồm một mục logic cần thiết cho quy trình của bạn.

Sau đó viết một bài kiểm tra cho mỗi quy tắc. Những bài kiểm tra sẽ thất bại. Viết mã để sửa bài kiểm tra.

Kiểm tra hồi quy với dữ liệu kiểm tra đã biết mà bạn đang nói đến không phải là kiểm tra đơn vị. Đó sẽ là thử nghiệm tích hợp, điều này khác với TDD. Với TDD, bạn có thể có một thử nghiệm duy nhất để kiểm tra rằng bạn có thể tải một tệp, nhưng nhìn chung không có thử nghiệm nào khác thực sự đi gần một tệp dữ liệu có dữ liệu thử nghiệm. Thay vào đó, bạn sẽ mô phỏng dữ liệu cần thiết để thực hiện quy tắc cụ thể bằng cách sử dụng một đối tượng chế giễu.

Bắt đầu với một chiến lược phần mềm tốt, sau đó áp dụng TDD.

(Tuyên bố miễn trừ trách nhiệm: Tôi có thể đã hiểu nhầm "churn" hoặc TDD hoặc cả hai.)

Đây là chiến lược được đề xuất của tôi để xử lý hàng loạt "dữ liệu bẩn": Chỉ định-Triage-Execute.

• Dự thảo một đặc điểm kỹ thuật của dữ liệu theo một cách nghiêm ngặt và hẹp, nhưng sẽ bao gồm phần lớn (giả sử, 80% trở lên) của dữ liệu đến. Gọi thông số kỹ thuật này 1 .
• Phát triển mô-đun Triage (TDD nếu bạn muốn) quyết định xem bản ghi có đáp ứng Đặc điểm kỹ thuật 1 không.
  • Hãy chắc chắn rằng mô-đun chạy rất nhanh.
  • Mô-đun sẽ trả về true / false: nó đáp ứng tất cả các quy tắc hoặc không.
• Phát triển mô-đun Thực thi (TDD nếu bạn muốn) phân tích bản ghi được biết là đáp ứng Đặc điểm kỹ thuật 1, thực hiện bất kỳ nhiệm vụ nào cần thiết cho khách hàng của bạn.
• Áp dụng Triage 1 trên tất cả dữ liệu đến.
  • Kết quả là một giá trị boolean cho mỗi bản ghi. Điều này về cơ bản phân tách dữ liệu đến thành: Thông số 1 hoặc Không xác định.
  • Áp dụng Thực thi 1 trên dữ liệu Thông số 1, bất cứ khi nào khách hàng cần.
• Thư giãn các quy tắc của Đặc tả 1 để thừa nhận 80% dữ liệu còn lại. Gọi thông số kỹ thuật này 2 .
• Phát triển Triage 2 và Thực thi 2 . Áp dụng nó cho bất kỳ dữ liệu nào không đáp ứng Đặc điểm kỹ thuật 1.
• Lặp lại càng nhiều cấp độ càng tốt, cho đến khi dữ liệu còn lại đủ nhỏ để có thể xử lý thủ công mỗi ngày.

Các mẩu tin hiệu quả:

Lưu tất cả các kết quả Triage (lịch sử hoặc hiện tại) được liên kết với một bản ghi. Nếu không có mô-đun Triage nào được sửa đổi kể từ lần chạy trước, thì nó không phải chạy lại trên dữ liệu cũ.

Câu chuyện "bạn phải biết những gì bạn muốn xây dựng trước khi thực hiện TDD":

Chỉ định-Triage-Execute là một cách để giữ cho các yêu cầu có thể quản lý được ở mỗi cấp độ và cho phép phát triển trong tương lai.

(Nếu có ai biết các thuật ngữ chính xác tiêu chuẩn cho ba bước đó, vui lòng cho tôi biết, tôi sẽ chỉnh sửa câu trả lời của mình.)