Pact-PHP <=9.x.x - Error Feedback Maybe Not as Usable as it Could Be - Pact/PHP newbie thoughts

[Grunet]

Tying in to my earlier issue around the READme, when I was trying to get code under test with Pact-PHP I found trying to figure out what was going wrong difficult when they did.

Here are some of the themes I ran into, in rough order of how difficult it felt like they made things

1. It was difficult to see what the requests being sent to the mock server by the code under test were. Often times I screwed up the matching configuration and had a hard time troubleshooting what I'd done wrong.

   • I eventually found out about the log file emitted by the mock server (I think I saw it mentioned on the Ruby Pact Mock Service's repo, and felt somewhat annoyed that I hadn't learned about them from the documentation here), but I realized that it wouldn't be captured in our CI setup and so ultimately made a wrapper to $builder->verify that would dump it the console
     • I think it would be nice to have some kind of option in Pact-PHP to see some/all of that information in the terminal, to help make troubleshooting easier

2. Crafting regex's for matching long, multi-line form-data request bodies was an extremely arduous process of trial-and-error for me (it didn't help that I'm not very proficient with regex). I probably spent more time on doing this for 1 test than almost everything else combined

   • It was hard in part because I wasn't able to copy-paste directly from the console output (if the comparison value check failed) or the log file (if the comparison against the real sent value failed) into an online regex checker tool (that would give more detailed guidance as to what was wrong) I think because of the slash escaping, so I ended up just trying things one at a time until they eventually clicked.
   • For this case specifically, it would've been amazing to have something like Jest's Inline Snapshots where the regex would be auto-generated from whatever the request was sending (even if it was just a starting point)

3. If a method under test threw an exception prior to the $builder->verify call listed right after it, I wasn't getting any information on what might've been going wrong with the request mocking that may've been contributing to it. As a workaround I wrapped the method's under test in a "try" block and put the $builder->verify call in a "finally block", but then the error message and long stack trace from $builder->verify was showing up above the same from an exception from the method under test even when it wasn't relevant (e.g. when an exception occurred before any requests were even sent out)

   • I probably just don't know the right pattern for this, but it would be nice if by default $builder->verify could always run, and then show it's exception messages after those of the method under test

4. When $builder->verify fails, the URL used in the requests is included in the error output in the terminal, but it's truncated really early (around ~24 characters before a (truncated...) message is shown) making it hard to figure out if there was a problem with it (e.g. regarding the matching setup)

   • This was very frustrating at first, but became somewhat less so once I realized the log file had the full information

(Let me know if it would be helpful to create reproductions for any of these or share example screenshots/error messages. I should be able to do the former I just haven't found the time so far since last time)

[YOU54F]

repros, further examples, improvements to the documentation are always welcome !