Menu

Top 15 populaire interviewvragen over Specflow

  • Hoofd
  • Andere
  • Top 15 populaire interviewvragen over Specflow

top 15 popular specflow interview questions

hoe je een xml-bestand opent in chrome

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Meest gestelde vragen en antwoorden over Specflow-interviews:

Onze vorige Specflow-zelfstudie bevatte informatie Testrapporten genereren en selectieve tests uitvoeren ​

In deze zelfstudie bekijken we de meest populaire Specflow-interviewvragen, samen met hun antwoorden.

Lees het Volledige Specflow-trainingsreeks voor een gemakkelijk begrip van het concept. Specflow is een tool die BDD-praktijken in het .NET-framework ondersteunt. Het is een open-sourceframework dat wordt gehost op GitHub. Het helpt bij het gebruik van ATDD (Acceptance Test Driver Development) voor .NET.

Specflow interviewvragen

Top Specflow interviewvragen en antwoorden

Hieronder vindt u de meest populaire Specflow-interviewvragen met antwoorden en voorbeelden zodat u ze gemakkelijk kunt begrijpen.

Q # 1) Wat is het verschil tussen het feature-bestand en de bind-bestanden?

Antwoord: Het schrijven van BDD-tests in Specflow heeft 2 hoofdcomponenten, namelijk

  1. Functiebestanden: Die de tests bevatten die zijn geschreven als scenario's in domeinspecifieke taal (DSL) en in wezen gewone Engelse bestanden zijn die geschikt en begrijpelijk zijn voor alle belanghebbenden van het project. In werkelijkheid zijn het de daadwerkelijke testbestanden en worden ze geïnterpreteerd via de bindingen of stapdefinities.
  2. Step Bindingen: Deze codebestanden zijn de feitelijke intelligentielogica achter testuitvoering. Elke stap in een scenario (dat deel uitmaakt van het feature-bestand) bindt aan een Step-definitiebestand dat daadwerkelijk wordt uitgevoerd wanneer de test wordt uitgevoerd.

Daarom maakt een combinatie van zowel Feature-bestanden als Step-definitie of -bindingen het mogelijk voor Specflow (of een ander BDD) framework om de tests uit te voeren.

Q # 2) Wat is BDD en hoe verschilt het van TDD of ATDD?

Antwoord: Al deze drie termen, d.w.z. BDD, TDD en ATDD, zijn enigszins gerelateerd aan Test Driven Development in het algemeen, maar ze verschillen inderdaad op veel manieren

  1. TDD: TDD maakt in feite tests vanuit het perspectief van een ontwikkelaar. In eenvoudige bewoordingen is het een reeks tests die een ontwikkelaar schrijft om zijn code te laten slagen (of te mislukken). Het is in wezen een techniek om uw code te laten mislukken totdat aan alle specifieke vereisten is voldaan. Het volgt in feite een refactorcyclus voor code totdat de tests allemaal groen zijn.
  2. BDD: BDD hangt nauw samen met TDD, maar is relevanter vanuit een 'outside-in'-perspectief, wat eigenlijk betekent dat BDD-tests meer gebonden zijn aan bedrijfs- / productvereisten en het gewenste gedrag van het systeem definiëren in de vorm van scenario's. TDD daarentegen handelt op meer granulair niveau van eenheidstests. Bovendien zijn BDD-specificaties over het algemeen gewone Engelse tekst die gemakkelijk te begrijpen is en een betere samenwerking tussen alle belanghebbenden van het project mogelijk maakt.
  3. ATDD: De focus van Acceptance Test-Driven Development ligt meer vanuit het acceptatieperspectief van de gebruiker. Deze tests bepalen ook het klantgedrag, maar vanuit het oogpunt van integratie of eindproduct, waarbij de uiteindelijke use case van een klant wordt omgezet in een testscenario en al het ontwikkelingswerk is gericht op het voldoen aan deze vereisten.

V # 3) Wat staat er in het automatisch gegenereerde bestand voor de Specflow-functie?

Antwoord: Specflow code-behind bestanden zijn automatisch gegenereerde bestanden met een '.cs' extensie. Deze bestanden hebben de bindingslogica van Steps tot de daadwerkelijke Step-definitie.

Enkele punten met betrekking tot de automatisch gegenereerde bestanden zijn:

  • Deze bestanden mogen niet handmatig worden gewijzigd of bewerkt. Zelfs als u dit probeert, worden de wijzigingen niet opgeslagen.
  • Na elke wijziging in het feature-bestand, genereert de compiler dit bestand opnieuw om updates vast te leggen.

V # 4) Hoe worden step-bindingen verspreid over verschillende bronbestanden benaderd?

Antwoord: Step-binding-bestanden kunnen worden hergebruikt, zelfs als ze in afzonderlijke bronbestanden bestaan ​​en het matchen van binding gebeurt via een regex.

De step bindings-bestanden zijn in wezen gedeeltelijke klassen die worden toegeschreven door (Verbindend) attribuut. Dit zorgt ervoor dat alle step-bindingen wereldwijd beschikbaar zijn en kunnen worden gebruikt met Scenario Steps in verschillende of dezelfde feature-bestanden.

V # 5) Hoe kunnen dubbelzinnige implementaties van step-binding worden opgelost?

Antwoord: Specflow biedt een mechanisme om dubbelzinnige implementatie van Step-binding te voorkomen met behulp van een concept genaamd Scoped bindingen.

Dit is handig in scenario's waarin u vergelijkbare stappen in scenario's hebt in dezelfde of verschillende feature-bestanden en als u beide stappen anders wilt behandelen.

In een normaal scenario, aangezien alle stapafstemming plaatsvindt via Regex en het een hebzuchtige overeenkomst is, moet u ervoor zorgen dat u een iets andere tekst schrijft (zodat ze niet overeenkomen met dezelfde implementatie) voor stappen, ook al hebben ze invloed op leesbaarheid.

Met Scoped Bindings kunt u tags specificeren met een bepaalde bindingsimplementatie of het volledige bindingsbestand en ervoor zorgen dat de overeenkomst ook een extra filter van categorie heeft.

De stappen die moeten worden gevolgd, staan ​​hieronder vermeld:

naar) Tag het scenario met een categorie met behulp van de syntaxis - @Label. Voorbeeld: We taggen het onderstaande scenario met de tag - @scopedBinding

​

b) Gebruik nu dezelfde tag op de step-binding die ervoor zorgt dat naast regex-match ook de tag- of categorie-match plaatsvindt (en zorgt ervoor dat andere stappen niet overeenkomen met deze implementatie, zelfs als regex-match succesvol is)

In het bovenstaande voorbeeld willen we de binding voor de stap bepalen.​ En ik heb India ingevoerd als zoekwoord ”, Zullen we het Scope-attribuut met Scoping-parameter als de tag toevoegen.

​

Net als bij scoping met tags, is het ook mogelijk om scoped-bindingen te hebben met Feature- en Scenario-titels.

V # 6) Hoe kan testcontext worden opgeslagen terwijl verschillende scenario's worden uitgevoerd?

Antwoord: De testcontext kan worden opgeslagen met behulp van verschillende benaderingen tijdens het uitvoeren van specflow-tests en elke benadering heeft zijn voor- en nadelen.

  1. ScenarioContext en FeatureContext gebruiken: Beschouw FeatureContext en ScenarioContext als een globaal woordenboek van sleutel-waardeparen dat toegankelijk is tijdens respectievelijk uitvoering van functies en uitvoering van scenario's. Het waardeveld kan elk type object opslaan en tijdens het ophalen moet het naar wens in het object worden gegoten.
  2. Velden gebruiken in bindende bestanden: Deze benadering maakt het mogelijk om context te delen tussen bindingsimplementaties in dezelfde en / of verschillende bindingsbestanden in dezelfde naamruimte. Het is niet anders bij het behouden van de status met behulp van klassevariabelen en kan indien nodig worden ingesteld of opgehaald voor bindende implementaties.
  3. Specflows eigen DI-framework gebruiken: Specflow biedt een kader voor contextinjectie en kan worden gebruikt om context door te geven in de vorm van Simple POCO-klassen / -objecten. De contextobjecten / klassen kunnen worden geïnjecteerd via constructorvelden en kunnen worden doorgegeven aan verschillende Step-bindende bestanden.

Zie een voorbeeld hieronder met 2 objecten geïnjecteerd via constructorinjectie.

​

V # 7) Wat zijn de beperkingen van Specflow of BDD in het algemeen?

Antwoord: BDD definieert, zoals de naam zelf aangeeft, het gedrag van de applicatie die in wezen use cases omzet in testscenario's.

Daarom kan de afwezigheid van belanghebbenden zoals een bedrijf, product en / of klanten van invloed zijn op de feitelijke specificaties waarvoor de ontwikkelaars schrijftests gaan implementeren en daarom kan het ertoe leiden dat niet de werkelijke waarde wordt geboden die het had kunnen leveren en dat alle belanghebbenden waren beschikbaar bij het definiëren van de scenario's.

Dat gezegd hebbende, zijn pro's meestal de nadelen van BDD te slim af en is het echt een zeer nuttige techniek om de specificaties te testen / valideren. Omdat het min of meer taalonafhankelijk is, omdat er BDD-frameworks beschikbaar zijn voor bijna alle belangrijke programmeertalen, zoals Cucumber voor Java, RSpec voor Ruby en Specflow voor .NET.

V # 8) Wat zijn stapargumenttransformaties?

Antwoord: Argumenttransformaties, zoals de naam al aangeeft, zijn niets anders dan het transformeren van de scenariostap.

Zie het als een extra aanpassingslaag die plaatsvindt voordat de daadwerkelijke stapbindingovereenkomst plaatsvindt, en het kan nuttig zijn om een ​​ander soort gebruikersinvoer te transformeren in plaats van verschillende individuele stapimplementaties te hebben voor hetzelfde type invoer.

Voor elke transformatiestap is het vereiste kenmerk StepArgumentTransformation

Raadpleeg bijvoorbeeld het onderstaande codevoorbeeld:

​

Verwijzend naar het codevoorbeeld hierboven, zijn alle drie de stappen gerelateerd. Maar als het de gebruikelijke regex-matching had doorlopen, zou u drie verschillende stapimplementaties moeten schrijven.

Met Step-argumenttransformaties is het mogelijk om de waarden te transformeren en een TimeStamp object uit de opgegeven parameters en keer terug naar de oorspronkelijke stapimplementatie.

Laten we eens kijken naar de implementatie van de transformatie.

​

Dus hier transformeren we de scenario-invoer naar een tussenliggende waarde (zoals TimeStamp) en keren we de getransformeerde waarde terug naar de daadwerkelijke bindende implementatie, zoals weergegeven in het onderstaande voorbeeld.

​

Merk op hoe de getransformeerde waarde van het type TimeSpan nu wordt teruggestuurd naar de daadwerkelijke Step-bindende implementatiemethode.

V # 9) Wat zijn de verschillende soorten haken die door Specflow worden geleverd?

Antwoord:

Specflow biedt veel aangepaste hooks of speciale gebeurtenissen waarmee de gebeurtenishandlers (in wezen methoden / functies) kunnen worden gebonden om bepaalde setup / demontagelogica uit te voeren.

Specflow biedt de volgende hooks:

  1. BeforeFeature / AfterFeature: De gebeurtenis die voor en na de functie wordt opgewekt, start en voltooit de uitvoering respectievelijk.
  2. BeforeScenario / AfterScenario: De gebeurtenis die is opgetreden voor en na de uitvoering van een scenario, start en eindigt respectievelijk.
  3. BeforeScenarioBlock / AfterScenarioBlock: De gebeurtenis die zich voordoet voor en na een scenarioblok, d.w.z. wanneer een van de scenarioblokken behorende bij 'Gegeven', 'Wanneer' of 'Dan' start of voltooit.
  4. BeforeStep / AfterStep: De gebeurtenis deed zich voor en na elke stap van het scenario voor.
  5. BeforeTestRun / AfterTestRun: Deze gebeurtenis wordt slechts één keer gegenereerd tijdens de volledige testuitvoering en één keer nadat de testuitvoering is voltooid.

Het is belangrijk om hier op te merken dat deze gebeurtenissen standaard worden geactiveerd, en alleen worden afgehandeld als er bindingen zijn voorzien voor deze hooks. Ook is het niet verplicht om deze haken paarsgewijs te implementeren en kan elke haak onafhankelijk van elkaar bestaan.

V # 10) Waarin verschilt ScenarioContext van FeatureContext?

Antwoord: Zowel ScenarioContext als FeatureContext zijn statische klassen die worden geleverd door het Specflow-framework en zijn erg handig voor het uitvoeren van taken zoals het doorgeven van informatie tussen bindingen, het verkrijgen van belangrijke informatie zoals de uitvoeringscontext van een feature / scenario, enz.

Laten we eens kijken hoe beide verschillen:

Zoals de naam al aangeeft, biedt ScenarioContext gegevens of informatie op Scenario-uitvoeringsniveau, terwijl FeatureContext zaken op functieniveau behandelt.

Simpel gezegd, alles dat is opgeslagen in featureContext is beschikbaar voor alle scenario's die aanwezig zijn in dat feature-bestand, terwijl ScenarioContext alleen beschikbaar is voor alleen de bindingen totdat de uitvoering van het tijdscenario bezig is.

V # 11) Hoe belangrijk is de volgorde van gegeven, wanneer en dan?

Antwoord: Specflow legt geen enkele beperking op aan de volgorde van Gegeven, wanneer en dan ​Het gaat meer om de logische volgorde van een testscenario en elke testpraktijk in het algemeen, d.w.z. zoals bij unit-tests volgen we meestal drie A's die staan ​​voor ​ Schikken, handelen en beweren ​

Dus voor specflow-scenario's is er geen beperking op het bestellen en het vereist ook niet dat alle drie de secties aanwezig moeten zijn.

Vaak kan de opstelling minimalistisch zijn en misschien zelfs niet nodig zijn. Daarom kunt u voor die scenario's gewoon de ' Gegeven 'Blokkeer en start het scenario met de' Wanneer ”Blok.

V # 12) Wat zijn ScenarioInfo en FeatureInfo?

Antwoord: SpecflowContext en FeatureContext bieden verder geneste statische klassen, namelijk ScenarioInfo en FeatureInfo.
ScenarioInfo geeft toegang tot informatie over het scenario dat momenteel wordt uitgevoerd.

Enkele van de dingen die u met deze les kunt leren, worden hieronder weergegeven:

  1. Titel: De titel van het scenario. Syntaxis: ScenarioContext.Current.ScenarioInfo.Title
  2. Trefwoorden: Lijst met tags in de vorm van Draad(). Syntaxis: ScenarioContext.Current.ScenarioInfo.Tags

S vergelijkbaar met ScenarioInfo, FeatureInfo biedt ook informatie met betrekking tot de huidige functie die momenteel wordt uitgevoerd.

Naast titel en tags biedt het ook andere handige dingen, zoals wat de doeltaal is waarvoor de feature code - achter het bestand code genereert, de taaldetails waarin het Feature File is geschreven, etc.

De syntaxis om waarden voor FeatureInfo te verkrijgen blijft hetzelfde als ScenarioInfo, zoals hieronder:
FeatureContext.Current.FeatureInfo

hoe dat bestand in pdf te openen

Vraag 13) Verschil tussen scenario-overzicht en Specflow-tabellen.

Antwoord:

ScenarioOverzicht is in feite een manier om gegevensgestuurde scenario's uit te voeren met behulp van Specflow, waarbij een lijst met invoer wordt gegeven in het Voorbeelden sectie in het scenario, en het scenario wordt eenmaal uitgevoerd, afhankelijk van het aantal gegeven voorbeelden.

Bekijk hieronder een codevoorbeeld om het duidelijker te begrijpen.

​

Tabellen zijn slechts middelen om tabelgegevens te leveren met elke stap van het scenario en worden doorgegeven als Specflow-tabelargument in de stapimplementatie die later indien nodig kan worden geparseerd naar het gewenste objecttype.

Raadpleeg het gedeelte 'vetgedrukt' in het onderstaande codevoorbeeld voor meer informatie:

​

Vergelijkbaar met het kenmerk Tags - u kunt alle informatie van ScenarioInfo gebruiken om de uitvoeringsstroom van elke stapimplementatie te regelen.

Q # 14) Controle uitvoeren van test via ScenarioInfo.

Net als bij scope-bindingen, waarmee u een extra filtercriterium kunt toevoegen terwijl u de stapdefinitie via tags afstemt, kunt u ook gebruikmaken van het besturen van de testuitvoering via de informatie die wordt geleverd met ScenarioInfo.

Bijvoorbeeld, Je hebt 2 scenario's met tags, d.w.z. @ tag1 en @ tag2 en beide bevatten dezelfde stapdefinitie. Nu moet u aangepaste logica toevoegen, afhankelijk van de scenariotags.

Dus in de implementatie van de stapdefinitie kunt u eenvoudig alle tags ophalen die aan een scenario zijn gekoppeld met ScenarioContext.Current.ScenarioInfo.Tags en controleer op de aanwezigheid van een tag in het scenario dat wordt uitgevoerd en beslis welke code u wilt uitvoeren.

Raadpleeg het onderstaande codevoorbeeld voor een beter begrip:

​

Vergelijkbaar met het kenmerk Tags - u kunt alle informatie van ScenarioInfo gebruiken om de uitvoeringsstroom van elke stapimplementatie te regelen.

V # 15) Hoe kunnen Specflow-tests worden uitgevoerd in een configuratie met continue integratie?

Antwoord:

Met moderne softwareontwikkelingsmethodologieën is continue integratie een soort modewoord en wordt dit over het algemeen een reeks praktijken genoemd, waarbij elke toewijding aan de broncode wordt beschouwd als een kandidaat voor productierelease.

Daarom triggert elke commit in wezen verschillende soorten tests als kwaliteitspoorten om ervoor te zorgen dat de doorgevoerde wijziging er niet voor zorgt dat tests mislukken of breken.

Specflow - zoals we weten, integreert zeer goed met bekende frameworks zoals NUnit en MSUnit en kan gemakkelijk door de consoletoepassingen van deze testframeworks worden uitgevoerd, gezien de DLL van het gecompileerde project met Specflow-functies en stapimplementaties.

Om Specflow-tests te kunnen uitvoeren die worden uitgevoerd als onderdeel van een continue integratie-installatie, is het volgende een lijst met stappen op hoog niveau die kunnen worden gevolgd:

# 1) Compileer het project met de Specflow-functie en stapdefinitie om een ​​gecompileerde DLL te krijgen.

#twee) Gebruik nu NUnit- of MSUnit-consolerunners en geef de gecompileerde DLL als testbron (deze frameworks bieden andere mogelijkheden en bieden ook testfilters, afhankelijk van de categorieën enz.).

Deze stap kan worden geïntegreerd met de Continuous Integration-pijplijn en kan worden uitgevoerd via shell of DOS-script met de CI-tool zoals Jenkins of Bamboo enz.

# 3) Zodra de test is voltooid, kan het gegenereerde uitvoerrapport (dat specifiek is voor de gebruikte console-runner) worden geconverteerd naar een beter leesbaar HTML-rapport met Specrun executable is beschikbaar als onderdeel van NugetPackage.

Deze stap kan ook worden uitgevoerd via de opdrachtregel die standaard wordt geleverd door alle belangrijke frameworks voor continue integratie.

# 4) Zodra de bovenstaande stap is voltooid, zijn we klaar met het rapport van de uitgevoerde tests en samengevatte statistieken van de testuitvoeringsdetails.

We hopen dat je genoten hebt van het hele scala aan tutorials in deze Specflow-trainingsreeks. Deze reeks tutorials zou inderdaad de beste gids zijn voor elke beginner of ervaren persoon die zijn / haar kennis over Specflow wil verrijken!

PREV-zelfstudie OFGa terug naar The EERSTE Tutorial

Aanbevolen literatuur

^