Menu

Top 15 des questions d'entrevue Specflow populaires

top 15 popular specflow interview questions

Essayez Notre Instrument Pour Éliminer Les Problèmes

Questions et réponses les plus fréquemment posées lors des entretiens avec Specflow:

Notre précédent tutoriel Specflow a présenté Comment générer des rapports de test et exécuter des tests sélectifs .

Dans ce didacticiel, nous examinerons les questions d'entrevue Specflow les plus populaires avec leurs réponses.

Lisez le Série complète de formations Specflow pour une compréhension facile du concept. Specflow est un outil prenant en charge les pratiques BDD dans le framework .NET. C'est un framework open-source hébergé sur GitHub. Il aide à utiliser ATDD (Acceptance Test Driver Development) pour .NET.

Questions d

Principales questions et réponses des entretiens Specflow

Vous trouverez ci-dessous les questions d'entrevue Specflow les plus populaires avec des réponses et des exemples pour faciliter votre compréhension.

Q # 1) Quelle est la différence entre le fichier d'entités et les fichiers de liaison?

Répondre: L'écriture de tests BDD dans Specflow comporte 2 composants principaux, à savoir

  1. Fichiers de fonctionnalités: Qui contiennent les tests écrits sous forme de scénarios en langage spécifique au domaine (DSL) et sont essentiellement des fichiers en anglais simple qui sont adaptés et compréhensibles pour toutes les parties prenantes du projet. En réalité, ce sont les fichiers de test réels et sont interprétés à travers les liaisons ou les définitions d'étape.
  2. Liaisons d'étape: Ces fichiers de code sont la logique d'intelligence réelle derrière l'exécution des tests. Chaque étape d'un scénario (qui fait partie d'un fichier d'entités) est liée à un fichier de définition d'étape qui s'exécute réellement lorsque le test est exécuté.

Par conséquent, une combinaison de fichiers de fonctionnalités et de définitions d'étape ou de liaisons permet à Specflow (ou à tout autre cadre BDD) d'exécuter les tests.

Q # 2) Qu'est-ce que BDD et en quoi est-il différent de TDD ou ATDD?

Répondre: Ces trois termes, à savoir BDD, TDD et ATDD, sont quelque peu liés au développement piloté par les tests en général, mais ils sont en effet différents à bien des égards.

  1. TDD: TDD crée essentiellement des tests du point de vue d'un développeur. En termes simples, il s’agit d’un ensemble de tests qu’un développeur écrit pour que son code réussisse (ou échoue). C'est essentiellement une technique pour faire échouer votre code jusqu'à ce que toutes les exigences spécifiques soient satisfaites. Il suit essentiellement un cycle de refactorisation du code jusqu'à ce que les tests soient tous verts.
  2. BDD: BDD est étroitement lié au TDD, mais est plus pertinent d'un point de vue «extérieur-intérieur», ce qui signifie en fait que les tests BDD sont davantage liés aux exigences métier / produit et définissent le comportement souhaité du système sous la forme de scénarios. TDD en revanche traite à un niveau de tests unitaires plus granulaire. En outre, les spécifications BDD sont généralement du texte anglais simple qui est facile à comprendre et permet une plus grande collaboration entre toutes les parties prenantes du projet.
  3. ATDD: Le développement piloté par les tests d’acceptation se concentre davantage sur la perspective de l’acceptation de l’utilisateur. Ces tests définissent également le comportement du client, mais du point de vue de l’intégration ou du produit final où le cas d’utilisation final d’un client est converti en un scénario de test et tout le travail de développement est concentré pour répondre à ces exigences.

Q # 3) Que contient le fichier généré automatiquement pour la fonction Specflow?

Répondre: Les fichiers code-behind Specflow sont des fichiers générés automatiquement avec une extension «.cs». Ces fichiers ont la logique de liaison des étapes à la définition de l'étape réelle.

Quelques points concernant les fichiers générés automatiquement sont:

  • Ces fichiers ne doivent pas être modifiés ou édités manuellement. Même si vous essayez de le faire, les modifications ne sont pas enregistrées.
  • Après chaque modification dans le fichier de fonctionnalités, le compilateur recrée ce fichier pour capturer les mises à jour.

Q # 4) Comment les liaisons d'étape sont-elles réparties entre les différents fichiers source accessibles?

Répondre: Les fichiers de liaison d'étape peuvent être réutilisés même s'ils existent dans des fichiers source séparés et la correspondance de liaison se produit via une expression régulière.

Les fichiers de liaisons d'étapes sont essentiellement des classes partielles attribuées par (Obligatoire) attribut. Cela garantit que toutes les liaisons d'étapes sont disponibles globalement et peuvent être utilisées avec les étapes de scénario dans des fichiers de fonctionnalités différents ou identiques.

Q # 5) Comment les implémentations de liaison d'étape ambiguës peuvent-elles être résolues?

Répondre: Specflow fournit un mécanisme pour éviter l'implémentation ambiguë de la liaison Step à l'aide d'un concept appelé Liaisons étendues.

Cela est utile dans les scénarios où vous avez des étapes similaires dans des scénarios dans des fichiers de fonctionnalités identiques ou différents et si vous souhaitez traiter les deux étapes différemment.

questions et réponses d'entrevue de services Web pour expérimentés

Dans un scénario normal, comme toutes les correspondances d'étapes se produisent via Regex, et que c'est une correspondance gourmande, vous devrez vous assurer d'écrire un texte légèrement différent (afin qu'ils ne correspondent pas à la même implémentation) pour les étapes même si elles ont un impact lisibilité.

À l'aide des liaisons étendues, vous pouvez spécifier des balises avec une implémentation de liaison particulière ou le fichier de liaison entier et vous assurer que la correspondance dispose également d'un filtre de catégorie supplémentaire.

Les étapes à suivre sont répertoriées ci-dessous:

à) Marquer le scénario avec une catégorie en utilisant la syntaxe - @Étiqueter. Exemple: Nous étiquetons le scénario ci-dessous avec le tag - @scopedBinding

@scopedBinding Scenario: Youtube should search for the given keyword and should navigate to search results page Given I have navigated to youtube website And I have entered India as search keyword When I press the search button Then I should be navigate to search results page

b) Maintenant, utilisez la même balise sur la liaison d'étape, ce qui garantira qu'en plus de la correspondance regex, la correspondance de balise ou de catégorie a également lieu (et garantit que les autres étapes ne correspondent pas à cette implémentation même si la correspondance regex est réussie)

Dans l'exemple ci-dessus, nous voulons étendre la liaison pour l'étape. ' Et j'ai entré l'Inde comme mot-clé de recherche ”, Nous ajouterons l'attribut Scope avec le paramètre Scoping comme balise.

(Given(@'I have entered (.*) as search keyword'), Scope(Tag ='scopedBinding')) public void GivenIHaveEnteredIndiaAsSearchKeyword(String searchString) { // step binding implementation }

Semblable à la portée avec balise, il est également possible d'avoir des liaisons étendues avec des titres de fonctionnalité et de scénario.

Q # 6) Comment le contexte de test peut-il être stocké lors de l'exécution de différents scénarios?

Répondre: Le contexte de test peut être stocké en utilisant différentes approches lors de l'exécution de tests specflow et chaque approche a ses avantages et ses inconvénients.

  1. Utilisation de ScenarioContext et FeatureContext: Considérez FeatureContext et ScenarioContext comme un dictionnaire global de paires clé-valeur et est accessible pendant l'exécution des fonctionnalités et l'exécution du scénario respectivement. Le champ de valeur peut stocker n'importe quel type d'objet et pendant la récupération, il doit être converti dans l'objet comme vous le souhaitez.
  2. Utilisation des champs dans les fichiers de liaison: Cette approche permet de partager le contexte entre les implémentations de liaison dans des fichiers de liaison identiques et / ou différents dans le même espace de noms. Il n’est pas différent de conserver l’état à l’aide de variables de classe et peut être défini ou récupéré entre les implémentations de liaison selon les besoins.
  3. En utilisant le propre framework DI de Specflow: Specflow fournit un cadre d'injection de contexte et peut être utilisé pour transmettre le contexte sous la forme de classes / objets POCO simples. Les objets / classes de contexte peuvent être injectés via des champs de constructeur et peuvent être passés le long de différents fichiers de liaison Step.

Voir un exemple ci-dessous ayant 2 objets injectés via l'injection de constructeur.

(Binding) public class StepImplementationClass { private readonly Context1 _context1; private readonly Context2 _context2; public YoutubeSearchFeatureSteps(Context1 context1, Context2 context2) { _context1 = context1; _context2 = context2; } }

Q # 7) Quelles sont les limitations de Specflow ou BDD en général?

Répondre: BDD, comme son nom l'indique, définit le comportement avec l'application qui convertit essentiellement les cas d'utilisation en scénarios de test.

Par conséquent, l'absence de parties prenantes telles qu'une entreprise, un produit et / ou des clients pourrait avoir un impact sur les spécifications réelles pour lesquelles les développeurs vont mettre en œuvre des tests d'écriture et par conséquent, cela pourrait entraîner de ne pas fournir la valeur réelle de ce qu'elle aurait pu fournir et que toutes les parties prenantes étaient disponibles lors de la définition des scénarios.

Cela dit, la plupart du temps, les pros déjouent les inconvénients de BDD et constituent vraiment une technique très utile pour tester / valider les spécifications. Comme il est plus ou moins indépendant du langage puisqu'il existe des frameworks BDD disponibles pour presque tous les principaux langages de programmation tels que Cucumber pour Java, RSpec pour Ruby et Specflow pour .NET.

Q # 8) Que sont les transformations d'argument d'étape?

Répondre: Les transformations d'argument comme son nom l'indique ne sont rien d'autre qu'une transformation de l'étape du scénario.

Considérez-le comme une couche supplémentaire de correspondance qui se produit avant que la correspondance de liaison d'étape réelle ne se produise, et cela peut être utile pour transformer un type différent d'entrée utilisateur plutôt que d'avoir différentes implémentations d'étapes individuelles pour le même type d'entrée.

Pour toute étape de transformation, l'attribut requis est ÉtapeArgumentTransformation

Par exemple, reportez-vous à l'exemple de code ci-dessous:

Given I have entered 50 days into the timestamp to minute converter Given I have entered 1 day, 2 hours, 3 minutes into the timestamp to minute converter Given I have entered 1 day, 1 hour, 1 minute, 30 seconds into the timestamp to minute converter

En référence à l'exemple de code ci-dessus, les trois étapes sont liées. Mais, si cela avait été par le biais de la correspondance habituelle de regex, alors vous seriez obligé d'écrire trois implémentations d'étapes différentes.

Avec les transformations d'argument Step en place, il est possible de transformer les valeurs et de créer un Horodatage objet des paramètres spécifiés et revenir à l'implémentation de l'étape d'origine.

Examinons la mise en œuvre de la transformation.

(StepArgumentTransformation(@'(?:(d*) day(?:s)?(?:, )?)?(?:(d*) hour(?:s)?(?:, )?)?(?:(d*) minute(?:s)?(?:, )?)?(?:(d*) second(?:s)?(?:, )?)?')) public TimeSpan convertToTimeSpan(String days, String hours, String minutes, String seconds) { // timestamp conversion logic }

Ainsi, nous transformons ici l'entrée de scénario en une valeur intermédiaire (comme TimeStamp) et renvoyons la valeur transformée à l'implémentation de liaison réelle, comme illustré dans l'exemple ci-dessous.

(Given(@'I have entered (.*) into the timestamp to minute converter')) public void GivenIHaveEnteredDaysIntoTheTimestampToMinuteConverter(TimeSpan tsTransformed) { // binding implementation }

Notez comment la valeur transformée de type TimeSpan est maintenant renvoyée à la méthode d'implémentation de liaison Step réelle.

Q # 9) Quels sont les différents types de hooks fournis par Specflow?

Répondre:

Specflow fournit beaucoup de Hooks personnalisés ou d'événements spéciaux avec lesquels les gestionnaires d'événements (essentiellement des méthodes / fonctions) peuvent être liés pour exécuter une logique de configuration / suppression.

Specflow fournit les hooks suivants:

  1. AvantFeature / AfterFeature: L'événement déclenché avant et après le démarrage de la fonctionnalité et la fin de l'exécution respectivement.
  2. BeforeScenario / AfterScenario: L'événement déclenché avant et après l'exécution d'un scénario démarre et se termine respectivement.
  3. BeforeScenarioBlock / AfterScenarioBlock: L'événement déclenché avant et après un bloc de scénario, c'est-à-dire lorsque l'un des blocs de scénario appartenant à «Donné», «Quand» ou «Alors» démarre ou se termine.
  4. BeforeStep / AfterStep: L'événement déclenché avant et après chaque étape du scénario.
  5. BeforeTestRun / AfterTestRun: Cet événement est déclenché une seule fois pendant toute l'exécution du test et une fois après la fin de l'exécution du test.

Il est important de noter ici que ces événements sont déclenchés par défaut et sont gérés si et seulement si des liaisons sont fournies pour ces hooks. De plus, il n'est pas obligatoire d'implémenter ces crochets par paires et chaque crochet peut exister indépendamment les uns des autres.

Q # 10) En quoi ScenarioContext est-il différent de FeatureContext?

Répondre: ScenarioContext et FeatureContext sont des classes statiques fournies par le framework Specflow et sont vraiment utiles pour effectuer des tâches telles que la transmission d'informations entre les liaisons, l'obtention d'informations importantes telles que le contexte d'exécution de la fonctionnalité / scénario, etc.

Voyons en quoi les deux diffèrent:

Comme son nom l'indique, ScenarioContext fournit des données ou des informations au niveau de l'exécution du scénario tandis que FeatureContext traite les choses au niveau de la fonctionnalité.

En termes simplistes, tout ce qui est stocké dans featureContext sera disponible pour tous les scénarios présents dans ce fichier de fonctionnalités tandis que ScenarioContext ne sera disponible que pour les liaisons jusqu'à ce que l'exécution du scénario de temps soit en cours.

Q # 11) Quelle est l'importance de l'ordre du donné, quand et alors?

Répondre: Specflow n'impose aucune restriction sur l'ordre des Donné, quand et alors . Il s'agit davantage du séquençage logique d'un scénario de test et de toute pratique de test en général, c'est-à-dire comme dans les tests unitaires, nous suivons généralement trois A pour ' Organiser, agir et affirmer ».

Donc, pour les scénarios specflow, il n'y a aucune restriction sur la commande et cela n'impose pas non plus que les trois sections soient présentes.

Souvent, la configuration peut être minimaliste et peut même ne pas être nécessaire. Par conséquent, pour ces scénarios, vous pouvez simplement ignorer le ' Donné 'Bloquer et démarrer le scénario avec le' Quand ' bloquer.

Q # 12) Que sont ScenarioInfo et FeatureInfo?

Répondre: SpecflowContext et FeatureContext fournissent en outre des classes statiques imbriquées, à savoir ScenarioInfo et FeatureInfo.
ScenarioInfo donne accès aux informations relatives au scénario en cours d'exécution.

Certaines des choses que vous pouvez apprendre avec ce cours sont données ci-dessous:

  1. Titre: Le titre du scénario. Syntaxe: ScenarioContext.Current.ScenarioInfo.Title
  2. Mots clés: Liste des balises sous forme de Chaîne de caractères(). Syntaxe: ScenarioContext.Current.ScenarioInfo.Tags

S imilar à ScenarioInfo, FeatureInfo fournit également des informations relatives à la fonctionnalité en cours d'exécution.

En plus du titre et des balises, il fournit également d'autres éléments utiles tels que la langue cible pour laquelle le code de fonctionnalité derrière le fichier génère du code, les détails de la langue dans laquelle le fichier de fonctionnalités est écrit, etc.

La syntaxe pour obtenir des valeurs pour FeatureInfo reste la même que ScenarioInfo comme ci-dessous:
FeatureContext.Current.FeatureInfo

comment puis-je devenir testeur de produits

Q # 13) Différence entre les tableaux Outline de scénario et Specflow.

Répondre:

Scénario est essentiellement un moyen d'exécuter des scénarios basés sur les données à l'aide de Specflow où une liste d'entrées est fournie dans le Exemples dans le scénario, et le scénario s'exécute une fois chacun selon le nombre d'exemples fournis.

Consultez un exemple de code ci-dessous pour le comprendre plus clairement.

Scenario Outline: Youtube keyword search And I have entered as search keyword When I press the search button Then I should be navigate to search results page Examples: | searchTerm | | India | | America

Les tables sont simplement des moyens de fournir des données tabulaires avec n'importe quelle étape du scénario et sont passées en tant qu'argument de table Specflow dans l'implémentation de l'étape qui peut être ultérieurement analysée au type d'objet souhaité selon les besoins.

Veuillez vous référer à la section 'gras' de l'exemple de code ci-dessous pour plus de détails:

Scenario: Pass data through Specflow tables for StudentInfo object Given I have entered following info for Student | FirstName | LastName | Age | YearOfBirth | | test | student | 20 | 1995 | When I press add Then i student should get added to database and entered info should be displayed on the screen

Similaire à l'attribut Tags - vous pouvez utiliser toutes les informations fournies par ScenarioInfo pour contrôler le flux d'exécution de toute implémentation d'étape.

Q # 14) Contrôle de l'exécution du test via ScenarioInfo.

Semblable aux liaisons de portée, qui peuvent permettre d'ajouter un critère de filtre supplémentaire tout en faisant correspondre la définition d'étape via des balises, vous pouvez également tirer parti du contrôle de l'exécution du test via les informations fournies avec ScenarioInfo.

Par exemple, Vous avez 2 scénarios avec des balises, à savoir @ tag1 et @ tag2 et les deux contiennent la même définition d'étape. Vous devez maintenant ajouter une logique personnalisée en fonction des balises de scénario.

Ainsi dans l'implémentation de la définition d'étape, vous pouvez simplement obtenir toutes les balises associées à un scénario en utilisant ScenarioContext.Current.ScenarioInfo.Tags et vérifiez la présence d'une balise dans le scénario en cours d'exécution et décidez quel code vous voulez exécuter.

Reportez-vous à l'exemple de code ci-dessous pour une meilleure compréhension:

(When(@'I press add')) public void WhenIPressAdd() { String() tags = ScenarioContext.Current.ScenarioInfo.Tags; String expectedTag = 'tag1'; if(tags.Any(s => s == expectedTag)) { // do something } else { // do something else } }

Similaire à l'attribut Tags - vous pouvez utiliser toutes les informations fournies par ScenarioInfo pour contrôler le flux d'exécution de toute implémentation d'étape.

Q # 15) Comment les tests Specflow peuvent-ils être exécutés dans une configuration d'intégration continue?

Répondre:

Avec les méthodologies de développement de logiciels modernes, l'intégration continue est une sorte de mot à la mode et est généralement appelée un ensemble de pratiques, où chaque engagement sur le code source est considéré comme un candidat pour la sortie de production.

Par conséquent, chaque validation déclenche essentiellement différents types de tests en tant que portes de qualité pour garantir que la modification validée n'entraîne pas l'échec ou la rupture des tests.

Specflow - comme nous le savons, s'intègre très bien aux frameworks connus tels que NUnit et MSUnit et peut être exécuté facilement via les applications console de ces frameworks de test étant donné la DLL du projet compilé qui a des fonctionnalités Specflow et des implémentations d'étapes.

Par conséquent, afin de réaliser des tests Specflow exécutés dans le cadre d'une configuration d'intégration continue, voici une liste d'étapes de haut niveau pouvant être suivies:

#1) Compilez le projet contenant la fonctionnalité Specflow et la définition d'étape pour obtenir une DLL compilée.

#deux) Maintenant, utilisez les exécuteurs de console NUnit ou MSUnit et fournissez la DLL compilée comme source de test (ces frameworks fournissent d'autres fonctionnalités ainsi que des filtres de test en fonction des catégories, etc.).

Cette étape peut être intégrée au pipeline d'intégration continue et peut être exécutée via un script shell ou DOS avec l'outil CI comme Jenkins ou Bamboo, etc.

# 3) Une fois l'exécution du test terminée, le rapport de sortie généré (qui est spécifique à l'exécuteur de console utilisé), peut être converti en un rapport HTML plus lisible en utilisant Specrun l'exécutable est disponible dans le cadre de NugetPackage.

Cette étape peut également être exécutée via la ligne de commande qui est fournie par tous les principaux frameworks d'intégration continue.

# 4) Une fois l'étape ci-dessus terminée, nous sommes prêts avec le rapport des tests exécutés et les métriques résumées des détails d'exécution des tests.

Nous espérons que vous avez apprécié la gamme complète de didacticiels de cette série de formation Specflow. Cette série de tutoriels serait en effet le meilleur guide pour toute personne débutante ou expérimentée qui souhaite enrichir ses connaissances sur Specflow!

Tutoriel PREV OURevenir à la PREMIER Tutoriel

lecture recommandée

^