Que signifie «stub» dans la programmation?

Par exemple, qu'est-ce que cela signifie dans cette citation?

L'intégration à une API externe est presque une garantie dans toute application Web moderne. Pour tester efficacement une telle intégration, vous devez la stuber . Un bon stub doit être facile à créer et constamment à jour avec les réponses API actuelles et actuelles. Dans cet article, nous présenterons une stratégie de test utilisant des stubs pour une API externe.

Un stub est un remplacement contrôlable pour une dépendance existante (ou un collaborateur) dans le système. En utilisant un stub, vous pouvez tester votre code sans traiter directement la dépendance.

Dépendance externe - Dépendance existante:
c'est un objet de votre système avec lequel votre code testé interagit et sur lequel vous n'avez aucun contrôle. (Les exemples courants sont les systèmes de fichiers, les threads, la mémoire, l'heure, etc.)

Par exemple dans le code ci-dessous:

public void Analyze(string filename)
    {
        if(filename.Length<8)
        {
            try
            {
                errorService.LogError("long file entered named:" + filename);
            }
            catch (Exception e)
            {
                mailService.SendEMail("admin@hotmail.com", "ErrorOnWebService", "someerror");
            }
        }
    }

Vous voulez tester la méthode mailService.SendEMail () , mais pour ce faire, vous devez simuler une exception dans votre méthode de test, il vous suffit donc de créer un objet Fake Stub errorService pour simuler le résultat souhaité, puis votre code de test sera capable de tester la méthode mailService.SendEMail () . Comme vous le voyez, vous devez simuler un résultat provenant d'une autre dépendance qui est un objet de classe ErrorService (objet de dépendance existant).

Un stub , dans ce contexte, signifie une implémentation fictive.

C'est-à-dire une implémentation simple et fausse qui est conforme à l'interface et qui doit être utilisée pour les tests.

Les termes de Layman, ce sont des données factices (ou de fausses données, des données de test, etc.) que vous pouvez utiliser pour tester ou développer votre code jusqu'à ce que vous (ou l'autre partie) soyez prêt à présenter / recevoir des données réelles. C'est le "Lorem Ipsum" d'un programmeur.

La base de données des employés n'est pas prête? Créez-en un simple avec Jane Doe, John Doe ... etc. L'API n'est pas prête? Créez un faux en créant un fichier .json statique contenant de fausses données.

Dans ce contexte, le mot «stub» est utilisé à la place de «mock», mais pour des raisons de clarté et de précision, l'auteur aurait dû utiliser «mock», car «mock» est une sorte de stub, mais pour des tests. Pour éviter toute confusion supplémentaire, nous devons définir ce qu'est un stub.

Dans le contexte général, un stub est un morceau de programme (généralement une fonction ou un objet) qui encapsule la complexité de l'appel d'un autre programme (généralement situé sur une autre machine, VM ou processus - mais pas toujours, il peut également être un objet). Étant donné que le programme réel à appeler ne se trouve généralement pas sur le même espace mémoire, son appel nécessite de nombreuses opérations telles que l'adressage, l'exécution de l'appel à distance réel, le rassemblement / la sérialisation des données / arguments à transmettre (et de même avec le résultat potentiel), peut-être même traitant d'authentification / sécurité, et ainsi de suite. Notez que dans certains contextes, les stubs sont également appelés proxies (comme les proxies dynamiques en Java).

Une maquette est un type de stub très spécifique et restrictif, car une maquette est un remplacement d'une autre fonction ou d'un autre objet à tester. Dans la pratique, nous utilisons souvent des simulations comme programmes locaux (fonctions ou objets) pour remplacer un programme distant dans l'environnement de test. Dans tous les cas, la maquette peut simuler le comportement réel du programme remplacé dans un contexte restreint.

Les types de stubs les plus connus sont évidemment destinés à la programmation distribuée, lorsqu'il est nécessaire d'appeler des procédures distantes ( RPC ) ou des objets distants ( RMI , CORBA ). La plupart des frameworks / bibliothèques de programmation distribués automatisent la génération de stubs afin que vous n'ayez pas à les écrire manuellement. Les stubs peuvent être générés à partir d'une définition d'interface, écrite avec IDL par exemple (mais vous pouvez également utiliser n'importe quel langage pour définir des interfaces).

En règle générale, dans RPC, RMI, CORBA, etc., on distingue les stubs côté client , qui prennent principalement en charge le marshaling / sérialisation des arguments et l'exécution de l'invocation à distance, et les stubs côté serveur , qui prennent principalement en charge le démarshaling / désérialisation. les arguments et exécutez réellement la fonction / méthode distante. De toute évidence, les stubs clients sont situés du côté client, tandis que les stubs de serveurs (souvent appelés squelettes) sont situés du côté serveur.

Écrire de bons stubs efficaces et génériques devient assez difficile lorsqu'il s'agit de références d'objets. La plupart des frameworks d'objets distribués tels que RMI et CORBA traitent des références d'objets distribués, mais c'est quelque chose que la plupart des programmeurs évitent dans les environnements REST par exemple. En règle générale, dans les environnements REST, les programmeurs JavaScript créent des fonctions stub simples pour encapsuler les appels AJAX (la sérialisation des objets étant prise en charge par JSON.parseet JSON.stringify). Le projet Swagger Codegen fournit un support étendu pour la génération automatique de stubs REST dans différentes langues.

Stub est une définition de fonction qui a le nom de fonction correct, le nombre correct de paramètres et produit un résultat factice du type correct.

Il aide à écrire le test et sert en quelque sorte d'échafaudage pour permettre d'exécuter les exemples avant même que la conception de la fonction ne soit terminée

Vous disposez également d'un très bon framework de test pour créer un tel stub. Un de mes préférés est Mockito Il y a aussi EasyMock et d'autres ... Mais Mockito est génial, vous devriez le lire - package très élégant et puissant

Cette phrase est presque certainement une analogie avec une phase de la construction d'une maison - «écraser» la plomberie. Pendant la construction, alors que les murs sont encore ouverts, la plomberie brute est mise en place. Ceci est nécessaire pour que la construction se poursuive. Ensuite, lorsque tout autour est suffisamment prêt, on revient et ajoute des robinets et des toilettes et le produit final. (Voir par exemple Comment installer un raccord de plomberie .)

Lorsque vous "stub out" une fonction en programmation, vous en créez suffisamment pour la contourner (pour tester ou pour écrire un autre code). Ensuite, vous revenez plus tard et le remplacez par l'implémentation complète.

Stubs RPC

• Fondamentalement, un stub côté client est une procédure qui regarde le client comme s'il s'agissait d'une procédure serveur appelable.
• Un stub côté serveur regarde le serveur comme s'il s'agissait d'un client appelant.
• Le programme client pense qu'il appelle le serveur; en fait, il appelle le stub client.
• Le programme serveur pense qu'il est appelé par le client; en fait, il est appelé par le stub du serveur.
• Les stubs s'envoient des messages pour que le RPC se produise.

La source

"Stubbing-out une fonction signifie que vous n'écrirez que suffisamment pour montrer que la fonction a été appelée, laissant les détails pour plus tard lorsque vous aurez plus de temps."

De: SAMS Teach yourself C ++, Jesse Liberty et Bradley Jones