Issue 1:
I think it's a bug related with the feature #19612

I have a route group for an admin section, and I want to prefix the URL and name of each route inside the App\Controller\Admin namespace.

If I go only for the route prefix it works without any problem

# config/routes.yaml
admin:
prefix: /admin
resource: ../src/Controller/Admin
type: annotation

The router debug gives me the following output:

-------------------------- ---------- -------- ------ -----------------------------------
Name Method Scheme Host Path
-------------------------- ---------- -------- ------ -----------------------------------
_twig_error_test ANY ANY ANY /_error/{code}.{_format}
_wdt ANY ANY ANY /_wdt/{token}
_profiler_home ANY ANY ANY /_profiler/
_profiler_search ANY ANY ANY /_profiler/search
_profiler_search_bar ANY ANY ANY /_profiler/search_bar
_profiler_phpinfo ANY ANY ANY /_profiler/phpinfo
_profiler_search_results ANY ANY ANY /_profiler/{token}/search/results
_profiler_open_file ANY ANY ANY /_profiler/open
_profiler ANY ANY ANY /_profiler/{token}
_profiler_router ANY ANY ANY /_profiler/{token}/router
_profiler_exception ANY ANY ANY /_profiler/{token}/exception
_profiler_exception_css ANY ANY ANY /_profiler/{token}/exception.css
index ANY ANY ANY /admin/
login ANY ANY ANY /admin/login
user_index GET ANY ANY /admin/user
user_new GET|POST ANY ANY /admin/user/new
user_show GET ANY ANY /admin/user/{id}
user_edit GET|POST ANY ANY /admin/user/{id}/edit
user_delete DELETE ANY ANY /admin/user/{id}
admin_logout ANY ANY ANY /admin/logout
-------------------------- ---------- -------- ------ -----------------------------------

The problem comes when I add the name_prefix route:

# config/routes.yaml
admin:
name_prefix: admin_
prefix: /admin
resource: ../src/Controller/Admin
type: annotation

The router debug gives the following output, and I can verify that the URLs are duplicated:

-------------------------- ---------- -------- ------ -----------------------------------
Name Method Scheme Host Path
-------------------------- ---------- -------- ------ -----------------------------------
index ANY ANY ANY /
login ANY ANY ANY /login
user_index GET ANY ANY /user
user_new GET|POST ANY ANY /user/new
user_show GET ANY ANY /user/{id}
user_edit GET|POST ANY ANY /user/{id}/edit
user_delete DELETE ANY ANY /user/{id}
_twig_error_test ANY ANY ANY /_error/{code}.{_format}
_wdt ANY ANY ANY /_wdt/{token}
_profiler_home ANY ANY ANY /_profiler/
_profiler_search ANY ANY ANY /_profiler/search
_profiler_search_bar ANY ANY ANY /_profiler/search_bar
_profiler_phpinfo ANY ANY ANY /_profiler/phpinfo
_profiler_search_results ANY ANY ANY /_profiler/{token}/search/results
_profiler_open_file ANY ANY ANY /_profiler/open
_profiler ANY ANY ANY /_profiler/{token}
_profiler_router ANY ANY ANY /_profiler/{token}/router
_profiler_exception ANY ANY ANY /_profiler/{token}/exception
_profiler_exception_css ANY ANY ANY /_profiler/{token}/exception.css
admin_index ANY ANY ANY /admin/
admin_login ANY ANY ANY /admin/login
admin_user_index GET ANY ANY /admin/user
admin_user_new GET|POST ANY ANY /admin/user/new
admin_user_show GET ANY ANY /admin/user/{id}
admin_user_edit GET|POST ANY ANY /admin/user/{id}/edit
admin_user_delete DELETE ANY ANY /admin/user/{id}
admin_logout ANY ANY ANY /admin/logout
-------------------------- ---------- -------- ------ -----------------------------------

Originally posted by @devnix in #19612 (comment)

Issue 2:
This issue is about discussion my DX initiative for optimization and generalization of symfony 2 functional testing mechanisms. I use this approach for about 2 years and i can provide corresponding PR if it receives positive feedback.

Problem

For now all the bundles that contain functional tests need to describe test application kernel class to boot and run test application. These surrogate kernel classes look very similar to each other. You can find them not only inside base symfony's bundles: FrameworkBundle, SecurityBundle, TwigBundle, but inside other bundles: FOSRestBundle, FOSOAuthServerBundle. I can give you other examples if you want. Moreover developers often additionally have to deal with autoloading (See for example here).

In my opinion such duplicating should be avoided. Instead it would be nice to have ability to describe what kind of test kernel we need in order to receive required kernel object from framework.

Another drawback can be appeared if KERNEL_DIR env variable is used to point directory that contains 2 or more files suffixed with "Kernel" word. Imagine that my AppKernel extends some IntermediateKernel (which extends base Symfony\Component\HttpKernel\Kernel\Kernel) located in the same folder. Due to WebTestCase uses Finder to locate kernel file by '*Kernel.php' glob in such cases we actually can not know in advance what kernel exactly would be choosen (it can depend on OS and filesystem type).

Proposal

Since every single bundle depends on framework-bundle we can place inside functionality to generate test kernels using user specified options.

I propose to implement base implementation for test kernel class that implements all things that surrogate test kernels like listed above usually do (simplified):

/**
* Kernel for functional / integration tests
*/
class BaseTestKernel extends Kernel implements TestKernelInterface
{
protected $testCase;
protected $rootConfig;
protected $configDir;
protected $rootDir;

/**
* Sets test kernel configuration
*/
public function setTestKernelConfiguration($testCase, $configDir, $rootConfig, $rootDir)
{
// initializing test configs
}

/**
* Registers bundles for the test kernel
*/
public function registerBundles()
{
$bundles = array();
$baseBundles = $this->getBaseBundles();
if (file_exists($filename = $this->configDir . '/' . $this->testCase . '/bundles.php')) {
$bundles = include $filename;
}
return array_merge($baseBundles, $bundles);
}

/**
* {@inheritdoc}
*/
public function getCacheDir()
{
return $this->getTempAppDir().'/cache/'.$this->environment;
}

/**
* {@inheritdoc}
*/
public function getLogDir()
{
return $this->getTempAppDir().'/logs';
}

/**
* {@inheritdoc}
*/
public function getTempAppDir()
{
return sys_get_temp_dir().'/'.$this->testCase;
}

/**
* {@inheritdoc}
*/
public function registerContainerConfiguration(LoaderInterface $loader)
{
$loader->load($this->rootConfig);
}

/**
* {@inheritDoc}
*/
public function serialize()
{
// serializing test kernel
}

/**
* {@inheritdoc}
*/
public function unserialize($str)
{
// unserializing test kernel
}

/**
* Returns base bundle list
*
* @return array
*/
protected function getBaseBundles()
{
return array(new \Symfony\Bundle\FrameworkBundle\FrameworkBundle());
}

/**
* {@inheritDoc}
*/
protected function getKernelParameters()
{
$parameters = parent::getKernelParameters();
$parameters['kernel.test_case'] = $this->testCase;

return $parameters;
}
}

This kernel class should be instantiated inside KernelTestCase::createKernel method upon the options ($testCase, $configDir, $rootConfig, $rootDir, $env, $debug) passed to the createClient method.

Framework bundle also can provide some default test application configuration that can be extended in the custom bundles and specified using $rootConfig option.

So this approach can significantly reduce duplication of the code that generates test kernels across the bundles and simultaneously provide the flexibility in configuring test kernel. We also can have more then one simply configured instances of test kernel inside bundle test suite to run tests in different configurations (different bundle config, different routing etc).

Also i think we should provide ability to extend TestCase class to replace used base test kernel class with another one (apparently implementing base TestKernelInterface).

Moreover it can be reasonable to allow setting environment variable (or php constant using phpunit.xml) KERNEL_CLASS that can hold FQCN of any kernel class (not only test kernel that implements TestKernelInterface) that can be used by KernelTestCase as a replacement of base test kernel class (BaseTestKernel in default case) to construct real kernel with main params - $environment and $debug. In this case we can simply run bundle's functional test cases in any application environment by replacing our pre-configured test kernels with real application kernel transforming our functional tests to integration ones.