PHPUnit and Phinx Integration Testing

Question

I am creating a PHP REST api using PHPUnit for unit tests and integration tests. I want to integrate phinx for DB migration (instead of creating the migration code myself).

I have two questions:

• How can I use Phinx for my database setup? Phinx is usually used as a command line tool, but I will need to somehow invoke the installation method in my unit test class.

• How do I go through integration testing of the migration classes I'm writing? I would like some kind of verification that after each migration step my database is in some expected state (possibly including some sample data that must be consistent during each migration).

Answer 1

Here is the solution.

<?php use Phinx\Console\PhinxApplication; use Symfony\Component\Console\Input\StringInput; use Symfony\Component\Console\Output\NullOutput; use Phinx\Wrapper\TextWrapper; class ExampleTest extends TestCase { private static $T; public function setUp(){ $app = new PhinxApplication(); $app->setAutoExit(false); $app->run(new StringInput(' '), new NullOutput()); self::$T = new TextWrapper($app); self::$T->getMigrate("testing"); } public function tearDown(){ self::$T->getRollback("testing"); } ?> 

Short and sweet.

Answer 2

Phinx will not automate everything except here what you can do.

How can I use Phinx for my database setup? Phinx - this is usually used as a command line tool, but I will need to be called from the installation method in my unit test class somehow.

You can use the exec PHP function to run external commands, see the documentation.

How do I go through integration testing of the migration classes that I write? I would like some kind of verification that after each migration step my database is in some expected state (possibly including some sample data that should be migrated).

This is harder. Probably the best approach would be to migrate the database using Phinx before running the test suites. Passing all tests automatically checks if the migration was successful, given that you have good code coverage. After all, the first thing you want to provide is that the application works from an end-user perspective - your functionality / integration tests cover just that.

The problem with testing something like this is that each migration is different, so another part of the database would change. Tests are usually aimed at a specific area of ​​code / functionality, so you won’t be able to have a simple single test that checks that the migration was successful, everything that is necessary for the update is updated, and nothing works. If you want to verify that the exact changes have been applied, you need to add a new test for each migration and remove the redundant tests. A general approach might be:

• Save the initial state of sql dumps using a common index (number / data) so that you can find the last one, for example Migration-2014-09-11-22-00.sql .
• In the boot boot, find the last dump, configure the database and apply it.
• Use a separate migration test case to claim it went well. In fact, you can create a separate Migration-2014-09-11-22-00.php that will contain statements related to migration and include them in testMigration() of the MigrationTest class. There is definitely more to one way to do this.
• Other unit tests and integration tests confirm that your application works as usual.