Tutoriel Laravel : Utiliser Stub pour résoudre les dépendances dans les tests unitaires

Résumé : Je connais le concept de tests unitaires depuis longtemps et je l'ai essayé lentement, ma compréhension des tests unitaires et de PHPUnit est devenue. plus clair et commencez à pratiquer les tests unitaires lentement. Comme nous le savons tous pour les dépendances dans Laravel, Laravel utilise IoC et les différents modules sont donc découplés. Et c'est précisément à cause de cela...

Je connais le concept de tests unitaires depuis longtemps et je l'ai essayé. Lentement, ma compréhension des tests unitaires et de PHPUnit est devenue plus claire, et j'ai commencé lentement à pratiquer les tests unitaires.

Dépendances dans Laravel

Nous savons tous que Laravel utilise IoC, et donc les différents modules sont découplés. Et c’est précisément pour cette raison que cela devient plus facile lorsque nous écrivons des tests unitaires dans Laravel.

À titre d'exemple

Considérez le scénario suivant. Lors du développement, nous pouvons ajouter un Repository entre le contrôleur et le modèle pour traiter les données. Alors notre Controller dépendra de Respository. En utilisant l'IoC de Laravel, nous pouvons définir un Service Provider pour injecter de manière centralisée Respository dans le conteneur.

Supposons que nous ayons maintenant un référentiel qui enregistre les informations sur le produit. Nous souhaitons obtenir certaines informations sur le produit dans le contrôleur, puis exécuter une logique métier.

Class GoodRepository{    public function getGoodById($goodId)
    {        // TODO: Get good by its id.
    }
}class GoodController extends Controller{    public function show($id, GoodRepository $goodRepository)
    {        // TODO: Do something with good info from that repository.
    }
}// In route/api.phpRoute::get('/api/good/{id}', 'GoodController@show');// Create a RepositoriesServiceProvider in Provider/RepositoriesServiceProvider.php。// And inject the GoodRepository into Container.class RepositoriesServiceProvider extends ServiceProvider{    public function boot()
    {
    
    }    
    public function register()
    {        $this->app->singleton(GoodRepository::class);
    }
}

D'accord, nous pouvons constater que GoodController dépend de GoodRepository, et GoodRepository dépend des données de la base de données. Mais lorsque nous effectuons des tests unitaires, nous espérons générer le moins de dépendances possible. Par conséquent, nous devrions vouloir pouvoir contrôler les données renvoyées par GoodRepository.

Dans Laravel, la méthode $this->get('/path/to/route'); est fournie pour tester les requêtes HTTP. Ce test impliquera inévitablement les dépendances que nous venons de mentionner. Comment résoudre ce problème de dépendance, nous pouvons demander à notre protagoniste, le stubware.

Stubbing

La pratique consistant à remplacer un objet par un double de test qui (éventuellement) renvoie une valeur de retour configurée est appelée stubbing.

Voici l'explication de la documentation PHPUnit. Je crois comprendre que ce qu'on appelle le stub vise à simuler le comportement d'une classe dépendante afin que ce comportement soit sous notre propre contrôle. Par exemple, dans la situation ci-dessus, nous espérons que la méthode GoodRepository de simulation getGoodById renvoie la même valeur que la structure de retour réelle sans recourir à des sources de données externes.

Utiliser des stubs dans Laravel

Nous avons enregistré le Service Provider singleton via GoodRepository Ensuite, selon cette idée, lorsque nous écrivons des tests unitaires, nous pouvons définir le Stub, enregistré comme singleton. GoodRepository

class GoodControllerTest extends TestCase{    public function testShow()
    {
        $data = []; // The data returns from GoodRepository::getGoodById.
        
        $stub = $this->createMock(GoodRepository::class);
        
        $stub->method('getGoodById')->will($this->returnValue($data));        
        $this->app->singleton(GoodRepository::class, function () use ($stub) {            return $stub;
        });
        
        $response = $this->get('/api/good/1');        
        // Some assertions.
    }
}

我们通过在这里将桩件 $stub 用单例模式注册给了 Container，在调用 $this->get('/api/good/1'); 时原本在 Controller 中的 GoodRepository 依赖就变成了我们自定义的桩件 $stub。我们将 $data 定义为和返回值相同的结构，注册到桩件中。这样，所有的数据都在我们可控的范围了。

如果我们在这里不使用桩件，而是直接依赖外部（数据库）中的数据，那么如果 id 为 1 的数据被删除了，我们是不是就要改成 2 了呢？我们是不是就要重新计算数据了匹配断言了呢？这样的测试，可靠性便大大降低。

Postscript

Pour tout système fiable, les tests unitaires sont essentiels. Heureusement, PHPUnit nous fournit des tests unitaires utiles. Ce dont parle cet article n’est qu’une goutte d’eau dans le seau de PHPUnit. Et j’explore et pratique moi-même lentement. Ensemble, encourageons-nous.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!