Passed
Push — master ( bc287d...4da5ca )
by Jean-Bernard
01:31
created

TemplatingControllerTest   A

Complexity

Total Complexity 4

Size/Duplication

Total Lines 56
Duplicated Lines 0 %

Coupling/Cohesion

Components 0
Dependencies 6

Importance

Changes 0
Metric Value
wmc 4
lcom 0
cbo 6
dl 0
loc 56
c 0
b 0
f 0
rs 10

4 Methods

Rating   Name   Duplication   Size   Complexity  
A testCanBeCreated() 0 11 1
A testHomeCanBeCreated() 0 11 1
A testEmptyReturnsResponse() 0 11 1
A testArrayReturnsResponse() 0 17 1
1
<?php
2
3
/*
4
 * This file is part of the Symfony-Util package.
5
 *
6
 * (c) Jean-Bernard Addor
7
 *
8
 * For the full copyright and license information, please view the LICENSE
9
 * file that was distributed with this source code.
10
 */
11
12
use PHPUnit\Framework\TestCase;
13
use Symfony\Bridge\Twig\TwigEngine;
14
use Symfony\Component\HttpFoundation\Response;
15
use Symfony\Component\Templating\TemplateNameParser;
16
use SymfonyUtil\Controller\TemplatingController;
17
18
class HomeTemplatingController extends TemplatingController // To test more in details
0 ignored issues
show
Coding Style Compatibility introduced by
PSR1 recommends that each class must be in a namespace of at least one level to avoid collisions.

You can fix this by adding a namespace to your class:

namespace YourVendor;

class YourClass { }

When choosing a vendor namespace, try to pick something that is not too generic to avoid conflicts with other libraries.

Loading history...
19
{
20
    const TEMPLATE = 'home.html.twig';
21
}
22
23
/**
24
 * @covers \SymfonyUtil\Controller\TemplatingController
25
 */
26
final class TemplatingControllerTest extends TestCase
0 ignored issues
show
Coding Style Compatibility introduced by
PSR1 recommends that each class should be in its own file to aid autoloaders.

Having each class in a dedicated file usually plays nice with PSR autoloaders and is therefore a well established practice. If you use other autoloaders, you might not want to follow this rule.

Loading history...
Coding Style Compatibility introduced by
PSR1 recommends that each class must be in a namespace of at least one level to avoid collisions.

You can fix this by adding a namespace to your class:

namespace YourVendor;

class YourClass { }

When choosing a vendor namespace, try to pick something that is not too generic to avoid conflicts with other libraries.

Loading history...
27
{
28
    public function testCanBeCreated()
29
    {
30
        $this->assertInstanceOf(
31
            // ::class, // 5.4 < php
32
            'SymfonyUtil\Controller\TemplatingController',
33
            new TemplatingController(new TwigEngine(
34
                new Twig_Environment(new Twig_Loader_Array(['index.html.twig' => 'Hello World!'])),
0 ignored issues
show
Documentation introduced by
new \Twig_Environment(ne...g' => 'Hello World!'))) is of type object<Twig_Environment>, but the function expects a object<Twig\Environment>.

It seems like the type of the argument is not accepted by the function/method which you are calling.

In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.

We suggest to add an explicit type cast like in the following example:

function acceptsInteger($int) { }

$x = '123'; // string "123"

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
35
                new TemplateNameParser()
36
            ))
37
        );
38
    }
39
40
    public function testHomeCanBeCreated()
41
    {
42
        $this->assertInstanceOf(
43
            // ::class, // 5.4 < php
44
            'SymfonyUtil\Controller\TemplatingController',
45
            new HomeTemplatingController(new TwigEngine(
46
                new Twig_Environment(new Twig_Loader_Array(['home.html.twig' => 'Hello World!'])),
0 ignored issues
show
Documentation introduced by
new \Twig_Environment(ne...g' => 'Hello World!'))) is of type object<Twig_Environment>, but the function expects a object<Twig\Environment>.

It seems like the type of the argument is not accepted by the function/method which you are calling.

In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.

We suggest to add an explicit type cast like in the following example:

function acceptsInteger($int) { }

$x = '123'; // string "123"

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
47
                new TemplateNameParser()
48
            ))
49
        );
50
    }
51
52
    public function testEmptyReturnsResponse()
53
    {
54
        $this->assertInstanceOf(
55
            // Response::class, // 5.4 < php
56
            'Symfony\Component\HttpFoundation\Response',
57
            (new TemplatingController(new TwigEngine(
58
                new Twig_Environment(new Twig_Loader_Array(['index.html.twig' => 'Hello World!'])),
0 ignored issues
show
Documentation introduced by
new \Twig_Environment(ne...g' => 'Hello World!'))) is of type object<Twig_Environment>, but the function expects a object<Twig\Environment>.

It seems like the type of the argument is not accepted by the function/method which you are calling.

In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.

We suggest to add an explicit type cast like in the following example:

function acceptsInteger($int) { }

$x = '123'; // string "123"

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
59
                new TemplateNameParser()
60
            )))->__invoke()
61
        );
62
    }
63
64
    public function testArrayReturnsResponse()
65
    {
66
        $this->assertInstanceOf(
67
            // Response::class, // 5.4 < php
68
            'Symfony\Component\HttpFoundation\Response',
69
            (new TemplatingController(new TwigEngine(
70
                new Twig_Environment(new Twig_Loader_Array([
0 ignored issues
show
Documentation introduced by
new \Twig_Environment(ne...i>{% endfor %}</ul>'))) is of type object<Twig_Environment>, but the function expects a object<Twig\Environment>.

It seems like the type of the argument is not accepted by the function/method which you are calling.

In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.

We suggest to add an explicit type cast like in the following example:

function acceptsInteger($int) { }

$x = '123'; // string "123"

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
71
                    'index.html.twig' => '<ul>{% for item in 0 %}<li>{{ item }}</li>{% endfor %}</ul>',
72
                ])),
73
                new TemplateNameParser()
74
            )))->__invoke([
0 ignored issues
show
Unused Code introduced by
The call to TemplatingController::__invoke() has too many arguments starting with array('One', 'Two', 'Three').

This check compares calls to functions or methods with their respective definitions. If the call has more arguments than are defined, it raises an issue.

If a function is defined several times with a different number of parameters, the check may pick up the wrong definition and report false positives. One codebase where this has been known to happen is Wordpress.

In this case you can add the @ignore PhpDoc annotation to the duplicate definition and it will be ignored.

Loading history...
75
                'One',
76
                'Two',
77
                'Three',
78
            ])
79
        );
80
    }
81
}
82
83
// http://api.symfony.com/3.3/Symfony/Bridge/Twig/TwigEngine.html
84
// http://api.symfony.com/3.3/Symfony/Bundle/TwigBundle/TwigEngine.html
85