Missing Namespace and comment from service container and testing context

service_container/3.3-di-changes.rst

@@ -264,6 +264,8 @@ But in Symfony 3.3, thanks to autowiring, all you need to do is type-hint the
 argument with ``InvoiceGenerator``::
 
     // src/Service/InvoiceMailer.php
+    namespace App\Service;
+
     // ...
 
     class InvoiceMailer
@@ -388,6 +390,9 @@ and autowiring like any other service.
 To make life even easier, it's now possible to autowire arguments to your controller
 action methods, like you can with the constructor of services. For example::
 
+    // src/Controller/InvoiceController.php
+    namespace App\Controller;
+
     use Psr\Log\LoggerInterface;
 
     class InvoiceController extends AbstractController
@@ -417,6 +422,8 @@ this file. For example, suppose you want to create an event subscriber. First, y
 create the class::
 
     // src/EventSubscriber/SetHeaderSusbcriber.php
+    namespace App\EventSubscriber;
+
     // ...
 
     use Symfony\Component\EventDispatcher\EventSubscriberInterface;

service_container/autowiring.rst

@@ -24,6 +24,7 @@ the alphabet.
 
 Start by creating a ROT13 transformer class::
 
+    // src/Util/Rot13Transformer.php
     namespace App\Util;
 
     class Rot13Transformer
@@ -36,6 +37,7 @@ Start by creating a ROT13 transformer class::
 
 And now a Twitter client using this transformer::
 
+    // src/Service/TwitterClient.php
     namespace App\Service;
 
     use App\Util\Rot13Transformer;
@@ -122,6 +124,7 @@ both services:
 
 Now, you can use the ``TwitterClient`` service immediately in a controller::
 
+    // src/Controller/DefaultController.php
     namespace App\Controller;
 
     use App\Service\TwitterClient;
@@ -153,6 +156,9 @@ Autowiring Logic Explained
 
 Autowiring works by reading the ``Rot13Transformer`` *type-hint* in ``TwitterClient``::
 
+    // src/Service/TwitterClient.php
+    namespace App\Service;
+
     // ...
     use App\Util\Rot13Transformer;
 
@@ -277,6 +283,7 @@ of concrete classes as it replaces your dependencies with other objects.
 
 To follow this best practice, suppose you decide to create a ``TransformerInterface``::
 
+    // src/Util/TransformerInterface.php
     namespace App\Util;
 
     interface TransformerInterface
@@ -376,6 +383,7 @@ Dealing with Multiple Implementations of the Same Type
 Suppose you create a second class - ``UppercaseTransformer`` that implements
 ``TransformerInterface``::
 
+    // src/Util/UppercaseTransformer.php
     namespace App\Util;
 
     class UppercaseTransformer implements TransformerInterface
@@ -404,6 +412,7 @@ create a *named autowiring alias* from a special string containing the
 interface followed by a variable name matching the one you use when doing
 the injection::
 
+    // src/Service/MastodonClient.php
     namespace App\Service;
 
     use App\Util\TransformerInterface;
@@ -546,6 +555,7 @@ When autowiring is enabled for a service, you can *also* configure the container
 to call methods on your class when it's instantiated. For example, suppose you want
 to inject the ``logger`` service, and decide to use setter-injection::
 
+    // src/Util/Rot13Transformer.php
     namespace App\Util;
 
     class Rot13Transformer

service_container/calls.rst

@@ -13,6 +13,7 @@ Usually, you'll want to inject your dependencies via the constructor. But someti
 especially if a dependency is optional, you may want to use "setter injection". For
 example::
 
+    // src/Service/MessageGenerator.php
     namespace App\Service;
 
     use Psr\Log\LoggerInterface;
@@ -84,6 +85,7 @@ To provide immutable services, some classes implement immutable setters.
 Such setters return a new instance of the configured class
 instead of mutating the object they were called on::
 
+    // src/Service/MessageGenerator.php
     namespace App\Service;
 
     use Psr\Log\LoggerInterface;

service_container/factories.rst

@@ -19,6 +19,11 @@ Static Factories
 Suppose you have a factory that configures and returns a new ``NewsletterManager``
 object by calling the static ``createNewsletterManager()`` method::
 
+    // src/Email\NewsletterManagerStaticFactory.php
+    namespace App\Email;
+
+    // ...
+
     class NewsletterManagerStaticFactory
     {
         public static function createNewsletterManager()
@@ -169,6 +174,10 @@ Invokable Factories
 Suppose you now change your factory method to ``__invoke()`` so that your
 factory service can be used as a callback::
 
+    // src/Email/InvokableNewsletterManagerFactory.php
+    namespace App\Email;
+
+    // ...
     class InvokableNewsletterManagerFactory
     {
         public function __invoke()

service_container/injection_types.rst

@@ -19,6 +19,7 @@ The most common way to inject dependencies is via a class's constructor.
 To do this you need to add an argument to the constructor signature to accept
 the dependency::
 
+    // src/Mail/NewsletterManager.php
     namespace App\Mail;
 
     // ...
@@ -115,6 +116,9 @@ Immutable-setter Injection
 Another possible injection is to use a method which returns a separate instance
 by cloning the original service, this approach allows you to make a service immutable::
 
+    // src/Mail/NewsletterManager.php
+    namespace App\Mail;
+
     // ...
     use Symfony\Component\Mailer\MailerInterface;
 
@@ -218,6 +222,9 @@ Setter Injection
 Another possible injection point into a class is by adding a setter method
 that accepts the dependency::
 
+    // src/Mail/NewsletterManager.php
+    namespace App\Mail;
+
     // ...
     class NewsletterManager
     {

service_container/request.rst

@@ -11,6 +11,7 @@ add it as an argument to the methods that need the request or inject the
 :method:`Symfony\\Component\\HttpFoundation\\RequestStack::getCurrentRequest`
 method::
 
+    // src/Newsletter/NewsletterManager.php
     namespace App\Newsletter;
 
     use Symfony\Component\HttpFoundation\RequestStack;

service_container/service_decoration.rst

@@ -378,6 +378,7 @@ Three different behaviors are available:
     When using ``null``, you may have to update the decorator constructor in
     order to make decorated dependency nullable::
 
+        // src/Service/DecoratorService.php
         namespace App\Service;
 
         use Acme\OptionalBundle\Service\OptionalService;

testing/profiling.rst

@@ -69,6 +69,9 @@ The data collected by the Symfony Profiler can be used to check the number of
 database calls, the time spent in the framework, etc. All this information is
 provided by the collectors obtained through the ``$client->getProfile()`` call::
 
+    // tests/Controller/LuckyControllerTest.php
+    namespace App\Tests\Controller;
+
     use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
 
     class LuckyControllerTest extends WebTestCase