Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.3.0

Request #19276 Mock: per-URL responses
Submitted: 2012-02-05 00:38 UTC
From: cweiske Assigned: avb
Status: Closed Package: HTTP_Request2 (version SVN)
PHP Version: Irrelevant OS:
Roadmaps: 2.1.0    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 13 - 2 = ?

 
 [2012-02-05 00:38 UTC] cweiske (Christian Weiske)
Description: ------------ When unit-testing classes/applications that use HTTP_Request2, one has to know the internals about what URLs are fetched when so that the correct mock responses can be set in the correct order. Sometimes I know which URLs need to be fetched, but not in which order, which makes it impossible to set the correct mock responses. I'd like to be able to set per-url responses, so that the mock adapter returns the correct response depending on the URL. Maybe also matches on headers (e.g. for content-type switching).

Comments

 [2012-03-21 17:22 UTC] avb (Alexey Borzov)
-Status: Open +Status: Analyzed -Assigned To: +Assigned To: avb -Roadmap Versions: +Roadmap Versions: 2.1.0
Well, we can easily add a second parameter to addResponse(): public function addResponse($response, $url = '') where $url may be either a full URL or a pattern (?). When choosing which response to send, we use the first one with an URL match or without URL set (this keeps BC). Sounds good enough? Matching on other stuff (methods / headers / body) starts to look suspiciously like what the web server is doing. I don't think that reinventing web server in Mock_Adapter is a worthwhile goal.
 [2012-04-07 16:14 UTC] avb (Alexey Borzov)
-Status: Analyzed +Status: Closed
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.