Gherkin 構文で記述された受け入れテストがいくつかあり、SpecFlow を使用して自動化しています。シナリオの一例 (ガーキンにはありませんが) は、
「昇給率が会社のしきい値を超えているレビューが送信された場合、「昇給承認者」がレビューを承認する必要があります。」
ご覧のとおり、これは特別な条件の例であり、追加の担当者がレビューを承認する必要があります。この例を考えると、次のシナリオを用意する必要がありますか?
会社のしきい値内の昇給率でレビューが送信された場合、「昇給承認者」はレビューを承認する必要はありません。
もしそうなら、カットオフラインはどこですか？明らかに、これは 1 つのシナリオごとに 2 つのシナリオを持つことにつながる可能性があります。すべてのレビュー）
> .. do you have to test the opposite?
従業員がマネージャーまたは上司の息子である場合、承認者ワークフローを必要としないシナリオもある可能性があるため、ビジネス要件があるまではノーと言います。この場合、simple-threshhold-opposite-test はbusinessvalueなしで失敗します。
テストの程度は、時間や正しく行う必要性など、さまざまな要因に依存するため、やみくもにテストすることを決定する前に、これを考慮する必要があります。
あなたが指定したシナリオは、コードを介した 2 つの非常に明確なパスと 2 つの異なる結果を定義しているため、通常は両方をテストする必要があります。
理想的には、既存の機能をテストする既存の一連のテストがあるでしょう。この場合、「昇給承認者」を必要としないしきい値内の昇給である可能性があり、その場合、このテストを再利用できます (回帰テストとして実行)。 ）、しきい値を超える増加のテストのみが必要になります。一連の回帰テストを構築すると、このテストはより迅速になります。
注：使用しているツールに精通していないため、関連する例を挙げることはできません