Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.1 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

Why calling this function jd()? I assume it stands for "JSON dump", however, looking at the code, there's no mention about JSON.

I think you may instead set a new VarDumper handler in your tests context. This will allow you to use the CliDumper rather than HtmlDumper. You will have less noise in your output. You can have an example here: https://symfony.com/doc/current/components/var_dumper.html#advanced-usage. You may do this in a Behat step executed before each scenario or feature.

Alternatively, you can set the VAR_DUMPER_FORMAT env var to cli in your test env to achieve this.

Indeed, I called jd() for JSON. It might be wiser to rename it vd() or vdd() for var_dump() and die();

Yes, I could add some setup to my Behat tests for this, but I found that other people had the same needs as me in the issue 49754. So I believe it could be useful to have such a function for "off-road" debugging :).

VAR_DUMPER_FORMAT=cli just writes to php://stdout, this is not useful when debugging api calls :)

There should be a "PlainTextDumper", and i would advocate that that would be the default,
unless there is a Accept: text/html header present, then HtmlDumper should be called.

unless there is a Accept: text/html header present, then HtmlDumper should be called.

I think this is the correct way to think about it, maybe allow */* to stay friendly to some random requests from a browser which can in the end display the HTML (Preview in Chrome dev tools), but if you're explicitly requesting machine readable stuff, it's safe to assume it shouldn't dump the markup, IMO.

unless there is a Accept: text/html header present, then HtmlDumper should be called.

I think that'd make sense. Anyone up to give it a try?
Closing here meanwhile, thanks for proposing.