top 15 popular specflow interview questions
Preguntas y respuestas más frecuentes de las entrevistas de Specflow:
Nuestro tutorial de Specflow anterior informó sobre Cómo generar informes de prueba y ejecutar pruebas selectivas .
En este tutorial, echaremos un vistazo a las preguntas de la entrevista de Specflow más populares junto con sus respuestas.
Lea el Serie completa de formación Specflow para una fácil comprensión del concepto. Specflow es una herramienta que apoya las prácticas de BDD en el marco .NET. Es un marco de código abierto alojado en GitHub. Ayuda en el uso de ATDD (desarrollo de controladores de prueba de aceptación) para .NET.
Principales preguntas y respuestas de la entrevista de Specflow
A continuación se enumeran las preguntas de la entrevista de Specflow más populares con respuestas y ejemplos para su fácil comprensión.
Q #1) ¿Cuál es la diferencia entre el archivo de características y los archivos vinculantes?
Responder: Escribir pruebas BDD en Specflow tiene 2 componentes principales, a saber
fecha de lanzamiento del casco de realidad virtual xbox one
- Archivos de características: Que contienen las pruebas escritas como Escenarios en Lenguaje Específico de Dominio (DSL) y son esencialmente archivos en inglés simple que son adecuados y comprensibles para todas las partes interesadas del proyecto. En realidad, son los archivos de prueba reales y se interpretan mediante los enlaces o definiciones de pasos.
- Enlaces de paso: Estos archivos de código son la lógica de inteligencia real detrás de la ejecución de la prueba. Cada paso de un escenario (que es parte del archivo de características) se vincula a un archivo de definición de pasos que se ejecuta realmente cuando se ejecuta la prueba.
Por lo tanto, una combinación de archivos de características y definición de pasos o enlaces hace posible que Specflow (o cualquier otro BDD) ejecute las pruebas.
P # 2) ¿Qué es BDD y en qué se diferencia de TDD o ATDD?
Responder: Todos estos tres términos, es decir, BDD, TDD y ATDD, están relacionados de alguna manera con el desarrollo basado en pruebas en general, pero de hecho son diferentes en muchos aspectos.
- TDD: TDD básicamente está creando pruebas desde la perspectiva de un desarrollador. En palabras simples, es un conjunto de pruebas que un desarrollador escribe para que su código pase (o falle). Es esencialmente una técnica para hacer que su código falle hasta que se aborden todos los requisitos específicos. Básicamente, sigue un ciclo de refactorización para el código hasta que todas las pruebas son verdes.
- BDD: BDD se relaciona estrechamente con TDD, pero es más relevante desde una perspectiva 'de afuera hacia adentro', lo que en realidad significa que las pruebas de BDD están más vinculadas a los requisitos del negocio / producto y definen el comportamiento deseado del sistema en forma de escenarios. TDD, por el contrario, se ocupa de un nivel de pruebas unitarias más granulares. Además, las especificaciones de BDD son generalmente texto en inglés simple que es fácil de entender y permite una mayor colaboración entre todas las partes interesadas del proyecto.
- ATDD: El enfoque del desarrollo basado en pruebas de aceptación es más desde la perspectiva de aceptación del usuario. Estas pruebas también definen el comportamiento del cliente, pero desde el punto de vista de la integración o del producto final, donde el caso de uso final del cliente se convierte en un escenario de prueba y todo el trabajo de desarrollo se centra en cumplir estos requisitos.
P # 3) ¿Qué contiene el archivo generado automáticamente para la función Specflow?
Responder: Los archivos de código subyacente de Specflow son archivos generados automáticamente con una extensión '.cs'. Estos archivos tienen la lógica de vinculación desde los Pasos hasta la definición del Paso real.
Algunos puntos con respecto a los archivos generados automáticamente son:
- Estos archivos no deben modificarse ni editarse manualmente. Incluso si intenta hacerlo, los cambios no se guardan.
- Después de todos y cada uno de los cambios en el archivo de características, el compilador vuelve a generar este archivo para capturar actualizaciones.
P # 4) ¿Cómo se distribuyen los enlaces de pasos en diferentes archivos fuente?
Responder: Los archivos de enlace de pasos se pueden reutilizar incluso si existen en archivos de origen separados y la coincidencia de enlaces se realiza a través de una expresión regular.
Los archivos de enlaces de pasos son esencialmente clases parciales atribuidas por (Vinculante) atributo. Esto asegura que todos los enlaces de pasos estén disponibles globalmente y puedan usarse con Pasos de escenario en archivos de características diferentes o iguales.
P # 5) ¿Cómo se pueden resolver las implementaciones de enlace de pasos ambiguas?
Responder: Specflow proporciona un mecanismo para evitar la implementación ambigua del enlace de pasos utilizando un concepto llamado Fijaciones con mira.
Esto es útil en escenarios donde tiene pasos similares en Escenarios en archivos de características iguales o diferentes y si desea tratar ambos Pasos de manera diferente.
En un escenario normal, como toda la coincidencia de pasos ocurre a través de Regex, y es una coincidencia codiciosa, tendrá que asegurarse de escribir un texto ligeramente diferente (para que no coincidan con la misma implementación) para los pasos aunque tengan un impacto legibilidad.
Con las vinculaciones con ámbito, puede especificar etiquetas con una implementación de vinculación particular o todo el archivo de vinculación y asegurarse de que la coincidencia también tenga un filtro de categoría adicional.
Los pasos que deben seguirse se enumeran a continuación:
a) Etiquete el escenario con una categoría utilizando la sintaxis: @Etiqueta. Ejemplo: Estamos etiquetando el siguiente escenario con la etiqueta - @scopedBinding
|_+_|b) Ahora use la misma etiqueta en el enlace de pasos, lo que garantizará que, además de la coincidencia de expresiones regulares, también se produzca la coincidencia de etiquetas o categorías (y garantiza que otros pasos no coincidan con esta implementación incluso si la coincidencia de expresiones regulares es exitosa)
En el ejemplo anterior, queremos establecer el alcance del enlace para el paso. ' Y he ingresado a la India como palabra clave de búsqueda ”, Agregaremos el atributo Scope con el parámetro Scoping como etiqueta.
|_+_|De forma similar al ámbito con etiqueta, también es posible tener enlaces con ámbito con títulos de Característica y Escenario.
P # 6) ¿Cómo se puede almacenar el contexto de prueba mientras se ejecutan diferentes escenarios?
Responder: El contexto de la prueba se puede almacenar utilizando diferentes enfoques mientras se ejecutan pruebas de flujo específico y cada enfoque tiene sus pros y sus contras.
- Usando ScenarioContext y FeatureContext: Piense en FeatureContext y ScenarioContext como un diccionario global de pares clave-valor y es accesible durante la ejecución de la función y la ejecución del escenario, respectivamente. El campo de valor puede almacenar cualquier tipo de Objeto y, durante la recuperación, es necesario convertirlo en el objeto como se desee.
- Usando campos en archivos vinculantes: Este enfoque permite compartir contexto a través de implementaciones vinculantes en el mismo y / o diferentes archivos vinculantes en el mismo espacio de nombres. No es diferente en mantener el estado usando variables de clase y se puede configurar o recuperar a través de implementaciones vinculantes según sea necesario.
- Usando el marco de DI propio de Specflow: Specflow proporciona un marco de inyección de contexto y se puede utilizar para pasar contexto en forma de clases / objetos simples de POCO. Los objetos / clases de contexto se pueden inyectar a través de campos del constructor y se pueden pasar a lo largo de diferentes archivos de enlace de Step.
Vea un ejemplo a continuación que tiene 2 objetos inyectados mediante inyección de constructor.
cómo abrir un archivo .apk en Windows|_+_|
P # 7) ¿Cuáles son las limitaciones de Specflow o BDD en general?
Responder: BDD, como su propio nombre lo indica, define el comportamiento con la aplicación que esencialmente convierte casos de uso en escenarios de prueba.
Por lo tanto, la ausencia de partes interesadas, como una empresa, un producto y / o clientes, podría afectar las especificaciones reales para las que los desarrolladores implementarán las pruebas de escritura y, por lo tanto, podría resultar en no proporcionar el valor real que podría haber proporcionado y que tenía todas las partes interesadas. estaban disponibles al definir los escenarios.
Dicho esto, la mayoría de las veces los pros son más astutos que los contras de BDD y es realmente una técnica muy útil para probar / validar las especificaciones. Ya que es más o menos independiente del lenguaje, ya que hay marcos BDD disponibles para casi todos los principales lenguajes de programación como Cucumber para Java, RSpec para Ruby y Specflow para .NET.
P # 8) ¿Qué son las transformaciones de argumentos por pasos?
Responder: Las transformaciones de argumentos, como su nombre lo indica, no son más que transformar el paso del escenario.
Piense en ello como una capa adicional de coincidencia que ocurre antes de que ocurra la coincidencia de enlace de paso real, y puede ser útil para transformar un tipo diferente de entrada de usuario en lugar de tener diferentes implementaciones de pasos individuales para el mismo tipo de entrada.
Para cualquier paso de transformación, el atributo requerido es PasoArgumentoTransformación
Por ejemplo, consulte el ejemplo de código a continuación:
|_+_|En referencia al ejemplo de código anterior, los tres pasos están relacionados. Pero, si hubiera pasado por la coincidencia habitual de expresiones regulares, entonces se le solicitaría que escriba tres implementaciones de pasos diferentes.
Con las transformaciones de argumentos de Step en su lugar, es posible transformar los valores y crear un TimeStamp objeto de los parámetros especificados y volver a la implementación del paso original.
Veamos la implementación de la transformación.
|_+_|Por lo tanto, aquí estamos transformando la entrada del escenario a un valor intermedio (como TimeStamp) y devolviendo el valor transformado a la implementación de enlace real como se muestra en el ejemplo siguiente.
|_+_|Observe cómo el valor transformado del tipo TimeSpan ahora se devuelve al método de implementación de enlace Step real.
P # 9) ¿Cuáles son los diferentes tipos de ganchos proporcionados por Specflow?
Responder:
Specflow proporciona una gran cantidad de Hooks personalizados o eventos especiales con los que los controladores de eventos (esencialmente métodos / funciones) pueden vincularse para ejecutar alguna lógica de configuración / desmontaje.
Specflow proporciona los siguientes ganchos:
- BeforeFeature / AfterFeature: El evento generado antes y después de que la característica comience y complete la ejecución, respectivamente.
- BeforeScenario / AfterScenario: El evento generado antes y después de que la ejecución de un escenario comience y finalice, respectivamente.
- BeforeScenarioBlock / AfterScenarioBlock: El evento que se genera antes y después de un Bloque de escenario, es decir, cuando cualquiera de los bloques de escenario que pertenecen a 'Dado', 'Cuándo' o 'Entonces' comienza o se completa.
- BeforeStep / AfterStep: El evento planteado antes y después de cada paso del escenario.
- BeforeTestRun / AfterTestRun: Este evento se genera solo una vez durante toda la ejecución de la prueba y una vez que finaliza la ejecución de la prueba.
Es importante tener en cuenta aquí que estos eventos se generan de forma predeterminada y se manejan si y solo si se proporcionan enlaces para estos ganchos. Además, no es obligatorio implementar estos ganchos en pares y cada gancho puede existir de forma independiente entre sí.
P # 10) ¿En qué se diferencia ScenarioContext de FeatureContext?
Responder: Tanto ScenarioContext como FeatureContext son clases estáticas proporcionadas por el marco Specflow y son realmente útiles para realizar tareas como pasar información entre enlaces, obtener información importante como el contexto de ejecución de la función / escenario, etc.
Veamos en qué se diferencian ambos:
Como su nombre lo indica, ScenarioContext proporciona datos o información en el nivel de ejecución del escenario, mientras que FeatureContext se ocupa de las cosas a nivel de función.
En términos simplistas, todo lo almacenado en featureContext estará disponible para todos los escenarios presentes en ese archivo de características, mientras que ScenarioContext estará disponible solo para los enlaces hasta que la ejecución del escenario de tiempo esté en progreso.
P # 11) ¿Qué importancia tiene el orden de entrega, cuándo y luego?
Responder: Specflow no impone ninguna restricción en el orden de Dado, cuando y entonces . Se trata más de la secuencia lógica de un escenario de prueba y de cualquier práctica de prueba en general, es decir, como en las pruebas unitarias, normalmente seguimos tres A para “ Organizar, actuar y afirmar ”.
Por lo tanto, para los escenarios de flujo de especificaciones, no hay restricciones para realizar pedidos y tampoco obliga a que las tres secciones estén presentes.
A menudo, a veces, la configuración puede ser minimalista y es posible que ni siquiera sea necesaria. Por lo tanto, para esos escenarios, simplemente puede omitir el ' Dado 'Bloquear e iniciar el escenario con el' Cuando ' cuadra.
P # 12) ¿Qué son ScenarioInfo y FeatureInfo?
Responder: SpecflowContext y FeatureContext proporcionan además clases estáticas anidadas, a saber, ScenarioInfo y FeatureInfo.
ScenarioInfo da acceso a información sobre el escenario que se está ejecutando actualmente.
Algunas de las cosas que puede conocer con esta clase se detallan a continuación:
- Título: El título del escenario. Sintaxis: ScenarioContext.Current.ScenarioInfo.Title
- Etiquetas: Lista de etiquetas en forma de Cuerda(). Sintaxis: ScenarioContext.Current.ScenarioInfo.Tags
S similar a ScenarioInfo, FeatureInfo también proporciona información relacionada con la función actual que se está ejecutando actualmente.
Además del título y las etiquetas, también proporciona otras cosas útiles como cuál es el idioma de destino para el que el código de característica detrás del archivo está generando código, los detalles del idioma en el que se escribe el archivo de características, etc.
La sintaxis para obtener valores para FeatureInfo sigue siendo la misma que ScenarioInfo como se muestra a continuación:
FeatureContext.Current.FeatureInfo
P # 13) Diferencia entre el esquema de escenario y las tablas Specflow.
Responder:
Escenario es básicamente una forma de ejecutar escenarios basados en datos utilizando Specflow donde se proporciona una lista de entradas en el Ejemplos en el escenario, y el escenario se ejecuta una vez cada uno según la cantidad de ejemplos proporcionados.
Vea un ejemplo de código a continuación para comprenderlo con mayor claridad.
|_+_|Las tablas son solo un medio para proporcionar datos tabulares con cualquier paso del escenario y se pasan como argumento de tabla de Specflow en la implementación del paso, que luego se puede analizar al tipo de objeto deseado según sea necesario.
Consulte la sección 'negrita' en el ejemplo de código a continuación para obtener más detalles:
|_+_|Similar al atributo Etiquetas: puede usar cualquier información proporcionada por ScenarioInfo para controlar el flujo de ejecución de la implementación de cualquier paso.
Q #14) Control de la ejecución de la prueba a través de ScenarioInfo.
De manera similar a los enlaces de alcance, que pueden permitir agregar un criterio de filtro adicional mientras se hace coincidir la definición de paso a través de etiquetas, también puede aprovechar el control de la ejecución de la prueba a través de la información proporcionada con ScenarioInfo.
Por ejemplo, Tiene 2 escenarios con etiquetas, es decir, @ tag1 y @ tag2 y ambos contienen la misma definición de paso. Ahora necesita agregar lógica personalizada según las etiquetas del escenario.
Por lo tanto, en la implementación de la definición del paso, simplemente puede obtener todas las etiquetas asociadas con un escenario usando ScenarioContext.Current.ScenarioInfo.Tags y verifique la presencia de una etiqueta en el escenario que se está ejecutando y decida qué código desea ejecutar.
Consulte el ejemplo de código a continuación para una mejor comprensión:
|_+_|Similar al atributo Etiquetas: puede usar cualquier información proporcionada por ScenarioInfo para controlar el flujo de ejecución de la implementación de cualquier paso.
P # 15) ¿Cómo se pueden ejecutar las pruebas de Specflow en un tipo de configuración de Integración continua?
Responder:
Con las metodologías modernas de desarrollo de software, la integración continua es una especie de palabra de moda y generalmente se la conoce como un conjunto de prácticas, donde cada compromiso con el código fuente se considera un candidato para el lanzamiento de producción.
Por lo tanto, cada confirmación esencialmente desencadena diferentes tipos de pruebas como puertas de calidad para garantizar que el cambio que se está comprometiendo no cause que ninguna prueba falle o se rompa.
Specflow: como sabemos, se integra muy bien con frameworks conocidos como NUnit y MSUnit y se puede ejecutar fácilmente a través de las aplicaciones de consola de estos frameworks de prueba dada la DLL del proyecto compilado que tiene características de Specflow e implementaciones de pasos.
¿Qué son las pruebas de regresión en las pruebas de software?
Por lo tanto, para lograr que las pruebas de Specflow se ejecuten como parte de una configuración de integración continua, la siguiente es una lista de pasos de alto nivel que se pueden seguir:
#1) Compile el proyecto que contiene la función Specflow y la definición de paso para obtener una DLL compilada.
#2) Ahora use los corredores de la consola NUnit o MSUnit y proporcione la DLL compilada como fuente de prueba (estos marcos brindan otras capacidades, además de proporcionar filtros de prueba según las categorías, etc.).
Este paso se puede integrar con la tubería de Integración Continua y se puede ejecutar a través de un script de shell o DOS con la herramienta CI como Jenkins o Bamboo, etc.
#3) Una vez que se completa la ejecución de la prueba, el informe de salida generado (que es específico del corredor de la consola utilizado), se puede convertir en un informe HTML más legible usando Specrun ejecutable está disponible como parte de NugetPackage.
Este paso también se puede ejecutar a través de la línea de comando que se proporciona de fábrica en todos los principales marcos de integración continua.
#4) Una vez que se completa el paso anterior, estamos listos con el informe de las pruebas ejecutadas y las métricas resumidas de los detalles de ejecución de la prueba.
Esperamos que haya disfrutado de toda la gama de tutoriales de esta serie de formación de Specflow. ¡Esta serie de tutoriales sería de hecho la mejor guía para cualquier principiante o persona experimentada que quiera enriquecer sus conocimientos sobre Specflow!
PREV Tutorial ORegresar al PRIMER Tutorial
Lectura recomendada
- Preguntas y respuestas de la entrevista
- Preguntas de la entrevista de Spock con respuestas (las más populares)
- Algunas preguntas interesantes de la entrevista sobre pruebas de software
- Las 20 preguntas y respuestas más populares de la entrevista de TestNG
- Las 30+ preguntas y respuestas más populares de la entrevista sobre pepino
- Las 50 preguntas y respuestas más populares de la entrevista CCNA
- Las 40 preguntas y respuestas más populares de la entrevista J2EE que debe leer
- Más de 25 preguntas y respuestas más populares de la entrevista ADO.NET