Xuất thân từ nền tảng phân tích & khoa học dữ liệu, tôi từng coi việc viết bài kiểm tra là một điều gì đó đau đớn. Tôi biết rằng nó quan trọng, nhưng tôi không bao giờ biết bắt đầu từ đâu và luôn trì hoãn cho đến khi kết thúc dự án. Còn gì nhàm chán hơn là thử nghiệm một đoạn mã đã hoạt động?

Gần đây, tôi bắt đầu nhìn mọi thứ theo cách khác. Tôi đã phát hiện ra Phát triển dựa trên thử nghiệm: viết các bài kiểm tra của bạn trước khi bạn thực sự viết mã cho phần chức năng của mã. Đó là một phương pháp hay nhất trong công nghệ phần mềm xứng đáng được áp dụng thường xuyên hơn cho các dự án khoa học dữ liệu.

Phát triển dựa trên thử nghiệm (TDD) là gì?

Một cách đơn giản để đặt nó là thông qua khung Red / Green / Refactor . Mỗi khi bạn muốn thêm chức năng vào mã, bạn có thể thực hiện theo chu trình gồm ba bước:

1. đỏ . Tạo một bài kiểm tra không thành công. tức là viết nhu cầu chức năng của mã của bạn
2. màu xanh lá cây . Viết mã sản xuất để vượt qua bài kiểm tra. tức là đáp ứng nhu cầu chức năng của mã
3. Cấu trúc lại. Dọn dẹp mớ hỗn độn bạn vừa tạo ra. tức là làm sạch mã của bạn mà không thay đổi chức năng

Hãy minh họa điều này bằng một ví dụ thực tế. Là một bước hậu xử lý cho dự án Nhận dạng thực thể được đặt tên , chúng tôi muốn xây dựng một hàm xử lý để trích xuất đơn vị thời lượng (ngày/tuần/tháng/..) và giá trị thời lượng trong văn bản.

1. Hãy viết một bài kiểm tra đơn vị đáp ứng nhu cầu chức năng và một chức năng trống.

2. Chúng tôi viết mã vượt qua bài kiểm tra.

Bài kiểm tra có màu XANH Hoan hô!! Đợi đã .. chúng tôi có chắc nó KHÔ, RẮN, pep8 không ??

3. Chúng tôi cấu trúc lại chức năng, để đảm bảo thực hành viết mã tốt nhất.

Ở đây, chúng tôi đã thêm các chú thích loại, tạo một hàm chung để chuyển đổi số chữ cái thành số float (có cả bài kiểm tra đơn vị của riêng nó) và tái cấu trúc cách chúng tôi điền vào từ điển.

Chúng ta có thể áp dụng Phát triển dựa trên thử nghiệm trong Khoa học dữ liệu ở đâu?

Phát triển theo hướng thử nghiệm không phù hợp ở mọi bước của dự án khoa học dữ liệu. Chẳng hạn, nó không đáng trong quá trình khám phá dữ liệu hoặc mô hình mà bạn không chắc chắn về những gì mình đang tìm kiếm: viết bài kiểm tra mà không biết đầu ra dự kiến ​​có thể là quá mức cần thiết.

Nó trở nên rất hữu ích bất cứ khi nào bạn cần xây dựng các quy trình sản xuất mạnh mẽ .

Trong bối cảnh này, chúng ta cần thực hiện một số loại thử nghiệm:

• Kiểm tra đơn vị: kiểm tra từng đoạn mã của dự án
• Kiểm tra mô hình : đảm bảo rằng mô hình có hiệu suất tốt và hoạt động chính xác
• Kiểm tra tích hợp : đảm bảo rằng có một liên kết tốt giữa từng đoạn mã

Đối với các bài kiểm tra mô hình , nó nên được sử dụng cẩn thận. Khi xử lý các mô hình dự đoán, chúng ta đang xử lý sự không chắc chắn . Thật vậy, nhiều thuật toán học máy vốn dĩ là ngẫu nhiên — nhiều lần chạy sử dụng cùng một đầu vào có thể tạo ra kết quả hơi khác nhau mỗi lần. Điều này có thể dẫn đến các bài kiểm tra không ổn định : một bài kiểm tra đôi khi vượt qua và đôi khi không thành công mặc dù không có thay đổi nào đối với mã hoặc bản thân bài kiểm tra. Nếu chúng ta quá cụ thể về các trường hợp thử nghiệm trong quá trình phát triển dựa trên thử nghiệm đầu tiên, thì rất có khả năng một số thử nghiệm sẽ bị lỗi trong lần lặp lại tiếp theo. Một mô hình mới có thể hoạt động khác đi trong một số trường hợp, trong khi hoạt động tốt hơn trên toàn cầu. Do đó, tốt hơn là chỉ đưa vào các thử nghiệm mô hình các trường hợp cơ bản cần thiết cho dự án.

Cuối cùng đối với các thử nghiệm tích hợp , nó áp dụng tốt cho các đoạn mã không bao gồm dự đoán mô hình. Nếu nó bao gồm dự đoán mô hình, thì tốt hơn là kiểm tra định dạng của đầu ra so với đầu ra thực tế.

Một cách thực hành tốt là đưa các bài kiểm tra đó vào CI/CD của dự án của bạn. Do đó, bất cứ khi nào một đề xuất chức năng mới được đưa ra, đảm bảo rằng không có chức năng nào khác bị hỏng.

Tại sao nó lại thay đổi cuộc chơi?

Việc áp dụng Phát triển dựa trên thử nghiệm thực sự thay đổi cách bạn tổ chức các phiên viết mã của mình và có rất nhiều lợi ích từ nó:

• Nó ngay lập tức xác nhận các thông số kỹ thuật và kinh doanh . Nó cũng là một tài liệu tuyệt vời cho một nhà khoa học dữ liệu khám phá dự án và cần hiểu cách thức hoạt động của dự án.
• Nó mang lại sự tự tin trong mã . Mọi trường hợp sử dụng đều được kiểm tra và bạn hoặc đồng đội của mình có thể thêm các chức năng bổ sung mà không sợ vi phạm bất kỳ điều gì đã được thực hiện.
• Đó là tiết kiệm thời gian . Người ta có thể coi đó là thứ đang làm chậm sự phát triển. Nhưng không phải vậy, nó buộc bạn phải suy nghĩ trước về các nhu cầu chức năng và dự đoán các trường hợp khó khăn. Hãy tin tôi, vào cuối ngày, nó tiết kiệm rất nhiều thời gian gỡ lỗi và lặp lại.
• Nó thậm chí còn làm cho sự phát triển trở nên thú vị hơn ! Nó chia mã thành các thử thách giải quyết vấn đề nhỏ . Và nó hoàn toàn phù hợp với mã hóa ngang hàng..