CakePHP PHPUnit Fixtures Drop Database Table Every Time

Question 1

It is default behaviour for CakePHP to create and drop all tables when testing.

So that they are (re)created for each test, you have the following options:

Create the schema and the records in the Fixture.
Import the schema from the database and create the records in the Fixture.
Import the schema and the records from the database.

I use option no. 2 as I have too much data for CakePHP to import (and drop) for each test.

public $import = array('model' => 'YourModel', 'records' => false, 'connection' => 'default');

I specified the connection "default" so that CakePHP looks to my default connection to import schema information. I think the problem is that your $import variable is trying to import tables from the test connection. These will stop existing after the first run, when they are dropped.

Question 2

The accepted answer does not resolve the question:

I have public $dropTables = false; Can anyone figure out why the merchant_rejects table is still being dropped?

From cakephp docs:

$dropTables

Control table create/drops on each test method.

Set this to false to avoid tables to be dropped if they already exist between each test method. Tables will still be dropped at the end of each test runner execution.

Notice this part:

Tables will still be dropped at the end of each test runner execution

Therefore, even if you public $dropTables = false; the table tied to the fixture will still be dropped after each test run. The accepted answer does not prevent this.

To prevent this do the following...

Create your fixture like this:

class MovieStarFixture extends CakeTestFixture {

    public $import = 'MovieStar';

    //data will be loaded into this fixture by the test cases

    // do not truncate movie_stars table between tests
    public function truncate($db){

        return null;
    }

    // do not drop movie_stars table between tests
    public function drop($db){

        return null;
    }
}

This prevents the fixture from truncating and dropping after each test method. This is done by causing the fixture to "pretend" that it drops and truncates the table between tests. However this means that the fixture will think the table is dropped and try to re-create it at the beginning of each test method run which will cause an error (warning about creating existing table), so you must also...

Do this:

In MovieStarTest add public $dropTables = false;. This will prevent the fixture from attempting to drop a table if it already exists. As a result of not dropping a table at the beginning of a test, the fixture will not attempt to create the table. This is what we want because the table already exists.

Now you will have your data persisted between your CakeTestCase::test*() method calls.

Question 3

It looks like lib/Cake/TestSuite/Fixture/CakeFixtureManager.php has a shutDown() function that drops the database. I would love to know where in the code it is supposed to check the $dropTables value before reaching this function. enter image description here

Question 4

Building on Xavier's answer, you can ensure the table is only populated once by doing the following without needing to set dropTables = false at the test level:

class MovieStarFixture extends CakeTestFixture
{

  public $import = ['model' => 'MovieStar', 'connection' => 'default', 'records' => true];

  private $created_flag = false;

  public function create($db)
  {
    $success = null;
    if (!$this->created_flag) {
      $success = parent::create($db);
    }
    return $success;
  }

  public function truncate($db)
  {
    $success = null;
    if (!$this->created_flag) {
      $success = parent::truncate($db);
    }
    return $success;
  }

  public function insert($db)
  {
    $success = null;
    if (!$this->created_flag) {
      $success = parent::insert($db);
      $this->created_flag = true;
    }
    return $success;
  }

  public function drop($db)
  {
    $success = null;
    if (!$this->created_flag) {
      $success = parent::drop($db);
    }
  }
}

There is always the trade off between isolation and speed to consider, but if you have a large table that won't be changed throughout the life time of your test then this can have a huge performance boost.