Est-ce que Unit Test signifie que le test doit être raillé?

Question

Le test unitaire signifie-t-il que le test doit être raillé ou que la définition du test unitaire peut être sans moquerie?

Par exemple ci-dessous, ce test est raillé, il est donc test unitaire:

/** 
* @test 
*/ 
public function it_should_return_true_if_ssh_client_is_connected() 
{ 
    $this->phpSecLibShh->shouldReceive('isConnected')->andReturn(true)->once(); 

    $this->assertTrue($this->shell->connected($this->phpSecLibShh)); 
} 

exemple ci-dessous, est ce test unitaire ou Test d'intégration? Je ne suis pas clair à ce sujet:

/** 
* @test 
*/ 
public function it_should_get_half_price_discount() 
{ 
    $cost = 50; 

    $order = new Order(); 

    // It does not connect to database or any other service 
    $discounted = $order->discount(Order::DISCOUNT_HALF_PRICE, $cost); 

    $this->assertEquals(25, $discounted); 
} 

Answer 1

L'idée principale du moqueur est de découpler la dépendance. Les tests unitaires ne devraient avoir aucune sorte de dépendance. Dites que votre logique métier se connecte à la couche de base de données qui, à son tour, se connecte à la base de données. Vous écrivez maintenant un test unitaire pour tester votre logique métier. Si vous n'êtes pas en train de découpler la couche de base de données de la logique métier, votre test unitaire ira sur la base de données, ce qui ne devrait jamais arriver. Donc, ce que vous devez faire est d'injecter la dépendance de la base de données dans la couche logique métier et lors de l'écriture du test unitaire, moquez cette dépendance. En bref, vous n'avez pas besoin de simulation pour les tests unitaires, mais si une dépendance est présente, cela devrait être raillé. Si votre test a une dépendance (disons dépendance de base de données, dépendance de fichier, etc.) alors votre test n'est pas test unitaire mais test d'intégration

Answer 2

Vijay, d'après mon expérience, l'équipe sera le meilleur juge pour décider si elle a besoin d'un solitaire/stratégie de test d'unité adaptative/sociale, car il n'y a pas de solution unique pour tous. Cela dit, je pense qu'être adaptatif est probablement plus pratique. Presque toutes les applications monolithiques de moyenne et grande taille auront au moins une dépendance externe qui peut ne pas être disponible dans les environnements de développement/test (par exemple: passerelle de paiement/moteur de décision). Les données simulées seront notre seule option ici. Cependant, dans le même cas de test unitaire, nous pourrions également associer un autre scénario sociable (en appelant une autre fonction dans la même classe/espace de noms). Il peut même être possible que la deuxième fonction ait son cas de test simulé séparé. Ainsi, il pourrait devenir une stratégie de test d'unité adaptative où l'équipe prend position de manière collective en termes de ce qu'elle appelle une unité et de quelle stratégie elle doit être utilisée scénario par scénario. Nous devrions également garder à l'esprit que lorsque nous commençons à construire un pipeline de déploiement, nos tests unitaires peuvent être exécutés dans le cadre d'un processus automatisé qui fournit lui-même les environnements. Il peut donc être utile de garder nos bancs d'essai unitaires isolés de toute dépendance de base de données/fichier. À l'avenir, lorsque de plus en plus d'applications seront déployées dans l'architecture et la conteneurisation de Microservice, nous aurons plus de clarté sur la stratégie de test unitaire à utiliser. Le développement/déploiement sera effectué dans des blocs apatrides et déployables indépendamment/gérables. Des outils comme les API Docker Daemon peuvent être utilisés pour faire tourner un conteneur qui héberge un service/une fonctionnalité spécifique lié/dépendant et l'exécuter dans le cadre de notre exécution de cas de test, cela nous évitera d'avoir à se moquer des autres services. un conteneur léger avec le service concerné et le tester.