Điểm:1

Làm cách nào để giả định \Drupal::httpClient()?

lá cờ jp

Tôi đang thử nghiệm một thư viện tiện ích (do chúng tôi tự tạo) thực hiện các lệnh gọi tới API REST bên ngoài với \Drupal::httpClient()

Vì vậy, tôi có một lớp thư viện với các hàm tĩnh:

lớp myUtils {
  hàm tĩnh công khai getFromApi($path)
  {
    ...
    $response = \Drupal::httpClient()->request( ... );
    ...
  }

...

}

và tôi muốn gọi nó từ một lớp kiểm tra:

lớp myUtilsTest mở rộng \Codeception\Test\Unit
{
  // Rất nhiều thứ khác ...
  hàm công khai testGetFromApi()
  {
     // Thực hiện một số phép thuật chế giễu
     ...
     myUtils::getFromApi('/some/test/path');
     ...
  }
}

tôi nhận ra tôi có thể làm một \GuzzleHttp\Handler\MockHandler và thiết lập nó để trả lại bất cứ thứ gì tôi muốn, nhưng làm cách nào để đặt nó thành "ghi đè" lệnh gọi tới \Drupal->httpClient()?

Tôi đã thấy một số ví dụ dường như cho rằng bạn có một thể hiện của một lớp có httpClient thành viên và điều này dễ dàng bị chế giễu - nhưng trong trường hợp sử dụng của tôi, không có lý do gì để thiết kế các tiện ích như vậy. Vì vậy, làm thế nào để tôi chế nhạo toàn cầu \Drupal::httpClient() trong trường hợp này?

Cảm ơn trước cho bất kỳ phản ứng.

Kevin avatar
lá cờ in
Dễ dàng hơn khi chỉ bao gồm một mô-đun chỉ thử nghiệm có dịch vụ phần mềm trung gian để cung cấp phản hồi cho bất kỳ API bên trong hoặc bên ngoài nào. Nếu không, bạn phải mô phỏng lớp được đưa vào dịch vụ mà bạn đang thử nghiệm và mô phỏng từng phương thức được sử dụng trong quá trình triển khai của bạn.
lá cờ in
Đây chính xác là tình huống tại sao bạn cần tiêm phụ thuộc, để các API mà bạn phụ thuộc được liên kết lỏng lẻo với mã của bạn và có thể bị giả lập cũng như tráo đổi trong quá trình thử nghiệm. Khi bạn bắt đầu phụ thuộc vào những thứ như API HTTP, API cơ sở dữ liệu, API thực thể và bạn bè, thay vào đó, bạn có thể cân nhắc đặt các công cụ của mình thành một lớp dịch vụ. Tôi sẽ dành các chức năng tĩnh cho logic độc lập (ví dụ: Html.php, Xss.php, UrlHelper.php của lõi, v.v. là những ví dụ hay).
lá cờ jp
OK, cảm ơn, sẽ xem xét nó! Tuy nhiên, việc phải thay đổi một kiến ​​trúc & triển khai hoàn toàn hợp lệ chỉ dành cho mục đích thử nghiệm đã khiến tôi hiểu sai một chút. Nhưng vâng, nó có thể là một cách.
Kevin avatar
lá cờ in
Việc sử dụng vùng chứa tĩnh trong các lớp học không được khuyến khích vì nhiều lý do, đây là một trong số đó. May mắn thay, nó không quá khó để làm DI.
jbarrio avatar
lá cờ cn
Tôi đồng ý với Patrick và cố gắng đóng góp vào điều này theo cách tích cực. Tôi muốn nói rằng bạn vừa tìm thấy điều gì đó cần cải thiện trong quá trình triển khai hiện tại của mình. Và có thể lý do bạn gặp phải vấn đề này là do bạn đã không thực hiện giải pháp của mình theo cách tiếp cận T(B)DD ngay từ đầu. Lần sau điều này sẽ không xảy ra với bạn nữa :_)
lá cờ jp
Tôi cho rằng bạn không sao cả! Trải nghiệm thử nghiệm của riêng tôi chủ yếu là từ Python, nơi có thể mô phỏng một cách linh hoạt hơn, do đó thiết kế mã thực tế không phải xem xét thử nghiệm (vì bạn luôn có thể thử nghiệm). Tất nhiên, đây là Drupal và PHP chứ không phải Python và Django, nơi có trải nghiệm chính của tôi. :-)
Điểm:3
lá cờ ph

Chuyển đổi lớp học của bạn để sử dụng phép nội xạ phụ thuộc sẽ giống như thế này:

sử dụng Drupal\Core\Plugin\ContainerFactoryPluginInterface;
sử dụng Symfony\Thành phần\DependencyInjection\ContainerInterface;
sử dụng GuzzleHttp\Client

lớp myUtils triển khai ContainerFactoryPluginInterface {

  /**
   * Dịch vụ http.
   *
   * @var \GuzzleHttp\Client
   */
  $httpClient được bảo vệ;

  hàm công khai cuối cùng __construct(mảng $configuration, $plugin_id, $plugin_definition, Client $httpClient) {
    $this->httpClient = $httpClient;
    cha mẹ::__construct($configuration, $plugin_id, $plugin_definition);
  }

  tạo hàm tĩnh công khai (ContainerInterface $container, mảng $configuration, $plugin_id, $plugin_definition) {
    trả về tĩnh mới (
      cấu hình $,
      $plugin_id,
      $plugin_definition,
      $container->get('http_client')
    );
  }

  hàm công khai getFromApi($path)
  {
    ...
    $response = $this->httpClient->request( ... );
    ...
  }

...

}

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.