Là đơn vị thử nghiệm mã thủ tục có hiệu quả?

Trong một dự án hiện tại, các quyền hạn muốn có thử nghiệm đơn vị được tích hợp vào chu kỳ phát triển của chúng tôi để tránh số lượng lỗi liên tục dường như thấm vào mã của chúng tôi. Vấn đề là mã spaghetti là 95% theo thủ tục, điều mà tôi chưa bao giờ thực hiện kiểm thử đơn vị (tất cả kinh nghiệm của tôi với kiểm thử đơn vị là với mã OOP)

Vì vậy, câu hỏi của tôi một cách ngắn gọn là liệu có nên khôn ngoan khi tiến hành thử nghiệm đơn vị với cơ sở mã hiện tại của chúng tôi hay đề nghị rằng nó bị hoãn cho đến khi ứng dụng được chuyển sang khung OOP thích hợp?

PS: Mặc dù tôi đã cố gắng đặt phong cách cho câu hỏi này là bất khả tri ngôn ngữ, tôi cảm thấy rằng việc nêu rõ ứng dụng đang sử dụng PHP và javascript sẽ giúp cung cấp các câu trả lời cụ thể hơn có thể trả lời câu hỏi này vì kinh nghiệm này xảy ra nhiều nhất với các ứng dụng như vậy.

Kiểm thử đơn vị hoạt động tốt với các đối tượng, đặc biệt là vì nó cung cấp nhiều tính năng ưa thích, như các đối tượng giả, giúp tạo ra các thử nghiệm tốt hơn nhanh hơn.

Điều này đang được nói, không có gì cấm thực hiện thử nghiệm đơn vị trên một cơ sở mã thủ tục . Trong OOP, hầu hết các thử nghiệm đơn vị là các phương thức thử nghiệm bằng cách chuyển một số tham số cho chúng và mong đợi một kết quả hoặc ngoại lệ của một loại cụ thể. Điều này có thể được thực hiện cho đến nay với mã thủ tục; chỉ là thay vì phương pháp thử nghiệm, bạn sẽ kiểm tra các chức năng .

Lưu ý rằng bạn sẽ phải:

• Cô lập các chức năng bạn phải kiểm tra và những chức năng bạn không cần. Trong OOP, điều này thật dễ dàng: các phương thức riêng tư không phải thử nghiệm vì người gọi sẽ không bao giờ có thể truy cập trực tiếp vào chúng. Rất có thể, trong mã thủ tục của bạn, một số chức năng giống như thế này và không cần kiểm tra.

• Hãy suy nghĩ về phạm vi toàn cầu . Vấn đề cũng tồn tại trong OOP, nhưng nếu bạn nói rằng bạn phải kiểm tra mã spaghetti, rất có thể những người viết mã này có thói quen xấu, chẳng hạn như sử dụng phạm vi toàn cầu quá nhiều và thực hiện một số điều điên rồ như thay đổi $_GEThoặc $_POSTmảng bên trong chức năng.

• Xử lý mã bên ngoài chức năng. Đây là một trường hợp phức tạp hơn, nhưng vẫn có thể. Hoặc require_oncelà một trang để xem điều gì xảy ra và nắm bắt đầu ra thông qua ob_start/ob_get_clean hoặc bạn thực hiện một yêu cầu HTTP từ bộ kiểm tra và phân tích phản hồi bằng cách phân tích cú pháp HTML. Đây không thực sự là một thử nghiệm UI: ở đây, bạn không quan tâm nếu một nút trên trang xuất hiện ở bên trái hoặc bên phải hoặc nếu một liên kết có chữ in hoa lớn màu đỏ hoặc màu xanh nhỏ. Điều bạn quan tâm là tìm một số phần tử HTML thông qua DOM và so sánh nội dung của chúng với phần tử mong đợi.

• Kiểm tra mã phản hồi . require_oncevới bộ đệm đầu ra là tốt, nhưng bạn cũng phải kiểm tra cách ứng dụng web xử lý lỗi. Ví dụ: nếu kết quả dự kiến ​​của một bài kiểm tra là 404 Không tìm thấy, bạn phải thực hiện một yêu cầu HTTP để biết phản hồi là gì.

đề nghị hoãn lại cho đến khi ứng dụng được chuyển sang khung OOP thích hợp

Nhận một số thử nghiệm tự động tại chỗ trước khi di chuyển sang nền tảng khác, không phải sau đó. Thêm các thử nghiệm khác trong khi thực hiện di chuyển, không phải sau đó. Nếu các bài kiểm tra đó là "bài kiểm tra tích hợp" hoặc bài kiểm tra đơn vị bạn phải tự quyết định, nhưng thông thường bạn có thể sử dụng khung kiểm tra xUnit yêu thích của mình cho cả hai loại.

Cách hiệu quả nhất để bắt đầu kiểm tra đơn vị là xác định loại lỗi xảy ra thường xuyên nhất hoặc có chi phí cao nhất. Sau đó tạo các bài kiểm tra nhắm vào các lỗi đó.

Làm thế nào những bài kiểm tra được thực hiện sẽ khác nhau giữa các mô hình và ngôn ngữ. Điều lớn nhất sẽ ảnh hưởng đến khả năng thực hiện kiểm thử đơn vị của bạn là chất lượng của mã; ít hơn nên mô hình sử dụng. Hãy nhớ kiểm thử đơn vị là về kiểm tra một "đơn vị" mã cách ly. Bất cứ điều gì ảnh hưởng đến khả năng cô lập "đơn vị" mã của bạn sẽ khiến việc kiểm tra khó khăn hơn.

• sử dụng toàn cầu
• phản ứng phụ
• mã kết hợp chặt chẽ
• mã ghép kém
• một số lượng lớn các điều kiện
• "đơn vị" thiết kế xấu

Tất cả những điều này sẽ có tác động cao hơn đến khó kiểm tra hơn mô hình ngôn ngữ.

Bất cứ khi nào bạn gặp tình huống có thể tự động kiểm tra các phần của mã của mình, kiểm tra đơn vị có thể có hiệu quả. Vì vậy, câu hỏi không phải là mã thủ tục có thể được kiểm tra đơn vị một cách hiệu quả, câu hỏi là mã NÀY có thể được kiểm tra đơn vị không. Điều đó sẽ phụ thuộc vào mức độ nó đọc và trạng thái nó đặt. Lý tưởng nhất là câu trả lời cho cả hai đều bằng không, nhưng nếu không, bạn vẫn có thể kiểm tra nó.

Như mọi khi bạn cần cân nhắc sự tự tin rằng mã là chính xác so với chi phí để có được sự tự tin đó. Hãy nhớ rằng một phần lợi ích cho kiểm tra đơn vị là xác định rõ ràng các phụ thuộc và theo nghĩa đó, nó thậm chí còn hiệu quả hơn đối với mã thủ tục kiểm tra đơn vị so với mã OOP.

Tôi không nghĩ có thể thực hiện các bài kiểm tra đơn vị thực sự đối với mã thủ tục. Vấn đề chính là mỗi thủ tục có thể sẽ có nhiều phụ thuộc không thể bỏ qua. Tốt nhất các bài kiểm tra sẽ là kiểm tra tích hợp. Tôi đã thực hiện một điều tương tự nhiều mặt trăng trước đây với các mô-đun VB6 và mô-đun VBA trong MS Access.

Điều đó nói rằng, nếu bạn có thể đặt giàn giáo thử nghiệm xung quanh các phương pháp gây đau đớn nhất, thì đó phải là giá trị, phải không?