Menú

Top 15 de les preguntes més populars de l'entrevista Specflow

  • Principal
  • Altres
  • Top 15 de les preguntes més populars de l'entrevista Specflow

top 15 popular specflow interview questions

Preguntes i respostes més freqüents de l'entrevista Specflow:

Es va informar sobre el nostre anterior tutorial de Specflow Com generar informes de proves i executar proves selectives .

En aquest tutorial, farem un cop d'ull a les preguntes d'entrevista Specflow més populars juntament amb les seves respostes.

Llegiu el document Sèrie d'entrenament completa de Specflow per a una fàcil comprensió del concepte. Specflow és una eina que admet pràctiques de BDD en el marc .NET. És un marc de codi obert allotjat a GitHub. Ajuda a utilitzar ATDD (Acceptance Test Driver Development) per a .NET.

Preguntes sobre l

Preguntes i respostes principals de l'entrevista Specflow

A continuació, es mostren les preguntes d’entrevistes Specflow més populars, amb respostes i exemples per facilitar la vostra comprensió.

quina és la clau de xarxa per al wifi

Q # 1) Quina diferència hi ha entre el fitxer de funcions i els fitxers vinculants?

Resposta: L’escriptura de proves BDD a Specflow té 2 components principals, a saber

  1. Fitxers de funcions: Que contenen les proves escrites com a escenaris en un llenguatge específic de domini (DSL) i són essencialment fitxers en anglès senzill, adequats i comprensibles per a tots els grups d'interès del projecte. En realitat, són els fitxers de prova reals i s’interpreten a través de les fixacions o definicions de passos.
  2. Enquadernacions de passos: Aquests fitxers de codi són la lògica d'intel·ligència real darrere de l'execució de la prova. Cada pas d'un escenari (que forma part del fitxer de funcions) s'uneix a un fitxer de definició de pas que realment s'executa quan s'executa la prova.

Per tant, una combinació de fitxers de funcions i definició de passos o enllaços fan possible que el framework Specflow (o qualsevol altre BDD) executi les proves.

Q # 2) Què és BDD i en què es diferencia de TDD o ATDD?

Resposta: Tots aquests tres termes, és a dir, BDD, TDD i ATDD, estan una mica relacionats amb el desenvolupament impulsat per proves en general, però de fet són diferents de moltes maneres

  1. TDD: TDD bàsicament crea proves des de la perspectiva d’un desenvolupador. En paraules simples, és un conjunt de proves que un desenvolupador escriu perquè el seu codi passi (o falli). Es tracta essencialment d’una tècnica per fer fallar el vostre codi fins que no es compleixin tots els requisits específics. Bàsicament segueix un cicle de refactorització del codi fins que les proves siguin verdes.
  2. BDD: El BDD es relaciona estretament amb el TDD, però és més rellevant des d’una perspectiva “out-in”, cosa que significa que les proves BDD estan més lligades als requisits comercials / del producte i defineixen el comportament desitjat del sistema en forma d’escenaris. El TDD, en canvi, s’ocupa a un nivell de proves d’unitat més granular. A més, les especificacions de BDD solen ser un text en anglès senzill, fàcil d’entendre i que permet una major col·laboració entre totes les parts interessades del projecte.
  3. ATDD: El focus del desenvolupament basat en proves d’acceptació és més des de la perspectiva d’acceptació de l’usuari. Aquestes proves també defineixen el comportament del client, però des del punt de vista de la integració o del producte final, on el cas d’ús final d’un client es converteix en un escenari de prova i tot el treball de desenvolupament es centra en complir aquests requisits.

P # 3) Què hi ha al fitxer generat automàticament per a la característica Specflow?

Resposta: Els fitxers que contenen codis posteriors a Specflow són fitxers generats automàticament amb una extensió '.cs'. Aquests fitxers tenen la lògica d’unió des de Passos fins a la definició de Pas real.

Pocs punts sobre els fitxers generats automàticament són:

  • Aquests fitxers no s'han de modificar ni editar manualment. Fins i tot si proveu de fer-ho, els canvis no es desaran.
  • Després de tots i cadascun dels canvis al fitxer de funcions, el compilador torna a generar aquest fitxer per capturar actualitzacions.

Q # 4) Com s’accedeix a les vinculacions de passos repartides entre diferents fitxers font?

Resposta: Els fitxers de vinculació de passos es poden tornar a utilitzar fins i tot si existeixen en fitxers font separats i la coincidència de vinculació es fa mitjançant una expressió regular.

Els fitxers de vinculació de passos són essencialment classes parcials atribuïdes per [Enquadernació] atribut. Això garanteix que totes les vinculacions de passos estiguin disponibles a tot el món i es puguin utilitzar amb els passos d'escenari en fitxers de característiques diferents o del mateix.

Q # 5) Com es poden resoldre les implementacions de vinculació de passos ambigües?

Resposta: Specflow proporciona un mecanisme per evitar la implementació ambigua de vinculació de passos mitjançant un concepte anomenat Enquadernacions d'abast.

Això és útil en escenaris en què teniu passos similars a Escenaris en fitxers de característiques iguals o diferents i si voleu tractar els dos passos de manera diferent.

En un escenari normal, ja que totes les coincidències de passos es produeixen a través de Regex, i és una coincidència llaminera, haureu d'assegurar-vos que escriviu un text lleugerament diferent (de manera que no coincideixin amb la mateixa implementació) per als passos tot i que afectin llegibilitat.

Mitjançant Scoped Bindings, podeu especificar etiquetes amb una implementació d’enllaç en particular o tot el fitxer d’enllaç i assegurar-vos que la coincidència també tingui un filtre addicional de categoria.

A continuació es detallen els passos que cal seguir:

a) Etiqueu l'escenari amb una categoria mitjançant la sintaxi - @Etiqueta. Exemple: Estem etiquetant l'escenari següent amb l'etiqueta - @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) Ara utilitzeu la mateixa etiqueta a la vinculació de passos, cosa que assegurarà que, a més de la coincidència regular, també es produeixi la coincidència entre etiquetes o categories (i garanteix que altres passos no coincideixin amb aquesta implementació encara que la coincidència regular sigui correcta)

A l'exemple anterior, volem abastar la vinculació del pas. ' I he entrat a l'Índia com a paraula clau de cerca ”, Afegirem l’atribut Scope amb el paràmetre Scoping com a etiqueta.

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

De manera similar a l'abast amb etiqueta, també és possible tenir enllaços d'abast amb títols de funcions i escenaris.

P # 6) Com es pot emmagatzemar el context de prova mentre s'executen diferents escenaris?

Resposta: El context de la prova es pot emmagatzemar utilitzant diferents enfocaments mentre s'executen proves de flux de spec, i cada enfocament té els seus pros i els seus contres.

  1. Ús de ScenarioContext i FeatureContext: Penseu en FeatureContext i ScenarioContext com un diccionari global de parells clau-valor i és accessible durant l'execució de funcions i l'execució d'escenaris respectivament. El camp de valor pot emmagatzemar qualsevol tipus d’objecte i durant la recuperació s’ha de llançar a l’objecte segons es desitgi.
  2. Ús de camps en fitxers de vinculació: Aquest enfocament permet compartir context entre implementacions d'enllaç en fitxers d'enllaç iguals i / o diferents en el mateix espai de noms. No és diferent en mantenir l’estat mitjançant variables de classe i es pot establir o recuperar a través d’implementacions vinculants segons calgui.
  3. Utilitzant el marc DI propi de Specflow: Specflow proporciona un marc d’injecció de context i es pot utilitzar per passar context en forma d’objectes o classes POCO simples. Els objectes / classes de context es poden injectar a través dels camps del constructor i es poden passar al llarg de diferents fitxers de vinculació de passos.

Vegeu un exemple següent amb dos objectes injectats mitjançant la injecció del constructor.

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

Q # 7) Quines són les limitacions de Specflow o BDD en general?

Preguntes sobre l'entrevista sql per 3 anys d'experiència

Resposta: BDD, com el seu propi nom indica, defineix el comportament amb l’aplicació que bàsicament converteix els casos d’ús en escenaris de prova.

Per tant, l’absència d’interessats com ara una empresa, un producte i / o clients pot afectar les especificacions reals per a les quals els desenvolupadors implementaran proves d’escriptura i, per tant, podria resultar en no proporcionar el valor real del que podria haver proporcionat i que tingués totes les parts interessades. estaven disponibles mentre es definien els escenaris.

Dit això, la majoria de les vegades els professionals superen els desavantatges de BDD i és realment una tècnica molt útil per provar / validar les especificacions. Com que és més o menys agnòstic del llenguatge, ja que hi ha marcs BDD disponibles per a gairebé tots els llenguatges de programació principals, com Cucumber for Java, RSpec for Ruby i Specflow for .NET.

Q # 8) Què són les transformacions de l'argument de pas?

Resposta: Les transformacions argumentals, tal com el seu nom indica, no són altra cosa que transformar el pas de l’escenari.

Penseu en això com una capa addicional de coincidència que es produeix abans que es produeixi la coincidència d’unió de passos real, i pot ser útil per transformar un tipus d’entrada d’usuari diferent en lloc de tenir implementacions de passos individuals diferents per al mateix tipus d’entrada.

Per a qualsevol pas de transformació, l'atribut requerit és StepArgumentTransformation

Per exemple, consulteu l'exemple de codi següent:

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 referència a l'exemple de codi anterior, els tres passos estan relacionats. Però, si hagués estat mitjançant la coincidència regular regex, hauríeu d'escriure tres implementacions de passos diferents.

Amb les transformacions d'arguments Step al seu lloc, és possible transformar els valors i crear un fitxer TimeStamp objecte dels paràmetres especificats i torneu a la implementació del pas original.

Vegem la implementació de la transformació.

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

Per tant, aquí estem transformant l'escenari d'entrada a un valor intermedi (com TimeStamp) i retornant el valor transformat a la implementació d'enllaç real tal com es mostra a la mostra següent.

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

Tingueu en compte que ara es torna el valor transformat del tipus TimeSpan al mètode d'implementació de l'enllaç de pas real.

P # 9) Quins són els diferents tipus de ganxos proporcionats per Specflow?

Resposta:

Specflow proporciona una gran quantitat de ganxos personalitzats o esdeveniments especials amb els quals els controladors d'esdeveniments (bàsicament mètodes / funcions) es poden vincular per executar una lògica de configuració / desglossament.

Specflow proporciona els següents ganxos:

  1. BeforeFeature / AfterFeature: L'esdeveniment generat abans i després de la funció comença i finalitza l'execució respectivament.
  2. BeforeScenario / AfterScenario: L'esdeveniment generat abans i després de l'execució d'un escenari s'inicia i es completa respectivament.
  3. BeforeScenarioBlock / AfterScenarioBlock: L’esdeveniment plantejat abans i després d’un bloc d’escenaris, és a dir, quan s’inicia o finalitza qualsevol dels escenaris que pertanyen a “Donat”, “Quan” o “Aleshores”.
  4. BeforeStep / AfterStep: L'esdeveniment plantejat abans i després de cada pas de l'escenari.
  5. BeforeTestRun / AfterTestRun: Aquest esdeveniment només es genera una vegada durant tota l'execució de la prova i una vegada finalitzada l'execució de la prova.

És important tenir en compte aquí que aquests esdeveniments es plantegen per defecte i es gestionen si i només si hi ha enllaços previstos per a aquests ganxos. A més, no és obligatori implementar aquests ganxos per parelles i cada ganxo pot existir independentment els uns dels altres.

Q # 10) En què es diferencia ScenarioContext de FeatureContext?

Resposta: Tant ScenarioContext com FeatureContext són classes estàtiques proporcionades pel marc Specflow i són molt útils per realitzar tasques com passar informació entre enllaços, obtenir informació important com el context d’execució de la característica / escenari, etc.

Vegem en què es diferencien tots dos:

Com el seu nom indica, ScenarioContext proporciona dades o informació a nivell d’execució d’escenaris, mentre que FeatureContext s’ocupa de les coses a nivell de funció.

En termes simplistes, qualsevol cosa emmagatzemada a featureContext estarà disponible per a tots els escenaris presents en aquest fitxer de funcions, mentre que ScenarioContext estarà disponible només per a les vinculacions fins que s’executi l’escenari de temps.

Q # 11) Quina importància té l’ordre de donar, quan i després?

Resposta: Specflow no imposa cap restricció a l'ordre de Donat, quan i després . Es tracta més de la seqüenciació lògica d’un escenari de proves i de qualsevol pràctica de proves en general, és a dir, com en les proves unitàries, normalment seguim tres ' Organitzar, actuar i afirmar '.

Per tant, per als escenaris de flux especificat, no hi ha cap restricció a l’ordenació i tampoc no s’exigeix ​​la presència de les tres seccions.

De vegades, la configuració pot ser minimalista i ni tan sols pot ser necessària. Per tant, per a aquests escenaris, només podeu ometre el ' Donat 'Bloqueja i inicia l'escenari amb el' Quan ' bloc.

P # 12) Què són ScenarioInfo i FeatureInfo?

Resposta: SpecflowContext i FeatureContext també proporcionen classes estàtiques imbricades, és a dir, ScenarioInfo i FeatureInfo.
ScenarioInfo dóna accés a la informació al voltant de l’escenari que s’està executant actualment.

A continuació es detallen algunes de les coses que podeu conèixer amb aquesta classe:

  1. Títol: El títol de l'escenari. Sintaxi: ScenarioContext.Current.ScenarioInfo.Title
  2. Etiquetes: Llista d 'etiquetes en forma de Cadena []. Sintaxi: ScenarioContext.Current.ScenarioInfo.Tags

S semblant a ScenarioInfo, FeatureInfo també proporciona informació relativa a la característica actual que s'està executant actualment.

A més del títol i les etiquetes, també proporciona altres coses útils, com ara quin és l’idioma de destinació per al qual el codi de funció que genera el codi que hi ha darrere del fitxer, els detalls de l’idioma en què està escrit el fitxer de funcions, etc.

La sintaxi per obtenir valors per a FeatureInfo continua sent la mateixa que ScenarioInfo que es mostra a continuació:
FeatureContext.Current.FeatureInfo

Q # 13) Diferència entre les taules Esquema de l'escenari i Specflow.

Resposta:

ScenarioOutline és bàsicament una manera d 'executar escenaris basats en dades mitjançant Specflow, on es proporciona una llista d' entrades a Exemples secció de l’escenari i l’escenari s’executa una vegada cadascun en funció del nombre d’exemples proporcionats.

Vegeu un exemple de codi a continuació per entendre-ho amb més claredat.

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 taules són només un mitjà per subministrar dades tabulars amb qualsevol pas de l’escenari i es passen com a argument de la taula Specflow a la implementació del pas, que posteriorment es pot analitzar segons el tipus d’objecte desitjat.

Consulteu la secció 'en negreta' del següent exemple de codi per obtenir més informació:

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

De manera similar a l’atribut Tags: podeu utilitzar qualsevol informació proporcionada per ScenarioInfo per controlar el flux d’execució de qualsevol implementació de passos.

Q # 14) Control de l'execució de la prova mitjançant ScenarioInfo.

De manera similar a les vinculacions d’àmbit, que poden permetre afegir un criteri de filtre addicional mentre coincideixen la definició de passos mitjançant etiquetes, també podeu aprofitar el control de l’execució de la prova mitjançant la informació proporcionada amb ScenarioInfo.

Per exemple, Teniu 2 escenaris amb etiquetes, és a dir, @ tag1 i @ tag2 i tots dos contenen la mateixa definició de pas. Ara cal afegir una lògica personalitzada en funció de les etiquetes d'escenari.

Per tant, a la implementació de definició de passos, podeu obtenir simplement totes les etiquetes associades a un escenari ScenarioContext.Current.ScenarioInfo.Tags i comproveu la presència d'una etiqueta a l'escenari que s'està executant i decidiu quin codi voleu executar.

Consulteu l'exemple de codi següent per obtenir una millor comprensió:

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

De manera similar a l’atribut Tags: podeu utilitzar qualsevol informació proporcionada per ScenarioInfo per controlar el flux d’execució de qualsevol implementació de passos.

P # 15) Com es poden executar les proves Specflow en una configuració d'integració contínua?

Resposta:

Amb les modernes metodologies de desenvolupament de programari, la integració contínua és una mena de paraula de moda i es coneix generalment com un conjunt de pràctiques, on cada compromís amb el codi font es considera candidat a la versió de producció.

preguntes i respostes de l’entrevista de l’administrador de salesforce

Per tant, cada confirmació desencadena essencialment diferents tipus de proves com a portes de qualitat per assegurar-se que el canvi que es comet no faci fallar ni trencar cap prova.

Specflow - com sabem, s’integra molt bé amb frameworks coneguts com NUnit i MSUnit i es pot executar fàcilment a través de les aplicacions de consola d’aquests frameworks de prova donada la DLL del projecte compilat que té funcions Specflow i implementacions de passos.

Per tant, per tal d’aconseguir que s’executin proves Specflow com a part d’una configuració d’integració contínua, a continuació es mostra una llista de passos d’alt nivell que es poden seguir:

# 1) Compileu el projecte que conté la característica Specflow i la definició de passos per obtenir una DLL compilada.

# 2) Ara utilitzeu corredors de consola NUnit o MSUnit i proporcioneu la DLL compilada com a font de prova (Aquests marcs proporcionen altres funcions, a més de proporcionar filtres de prova en funció de les categories, etc.).

Aquest pas es pot integrar amb la canonada d’integració contínua i es pot executar mitjançant un script shell o DOS amb l’eina CI com Jenkins o Bamboo, etc.

# 3) Un cop finalitzada l'execució de la prova, l'informe de sortida generat (que és específic del corredor de consola utilitzat) es pot convertir en un informe HTML més llegible mitjançant Specrun executable està disponible com a part de NugetPackage.

Aquest pas també es pot executar a través de la línia d'ordres que tots els principals marcs d'integració contínua proporcionen fora de la caixa.

# 4) Un cop finalitzat el pas anterior, estem preparats amb l'informe de les proves executades i les mètriques resumides dels detalls d'execució de la prova.

Esperem que us hagi agradat tota la gamma de tutorials d'aquesta sèrie de formació Specflow. Aquesta sèrie de tutorials seria la millor guia per a qualsevol principiant o persona experimentada que vulgui enriquir el seu coneixement a Specflow.

PREV Tutorial OTorneu a PRIMER Tutorial

Lectura recomanada

^