問題タブ [atdd]

私たちの開発では、TDD を使用しているため、次のようなテストがいくつかあります。

ここで書いているテストは「単体テスト」のようなものです。

次に、specs2 が、より表現しやすい別の種類の構文を提供していることがわかりました。これに興味があります。

TDDで試してみたいのですが、すぐにこの種のテストは「受け入れ仕様」であることがわかりました。私の頭に浮かんだ強い質問があります：

「TDD」と言うと、どのようなテストですか? それらは「単体テスト」でなければなりませんか？「受け入れ仕様」を使用して実装を推進することは良い習慣ですか?

機能を定義するための受け入れテスト駆動開発アプローチに移行しています。うまくいっているように見えますが、テスト管理で問題が発生し始めています。現在、SharePoint/Excel を使用して受け入れテストを追跡しています。これは、技術者以外の顧客、QA、および開発者がすべてテストを更新するためです。問題は、テストがコードと共に生きていないことです。そのため、テストはコードとともに分岐/バージョン管理されておらず、すべて非常に手動です。テスト ケース管理ソフトウェア (たとえば、Zephyr、TestRail など) をフルに検討していますが、それは少し重く感じられ、最終的にはテスト データはまだコードと共に生きていません。

開発者以外にも使いやすいが、git で動作する方法でデータを保存するテスト管理アプリケーションはありますか? コードと一緒にテストを維持しようとするのはばかげたことですか?

ありがとう、エリック

ATDD の基本的なサイクルは、受け入れテストを作成した後、その受け入れテストの TDD テストを作成することです。しかし、私の質問は、どの単体テストがどの受け入れテストに関連しているかをどのように指定できるでしょうか? それは、ATDD と TDD を行った機能またはその他の手法によって可能でしょうか?

SpecFlow を使用して、永続化レイヤーと通信する API サービス レイヤーを呼び出しました。私たちのシナリオのほとんどは、API を使用してデータベースをさまざまな状態にセットアップすることで適切にカバーされていますが、失敗状態であるため、API を介してデータベースを取得できないシナリオがいくつかあります。

私たちは、SpecFlow ソリューションが対話するレイヤーを作成できると考えていました。これにより、データベースがその状態に「ファッジ」され、API レイヤーを呼び出して、期待される応答が得られるかどうかを確認できるようになります。しかし、これは BDD に関して正しいのでしょうか? BDD についての私の理解は、メインのハッピー パスと例外パスをテストする ATDD と非常によく似ており、細かい粒度のものは単体テストする必要があります。

API を介して何かを実行できない場合は、BDD シナリオでテストすべきではありませんか?

Robot フレームワークと Python の違いは何ですか? また、Robot フレームワークをテストに使用するために Python 言語をインストールする必要があるのはなぜですか? また、Robot フレームワークはどこで実行すればよいですか? コマンドラインからですか？

知りたいのですが、BDDは受け入れテストレベルでのみ機能しますか? そうでない場合、ユニットテストレベルでも機能しますか? BDD は単体テストについて何か提案がありますか?

ありがとうございました

私たちの新しいプロジェクトでは、BDD/TDD の基礎として使用できる仕様を顧客と一緒に作成する方法として、Gherkin 構文を使用してみたいと思います。

私の考えでは、たとえば、顧客が特定のイベントが発生したときにUI 要素を特定の色にする必要があると言うシナリオにアプローチする方法が明確ではありません。Gherkin 仕様は、thenステップで色の変化をキャプチャしようとする必要がありますか? これは、テスト (Jasmine など) では、UI 要素の変更を生成する変数の値ではなく、UI 要素の色をチェックする必要があるということですか?