Có nên có các bài kiểm tra đơn vị cho các biểu thức chính quy phức tạp?

Tôi có nên viết bài kiểm tra đơn vị cho các biểu thức chính quy phức tạp trong ứng dụng của mình không?

• Một mặt: chúng rất dễ kiểm tra vì định dạng đầu vào và đầu ra thường đơn giản và được xác định rõ ràng và chúng thường có thể trở nên phức tạp nên các thử nghiệm về chúng đặc biệt có giá trị.
• Mặt khác: bản thân chúng hiếm khi là một phần của giao diện của một số đơn vị. Có thể tốt hơn nếu chỉ kiểm tra giao diện và thực hiện điều đó theo cách ngầm kiểm tra các biểu thức chính quy.

CHỈNH SỬA:

Tôi đồng ý với Doc Brown, người trong nhận xét của ông lưu ý rằng đây là trường hợp đặc biệt về kiểm tra đơn vị các thành phần bên trong .

Nhưng như regex thành phần nội bộ có một vài đặc điểm đặc biệt:

1. Một regex dòng đơn có thể thực sự phức tạp mà không thực sự là một mô-đun riêng biệt.
2. Regexes ánh xạ đầu vào thành đầu ra mà không có bất kỳ tác dụng phụ nào và do đó thực sự dễ dàng để kiểm tra riêng.

Kiểm tra giáo điều sang một bên, câu hỏi thực sự là liệu nó có cung cấp giá trị cho đơn vị kiểm tra các biểu thức chính quy phức tạp hay không. Có vẻ như khá rõ ràng rằng nó cung cấp giá trị (bất kể regex có phải là một phần của giao diện công cộng hay không) nếu regex đủ phức tạp, vì nó cho phép bạn tìm và tái tạo lỗi và ngăn chặn hồi quy.

Regex có thể là một công cụ mạnh mẽ, nhưng nó không phải là một công cụ mà bạn có thể tin tưởng để vẫn hoạt động nếu bạn thực hiện ngay cả những thay đổi nhỏ đối với các biểu thức phức tạp.

Vì vậy, tạo ra nhiều bài kiểm tra tài liệu các trường hợp mà nó nên bao gồm. Và tạo ra nhiều bài kiểm tra mà tài liệu trường hợp nó sẽ thất bại, nếu nó được sử dụng để xác nhận.

Bất cứ khi nào bạn cần thay đổi regex của mình, bạn thêm các trường hợp mới dưới dạng thử nghiệm, sửa đổi regex của bạn và hy vọng điều tốt nhất.

Nếu tôi ở trong một tổ chức nói chung không sử dụng các bài kiểm tra đơn vị, tôi vẫn sẽ viết một chương trình kiểm tra để kiểm tra bất kỳ regex nào chúng tôi sẽ sử dụng. Tôi thậm chí sẽ tự làm điều đó nếu tôi phải làm vậy, tóc tôi không cần phải mất thêm màu nào nữa.

Biểu thức chính quy là mã cùng với phần còn lại của ứng dụng của bạn. Bạn nên kiểm tra xem mã nói chung có làm những gì bạn mong đợi không. Điều này có một số mục đích:

• Kiểm tra là tài liệu runnable. Nó thể hiện rõ ràng những gì bạn cần mã để làm. Nếu nó được thử nghiệm thì nó rất quan trọng.
• Những người duy trì trong tương lai có thể chắc chắn rằng nếu họ sửa đổi nó, các thử nghiệm sẽ đảm bảo rằng hành vi không thay đổi.

Vì có một trở ngại thêm để khắc phục bằng cách có mã bằng một ngôn ngữ khác được nhúng với phần còn lại, rất có thể bạn nên chú ý thêm cho lợi ích của việc bảo trì.

Tóm lại, bạn nên kiểm tra ứng dụng của bạn, thời gian. Cho dù bạn kiểm tra regex của mình bằng các kiểm tra tự động chạy nó một cách cô lập, như là một phần của hộp đen lớn hơn hoặc nếu bạn chỉ xoay quanh nó bằng tay là thứ yếu để đảm bảo rằng nó hoạt động.

Ưu điểm chính của kiểm tra đơn vị là chúng tiết kiệm thời gian. Họ cho phép bạn kiểm tra mọi thứ nhiều lần như bạn muốn bây giờ hoặc tại bất kỳ thời điểm nào trong tương lai. Nếu có bất kỳ lý do nào để tin rằng regex của bạn tại bất kỳ thời điểm nào sẽ được tái cấu trúc, điều chỉnh, có nhiều ràng buộc hơn, vâng, bạn có thể muốn một số bài kiểm tra hồi quy cho nó hoặc khi bạn thay đổi nó, bạn sẽ phải đi thông qua một giờ suy nghĩ thông qua tất cả các trường hợp cạnh để bạn không phá vỡ nó. Điều đó, hoặc bạn học cách sống với việc sợ mã của mình và đơn giản là không bao giờ thay đổi nó.

Mặt khác: bản thân chúng hiếm khi là một phần của giao diện của một số đơn vị. Có thể tốt hơn nếu chỉ kiểm tra giao diện và thực hiện điều đó theo cách ngầm kiểm tra các biểu thức chính quy.

Tôi nghĩ với điều này bạn đã tự trả lời nó. Các quy tắc trong một đơn vị rất có thể là một chi tiết thực hiện.

Những gì diễn ra để kiểm tra SQL của bạn có lẽ cũng dành cho regexes. Khi bạn thay đổi một đoạn SQL, bạn có thể chạy nó thông qua một số máy khách SQL bằng tay để xem liệu nó có mang lại những gì bạn mong đợi không. Điều tương tự cũng xảy ra khi tôi thay đổi regex Tôi sử dụng một số công cụ regex với một số đầu vào mẫu để xem nó có làm những gì tôi mong đợi không.

Những gì tôi thấy hữu ích là một nhận xét gần regex với một mẫu văn bản mà nó phải phù hợp.

Nếu bạn phải hỏi, câu trả lời là có.

Giả sử một số FNG xuất hiện và nghĩ rằng anh ta có thể "cải thiện" regex của bạn. Bây giờ, anh ta là một FNG, nên tự động là một thằng ngốc. Chính xác là loại người không nên chạm vào mã quý giá của bạn trong mọi trường hợp! Nhưng có lẽ anh ấy liên quan đến PHB hoặc một cái gì đó, vì vậy bạn không thể làm gì.

Ngoại trừ bạn biết PHB sẽ kéo bạn đá và hét trở lại dự án này để "có thể cung cấp cho anh chàng một số gợi ý về cách bạn thực hiện mớ hỗn độn này" khi mọi thứ trở nên tồi tệ. Vì vậy, bạn viết ra tất cả các trường hợp mà bạn đã xem xét cẩn thận khi xây dựng kiệt tác tuyệt đẹp của bạn.

Và vì bạn đã viết tất cả chúng xuống, bạn đã có hai phần ba để có một bộ các trường hợp thử nghiệm, vì - hãy đối mặt với nó - các trường hợp thử nghiệm regex rất dễ chạy khi bạn đã xây dựng khung.

Vì vậy, bây giờ, bạn có một tập hợp các điều kiện cạnh, các lựa chọn thay thế và kết quả mong đợi. Và đột nhiên các trường hợp thử nghiệm là tài liệu đúng như đã hứa trong tất cả các bài đăng trên blog của tôi. Bạn chỉ cần nói với FNG rằng nếu "cải tiến" của anh ấy không vượt qua các trường hợp thử nghiệm hiện tại, thì đó không phải là một sự cải tiến, phải không? Và ở đâu đề nghị trường hợp thử nghiệm mới của mình rằng chứng minh một số vấn đề với mã gốc, mà vì nó hoạt động, ông không cần phải được sửa đổi, bao giờ hết !!!