I don't know why tests are failing, on AppVeyor the error is not related to my changes and on Travis CI I don't know what isdeps=low.

Failures are unrelated :)

Actually travis fails because#18275 has not been reverted in 3.0 and master yet.

It has been reverted in 3.0

and in master as well now.

I have force-pushed the commit to launch CI tests again.

@alexislefebvre thanks for sending this proposal. I'm not against it ... but adding a new method always "complicates" things (people must learn a new method, Symfony developers need to maintain that method forever, etc.)

I'd like to ask some Symfony Form experts, like@HeahDude, if they think this is absolutely necessary or if the problem to solve (which I don't understand) can be solved in a simpler way. Thanks!

@javiereguiluz Please don't say I'm an expert :) "involved" seems more appropriate.

For me it's a 👍 (I've already add one it a few days ago on the description).

@HeahDude could you please explain the problem to solve to people like me, not involved in the Form component?@alexislefebvre said:"I want to submit additional values in my tests but Symfony doesn't allow me to do that". Why does he want to submit additional values? Why doesn't Symfony allow to do that? Why should be "force" Symfony yo allow something it doesn't allow? Thanks.

@javiereguiluz because a form view in a template (like used in a tested page with a crawler) might contain no fields.

Think of aCollectionType with an empty collection. Then it would require to add some fields with javascript to populate the form and submit.

Currently theDomCrawler/BrowserKit components do not allow to submit extra fields (which are not present in the view because they cannot be generated dynamically).

This PR fixes it by allowing to submit extra fields.

@HeahDude thanks for the explanation. I think the "right" solution would be to allow the crawler to add nodes dynamically and then submit the form ... but my guess is that they want to maintain the DomCrawler as "read-only", so we can't add anything. Therefore, the proposed solution seems the way to go. Thanks!

Maybe this one could have aBrowserKit label instead ofForm.

Thanks@HeahDude for your explanation to@javiereguiluz. :)

Upon further reflection, one drawback of thissubmitWithAdditionalValues() method is that ithides what is happening, it can be used to add data, but not to remove data (e.g. remove an existing field from a collection) which is almost as important as adding data.

If you're not OK to add a new method for a not so common case, I suggest another approach:

1. reduce this PR: implement theconvertFieldsToArray() method I added inSymfony/Component/DomCrawler/Form.php and remove the other changes from this PR. It would be useful because it allows to use a syntax close to the other tests (foo[bar] instead of a PHP array)
2. document how to add or remove data during tests: examples in this PRhttps://github.com/symfony/symfony-docs/pull/6403/files or onStack Overflow

ping@jakzal :)

Can someone please give some feedback about mylast comment? Thanks.

Looks good :)

Since the method is inForm wouldn't it make sense to call this methodsubmitWithAdditionnalFields ?

orsubmitWithExtraFields ?

Tests are failing because you need to update theDomCrawler dependency of theBrowerKit component to~3.1

After further reflection, I don't like thissubmitWithAdditionalValues() method, I will remove it in order to have a simpler PR. Do you think it's better to close this PR and open a new one (while referencing this PR) instead of altering this PR?

I'll work on the documentation instead, these changes are not necessary to test a collection of fields.

Thanks to@HeahDude and the others for your help and sorry for the inconvenience!

I opened aPR for the documentation, I hope that it will be more useful to document how to test a form collection for all the Symfony versions instead of adding a method that will be usable only with the last version of Symfony.