Forums / Developer / Need help getting started with unit testing extensions

Need help getting started with unit testing extensions

Author Message

Eirik Alfstad Johansen

Friday 13 November 2009 11:47:14 am

Hi,

During the summer conference this year there was some discussion regarding unit testing which I found very interesting. I have, however, not been able to find enough information about this since then to get started unit testing our extensions. Here's what I've found so far:

1. A page at eZPedia (http://ezpedia.org/en/ez/testing_ez_publish_test_system) giving a brief introduction to how unit tests are implemented in eZ Publish, but with very little information about extensions in particular.

2. A few extensions which implement unit testing like ezfind. However, all the extensions I've come across so far seem to focus mostly on DB tests, and hence derive from the ezpDatabaseTestCase class as apposed to the ezpTestCase class mentioned at eZPedia.

Would it be possible for someone with experience in writing unit tests for extensions to give a brief introduction into how it's done (like Paul B. og Paul F.)? Or perhaps an article is in order?

Thanks in advance !

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Bertrand Dunogier

Friday 13 November 2009 3:40:31 pm

It's actually not very hard, you should be rock & rolling in no time.

One good starting extension is ezselection2. Paul (F) has written a good amount of unit tests for it already: http://svn.ez.no/svn/extensions/ezselection2/.

Now, most of what you'll find on ezpedia is right. The most important parts:

  • do not forget to generate the tests autoloads: ./bin/php/ezpgenerateautoloads.php -s
  • you can filter out your tests by adding extension/extension_name at the end of the command line

Globally, start by writing tests for the "helper" classes your extension(s) probably rely on. The convention would be to mirror your extension's class hierarchy in the tests folder:

extension/myext/datatypes/foo/footype.php
extension/myext/tests/datatypes/foo/footype_test.php
extension/myext/tests/datatypes/foo/footype_regression.php

It can be a bit tedious for large extensions, but well, standards are standards ;)

About the tests themselves, it is very likely they will inherit ezpDatabaseTestCase. Don't forget to inherit ezpDatabaseTestSuite. You can also add custom SQL scripts that will be automatically imported at suite startup by using the $sqlFiles array property in your class. Be very careful about the database driver specification... and don't forget to add an extra blank at the end of the SQL files. It's very easy to waste time on that.

If one of your tests doesn't use the database at all (network access class, file parsing, http stuff), just inherit ezpTestCase instead. $sqlFiles is one of the major differences, aside with the fixture.

You can also check the kernel tests. Most extensions will obey the same structure as kernel features, and how they can be implemented won't be that different.

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Gaetano Giunta

Saturday 14 November 2009 7:43:20 am

Thanks for the tips Bertrand (even though it sounds too deeply technical for those who have not started with them yet).

One question I have is: what is the recommended way to introduce specific ini settings in the unit tests?

Eg. test this when ini x.y.z is set to A, then test it when it is set to B.

Principal Consultant International Business
Member of the Community Project Board

Bertrand Dunogier

Saturday 14 November 2009 12:25:22 pm

"

One question I have is: what is the recommended way to introduce specific ini settings in the unit tests?

Eg. test this when ini x.y.z is set to A, then test it when it is set to B.

"

Does anyone know how you can split the quote ? e.g. answer between lines... I haven't found a way on chrome or firefox yet.

I have the perfect answer to the INI question ! :)
Check this file: http://pubsvn.ez.no/nextgen/trunk/tests/toolkit/ezpinihelper.php

It's a helper class I've used to test some features where I needed forced values for INI settings (setting up the cluster environnement for instance). It is very simple:

// Set DatabaseSettings.DatabaseName to 'myotherdb' in site.ini
ezpINIHelper::setINISetting( 'site.ini', 'DatabaseSettings', 'DatabaseName', 'myotherdb' );

// bla bla bla, test stuff with DB

// Restore the previous settings
ezpINIHelper::restoreINISettings()

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier