Tôi đang viết một plugin tạo yêu cầu cho API đồ thị của Facebook. Vì tôi không muốn các bài kiểm tra đơn vị của mình thực sự thực hiện các yêu cầu này, làm thế nào để tôi vượt qua điều này? Phương pháp của tôi gọi cả hai wp_remote_getvà wp_remote_post. Tìm kiếm ở đó dường như là một cách để giả lập các chức năng bằng cách sử dụng runkit, ở đây

Tôi muốn tránh việc có những người đóng góp yêu cầu quá nhiều phụ thuộc nên muốn tránh phương pháp trên. Có lựa chọn nào khác không? Lớp học của tôi mở rộng WP_UnitTestCasevì vậy tôi hy vọng có thể có thứ gì đó từ bài kiểm tra đơn vị wp mà tôi có thể sử dụng?

Nếu bạn xem WP_HTTP->request()(bao gồm tất cả các chức năng liên quan), nó sẽ cung cấp một bộ lọc cho mục đích ghi đè yêu cầu có lợi cho việc trả lại dữ liệu tùy ý dưới dạng phản hồi:

// Allow plugins to short-circuit the request
$pre = apply_filters( 'pre_http_request', false, $r, $url );
if ( false !== $pre )
    return $pre;

Lấy kết quả bạn nhận được từ một yêu cầu hợp lệ hoặc không hợp lệ, tuần tự hóa chúng thành các chuỗi, sau đó thêm mã không xác định lại chuỗi vào biến thay vì thực hiện yêu cầu.

Để cô lập mã của bạn hơn nữa, tôi sẽ gói các wp_remote_getcuộc gọi vv trong một giao diện với hai triển khai. Một cuộc gọi thực hiện và cuộc gọi wp_remote_getkhác trả về dữ liệu thử nghiệm.

Sử dụng một công cụ như runkit trong tình huống này giúp khắc phục vấn đề thực tế mà bạn gặp phải, đó là mã của bạn và các API được liên kết quá chặt chẽ, và mức độ đóng gói và trừu tượng sẽ có lợi.

Tôi đã phải chế giễu các chức năng yêu cầu HTTP của WordPress trong một số trường hợp và vì vậy tôi đã quyết định xây dựng một công cụ để thực hiện điều đó: WP HTTP TestCase

Về cơ bản nó cung cấp một cách dễ dàng để làm những điều khác nhau mà các câu trả lời khác đã vạch ra. Từ bài đọc:

WP HTTP Testcase

Testcase PHPUnit để kiểm tra mã sử dụng WP_Http lớp của WordPress .

Nếu bạn sử dụng wp_remote_request()hoặc các trình bao bọc khác cho WP_Http các phương thức trong mã của mình, điều này gây khó khăn cho việc kiểm tra, đặc biệt là nếu máy chủ từ xa có thể không truy cập được từ môi trường thử nghiệm của bạn. Testcase này giải quyết điều này bằng cách cho phép bạn định tuyến các yêu cầu của mình đến một địa chỉ máy chủ khác, sử dụng một bộ phản hồi được lưu trong bộ nhớ cache hoặc chỉ chế giễu các phản hồi từ xa bằng cách cung cấp các phản hồi nhân tạo.

Cài đặt

Bạn có thể cài đặt gói này bằng trình soạn thảo:

composer require --dev jdgrimes/wp-http-testcase:~1.1

Sử dụng

Để sử dụng nó trong mã của bạn, trước tiên bạn cần bao gồm wp-http-testcase.phptệp trong tệp bootstrap PHPUnit của bạn. Nếu bạn sẽ sử dụng các tính năng lưu trữ định tuyến và phản hồi của máy chủ lưu trữ, bạn sẽ cần gọi WP_HTTP_TestCase::init()trong tệp bootstrap của mình.

Sau đó, trong các thử nghiệm liên quan đến WP_Httpbạn, bạn cần gia hạn WP_HTTP_TestCasethay vì WP_UnitTestCasenhư bình thường.

Phản hồi nhạo báng

Sử dụng bộ đệm phản hồi

Cách tốt nhất để kiểm tra, khi có thể, đó là thiết lập một máy chủ giả để xử lý các yêu cầu. Trong một số trường hợp, bạn có thể muốn hoặc thực sự cần gửi các yêu cầu thông qua máy chủ thực và điều đó cũng có thể được thực hiện. Những việc bạn làm sẽ phụ thuộc vào bản chất của các yêu cầu và tác dụng phụ mà chúng tạo ra trên máy chủ người nhận.

Thiết lập máy chủ thử nghiệm

Ví dụ: nếu bạn đang kiểm tra một plugin tạo yêu cầu cho API được cung cấp bởi một plugin hoặc phần mềm khác, bạn có thể không muốn hoặc không cần kiểm tra điều này trên một trang web trực tiếp. Thay vào đó, bạn có thể thiết lập một trang web thử nghiệm hoặc sử dụng máy chủ cục bộ là một phần của môi trường phát triển của bạn. Ở đó bạn có thể cài đặt phần mềm xử lý các yêu cầu. Khi điều này được thực hiện, bạn có thể chạy thử nghiệm đối với trang web thử nghiệm như thế này:

WP_HTTP_TC_HOST=localhost phpunit

Chỉ cần thay thế localhostbằng tên máy chủ của máy chủ cục bộ. Lưu ý rằng các WP_HTTP_TC_*cờ có thể được định nghĩa là các hằng PHP hoặc là các biến môi trường bash như trên. Sau này sẽ được ưu tiên.

Kích hoạt bộ đệm

Tất nhiên điều này sẽ chậm hơn nhiều so với hầu hết các bài kiểm tra đơn vị khác, bởi vì các yêu cầu bị ràng buộc phải mất một chút thời gian. Đó là nơi bộ nhớ đệm xuất hiện. Khi bật bộ đệm, phản hồi cho từng yêu cầu được lưu trong bộ nhớ cache lần đầu tiên được chạy và phiên bản được lưu trong bộ nhớ cache sẽ được sử dụng trong tương lai. Điều này có nghĩa là các bài kiểm tra của bạn có thể vẫn nhanh như chớp.

Để bật bộ đệm, chỉ cần thêm phần này vào bootstrap của bạn:

define( 'WP_HTTP_TC_USE_CACHING', true );

Có lẽ bạn cũng muốn chỉ định thư mục để lưu bộ đệm vào, thông qua WP_HTTP_TC_CACHE_DIR. Bạn có thể sử dụng nhiều nhóm bộ đệm và chuyển đổi giữa chúng bằng cách sử dụng WP_HTTP_TC_CACHE_GROUP.

Sử dụng máy chủ trực tiếp

Tuy nhiên, có trường hợp thứ hai, trong đó bạn không thể thiết lập máy chủ thử nghiệm. Một ví dụ trong trường hợp này sẽ là trường hợp nếu plugin của bạn thực hiện các yêu cầu đối với API do GitHub cung cấp. Tùy thuộc vào tình huống, có thể thực sự khả thi khi thực hiện các yêu cầu cho người nhận "trực tiếp". Vấn đề chính một lần nữa là các yêu cầu sẽ khiến các bài kiểm tra mất nhiều thời gian để hoàn thành. Cũng có khả năng API không phải lúc nào cũng có thể truy cập được từ môi trường thử nghiệm của bạn hoặc các thử nghiệm của bạn cuối cùng sẽ đập API quá mạnh và bạn sẽ bị chặn. Đây là nơi bộ nhớ đệm có thể giúp bạn. Bạn chỉ cần chạy thử nghiệm với API "trực tiếp" một lần và phần còn lại bạn có thể kiểm tra bằng các phản hồi được lưu trong bộ nhớ cache.

Cung cấp phản hồi nhân tạo

Tất nhiên, có thể đôi khi không thể tạo máy chủ thử nghiệm và cũng không khả thi để chạy với máy chủ trực tiếp. Trong trường hợp này, bạn có thể muốn mã hóa các câu trả lời nhân tạo cứng vào các bài kiểm tra của mình. Đây là cách bạn có thể làm điều đó:

Trước khi gọi mã sẽ gọi yêu cầu HTTP, bạn cần đặt hàm để giả lập các phản hồi như sau:

$this->http_responder = array( $this, 'mock_server_response' );

Hàm trả lời HTTP sẽ được chuyển qua hai đối số, đối số yêu cầu và URL mà yêu cầu được dành cho.

protected function mock_server_response( $request, $url ) {
   return array( 'body' => 'Test response.' ); 
}

Để biết danh sách đầy đủ các $requestđối số và phản hồi, xem WP_Http::request()

Trong một (hai) từ (s): Mock Data. PHPUnit đã getMock()có sẵn chính xác cho điều đó. Vì các câu trả lời khác đã được triệu tập hoàn hảo

• nơi nhận dữ liệu giả hợp lệ (Otto) - đảm bảo bạn thỉnh thoảng lấy dữ liệu mới
• và nơi để chặn dữ liệu (Rarst)
• và sử dụng công cụ nào (TomJNowell)

Chỉ có (có thể) vấn đề còn lại là xác minh chứng chỉ SSL cục bộ của bạn có thể không thành công. WP có một bộ lọc cho điều đó:

add_filter( 'https_local_ssl_verify', '__return_false' );

Để biết thêm bất kỳ thông tin về API WP HTTP, bạn có thể muốn thâm nhập vào câu trả lời này , câu trả lời này , câu trả lời này bởi @Wyck và câu trả lời này bởi @toscho .