[Phpmyadmin-devel] Mocking static methods - Unit tests
Hi, I have been writing Unit Tests for classes and libraries under libraries/config/*. For isolation between different libraries, its preferred to mock certain functions. Since some of the code is functional, I tried to convert (for a start) libraries/config/validate.lib.php into a class with static methods. However, the issue here is that mocking static methods is not really possible with PHPUnit and there are a few workarounds I came across and would like to know which one should we go for, or if there is anything better that can be done. So, while the writer of PHPUnit specifies how to mock static methods here[0], its only possible if the static calls are to the same class. For example, for testing FormDisplay::_validate, I need to mock PMA_config_validate. After I convert validate.lib.php to a class, say, PMA_Validator, I will have to mock PMA_Validator::config_validate, but the above solution won't work here (since PMA_Validator cannot be mocked). A workaround for this could be to pass the mocked static class as mentioned in [0] to the FormDisplay.class.php and make all static calls via that class. For this, we could have something of this sort in the constructor of FormDisplay: if (defined('TESTSUITE')) $this->validator = $GLOBALS['dummyValidator'] or $this->validator = <mockedClassPassedInTheArgument> else $this->validator = 'PMA_Validator' and the calls can be made like: $caller = $this->validator; // $this->validator::config_validate won't work $caller:config_validate(); Another solution could be what is mentioned in a blog here[1]. The problem with this solution is that the file, FormDisplay.class.php would include and hence declare the PMA_Validator class before our test suite tries to (re)declare it by extending MockProxy class. In either case, it looks like some sort of modification would be needed to test these classes. Please advice. [0] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method... [1] http://www.deanspot.org/content/mocking-static-method-calls-phpunit -- Ayush Chaudhary
On Tue, Jul 9, 2013 at 2:21 PM, Ayush Chaudhary <ayushchd@gmail.com> wrote:
Hi,
I have been writing Unit Tests for classes and libraries under libraries/config/*. For isolation between different libraries, its preferred to mock certain functions. Since some of the code is functional, I tried to convert (for a start) libraries/config/validate.lib.php into a class with static methods.
However, the issue here is that mocking static methods is not really possible with PHPUnit and there are a few workarounds I came across and would like to know which one should we go for, or if there is anything better that can be done.
So, while the writer of PHPUnit specifies how to mock static methods here[0], its only possible if the static calls are to the same class.
For example, for testing FormDisplay::_validate, I need to mock PMA_config_validate. After I convert validate.lib.php to a class, say, PMA_Validator, I will have to mock PMA_Validator::config_validate, but the above solution won't work here (since PMA_Validator cannot be mocked). A workaround for this could be to pass the mocked static class as mentioned in [0] to the FormDisplay.class.php and make all static calls via that class.
For this, we could have something of this sort in the constructor of FormDisplay:
if (defined('TESTSUITE')) $this->validator = $GLOBALS['dummyValidator'] or $this->validator = <mockedClassPassedInTheArgument> else $this->validator = 'PMA_Validator'
and the calls can be made like:
$caller = $this->validator; // $this->validator::config_validate won't work $caller:config_validate();
Another solution could be what is mentioned in a blog here[1]. The problem with this solution is that the file, FormDisplay.class.php would include and hence declare the PMA_Validator class before our test suite tries to (re)declare it by extending MockProxy class.
In either case, it looks like some sort of modification would be needed to test these classes.
Please advice.
[0] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method... [1] http://www.deanspot.org/content/mocking-static-method-calls-phpunit
As Sebastian Bergmann says, "static methods are death to testability". This makes me wonder what disadvantages we would have if we make the methods of PMA_Validator class non-static and use instantiated object of PMA_Validator class to do the validations?
-- Thanks and Regards, Madhura Jayaratne
On Tuesday, 9 July 2013 at 5:58 PM, Madhura Jayaratne wrote:
On Tue, Jul 9, 2013 at 2:21 PM, Ayush Chaudhary <ayushchd@gmail.com (mailto:ayushchd@gmail.com)> wrote:
Hi,
I have been writing Unit Tests for classes and libraries under libraries/config/*. For isolation between different libraries, its preferred to mock certain functions. Since some of the code is functional, I tried to convert (for a start) libraries/config/validate.lib.php into a class with static methods.
However, the issue here is that mocking static methods is not really possible with PHPUnit and there are a few workarounds I came across and would like to know which one should we go for, or if there is anything better that can be done.
So, while the writer of PHPUnit specifies how to mock static methods here[0], its only possible if the static calls are to the same class.
For example, for testing FormDisplay::_validate, I need to mock PMA_config_validate. After I convert validate.lib.php to a class, say, PMA_Validator, I will have to mock PMA_Validator::config_validate, but the above solution won't work here (since PMA_Validator cannot be mocked). A workaround for this could be to pass the mocked static class as mentioned in [0] to the FormDisplay.class.php and make all static calls via that class.
For this, we could have something of this sort in the constructor of FormDisplay:
if (defined('TESTSUITE')) $this->validator = $GLOBALS['dummyValidator'] or $this->validator = <mockedClassPassedInTheArgument> else $this->validator = 'PMA_Validator'
and the calls can be made like:
$caller = $this->validator; // $this->validator::config_validate won't work $caller:config_validate();
Another solution could be what is mentioned in a blog here[1]. The problem with this solution is that the file, FormDisplay.class.php would include and hence declare the PMA_Validator class before our test suite tries to (re)declare it by extending MockProxy class.
In either case, it looks like some sort of modification would be needed to test these classes.
Please advice.
[0] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method... [1] http://www.deanspot.org/content/mocking-static-method-calls-phpunit
As Sebastian Bergmann says, "static methods are death to testability".This makes me wonder what disadvantages we would have if we make the methods of PMA_Validator class non-static and use instantiated object of PMA_Validator class to do the validations?
I doubt there would be any disadvantages. In any case, from the POV of Unit Testing, we will have to include the instantiated object or the class name, as a member of the class that calls the respective methods (in this example. FormDisplay) Further, I'd like to know how useful this statement on PHP.net can be in this context: 'A property declared as static can not be accessed with an instantiated class object (though a static method can)'
-- Thanks and Regards,
Madhura Jayaratne
------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net (mailto:Phpmyadmin-devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Tue, Jul 9, 2013 at 5:49 PM, Ayush Chaudhary <ayushchd@gmail.com> wrote:
On Tuesday, 9 July 2013 at 5:58 PM, Madhura Jayaratne wrote:
On Tue, Jul 9, 2013 at 2:21 PM, Ayush Chaudhary <ayushchd@gmail.com>wrote:
Hi,
I have been writing Unit Tests for classes and libraries under libraries/config/*. For isolation between different libraries, its preferred to mock certain functions. Since some of the code is functional, I tried to convert (for a start) libraries/config/validate.lib.php into a class with static methods.
However, the issue here is that mocking static methods is not really possible with PHPUnit and there are a few workarounds I came across and would like to know which one should we go for, or if there is anything better that can be done.
So, while the writer of PHPUnit specifies how to mock static methods here[0], its only possible if the static calls are to the same class.
For example, for testing FormDisplay::_validate, I need to mock PMA_config_validate. After I convert validate.lib.php to a class, say, PMA_Validator, I will have to mock PMA_Validator::config_validate, but the above solution won't work here (since PMA_Validator cannot be mocked). A workaround for this could be to pass the mocked static class as mentioned in [0] to the FormDisplay.class.php and make all static calls via that class.
For this, we could have something of this sort in the constructor of FormDisplay:
if (defined('TESTSUITE')) $this->validator = $GLOBALS['dummyValidator'] or $this->validator = <mockedClassPassedInTheArgument> else $this->validator = 'PMA_Validator'
and the calls can be made like:
$caller = $this->validator; // $this->validator::config_validate won't work $caller:config_validate();
Another solution could be what is mentioned in a blog here[1]. The problem with this solution is that the file, FormDisplay.class.php would include and hence declare the PMA_Validator class before our test suite tries to (re)declare it by extending MockProxy class.
In either case, it looks like some sort of modification would be needed to test these classes.
Please advice.
[0] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method... [1] http://www.deanspot.org/content/mocking-static-method-calls-phpunit
As Sebastian Bergmann says, "static methods are death to testability". This makes me wonder what disadvantages we would have if we make the methods of PMA_Validator class non-static and use instantiated object of PMA_Validator class to do the validations?
I doubt there would be any disadvantages. In any case, from the POV of Unit Testing, we will have to include the instantiated object or the class name, as a member of the class that calls the respective methods (in this example. FormDisplay)
Further, I'd like to know how useful this statement on PHP.net can be in this context:
'A property declared as static can not be accessed with an instantiated class object (*though a static method can*)'
I guess this [1] will help
[1] http://stackoverflow.com/questions/14331450/a-property-declared-as-static-ca... -- Thanks and Regards, Madhura Jayaratne
On Tue, Jul 9, 2013 at 5:43 PM, Madhura Jayaratne <madhura.cj@gmail.com>wrote:
On Tue, Jul 9, 2013 at 2:21 PM, Ayush Chaudhary <ayushchd@gmail.com>wrote:
Hi,
I have been writing Unit Tests for classes and libraries under libraries/config/*. For isolation between different libraries, its preferred to mock certain functions. Since some of the code is functional, I tried to convert (for a start) libraries/config/validate.lib.php into a class with static methods.
However, the issue here is that mocking static methods is not really possible with PHPUnit and there are a few workarounds I came across and would like to know which one should we go for, or if there is anything better that can be done.
So, while the writer of PHPUnit specifies how to mock static methods here[0], its only possible if the static calls are to the same class.
For example, for testing FormDisplay::_validate, I need to mock PMA_config_validate. After I convert validate.lib.php to a class, say, PMA_Validator, I will have to mock PMA_Validator::config_validate, but the above solution won't work here (since PMA_Validator cannot be mocked). A workaround for this could be to pass the mocked static class as mentioned in [0] to the FormDisplay.class.php and make all static calls via that class.
For this, we could have something of this sort in the constructor of FormDisplay:
if (defined('TESTSUITE')) $this->validator = $GLOBALS['dummyValidator'] or $this->validator = <mockedClassPassedInTheArgument> else $this->validator = 'PMA_Validator'
and the calls can be made like:
$caller = $this->validator; // $this->validator::config_validate won't work $caller:config_validate();
Another solution could be what is mentioned in a blog here[1]. The problem with this solution is that the file, FormDisplay.class.php would include and hence declare the PMA_Validator class before our test suite tries to (re)declare it by extending MockProxy class.
In either case, it looks like some sort of modification would be needed to test these classes.
Please advice.
[0] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method... [1] http://www.deanspot.org/content/mocking-static-method-calls-phpunit
As Sebastian Bergmann says, "static methods are death to testability". This makes me wonder what disadvantages we would have if we make the methods of PMA_Validator class non-static and use instantiated object of PMA_Validator class to do the validations?
Hi all,
Any objection to this, otherwise Ayush can go ahead with this approach? -- Thanks and Regards, Madhura Jayaratne
2013/7/16 Madhura Jayaratne <madhura.cj@gmail.com>:
On Tue, Jul 9, 2013 at 5:43 PM, Madhura Jayaratne <madhura.cj@gmail.com> wrote:
On Tue, Jul 9, 2013 at 2:21 PM, Ayush Chaudhary <ayushchd@gmail.com> wrote:
Hi,
I have been writing Unit Tests for classes and libraries under libraries/config/*. For isolation between different libraries, its preferred to mock certain functions. Since some of the code is functional, I tried to convert (for a start) libraries/config/validate.lib.php into a class with static methods.
However, the issue here is that mocking static methods is not really possible with PHPUnit and there are a few workarounds I came across and would like to know which one should we go for, or if there is anything better that can be done.
So, while the writer of PHPUnit specifies how to mock static methods here[0], its only possible if the static calls are to the same class.
For example, for testing FormDisplay::_validate, I need to mock PMA_config_validate. After I convert validate.lib.php to a class, say, PMA_Validator, I will have to mock PMA_Validator::config_validate, but the above solution won't work here (since PMA_Validator cannot be mocked). A workaround for this could be to pass the mocked static class as mentioned in [0] to the FormDisplay.class.php and make all static calls via that class.
For this, we could have something of this sort in the constructor of FormDisplay:
if (defined('TESTSUITE')) $this->validator = $GLOBALS['dummyValidator'] or $this->validator = <mockedClassPassedInTheArgument> else $this->validator = 'PMA_Validator'
and the calls can be made like:
$caller = $this->validator; // $this->validator::config_validate won't work $caller:config_validate();
Another solution could be what is mentioned in a blog here[1]. The problem with this solution is that the file, FormDisplay.class.php would include and hence declare the PMA_Validator class before our test suite tries to (re)declare it by extending MockProxy class.
In either case, it looks like some sort of modification would be needed to test these classes.
Please advice.
[0] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method... [1] http://www.deanspot.org/content/mocking-static-method-calls-phpunit
As Sebastian Bergmann says, "static methods are death to testability". This makes me wonder what disadvantages we would have if we make the methods of PMA_Validator class non-static and use instantiated object of PMA_Validator class to do the validations?
Hi all,
Any objection to this, otherwise Ayush can go ahead with this approach?
No objections. -- Kind regards, Dieter Adriaenssens
participants (3)
-
Ayush Chaudhary -
Dieter Adriaenssens -
Madhura Jayaratne