Suggestion: Show the generated Request object on --debug or -vvv

[ThomasLandauer]

Follow up of Codeception/Codeception#5977 (comment)

Since Symfony Module doesn't perform an actual HTTP request, but rather generates a Symfony Request object, it would be nice to be able to dump this object somehow, to see what's actually in there.

[TavoNiievez]

Hey @ThomasLandauer it would be quite useful!
Can you specify which attributes of the object you think would be useful for debugging? That object is relatively large and even has other nested objects, so if you can give a list of the ones that you think are most relevant, based on that comparison, I think it would help for the person who will implement this feature.

[ThomasLandauer]

This is the object we're talking about, right? https://github.com/symfony/browser-kit/blob/v5.1.5/Request.php

Looking at the properties there, I'd say:

• protected $uri; Just a string? => Show it!
• protected $method; Just a string too? => Show it
• protected $parameters; What is this? HTTP headers and stuff?
• protected $files; Uploaded files?
• protected $cookies; An array of strings? => Show it
• protected $server; This I don't understand. Is this $_SERVER? But how can the client decide what the server looks like?
• protected $content; HTTP body?

It's hard to say which one is unimportant ;-) How long would it be if you just dump it all? In general I'd say it's better to scroll through some lengthy output, rather than missing that one crucial information ;-)

[TavoNiievez]

@ThomasLandauer I was revisiting this issue to evaluate if it could be part of v2.0.

However, when reviewing the code, I noticed that this change should be implemented in innerbrowser and not in a module that extends from it, the reason is that we would have to do the same change in other modules like laravel. The symfony module should only worry about printing with --debug the things that are specific to the framework, such as the metrics that the Symfony Profiler provides.

For that reason, I am closing this issue in favor of Codeception/lib-innerbrowser#16, please edit the description there if you think that something of what was commented here is relevant for who decides to implement it.

[ThomasLandauer]

Thanks - and sorry for opening the same thing twice! ;-)