タグ付けされた質問 「bdd」

私は現在、キュウリのようなBDDテストフレームワークを調査しています。 機能ファイルはシンプルな自然言語で記述されているため、わかりやすさが向上し、明確なビジョンが得られます しかし、自然言語は、ソフトウェアエンジニアリングで発生する問題のほとんどの原因ではありませんか？ 自然言語があいまいであり、それがクライアントの要件の誤解と開発者の理解のために多くのソフトウェアプロジェクトが失敗する理由です。私はここでニッチを取得しません。 はい、テストを小さな単純で実行可能なアクションに分解することは理にかなっており、ある程度の明快さを提供しますが、全体として生産性を向上させますか？ PS：私は専門家ではないので、ここでは意見を述べていません。私はその概念を理解したいだけです。

9 bdd  cucumber 

過去数週間、私はテスト方法論のギャップを埋める方法を検討し、検討してきました。簡単に言うと、単体テストは小さすぎ、従来の統合テストは大きすぎます。 頻繁にシナリオがアップになるAとB、両方の使用コンポーネントをC。ただしA、のB要件は少し異なり、についての仮定も少し異なりますC。私が開発者である場合A、どこでどのように私の想定をテストするのCですか？ 明らかにAモックされた仮定Cを使用Aした単体テストは、単独でのテストには適していますが、仮定自体はテストしません。 別の可能性は、の単体テストを追加することですC。ただし、これはA開発段階ではありますがC、仮定を進化させてテストを変更するのは非常にA不格好なため、これは理想的ではありません。実際、A開発者はC（たとえば、外部ライブラリ）の単体テストに適切にアクセスできない場合もあります。 これをより具体的な例でフレーム化するには：これがノードアプリケーションであると想定します。 AにB依存しC、（特に）ファイルを読み取り、ファイルの内容をに渡されたオブジェクトに格納しますC。最初Cは、処理するすべてのファイルが小さく、重大なブロックなしで同期的に読み取ることができます。ただし、の開発者Bは、自分のファイルが巨大になりC、非同期読み取りに切り替える必要があることを認識しています。これにより、で散発的な同期バグが発生します。Aこれは、Cファイルを同期的に読み取ることを前提としています。 これは、完全な統合テストから追跡するのが非常に難しいことで有名なタイプのバグであり、統合テストではまったく検出されない可能性があります。またA、Asの前提条件がモックされているため、sの単体テストでは捕捉されません。ただし、「」Aおよび「」のみを実行する「ミニ」統合テストで簡単に検出できますC。 このタイプのテストへの参照はわずかしか見つかりませんでした。小型の統合、コンポーネント統合テスト、ユニット統合テスト。また、正式なTDD単体テストではなく、BDDテストの方向性にも関係しています。 このテストギャップをどのように埋めますか？具体的には、そのようなテストはどこに置くのですか？どのように私はの入力あざけりないAとC「ミニ」統合テストのために？そして、これらのテストと単体テストの間でテストの懸念を分離するためにどれだけの努力を払う必要がありますか？または、テストのギャップを埋めるためのより良い方法はありますか？

9 unit-testing  testing  node.js  integration-tests  bdd 

今日、仕様ワークショップを開催することにより、ソフトウェア開発プロセスにBDDを導入しようとしました。 このワークショップには、2人の開発者、1人のテスター、1人のビジネスアナリストがいました。ワークショップは1時間30分続き、その終わりまでに、新機能のいくつかのBDDシナリオを理解することができました。私たちは見逃す可能性のあるシナリオと難しいシナリオを見つけることに焦点を当てようとしました。 ワークショップの最後には、実際にワークショップに不満を抱く人もいました。 ある開発者は、ビジネスアナリストから直接シナリオを渡され、彼女と一緒にそれらをレビューするのに慣れていたので、自分の時間を浪費していると感じました。ビジネスアナリストは、私たちのシナリオのカバレッジに自信がありませんでした（他の重要なことを見逃している可能性があると感じていました）。しかし、より重要なのは、このワークショップは自分でこれらのシナリオすべてを理解できたので、時間の無駄でもあると感じました。そして、より短い期間で。 この実験的なワークショップは1時間30分続きましたが、その終わりまでに、私たちがやったことについて十分な自信が持てませんでした。 BAの脳からのルール。 だから私の質問は、そのようなワークショップが実際にどのように機能するかです。理論的には、開発する新しい機能がある場合、ツリー「amigos」（dev / tester / ba）を同じ部屋に配置して、例を使用して新しい機能のさまざまな要件を共同で作成できるようにします。そのメリットはすべてわかります。特に知識の共有と共通の製品/最終目標/達成済みのビジョンに関して。 この実験から、私たちの結論は、実際にはそれ以上に効果的な費用であるということであった最初の例で彼自身の仕事にBAを持っているだけで、その後見直し/ 3「アミーゴ」で再加工するシナリオを持っています。BAが自分で作業できるようにすることで、実際に何かを見落とすことが少なくなり、後でシナリオを確認して再確認できるようになります。新しい機能のすべての要件を真剣にカバーするには、単純な1回のブレインストーミング/意図的なディスカバリーセッションで十分だとは考えていません。ビジネスアナリストは、実際にはその種のものに最適な人物です。私たちにできる最善のことは、彼女が書いたものをレビューして、共通の理解があるかどうかを確認することです（それにより、彼女のシナリオの一部を書き直したり、見逃した可能性のある新しいシナリオを追加したりできます）。 それで、実際にそれを効果的に機能させるにはどうすればよいですか？

9 bdd 

私はBDDから始めて、これが私の話です。 Feature: Months and days to days In order to see months and days as days As a date conversion fan I need a webpage where users can enter days and months and convert them to days. 疑問があります... 何かをコーディングする前にシナリオを書くべきでしょうか、それとも最初にシナリオを書いてからコードを書いたり、シナリオをもう一度書いてからコードを書いたりするべきでしょうか... 以前にシナリオを作成する必要がある場合、私のステップを承認しても製品コードはまだ完了しませんか？ いつコードをリファクタリングする必要がありますか？機能が完了した後、または各シナリオの実装後？

9 programming-practices  tdd  refactoring  development-methodologies  bdd 

私のチームは、IDEに統合されるドメイン固有言語（DSL）のコンパイラを作成しています。現在、私たちはコンパイラーの分析フェーズに集中しています。リアルタイムのパフォーマンスと非常に詳細なエラー/警告/メッセージ情報が必要なため、既存のパーサージェネレーター（ANTLRなど）は使用していません。我々は持っています 各クラスは、言語の具体的な構文ツリーのノードを表します。 各ノードの注釈として機能するクラス（つまり、エラーや追加情報）、および 具体的な構文ツリー（つまり、レクサー、パーサー、文字列のキャッシュ、構文ビジター）を構築および操作する内部クラス。 テストを整理するための全体的な戦略を決定しようとしています。当社は、行動主導型開発（BDD）とドメイン主導型設計（DDD）を推進しています。弊社のドメイン用にDSLを構築していますが、コンパイラのドメインはプログラミング言語です。 私たちはまだコンパイラーを構築中であり、すでにいくつかのテストを行っています。100％ステートメントカバレッジを目指しています。 現在、構文ツリービルダーにソースコードを入力し、結果の構文ツリーのすべてのノードの各プロパティで検証を実行して、期待される情報（行番号、関連するエラー、子/親トークン、トークンの幅、トークンのタイプなど）。ここで、各ノードは独自のクラスであり、ノードに添付された特定の注釈とエラーは個別のクラスであるため、このテストは多くのクラスを参照することになります。 現在、入力（文字列）と出力（トークンのリスト）を他のクラス（構文ツリーのノードのクラスなど）から分離できるレクサーなどの特定のクラスのテストがあります。これらのテストはより詳細です。 これで、すぐ上の段落のテストを、テスト中のクラス（レクサー、文字列キャッシュなど）に対応させることができます。ただし、上記の2番目の段落のテストは、コンパイラーの分析フェーズ全体を実際にテストします。つまり、入力ソースコードが与えられている場合、各テストは構文ツリーに対して300以上のアサーションを持つことができます。テストは、分析フェーズの動作のためのものです。 これは適切なテスト戦略ですか？そうでない場合、私たちは何を別の方法で行うべきですか？テストにはどのような組織戦略を使用する必要がありますか？

8 unit-testing  compiler  domain-driven-design  bdd