ATDD、Gherkin、Specflowアプローチ、ブラックボックステストの問題

Question

私はATDDで外で開発する経験を積み重ねようとしています。今では最初のロードブロッキングがあります。

アプリケーションは、重複してファイルシステムを検索できる単純なデスクトップアプリケーション（wpf）です。

私が実装したい最初の機能は、検索するディレクトリをカスタマイズすることです。しかし、私はどのように私はその機能の終わりをテストする必要があります知りません。

2つのファイル（重複）でテストディレクトリを作成し、そのディレクトリをユーザーインターフェイスで選択してから検索を開始し、結果が2つの作成ファイルであることを検証するのはよい自動化アプローチですか？

私は、検索ディレクトリを特定する機能をさらに多くテストしています。

特集：あなたがしたい場合、あなたは、エンドツーエンドのすべてをテストする必要はありませんBDD、またはATDDで私の混乱

Answer 1

を減らすことができ、フィードバックのためのCustomizeSearchDirectories

In order to speed up and better control the search 

As a customer 

I want to customize the directories which will be searched 

感謝。何らかの形でシステムを使い、それをスパイして、予想されたことが起こったのを見ることは、まったく問題ありません。

"検索するディレクトリをカスタマイズする"場合は、ディレクトリを指定して、ディレクトリが正しく指定されていることを確認できます。これは必ずしもユーザーインターフェイスの使用を意味しません。

Scenario: customize the directories which should be searched 
    Given Thomas wants to search two directories 
    When he selects ./tmp and ./home/thomas 
    Then should ./tmp and ./home/thomas be selected 

この例では、検索し、最終的にそれが検索されることを正確にこれらのディレクトリであることを検証するために、ディレクトリた、私が欲しいものを指定します。関連するファイルシステムがあるかどうかを指定するのではなく、UIの詳細を指定しません。これらのことは、後で使用するいくつかのヘルパーメソッドにスタックすることができます。

これは、コアロジックを確認したり、2つのディレクトリを選択したり、ユーザーインターフェイスからシステムとのやりとりを検証できることを意味します。

まず、コアロジックを確認することです。必要な場合は、UIが存在するときにUIから確認することがあります。