2015-03-20 1 views
3

Supposons la classe Compte (dans le fichier account.php) qui utilise une variable $ DB pour stocker des données dans la base de données. La variable $ DB est initialisée dans un autre fichier globals.php.Comment testeriez-vous le code PHP qui utilise une variable globale?


/**** globals.php ****/ 

$DB = PDO (....); 

/**** account.php ****/ 

public function create($data) { 
global $DB; 
.... 
} 

Maintenant, supposons que vous voulez tester une fonction en classe compte en utilisant le test appelé de créer des PHPUnit. Comment initialiseriez-vous l'objet $ DB?

+1

C'est pourquoi vous n'utilisez pas de globales. – Styphon

+0

Pourquoi ne pas passer le gestionnaire db à la classe ou à la fonction? – Carter

Répondre

1

Idéalement, vous ne devez pas utiliser de globales pour masquer des dépendances et provoquer des événements dus à des modifications de la variable globale.

Il serait possible de pirater et remplacer votre variable afin que vous puissiez le railler. Vous pouvez utiliser la méthode setUp pour stocker ce qui est dans le $DB global, puis le restaurer dans la méthode teardown(). De cette façon, vous ne cassez pas accidentellement un autre test avec votre maquette. Maintenant, simplement parce que vous pouvez le faire, ne signifie pas que vous devriez le faire. Il vaudrait mieux refactoriser votre code pour qu'il ne dépende pas de la portée globale. Mais si ce n'est pas une option en ce moment, voici un travail qui rendra au moins le test utilisable jusqu'à ce que vous refactor.

0

Comment initialiser l'objet $DB?

Juste lsinitialisez comme d'habitude:

class TestCase extends PHPUnit_Framework_TestCase 
{ 
    function testDatabaseConnection() 
    { 
     require 'path/to/globals.php'; // take "global" variable in local scope 
     $GLOBALS['DB'] = $DB; // make it globally available 

     $account = new account(); 
     $this->assertInstanceOf('account', $account); 

     $this->assertTrue($account->create("data")); 

     ... 
    } 
} 

commencer ensuite avec des tests et obtenir un sentiment comment le code se comporte lorsque vous testez soigneusement.

Vous pouvez ensuite envisager d'initialiser la connexion à la base de données avant la création de la classe de test, afin de pouvoir écrire les routines de test plus rapidement.

plus tard, vous vous écrire probablement une méthode d'aide à instancier la classe de compte.

C'est peut-être aussi le moment où vous vous rendez compte que l'injection de l'objet de connexion à la base de données dans le constructeur n'est peut-être pas aussi mauvaise.