Passed
Push — master ( 8f2c7f...261aac )
by Anatoliy
01:58
created

SurprisingTest::notString()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 14
Code Lines 8

Duplication

Lines 0
Ratio 0 %

Importance

Changes 0
Metric Value
dl 0
loc 14
rs 9.4285
c 0
b 0
f 0
cc 1
eloc 8
nc 1
nop 0
1
<?php
2
declare(strict_types=1);
3
4
5
/**
6
 * Created by PhpStorm.
7
 * User: danchukas
8
 * Date: 2017-06-22 18:10
9
 */
10
11
namespace DanchukAS\DenyMultiplyRunTest;
12
13
use DanchukAS\DenyMultiplyRun\DenyMultiplyRun;
14
use PHPUnit\Framework\TestCase;
15
16
17
/**
18
 * Class SurprisingTest
19
 * поглиблені тести на "всі найбільш можливі ситуації"
20
 * @package DanchukAS\DenyMultiplyRunTest
21
 */
22
class SurprisingTest extends TestCase
23
{
24
25
    private static $noExistFileName;
26
27
    private static $existFileName;
28
29
30
    function setUp()
0 ignored issues
show
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for setUp.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
31
    {
32
        self::$noExistFileName = sys_get_temp_dir() . '/' . uniqid('vd_', true);
33
        self::$existFileName = tempnam(sys_get_temp_dir(), 'vo_');
34
    }
35
36
    function tearDown()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for tearDown.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
37
    {
38
        /** @noinspection PhpUsageOfSilenceOperatorInspection */
39
        @unlink(self::$noExistFileName);
1 ignored issue
show
Security Best Practice introduced by
It seems like you do not handle an error condition for unlink(). This can introduce security issues, and is generally not recommended. ( Ignorable by Annotation )

If this is a false-positive, you can also ignore this issue in your code via the ignore-unhandled  annotation

39
        /** @scrutinizer ignore-unhandled */ @unlink(self::$noExistFileName);

If you suppress an error, we recommend checking for the error condition explicitly:

// For example instead of
@mkdir($dir);

// Better use
if (@mkdir($dir) === false) {
    throw new \RuntimeException('The directory '.$dir.' could not be created.');
}
Loading history...
40
        /** @noinspection PhpUsageOfSilenceOperatorInspection */
41
        @unlink(self::$existFileName);
42
    }
43
44
45
    /**
46
     * @expectedException \DanchukAS\DenyMultiplyRun\Exception\ProcessExisted
47
     */
48
    function testDoubleCall()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for testDoubleCall.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
49
    {
50
        $file_name = self::$noExistFileName;
51
        DenyMultiplyRun::setPidFile($file_name);
52
        DenyMultiplyRun::setPidFile($file_name);
53
54
    }
0 ignored issues
show
Coding Style introduced by
Function closing brace must go on the next line following the body; found 1 blank lines before brace
Loading history...
55
56
57
    function testDeleteNoExistedPidFile()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for testDeleteNoExistedPidFile.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
58
    {
59
        self::expectException("DanchukAS\DenyMultiplyRun\Exception\DeleteFileFail");
0 ignored issues
show
Bug Best Practice introduced by
The method PHPUnit\Framework\TestCase::expectException() is not static, but was called statically. ( Ignorable by Annotation )

If this is a false-positive, you can also ignore this issue in your code via the ignore-call  annotation

59
        /** @scrutinizer ignore-call */ self::expectException("DanchukAS\DenyMultiplyRun\Exception\DeleteFileFail");
Loading history...
60
        DenyMultiplyRun::deletePidFile(self::$noExistFileName);
61
    }
62
63
64
    function testDeletePidFileWrongParam()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for testDeletePidFileWrongParam.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
65
    {
66
        self::expectException("DanchukAS\DenyMultiplyRun\Exception\DeleteFileFail");
0 ignored issues
show
Bug Best Practice introduced by
The method PHPUnit\Framework\TestCase::expectException() is not static, but was called statically. ( Ignorable by Annotation )

If this is a false-positive, you can also ignore this issue in your code via the ignore-call  annotation

66
        /** @scrutinizer ignore-call */ self::expectException("DanchukAS\DenyMultiplyRun\Exception\DeleteFileFail");
Loading history...
67
        DenyMultiplyRun::deletePidFile(null);
68
    }
69
70
71
    function testDeleteNoAccessFile()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for testDeleteNoAccessFile.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
72
    {
73
        // existed file without write access for current user.
74
        // for Ubuntu is /etc/hosts.
75
        $file_name = "/etc/hosts";
76
77
        if (!file_exists($file_name)) {
78
            self::markTestSkipped("test only for *nix.");
79
        }
80
81
        if (is_writable($file_name)) {
82
            self::markTestSkipped("test runned under super/admin user. Change user.");
83
        }
84
85
        self::expectException("DanchukAS\DenyMultiplyRun\Exception\DeleteFileFail");
0 ignored issues
show
Bug Best Practice introduced by
The method PHPUnit\Framework\TestCase::expectException() is not static, but was called statically. ( Ignorable by Annotation )

If this is a false-positive, you can also ignore this issue in your code via the ignore-call  annotation

85
        /** @scrutinizer ignore-call */ self::expectException("DanchukAS\DenyMultiplyRun\Exception\DeleteFileFail");
Loading history...
86
        DenyMultiplyRun::deletePidFile($file_name);
87
    }
88
89
    /**
90
     * @dataProvider notString
91
     * @param mixed $notString
92
     */
93
    function testWrongTypeParam($notString)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for testWrongTypeParam.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
94
    {
95
        self::expectException("TypeError");
0 ignored issues
show
Bug Best Practice introduced by
The method PHPUnit\Framework\TestCase::expectException() is not static, but was called statically. ( Ignorable by Annotation )

If this is a false-positive, you can also ignore this issue in your code via the ignore-call  annotation

95
        /** @scrutinizer ignore-call */ self::expectException("TypeError");
Loading history...
96
        DenyMultiplyRun::setPidFile($notString);
97
98
    }
0 ignored issues
show
Coding Style introduced by
Function closing brace must go on the next line following the body; found 1 blank lines before brace
Loading history...
99
100
    /**
101
     * @dataProvider WrongParam
102
     * @param string $no_valid_file_name
103
     */
104
    function testWrongParam(string $no_valid_file_name)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for testWrongParam.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
105
    {
106
        self::expectException("Exception");
0 ignored issues
show
Bug Best Practice introduced by
The method PHPUnit\Framework\TestCase::expectException() is not static, but was called statically. ( Ignorable by Annotation )

If this is a false-positive, you can also ignore this issue in your code via the ignore-call  annotation

106
        /** @scrutinizer ignore-call */ self::expectException("Exception");
Loading history...
107
        DenyMultiplyRun::setPidFile($no_valid_file_name);
108
    }
109
110
111
    /**
112
     * @return array
113
     */
114
    function notString()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for notString.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
115
    {
116
        $r = fopen(__FILE__, "r");
117
        fclose($r);
118
119
        return [
120
            [null]
121
            , [false]
122
            , [0]
123
            , [[]]
124
            , [function () {
125
            }]
126
            , [new \Exception]
127
            , [$r]];
128
    }
129
130
131
    /**
132
     * @return array
133
     */
134
    function WrongParam()
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Coding Style introduced by
Method name "SurprisingTest::WrongParam" is not in camel caps format
Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for WrongParam.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
135
    {
136
        return [[""], ["."], ["/"], ['//']];
137
    }
138
139
140
    /**
141
     * @dataProvider notString
142
     */
143
    function testLockedFileBeforeClose($badResource)
0 ignored issues
show
Best Practice introduced by
It is generally recommended to explicitly declare the visibility for methods.

Adding explicit visibility (private, protected, or public) is generally recommend to communicate to other developers how, and from where this method is intended to be used.

Loading history...
Comprehensibility Best Practice introduced by
It is recommend to declare an explicit visibility for testLockedFileBeforeClose.

Generally, we recommend to declare visibility for all methods in your source code. This has the advantage of clearly communication to other developers, and also yourself, how this method should be consumed.

If you are not sure which visibility to choose, it is a good idea to start with the most restrictive visibility, and then raise visibility as needed, i.e. start with private, and only raise it to protected if a sub-class needs to have access, or public if an external class needs access.

Loading history...
144
    {
145
        $method = new \ReflectionMethod("DanchukAS\DenyMultiplyRun\DenyMultiplyRun", "closePidFile");
146
147
        $method->setAccessible(true);
148
        self::expectException("DanchukAS\DenyMultiplyRun\Exception\CloseFileFail");
0 ignored issues
show
Bug Best Practice introduced by
The method PHPUnit\Framework\TestCase::expectException() is not static, but was called statically. ( Ignorable by Annotation )

If this is a false-positive, you can also ignore this issue in your code via the ignore-call  annotation

148
        /** @scrutinizer ignore-call */ self::expectException("DanchukAS\DenyMultiplyRun\Exception\CloseFileFail");
Loading history...
149
        $method->invoke(null, $badResource);
150
        $method->setAccessible(false);
151
152
    }
0 ignored issues
show
Coding Style introduced by
Function closing brace must go on the next line following the body; found 1 blank lines before brace
Loading history...
153
154
155
156
}
157