Merge branch '4.4' into 5.1

* 4.4:
  Change branch "master" to "5.x"
  Change "-t" to "--track" to be more explicit
  Fix typo
  [Testing] Updated the contents about getting the container in tests

Author: wouterj

contributing/code/pull_requests.rst

@@ -129,7 +129,7 @@ work:
   </contributing/code/maintenance>` (you may have to choose a higher branch if
   the feature you are fixing was introduced in a later version);
 
-* ``master``, if you are adding a new feature.
+* ``5.x``, if you are adding a new feature.
 
   The only exception is when a new :doc:`major Symfony version </contributing/community/releases>`
   (4.0, 5.0, etc.) comes out every two years. Because of the
@@ -142,7 +142,7 @@ work:
     All bug fixes merged into maintenance branches are also merged into more
     recent branches on a regular basis. For instance, if you submit a PR
     for the ``3.4`` branch, the PR will also be applied by the core team on
-    the ``master`` branch.
+    the ``5.x`` branch.
 
 Create a Topic Branch
 ~~~~~~~~~~~~~~~~~~~~~
@@ -152,14 +152,14 @@ topic branch:
 
 .. code-block:: terminal
 
-    $ git checkout -b BRANCH_NAME master
+    $ git checkout -b BRANCH_NAME 5.x
 
 Or, if you want to provide a bug fix for the ``3.4`` branch, first track the remote
 ``3.4`` branch locally:
 
 .. code-block:: terminal
 
-    $ git checkout -t origin/3.4
+    $ git checkout --track origin/3.4
 
 Then create a new branch off the ``3.4`` branch to work on the bug fix:
 
@@ -277,15 +277,15 @@ while to finish your changes):
 
 .. code-block:: terminal
 
-    $ git checkout master
+    $ git checkout 5.x
     $ git fetch upstream
-    $ git merge upstream/master
+    $ git merge upstream/5.x
     $ git checkout BRANCH_NAME
-    $ git rebase master
+    $ git rebase 5.x
 
 .. tip::
 
-    Replace ``master`` with the branch you selected previously (e.g. ``3.4``)
+    Replace ``5.x`` with the branch you selected previously (e.g. ``3.4``)
     if you are working on a bug fix.
 
 When doing the ``rebase`` command, you might have to fix merge conflicts.
@@ -402,12 +402,12 @@ Rework your Pull Request
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Based on the feedback on the pull request, you might need to rework your
-PR. Before re-submitting the PR, rebase with ``upstream/master`` or
+PR. Before re-submitting the PR, rebase with ``upstream/5.x`` or
 ``upstream/3.4``, don't merge; and force the push to the origin:
 
 .. code-block:: terminal
 
-    $ git rebase -f upstream/master
+    $ git rebase -f upstream/5.x
     $ git push --force origin BRANCH_NAME
 
 .. note::

testing.rst

@@ -534,74 +534,51 @@ You can also get the objects related to the latest request::
 Accessing the Container
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-It's highly recommended that a functional test only tests the response. But
-under certain very rare circumstances, you might want to access some services
-to write assertions. Given that services are private by default, test classes
-define a property that stores a special container created by Symfony which
-allows fetching both public and all non-removed private services::
-
-    // gives access to the same services used in your test, unless you're using
-    // $client->insulate() or using real HTTP requests to test your application
-    // don't forget to call self::bootKernel() before, otherwise, the container
-    // will be empty
-    $container = self::$container;
-
-For a list of services available in your application, use the ``debug:container``
-command.
-
-If a private service is *never* used in your application (outside of your test),
-it is *removed* from the container and cannot be accessed as described above. In
-that case, you can create a public alias in the ``test`` environment and access
-it via that alias:
+Functional tests should only test the response (e.g. its contents or its HTTP
+status code). However, in some rare circumstances you may need to access the
+container to use some service.
 
-.. configuration-block::
-
-    .. code-block:: yaml
-
-        # config/services_test.yaml
-        services:
-            # access the service in your test via
-            # self::$container->get('test.App\Test\SomeTestHelper')
-            test.App\Test\SomeTestHelper:
-                # the id of the private service
-                alias: 'App\Test\SomeTestHelper'
-                public: true
+First, you can get the same container used in the application, which only
+includes the public services::
 
-    .. code-block:: xml
-
-        <!-- config/services_test.xml -->
-        <?xml version="1.0" encoding="UTF-8" ?>
-        <container xmlns="http://symfony.com/schema/dic/services"
-            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-            xsi:schemaLocation="http://symfony.com/schema/dic/services
-                https://symfony.com/schema/dic/services/services-1.0.xsd">
+    public function testSomething()
+    {
+        $client = self::createClient();
+        $container = $client->getContainer();
+        // $someService = $container->get('the-service-ID');
 
-            <services>
-                <!-- ... -->
+        // ...
+    }
 
-                <service id="test.App\Test\SomeTestHelper" alias="App\Test\SomeTestHelper" public="true"/>
-            </services>
-        </container>
+Symfony tests also have access to a special container that includes both the
+public services and the non-removed :ref:`private services <container-public>`
+services::
 
-    .. code-block:: php
+    public function testSomething()
+    {
+        // this call is needed; otherwise the container will be empty
+        self::bootKernel();
 
-        // config/services_test.php
-        namespace Symfony\Component\DependencyInjection\Loader\Configurator;
+        $container = self::$container;
+        // $someService = $container->get('the-service-ID');
 
-        use App\Service\MessageGenerator;
-        use App\Service\SiteUpdateManager;
+        // ...
+    }
 
-        return function(ContainerConfigurator $configurator) {
-            // ...
+Finally, for the most rare edge-cases, Symfony includes a special container
+which provides access to all services, public and private. This special
+container is a service that can be get via the normal container::
 
-            $services->alias('test.App\Test\SomeTestHelper', 'App\Test\SomeTestHelper')->public();
-        };
+    public function testSomething()
+    {
+        $client = self::createClient();
+        $normalContainer = $client->getContainer();
+        $specialContainer = $normalContainer->get('test.service_container');
 
-.. tip::
+        // $somePrivateService = $specialContainer->get('the-service-ID');
 
-    The special container that gives access to private services exists only in
-    the ``test`` environment and is itself a service that you can get from the
-    real container using the ``test.service_container`` id.
+        // ...
+    }
 
 .. tip::
 
@@ -909,7 +886,7 @@ their type::
     $form['photo']->upload('/path/to/lucas.jpg');
 
     // In the case of a multiple file upload
-    $form['my_form[field][O]']->upload('/path/to/lucas.jpg');
+    $form['my_form[field][0]']->upload('/path/to/lucas.jpg');
     $form['my_form[field][1]']->upload('/path/to/lisa.jpg');
 
 .. tip::