This project does not seem to handle request data directly as such no vulnerable execution paths were found.
include
, or for example
via PHP's auto-loading mechanism.
These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more
1 | <?php |
||
2 | |||
3 | namespace Khepin\Utils; |
||
4 | |||
5 | use Doctrine\ORM\EntityManager; |
||
6 | use \Mockery as m; |
||
7 | use Doctrine\ODM\MongoDB\Mapping\Driver\AnnotationDriver; |
||
8 | |||
9 | class BaseTestCaseMongo extends \PHPUnit_Framework_TestCase |
||
10 | { |
||
11 | protected $doctrine; |
||
12 | |||
13 | private function getMockAnnotatedConfig() |
||
14 | { |
||
15 | $mappingDriver = $this->getMetadataDriverImplementation(); |
||
16 | |||
17 | $config = m::mock('Doctrine\ODM\MongoDB\Configuration', array( |
||
18 | 'getProxyDir' => __DIR__.'/../temp', |
||
19 | 'getProxyNamespace' => 'Proxy', |
||
20 | 'getAutoGenerateProxyClasses' => true, |
||
21 | 'getClassMetadataFactoryName' => 'Doctrine\\ODM\\MongoDB\\Mapping\\ClassMetadataFactory', |
||
22 | 'getMetadataDriverImpl' => $mappingDriver, |
||
23 | 'getDefaultRepositoryClassName' => 'Doctrine\\ODM\\MongoDB\\DocumentRepository', |
||
24 | 'getMongoCmd' => '$', |
||
25 | 'getMetadataCacheImpl' => null, |
||
26 | 'getHydratorDir' => __DIR__.'/../temp', |
||
27 | 'getHydratorNamespace' => 'Hydrator', |
||
28 | 'getAutoGenerateHydratorClasses'=> true, |
||
29 | 'getDefaultCommitOptions' => array('safe' => true), |
||
30 | 'getDefaultDB' => 'khepinyamlfixturestest', |
||
31 | 'getRetryConnect' => 2, |
||
32 | 'getRetryQuery' => 2, |
||
33 | 'getLoggerCallable' => null, |
||
34 | 'getRepositoryFactory' => new \Doctrine\ODM\MongoDB\Repository\DefaultRepositoryFactory(), |
||
35 | 'getPersistentCollectionFactory'=> new \Doctrine\ODM\MongoDB\PersistentCollection\DefaultPersistentCollectionFactory(), |
||
36 | )); |
||
37 | |||
38 | return $config; |
||
39 | } |
||
40 | |||
41 | /** |
||
42 | * Creates default mapping driver |
||
43 | * |
||
44 | * @return \Doctrine\ORM\Mapping\Driver\Driver |
||
45 | */ |
||
46 | protected function getMetadataDriverImplementation() |
||
0 ignored issues
–
show
|
|||
47 | { |
||
48 | return new AnnotationDriver( |
||
49 | $_ENV['annotation_reader'], |
||
50 | __DIR__.'/../Fixture/Document' |
||
51 | ); |
||
52 | } |
||
53 | |||
54 | /** |
||
55 | * EntityManager mock object together with |
||
56 | * annotation mapping driver and pdo_sqlite |
||
57 | * database in memory |
||
58 | * |
||
59 | * @param EventManager $evm |
||
0 ignored issues
–
show
There is no parameter named
$evm . Was it maybe removed?
This check looks for PHPDoc comments describing methods or function parameters that do not exist on the corresponding method or function. Consider the following example. The parameter /**
* @param array $germany
* @param array $island
* @param array $italy
*/
function finale($germany, $island) {
return "2:1";
}
The most likely cause is that the parameter was removed, but the annotation was not. ![]() |
|||
60 | * @return EntityManager |
||
61 | */ |
||
62 | protected function getDoctrine() |
||
63 | { |
||
64 | $config = $this->getMockAnnotatedConfig(); |
||
65 | $dm = \Doctrine\ODM\MongoDB\DocumentManager::create(null, $config); |
||
66 | |||
67 | return $this->doctrine = m::mock(array( |
||
68 | 'getManager' => $dm, |
||
69 | 'getManagers' => array($dm), |
||
70 | 'getManagerForClass' => $dm |
||
71 | )); |
||
72 | |||
73 | // $conn = array( |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
43% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
74 | // 'driver' => 'pdo_sqlite', |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
58% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
75 | // 'memory' => true, |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
43% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
76 | // // 'path' => __DIR__.'/../db.sqlite', |
||
77 | // ); |
||
78 | |||
79 | // $config = $this->getMockAnnotatedConfig(); |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
55% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
80 | // $em = EntityManager::create($conn, $config); |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
54% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
81 | |||
82 | // $entities = array( |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
43% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
83 | // 'Khepin\\Fixture\\Entity\\Car', |
||
84 | // 'Khepin\\Fixture\\Entity\\Driver' |
||
85 | // ); |
||
86 | |||
87 | // $schema = array_map(function($class) use ($em) { |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
58% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
88 | // return $em->getClassMetadata($class); |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
70% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
89 | // }, $entities); |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
72% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
90 | |||
91 | // $schemaTool = new SchemaTool($em); |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
50% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
92 | // $schemaTool->dropSchema(array()); |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
80% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
93 | // $schemaTool->createSchema($schema); |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
75% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
94 | // return $this->doctrine = m::mock(array( |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
47% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
95 | // 'getEntityManager' => $em, |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
58% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
96 | // 'getManager' => $em, |
||
0 ignored issues
–
show
Unused Code
Comprehensibility
introduced
by
58% of this comment could be valid code. Did you maybe forget this after debugging?
Sometimes obsolete code just ends up commented out instead of removed. In this case it is better to remove the code once you have checked you do not need it. The code might also have been commented out for debugging purposes. In this case it is vital that someone uncomments it again or your project may behave in very unexpected ways in production. This check looks for comments that seem to be mostly valid code and reports them. ![]() |
|||
97 | // ) |
||
98 | // ); |
||
99 | } |
||
100 | } |
||
101 |
Instead of super-globals, we recommend to explicitly inject the dependencies of your class. This makes your code less dependent on global state and it becomes generally more testable: