Meniu

Top 15 Întrebări de interviuri populare Specflow

  • Principal
  • Alte
  • Top 15 Întrebări de interviuri populare Specflow

top 15 popular specflow interview questions

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Cele mai frecvente întrebări și răspunsuri ale interviului Specflow:

Tutorialul precedent Specflow a fost prezentat pe scurt Cum se generează rapoarte de testare și se execută teste selective .

În acest tutorial, vom arunca o privire asupra celor mai populare Întrebări de interviu Specflow împreună cu răspunsurile acestora.

Citiți prin Seria completă de formare Specflow pentru o înțelegere ușoară a conceptului. Specflow este un instrument care susține practicile BDD în cadrul .NET. Este un cadru open-source găzduit pe GitHub. Ajută la utilizarea ATDD (Acceptance Test Driver Development) pentru .NET.

Întrebări de interviu Specflow

Întrebări și răspunsuri de interviu de top Specflow

Mai jos sunt enumerate cele mai populare întrebări de interviu Specflow, cu răspunsuri și exemple pentru înțelegerea dvs. ușoară.

Q # 1) Care este diferența dintre fișierul de caracteristici și fișierele obligatorii?

Răspuns: Scrierea testelor BDD în Specflow are 2 componente majore și anume

  1. Fișiere de caracteristici: Care conțin testele scrise ca scenarii în limbaj specific domeniului (DSL) și sunt în esență fișiere simple în limba engleză, care sunt potrivite și ușor de înțeles pentru toți factorii interesați ai proiectului. În realitate, acestea sunt fișierele de testare reale și sunt interpretate prin legături sau definiții de pași.
  2. Legături pas: Aceste fișiere de cod reprezintă logica reală de informații din spatele executării testului. Fiecare pas dintr-un scenariu (care este o parte a fișierului de caracteristici) se leagă de un fișier de definire a pasului care se execută de fapt atunci când testul este rulat.

Prin urmare, o combinație atât a fișierelor de caracteristici, cât și a definiției pasului sau a legărilor fac posibil ca cadrul Specflow (sau orice alt BDD) să ruleze testele.

Q # 2) Ce este BDD și în ce este diferit de TDD sau ATDD?

Răspuns: Toți acești trei termeni, adică BDD, TDD și ATDD, sunt oarecum legați de Test Driven Development, în general, dar sunt într-adevăr diferiți în multe feluri

  1. TDD: TDD creează practic teste din perspectiva dezvoltatorului. În cuvinte simple, este un set de teste pe care un dezvoltator le scrie pentru ca codul său să treacă (sau să nu reușească). Este, în esență, o tehnică de a face codul să eșueze până când toate cerințele specifice sunt abordate. Practic, urmează un ciclu de refactor pentru cod până când testele sunt verzi.
  2. BDD: BDD este strâns legat de TDD, dar este mai relevant dintr-o perspectivă „out-in”, ceea ce înseamnă că testele BDD sunt mai legate de cerințele de afaceri / produs și definesc comportamentul dorit al sistemului sub formă de scenarii. În schimb, TDD se referă la un nivel mai granular de teste unitare. De asemenea, specificațiile BDD sunt, în general, text simplu în limba engleză, care este ușor de înțeles și permite o colaborare mai mare între toate părțile interesate ale proiectului.
  3. ATDD: Accentul dezvoltării bazate pe testul de acceptare este mai mult din perspectiva acceptării utilizatorului. Aceste teste definesc, de asemenea, comportamentul clienților, dar din punctul de vedere al integrării sau al produsului final, în cazul în care cazul de utilizare final al unui client este transformat într-un scenariu de testare, iar toate lucrările de dezvoltare sunt concentrate pentru a îndeplini aceste cerințe.

Î # 3) Ce conține fișierul generat automat pentru caracteristica Specflow?

Răspuns: Fișierele codificate în urma specflow sunt fișiere generate automat cu o extensie „.cs”. Aceste fișiere au logica de legare de la Pași la definiția reală a Pașilor.

Câteva puncte referitoare la fișierele generate automat sunt:

  • Aceste fișiere nu trebuie modificate sau editate manual. Chiar dacă încercați să faceți acest lucru, modificările nu vor fi salvate.
  • După fiecare modificare a fișierului de caracteristici, compilatorul re-generează acest fișier pentru a captura actualizări.

Q # 4) Cum sunt accesate legările de pași răspândite în diferite fișiere sursă?

Răspuns: Fișierele de legare în trepte pot fi refolosite chiar dacă există în fișiere sursă separate și potrivirea legării se întâmplă printr-o regex.

Fișierele de legare pas sunt în esență clase parțiale atribuite de (Legare) atribut. Acest lucru asigură faptul că toate legările de pași sunt disponibile la nivel global și pot fi utilizate cu pași de scenariu în fișiere de caracteristici diferite sau identice.

Q # 5) Cum pot fi rezolvate implementările de legare de pași ambigui?

Răspuns: Specflow oferă un mecanism pentru a evita implementarea ambiguă a legării pasului folosind un concept numit Bindings Scoped.

Acest lucru este util în scenarii în care aveți pași similari în Scenarii în aceleași sau diferite fișiere de caracteristici și dacă doriți să tratați ambii pași diferit.

Într-un scenariu normal, deoarece toate potrivirile de pași se întâmplă prin Regex și este o potrivire lacomă, va trebui să vă asigurați că scrieți un text ușor diferit (astfel încât să nu se potrivească cu aceeași implementare) pentru pași, chiar dacă au impact lizibilitate.

Folosind Scoped Bindings, puteți specifica etichete cu o anumită implementare de legare sau întregul fișier de legare și vă puteți asigura că potrivirea are și un filtru suplimentar de categorie.

Pașii care trebuie urmați sunt enumerați mai jos:

la) Etichetați scenariul cu o categorie folosind sintaxa - @Etichetă. Exemplu: Etichetăm scenariul de mai jos cu eticheta - @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) Acum utilizați aceeași etichetă pe legarea pasului, care va asigura că, pe lângă potrivirea regex, are loc și potrivirea etichetei sau a categoriei (și asigură că alți pași nu se potrivesc cu această implementare, chiar dacă potrivirea regex are succes)

În exemplul de mai sus, dorim să extindem legarea pentru pas. „ Și am intrat în India ca cuvânt cheie de căutare ”, Vom adăuga atributul Scope cu parametrul Scoping ca etichetă.

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

Similar cu scoping cu etichetă, este posibil să aveți și legături scoped cu titluri Feature și Scenario.

Q # 6) Cum poate fi stocat contextul de testare în timp ce rulează diferite scenarii?

Răspuns: Contextul testului poate fi stocat folosind abordări diferite în timp ce rulează teste de flux de specificații și fiecare abordare are argumentele pro și contra.

  1. Utilizarea ScenarioContext și FeatureContext: Gândiți-vă la FeatureContext și ScenarioContext ca la un dicționar global de perechi cheie-valoare și este accesibil în timpul executării caracteristicilor și, respectiv, a executării scenariului. Câmpul valoric poate stoca orice tip de obiect și, în timpul recuperării, trebuie să fie aruncat în obiect după cum doriți.
  2. Utilizarea câmpurilor din fișierele de legare: Această abordare permite partajarea contextului între implementările de legare în aceleași și / sau fișiere de legare diferite în același spațiu de nume. Nu este diferit în menținerea stării folosind variabile de clasă și poate fi setat sau recuperat prin implementări obligatorii, după cum este necesar.
  3. Folosind propriul cadru DI Specflow: Specflow oferă un cadru de injecție de context și poate fi folosit pentru a transmite contextul sub formă de clase / obiecte POCO simple. Obiectele / clasele contextuale pot fi injectate prin câmpurile constructorului și pot fi transmise de-a lungul diferitelor fișiere de legare pas.

Vezi un exemplu de mai jos cu 2 obiecte injectate prin injecția constructorului.

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

Q # 7) Care sunt limitările Specflow sau BDD în general?

Răspuns: BDD, așa cum sugerează și numele, definește comportamentul cu aplicația, care transformă în esență cazurile de utilizare pentru a testa scenarii.

Prin urmare, absența unor părți interesate, cum ar fi o afacere, un produs și / sau clienți, ar putea avea un impact asupra specificațiilor efective pentru care dezvoltatorii urmează să implementeze teste de scriere și, prin urmare, ar putea avea ca rezultat neacordarea valorii reale, ceea ce ar fi putut oferi și ar avea toți părțile interesate erau disponibile la definirea scenariilor.

îmbinare exterioară stângă vs îmbinare stângă

Acestea fiind spuse că de cele mai multe ori profesioniștii depășesc dezavantajele BDD și este într-adevăr o tehnică foarte utilă pentru a testa / valida specificațiile. Deoarece este mai mult sau mai puțin agnostic de limbaj, deoarece există cadre BDD disponibile pentru aproape toate limbajele de programare majore, cum ar fi Castravete pentru Java, RSpec pentru Ruby și Specflow pentru .NET.

Q # 8) Ce sunt transformările argumentului pasului?

Răspuns: Transformările argumentelor, așa cum sugerează și numele, nu sunt altceva decât transformarea etapei scenariului.

Gândiți-vă la acesta ca la un strat suplimentar de potrivire care se întâmplă înainte ca meciul de legare a pasului real să se întâmple și poate fi util pentru transformarea unui tip diferit de intrare de utilizator, mai degrabă decât pentru a avea implementări de pași individuali pentru același tip de intrare.

Pentru orice pas de transformare, atributul necesar este StepArgumentTransformation

De exemplu, consultați exemplul de cod de mai jos:

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

Referindu-ne la exemplul de cod de mai sus, toți cei trei pași sunt legați. Dar, dacă ar fi fost prin potrivirea obișnuită a regexului, atunci vi s-ar cere să scrieți trei implementări de pași diferiți.

Cu transformările argumentului Step în loc, este posibil să transformați valorile și să creați un Timestamp-ul obiect din parametrii specificați și reveniți la implementarea pasului original.

Să ne uităm la implementarea transformării.

(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 }

Astfel, aici transformăm scenariul de intrare într-o valoare intermediară (cum ar fi TimeStamp) și returnăm valoarea transformată la implementarea de legare efectivă așa cum se arată în eșantionul de mai jos.

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

Observați, cum valoarea transformată de tip TimeSpan este acum returnată înapoi la metoda de implementare a legării pasului.

Q # 9) Care sunt diferitele tipuri de cârlige furnizate de Specflow?

Răspuns:

Specflow oferă o mulțime de Hook-uri personalizate sau evenimente speciale cu care gestionarii de evenimente (în esență, metode / funcții) pot fi obligate să execute unele logici de configurare / detașare.

Specflow oferă următoarele cârlige:

  1. BeforeFeature / AfterFeature: Evenimentul ridicat înainte și după caracteristică începe și finalizează executarea respectiv.
  2. BeforeScenario / AfterScenario: Evenimentul ridicat înainte și după executarea unui scenariu începe și se finalizează, respectiv.
  3. BeforeScenarioBlock / AfterScenarioBlock: Evenimentul ridicat înainte și după un bloc de scenariu, adică atunci când oricare dintre scenariile care aparțin „Dat”, „Când” sau „Atunci” începe sau se finalizează.
  4. BeforeStep / AfterStep: Evenimentul ridicat înainte și după fiecare pas al scenariului.
  5. BeforeTestRun / AfterTestRun: Acest eveniment este ridicat o singură dată pe parcursul întregii execuții a testului și o dată după finalizarea executării testului.

Este important să rețineți aici că aceste evenimente sunt ridicate în mod implicit și sunt tratate dacă și numai dacă există legături prevăzute pentru aceste cârlige. De asemenea, nu este obligatoriu să implementați aceste cârlige în perechi și fiecare cârlig poate exista independent unul de celălalt.

Q # 10) Cum diferă ScenarioContext de FeatureContext?

Răspuns: Atât ScenarioContext, cât și FeatureContext sunt clase statice furnizate de cadrul Specflow și sunt foarte utile pentru efectuarea de activități precum trecerea informațiilor între legături, obținerea de informații importante, cum ar fi contextul de execuție al caracteristicii / scenariului etc.

Să vedem cum diferă ambele:

După cum sugerează și numele, ScenarioContext oferă date sau informații la nivelul de execuție al scenariului, în timp ce FeatureContext se ocupă de lucruri la nivel de caracteristică.

În termeni simpliști, orice stocat în featureContext va fi disponibil pentru toate scenariile prezente în acel fișier de caracteristici, în timp ce ScenarioContext va fi disponibil doar pentru legături până când executarea scenariului de timp este în desfășurare.

Q # 11) Cât de importantă este ordinea de dat, când și apoi?

Răspuns: Specflow nu impune nicio restricție asupra ordinii Dat, când și apoi . Este mai mult despre secvențierea logică a unui scenariu de testare și a oricărei practici de testare în general, adică, ca în testele unitare, de obicei urmărim trei A ' Aranjează, acționează și afirmă ”.

Deci, pentru scenariile de flux de specificații, nu există restricții privind comanda și, de asemenea, nu se impune ca toate cele trei secțiuni să fie prezente.

Uneori, configurarea poate fi minimalistă și nu poate fi necesară. Prin urmare, pentru aceste scenarii, puteți omite pur și simplu „ Dat ”Blocați și începeți scenariul cu„ Când ' bloc.

Q # 12) Ce sunt ScenarioInfo și FeatureInfo?

Răspuns: SpecflowContext și FeatureContext oferă în continuare clase statice imbricate și anume ScenarioInfo și FeatureInfo.
ScenarioInfo oferă acces la informații despre scenariul care se execută în prezent.

Unele dintre lucrurile pe care le puteți cunoaște cu această clasă sunt prezentate mai jos:

  1. Titlu: Titlul scenariului. Sintaxă: ScenarioContext.Current.ScenarioInfo.Title
  2. Etichete: Lista etichetelor sub forma Şir(). Sintaxă: ScenarioContext.Current.ScenarioInfo.Tags

S asemănător cu ScenarioInfo, FeatureInfo oferă, de asemenea, informații referitoare la caracteristica curentă care se execută în prezent.

În plus față de titlu și etichete, oferă și alte lucruri utile, cum ar fi limba țintă pentru care codul de caracteristică din spatele fișierului generează cod, detaliile limbii în care este scris fișierul de caracteristici etc.

Sintaxa pentru a obține valori pentru FeatureInfo rămâne aceeași cu ScenarioInfo ca mai jos:
FeatureContext.Current.FeatureInfo

Q # 13) Diferența dintre schemele Scenariului și tabelele Specflow.

Răspuns:

ScenariuOutline este în esență o modalitate de a executa scenarii bazate pe date folosind Specflow unde o listă de intrări sunt furnizate în Exemple din scenariu, iar scenariul se execută o dată fiecare în funcție de numărul de exemple furnizate.

Vedeți mai jos un eșantion de cod pentru a-l înțelege mai clar.

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

Tabelele sunt doar mijloace de furnizare a datelor tabulare cu orice pas al scenariului și sunt transmise ca argument al tabelului Specflow în implementarea pasului, care poate fi ulterior analizat la tipul de obiect dorit, după cum este necesar.

Vă rugăm să consultați secțiunea „aldină” din exemplul de cod de mai jos pentru mai multe detalii:

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

Similar cu atributul Etichete - puteți utiliza orice informații furnizate de ScenarioInfo pentru a controla fluxul de execuție a oricărei etape de implementare.

Q # 14) Controlul executării testului prin ScenarioInfo.

Similar cu legările de domeniu, care pot permite adăugarea unui criteriu de filtrare suplimentar în timp ce se potrivește definiția pasului prin etichete, puteți utiliza, de asemenea, controlul execuției testului prin informațiile furnizate cu ScenarioInfo.

De exemplu, Aveți 2 scenarii cu etichete, adică @ tag1 și @ tag2 și ambele conțin aceeași definiție a pasului. Acum trebuie să adăugați logică personalizată în funcție de etichetele de scenariu.

Astfel, în implementarea definiției pasului, puteți obține pur și simplu toate etichetele asociate cu un scenariu folosind ScenarioContext.Current.ScenarioInfo.Tags și verificați prezența unei etichete în scenariul în curs de executare și decideți ce cod doriți să executați.

Consultați exemplul de cod de mai jos pentru o mai bună înțelegere:

(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 } }

Similar cu atributul Etichete - puteți utiliza orice informații furnizate de ScenarioInfo pentru a controla fluxul de execuție a oricărei etape de implementare.

Q # 15) Cum se pot executa testele Specflow într-un tip de integrare continuă?

Răspuns:

Cu metodologiile moderne de dezvoltare software, integrarea continuă este un fel de cuvânt la modă și este, în general, denumită un set de practici, în care fiecare angajare în codul sursă este considerată un candidat pentru lansarea producției.

Prin urmare, fiecare comitere declanșează în esență diferite tipuri de teste, ca porți de calitate, pentru a se asigura că modificarea efectuată nu provoacă eșecul sau ruperea testelor.

Specflow - după cum știm, se integrează foarte bine cu cadre cunoscute precum NUnit și MSUnit și poate fi rulat cu ușurință prin intermediul aplicațiilor de consolă ale acestor cadre de testare, având în vedere DLL-ul proiectului compilat, care are caracteristici Specflow și implementări de pași.

Prin urmare, pentru a realiza teste Specflow care rulează ca parte a unei configurări de integrare continuă, următoarea este o listă de pași la nivel înalt care pot fi urmați:

# 1) Compilați proiectul care conține caracteristica Specflow și definiția pasului pentru a obține un DLL compilat.

#Două) Acum utilizați alergătorii de consolă NUnit sau MSUnit și furnizați DLL compilat ca sursă de testare (Aceste cadre oferă alte capacități, precum și oferă filtre de testare în funcție de categorii etc.).

Acest pas poate fi integrat cu conducta de integrare continuă și poate fi executat prin script shell sau DOS cu instrumentul CI precum Jenkins sau Bamboo etc.

# 3) Odată ce se finalizează execuția testului, raportul de ieșire generat (care este specific runnerului de consolă utilizat), poate fi convertit într-un raport HTML mai lizibil folosind Specrun executabil este disponibil ca parte a NugetPackage.

Acest pas poate fi, de asemenea, executat prin linia de comandă care este furnizată din cutie de toate cadrele majore de integrare continuă.

# 4) Odată ce pasul de mai sus se finalizează, suntem pregătiți cu raportul testelor executate și valorile sumare ale detaliilor de execuție a testului.

Sperăm că v-a plăcut întreaga gamă de tutoriale din această serie de formare Specflow. Această serie de tutoriale ar fi într-adevăr cel mai bun ghid pentru orice începător sau persoană experimentată care dorește să-și îmbogățească cunoștințele despre Specflow!

PREV Tutorial SAUDu-te înapoi la PRIMUL Tutorial

Lectură recomandată

^