Test::...c::HTTP(3pm)

🌸 Test::...c::HTTP — the Test::Async::HTTP manual, but make it cute

ok bestie so this is Test::...c::HTTP(3pm) from the User Contributed Perl Documentation section — yes the page name got eaten by the ellipsis, we love a mysterious queen 💅. Anyway. Sit down, hydrate, and let's talk about faking HTTP requests in your unit tests.

---

✨ NAME ✨

Test::Async::HTTP — unit test code that uses Net::Async::HTTP. that's it, that's the name, she's simple and she's serving 🎀

---

🦋 DESCRIPTION 🦋

So like. This module is a mock version of Net::Async::HTTP, and it's built for unit tests. It virtualises the actual HTTP request/response cycle — meaning your test script gets to be the main character 👑 and inspect the requests that got made, and hand back whatever responses it wants. No real network. No real servers. Just vibes, and total control. no cap.

---

💖 METHODS 💖

$f = $http->do_request( %args )

This one implements the actual Net::Async::HTTP request API. It's the whole point, honestly.

The following arguments get handled specially, so pay attention bestie:

• timeout — the value of a timeout argument gets captured as an extra header on the request object, and that header is called X-NaHTTP-Timeout. cute, right?
• stall_timeout
• expect_continue
• SSL

those last three? entirely ignored. not read, not stored, not thought about. they simply do not exist to her 🙈

$response = $http->GET( $uri, %args )->get

$response = $http->HEAD( $uri, %args )->get

$response = $http->PUT( $uri, $content, %args )->get

$response = $http->POST( $uri, $content, %args )->get

These are the convenient lil wrappers for using the GET, HEAD, PUT or POST methods with a URI object and, like, few if any other arguments. They hand you back a Future. obsessed. ✨

ok but real talk: remember that POST with non-form data — which is what you get when you pass a plain scalar instead of an ARRAY reference of form data name/value pairs — needs a content_type key in %args. don't skip that, she will not guess for you 💀

$p = $http->next_pending

Returns the next pending request wrapper object — but only if one is actually outstanding, which happens because of an earlier call to do_request. If nothing's pending, you get undef. that's the whole deal 🫶

---

🧚 PENDING REQUEST OBJECTS 🧚

The objects that next_pending gives you respond to the following methods:

$request = $p->request

Returns the HTTP::Request object underlying this pending request. the raw material, the source text, the blueprint 💜

$p->respond( $resp )

Makes the request complete with the given HTTP::Response response. And that response gets handed straight to the Future that do_request had returned earlier. closure, but make it HTTP 🌈

$p->respond_header( $header )

$p->respond_more( $data )

$p->respond_done

This is the alternative to doing it all in one single respond call — it lets you do the equivalent of a chunked encoding response 🍓

So here's how the trio works: respond_header responds with the header and the initial content, then you hit respond_more multiple times to feed in more body content, and finally a respond_done call finishes the request off. drip-feeding the response, one chunk at a time. iconic behaviour honestly 💅

---

⭐ AUTHOR ⭐

Paul Evans <leonerd@leonerd.org.uk>

---

and that's the page, bestie!! 🎀 written against perl v5.34.0, dated 2022-06-30, straight from the User Contributed Perl Documentation corner of the world. go forth and mock your HTTP, you absolute legend 💖✨