メニュー

Specflowの人気のあるインタビューの質問トップ15

top 15 popular specflow interview questions

問題を排除するために楽器を試してください

最もよくあるSpecflowインタビューの質問と回答：

以前のSpecflowチュートリアルの概要 テストレポートを生成して選択テストを実行する方法 。

このチュートリアルでは、最も人気のあるSpecflowインタビューの質問とその回答を見ていきます。

を読んでください 完全なSpecflowトレーニングシリーズ 概念を簡単に理解するために。 Specflowは、.NETFrameworkでのBDDプラクティスをサポートするツールです。これは、GitHubでホストされているオープンソースフレームワークです。 .NET用のATDD（受け入れテストドライバー開発）の使用を支援します。

Specflowインタビューの質問

トップSpecflowインタビューの質問と回答

以下に、最も人気のあるSpecflowインタビューの質問と、簡単に理解できるように回答と例を示します。

Q＃1） 機能ファイルとバインディングファイルの違いは何ですか？

回答： SpecflowでのBDDテストの記述には、2つの主要なコンポーネントがあります。

  1. 機能ファイル： これには、ドメイン固有言語（DSL）でシナリオとして記述されたテストが含まれており、プロジェクトのすべての利害関係者にとって適切で理解しやすい基本的にプレーンな英語のファイルです。実際には、これらは実際のテストファイルであり、バインディングまたはステップ定義を通じて解釈されます。
  2. ステップバインディング： これらのコードファイルは、テスト実行の背後にある実際のインテリジェンスロジックです。シナリオ（機能ファイルの一部）の各ステップは、テストの実行時に実際に実行されるステップ定義ファイルにバインドされます。

したがって、機能ファイルとステップ定義またはバインディングの両方を組み合わせることで、Specflow（またはその他のBDD）フレームワークでテストを実行できます。

Q＃2）BDDとは何ですか？TDDやATDDとはどのように異なりますか？

回答： これらの3つの用語、つまりBDD、TDD、およびATDDはすべて、一般にテスト駆動開発にいくらか関連していますが、実際には多くの点で異なります。

  1. TDD： TDDは基本的に、開発者の観点からテストを作成しています。簡単に言うと、これは開発者がコードを合格（または不合格）にするために作成する一連のテストです。これは基本的に、特定の要件がすべて解決されるまでコードを失敗させる手法です。基本的に、テストがすべて緑色になるまで、コードのリファクタリングサイクルに従います。
  2. BDD： BDDはTDDと密接に関連していますが、「アウトサイドイン」の観点からより関連性があります。つまり、BDDテストはビジネス/製品の要件により密接に関連しており、シナリオの形式でシステムの望ましい動作を定義します。対照的に、TDDはより詳細な単体テストレベルを扱います。また、BDD仕様は一般的にわかりやすい英語のテキストであり、プロジェクトのすべての利害関係者間のコラボレーションを強化できます。
  3. ATDD： 受け入れテスト駆動開発の焦点は、ユーザーの受け入れの観点からです。これらのテストは顧客の行動も定義しますが、統合または最終製品の観点から、顧客の最終的なユースケースがテストシナリオに変換され、すべての開発作業がこれらの要件を満たすことに焦点を合わせます。

Q＃3）Specflow機能の自動生成ファイルには何が含まれていますか？

回答： Specflowコードビハインドファイルは、拡張子が「.cs」の自動生成ファイルです。これらのファイルには、ステップから実際のステップ定義へのバインディングロジックがあります。

自動生成されたファイルに関するいくつかのポイントは次のとおりです。

  • これらのファイルは手動で変更または編集しないでください。これを実行しようとしても、変更は保存されません。
  • 機能ファイルを変更するたびに、コンパイラはこのファイルを再生成して更新をキャプチャします。

Q＃4）アクセスされるさまざまなソースファイルにステップバインディングをどのように分散させますか？

回答： ステップバインディングファイルは、別々のソースファイルに存在し、正規表現を介してバインディングマッチングが行われる場合でも、再利用できます。

ステップバインディングファイルは、基本的に、 【製本】 属性。これにより、すべてのステップバインディングがグローバルに使用可能になり、異なるまたは同じ機能ファイルのシナリオステップで使用できるようになります。

Q＃5）あいまいなステップバインディングの実装をどのように解決できますか？

回答： Specflowは、と呼ばれる概念を使用して、あいまいなステップバインディングの実装を回避するメカニズムを提供します。 スコープバインディング。

これは、同じまたは異なる機能ファイルのシナリオに同様のステップがあるシナリオで、両方のステップを異なる方法で処理する場合に役立ちます。

通常のシナリオでは、すべてのステップマッチングは正規表現を介して行われ、貪欲なマッチであるため、影響がある場合でも、ステップに対してわずかに異なるテキストを書き込む必要があります（同じ実装と一致しないようにするため）。読みやすさ。

スコープバインディングを使用すると、特定のバインディング実装またはバインディングファイル全体でタグを指定し、マッチングにカテゴリの追加フィルターも含めることができます。

従う必要のある手順を以下に示します。

に） 構文を使用してシナリオにカテゴリのタグを付ける– @鬼ごっこ。 例： 以下のシナリオにタグを付けています– @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） ここで、ステップバインディングで同じタグを使用します。これにより、正規表現の一致に加えて、タグまたはカテゴリの一致も発生します（また、正規表現の一致が成功した場合でも、他のステップがこの実装に一致しないことが保証されます）

上記の例では、ステップのバインディングのスコープを設定します。 「「 そして私は検索キーワードとしてインドを入力しました 」、タグとしてScopingパラメーターを指定してScope属性を追加します。

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

タグを使用したスコープと同様に、機能とシナリオのタイトルを使用してスコープ付きバインディングを作成することもできます。

Q＃6）さまざまなシナリオの実行中にテストコンテキストを保存するにはどうすればよいですか？

回答： テストコンテキストは、スペックフローテストの実行中にさまざまなアプローチを使用して保存でき、各アプローチには長所と短所があります。

  1. SceneContextとFeatureContextの使用： FeatureContextとScenarioContextは、キーと値のペアのグローバルディクショナリと考えてください。それぞれ、機能の実行中とシナリオの実行中にアクセスできます。値フィールドには任意のタイプのオブジェクトを格納でき、取得時に必要に応じてオブジェクトにキャストする必要があります。
  2. バインディングファイルでのフィールドの使用： このアプローチにより、同じ名前空間内の同じおよび/または異なるバインディングファイル内のバインディング実装間でコンテキストを共有できます。クラス変数を使用して状態を維持する点で違いはなく、必要に応じてバインディング実装間で設定または取得できます。
  3. Specflow独自のDIフレームワークの使用： Specflowは、コンテキストインジェクションフレームワークを提供し、単純なPOCOクラス/オブジェクトの形式でコンテキストを渡すために使用できます。コンテキストオブジェクト/クラスは、コンストラクタフィールドを介して挿入でき、さまざまなステップバインディングファイルに渡すことができます。

コンストラクター注入によって2つのオブジェクトが注入された以下の例を参照してください。

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

Q＃7）SpecflowまたはBDDの一般的な制限は何ですか？

回答： BDDは、その名前自体が示すように、基本的にユースケースをテストシナリオに変換するアプリケーションの動作を定義します。

したがって、ビジネス、製品、顧客などの利害関係者がいないと、開発者が書き込みテストを実装する実際の仕様に影響を与える可能性があり、その結果、提供できたはずの実際の価値が提供されず、すべての利害関係者がいる可能性があります。シナリオの定義中に利用可能でした。

ほとんどの場合、長所はBDDの短所を上回り、仕様をテスト/検証するのに非常に役立つ手法であると言っています。 Cucumber for Java、RSpec for Ruby、Specflow for .NETなど、ほとんどすべての主要なプログラミング言語で利用できるBDDフレームワークがあるため、多かれ少なかれ言語に依存しません。

Q＃8）ステップ引数変換とは何ですか？

回答： 名前が示すように、引数の変換は、シナリオのステップを変換することに他なりません。

これは、実際のステップバインディングの一致が発生する前に発生する追加の一致レイヤーと考えてください。同じタイプの入力に対して異なる個別のステップ実装を使用するのではなく、異なる種類のユーザー入力を変換する場合に役立ちます。

変換ステップの場合、必要な属性は次のとおりです。 StepArgumentTransformation

たとえば、以下のコードサンプルを参照してください。

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

上記のコードサンプルを参照すると、3つのステップすべてが関連しています。ただし、通常の正規表現のマッチングを行っていた場合は、3つの異なるステップの実装を作成する必要があります。

私のネットワークセキュリティキーは何ですか

ステップ引数変換を適切に行うと、値を変換して作成することができます。 タイムスタンプ 指定されたパラメータからオブジェクトを取得し、元のステップの実装に戻ります。

変換の実装を見てみましょう。

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

したがって、ここでは、シナリオ入力を中間値（TimeStampなど）に変換し、以下のサンプルに示すように、変換された値を実際のバインディング実装に戻します。

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

TimeSpan型の変換された値が、実際のステップバインディング実装メソッドにどのように返されるかに注意してください。

Q＃9）Specflowが提供するフックの種類は何ですか？

回答：

Specflowは、イベントハンドラー（基本的にメソッド/関数）をバインドしてセットアップ/ティアダウンロジックを実行できる、多くのカスタムフックまたは特別なイベントを提供します。

Specflowは次のフックを提供します。

  1. BeforeFeature / AfterFeature： 機能の開始前と実行後に発生したイベントは、それぞれ実行を開始および完了します。
  2. BeforeScenario / AfterScenario： シナリオの実行の前後に発生したイベントは、それぞれ開始および完了します。
  3. BeforeScenarioBlock / AfterScenarioBlock： シナリオブロックの前後に発生するイベント。つまり、「Given」、「When」、または「Then」に属するシナリオブロックのいずれかが開始または完了したとき。
  4. BeforeStep / AfterStep： シナリオの各ステップの前後に発生したイベント。
  5. BeforeTestRun / AfterTestRun： このイベントは、テストの実行全体で1回だけ発生し、テストの実行が完了した後に1回だけ発生します。

ここで重要なのは、これらのイベントはデフォルトで発生し、これらのフックにバインディングが提供されている場合にのみ処理されるということです。また、これらのフックをペアで実装することは必須ではなく、すべてのフックは互いに独立して存在できます。

Q＃10）ScenarioContextはFeatureContextとどう違うのですか？

回答： SceneContextとFeatureContextはどちらも、Specflowフレームワークによって提供される静的クラスであり、バインディング間で情報を渡す、機能/シナリオの実行コンテキストなどの重要な情報を取得するなどのタスクを実行するのに非常に役立ちます。

両方の違いを見てみましょう。

名前が示すように、ScenarioContextはシナリオ実行レベルでデータまたは情報を提供し、FeatureContextは機能レベルで処理します。

簡単に言うと、featureContextに格納されているものはすべて、その機能ファイルに存在するすべてのシナリオで使用できますが、ScenarioContextは、シナリオの実行が進行するまで、バインディングのみで使用できます。

Q＃11）与えられた順序は、いつ、どのくらい重要ですか？

回答： Specflowは、次の順序に制限を課しません。 与えられた、いつそしてその後 。これは、テストシナリオの論理的な順序付けと、一般的なテストプラクティスに関するものです。つまり、単体テストのように、通常は3つのAの略です。 「」 手配、行動、主張 」。

したがって、スペックフローシナリオの場合、順序に制限はなく、3つのセクションすべてが存在する必要もありません。

多くの場合、セットアップは最小限であり、必要さえない場合があります。したがって、これらのシナリオでは、「 与えられた 」をブロックして、「 いつ 」ブロック。

Q＃12）ScenarioInfoとFeatureInfoとは何ですか？

回答： SpecflowContextとFeatureContextは、ネストされた静的クラス、つまりScenarioInfoとFeatureInfoをさらに提供します。
SceneInfoは、現在実行されているシナリオに関する情報へのアクセスを提供します。

このクラスで知っておくべきことのいくつかを以下に示します。

  1. 題名： シナリオのタイトル。 構文： SceneContext.Current.ScenarioInfo.Title
  2. タグ： の形式のタグのリスト ストリング()。 構文： SceneContext.Current.ScenarioInfo.Tags

S に似ています シナリオ情報、機能情報 また、現在実行されている現在の機能に関する情報も提供します。

タイトルとタグに加えて、ファイルの背後にある機能コードがコードを生成するターゲット言語、機能ファイルが書き込まれる言語の詳細など、他の便利なものも提供します。

FeatureInfoの値を取得するための構文は、以下のようにScenarioInfoと同じままです。
FeatureContext.Current.FeatureInfo

ソフトウェアテストにおける検証と妥当性確認とは

Q＃13）シナリオの概要とSpecflowテーブルの違い。

回答：

シナリオ概要 基本的には、Specflowを使用してデータ駆動型シナリオを実行する方法であり、入力のリストが 例 シナリオのセクションであり、シナリオは、提供された例の数に応じて1回ずつ実行されます。

より明確に理解するには、以下のコードサンプルを参照してください。

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

テーブルは、シナリオの任意のステップで表形式のデータを提供するための手段であり、ステップの実装でSpecflowテーブル引数として渡されます。この引数は、後で必要に応じて目的のオブジェクトタイプに解析できます。

詳細については、以下のコードサンプルの「太字」セクションを参照してください。

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

タグ属性と同様に、ScenarioInfoが提供する任意の情報を使用して、任意のステップ実装の実行フローを制御できます。

Q＃14） SceneInfoを介して実行されるテストの制御。

タグを介してステップ定義を照合しながら追加のフィルター基準を追加できるスコープバインディングと同様に、ScenarioInfoで提供される情報を介してテスト実行の制御を活用することもできます。

例えば、 タグ付きの2つのシナリオ、つまり@ tag1と@ tag2があり、どちらにも同じステップ定義が含まれています。次に、シナリオタグに応じてカスタムロジックを追加する必要があります。

したがって、ステップ定義の実装では、を使用してシナリオに関連付けられたすべてのタグを簡単に取得できます。 SceneContext.Current.ScenarioInfo.Tags 実行中のシナリオにタグが存在するかどうかを確認し、実行するコードを決定します。

理解を深めるには、以下のコードサンプルを参照してください。

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

タグ属性と同様に、ScenarioInfoが提供する任意の情報を使用して、任意のステップ実装の実行フローを制御できます。

Q＃15）継続的インテグレーションのようなセットアップでSpecflowテストを実行するにはどうすればよいですか？

回答：

最新のソフトウェア開発手法では、継続的インテグレーションは一種の流行語であり、一般に一連のプラクティスと呼ばれ、ソースコードへのすべてのコミットが製品リリースの候補と見なされます。

したがって、コミットするたびに、品質ゲートとしてさまざまなタイプのテストが基本的にトリガーされ、コミットされている変更によってテストが失敗したり中断したりしないことが保証されます。

Specflow –ご存知のとおり、NUnitやMSUnitなどの既知のフレームワークと非常によく統合されており、Specflow機能とステップ実装を備えたコンパイル済みプロジェクトのDLLがあれば、これらのテストフレームワークのコンソールアプリケーションから簡単に実行できます。

したがって、継続的インテグレーションのセットアップの一部として実行されるSpecflowテストを実現するために、実行できる高レベルの手順のリストを次に示します。

＃1） Specflow機能とステップ定義を含むプロジェクトをコンパイルして、コンパイルされたDLLを取得します。

＃二） ここで、NUnitまたはMSUnitコンソールランナーを使用し、コンパイルされたDLLをテストソースとして提供します（これらのフレームワークは、他の機能を提供するだけでなく、カテゴリなどに応じてテストフィルターを提供します）。

このステップは、継続的インテグレーションパイプラインと統合でき、JenkinsやBambooなどのCIツールを使用してシェルまたはDOSスクリプトを介して実行できます。

＃3） テストの実行が完了すると、生成された出力レポート（使用されているコンソールランナーに固有）は、を使用してより読みやすいHTMLレポートに変換できます。 Specrun 実行可能ファイルは、NugetPackageの一部として利用できます。

このステップは、すべての主要な継続的インテグレーションフレームワークによってすぐに提供されるコマンドラインからも実行できます。

＃4） 上記の手順が完了すると、実行されたテストのレポートと、テスト実行の詳細の要約されたメトリックが準備できます。

このSpecflowトレーニングシリーズのすべてのチュートリアルをお楽しみいただけたでしょうか。この一連のチュートリアルは、Specflowに関する知識を深めたい初心者や経験豊富な人にとって、まさに最高のガイドになるでしょう。

前のチュートリアル またはに戻る 最初のチュートリアル

推奨読書

^