Posts tagged database

phpunit_logov2

PHPUnit – Unit Tests – Logically Organize Fixtures

0

I have been working on a project to update an out-of-date Continuous Integration (CI) environment, and one of the tasks was to update the unit tests which required database access. My goal was to ensure that fixtures¬†would be accessible from a central, logical location, much like fundamental coding practices (Don’t Repeat Yourself). After some source code investigation, I found that PHPUnit provides the interface to add multiple fixture files as part of the “getDataset” method for running your unit tests which require database access. Based on this available functionality, I opted to put fixtures together that were not specific to any test, but generic for any test to use them. If you think about it, this really makes the most sense, otherwise you are having to maintain several fixture files which are tightly coupled to specific tests, which are bound to contain data overlap. Even if you do require fixture data which is coupled to a specific to a test, you can still add it to the centralized fixtures, as the other tests won’t even consider the data during their tests, unless you make them aware of the test specific data.

With all that being said I ended up organizing my fixtures like this:


# Template

/path/to/unitTests/fixture

./<database_name>/<table_name>.yml

# Actual

/home/mpurcell/projects/hobis/api/test/etc/fixture

./ml_book/author.yml

./ml_book/book.yml
./ml_book/book_author_link.yml

As you can see, I can group my fixture files by database, using the table name for the name of the fixture file. Sure these may be susceptible to change, but only as often as you actually rename databases/tables, so it should be infrequent. Now for some sample content:


# book.yml

book:

  id: 1

  name: War and Peace

  publish_year: 1869

# author.yml

author:

  id: 1

  name_first: Leo

  name_last: Tolstoy

#book_author_link.yml

book_author_link:

  id: 1

  book_id: 1

  author_id: 1

All three of the above fixture files are organized in the fixture directory under the ‘ml_book’ database and each have a representative row, including the linking table, which will satisfy any FK constraints at the database layer.

The last step is to have your test load the necessary fixtures:


class BookTest extends PHPUnit_Extensions_Database_TestCase
{

    // Dataset is a required method as defined by parent class
    protected function getDataset()
    {

        // Order is important, as we must load in primary fixtures before attempting to load FK fixtures
        $dataset = new PHPUnit_Extensions_Database_DataSet_YamlDataSet('etc/fixture/ml_book/book.yml');

        $dataset->addYamlFile('etc/fixture/ml_book/author.yml');

        $dataset->addYamlFile('etc/fixture/ml_book/book_author_link.yml');

        return $dataset;
    }
    ...
 }

And there you have it, a way to logically group your fixtures and add them to any test in which you need database datasets. I did take a look at the xml file dataset parser, and it DOES NOT afford the same functionality, and to be honest, doesn’t bother me, as I have always felt that yaml is better than xml for configuration files, as the xml files require a lot more text to accomplish the same functionality.

Also, I did some tailing of the query log, and for every table you added in the manner described above, the table would be truncated for every test, ensuring a truly sanitized environment before executing the next test.

magento_logo_3533

Magento – Unable to Connect to Database

0

Just spent 30 minutes fighting the magento GUI installer, which kept giving me a ‘unable to connect to database’ error. Only after trying a multitude of config permutations did I realize that I had to put a valid hostname (not localhost) into the hostname textbox (even though I could connect to localhost via command line). Before entering a hostname into the textbox, be sure the hostname is in accessible (either via DNS or /etc/hosts). Good luck.

Go to Top