1

66 以上のシナリオを含む Cucumber 機能ファイルがあります。機能ファイルのタイトルは、シナリオの内容を表しています。

でも66（200歩）は結構な数に感じます。これは、機能のタイトルが広すぎることを示唆していますか?

(ベスト プラクティスの観点から) 1 つの機能ファイルに含める必要があるシナリオの最大数は?

前もって感謝します ：）

4

2 に答える 2

4

システムと機能ファイルはわかりませんが、シナリオとその目的について誤解があると断言できます。

シナリオの目的は、例によって機能を明確にすることです。通常、人々はすべてのユース ケースをカバーするシナリオを作成する傾向があります。そのようにシナリオを実行すると、この機能は人間が判読できる能力を失います。

受け入れテストは、作成するのにも変更するのにも費用がかかることに注意してください。最低限のシナリオを書きます。機能を理解する上で追加の価値をもたらさないシナリオがある場合、そのシナリオは存在すべきではありません。すべてのユース ケースを下位レベルのテスト (単体テスト) に移動します。

ほとんどの場合、この機能には、ユニット単位のシナリオ数、または複雑な機能の場合は数十のシナリオがあります。

編集: シナリオの数が 10 に近づく場合は、フィーチャー ファイルを、フィーチャーのより深い部分を説明するファイルに分割します。

于 2016-03-12T12:11:51.043 に答える
1

はい、200 というのは、1 つのファイルのシナリオ数が異常に多いことです。ファイル内の特定のシナリオを見つけたり、整理したりするのは難しい場合があります。(複数の小さなファイルの方が整理しやすいです。ファイルのディレクトリは、コメント付きの長いファイルや、さらに悪いことにコメントなしの順序付けスキームよりも理解しやすく、維持しやすいです。) ファイルの実行にも長い時間がかかります。開発を難しくします。

さらに重要なことは、1 つの機能に対して 200 のシナリオがあるということは、その機能が非常に複雑であるか、非常に広範であることを意味する可能性があるということです。どちらの場合も、おそらく複数の小さな機能ファイルに分割できます。また、シナリオが多すぎることを意味する場合もあります。一部の変数のすべての値に対するシナリオ (単一のシナリオを記述し、異なる値について心配する必要がない場合があります) や、すべての機能のすべての詳細に対するシナリオ (小規模な単体テストを記述する方がよい場合があります) があります。詳細については、より集中的かつ迅速に）。

しかし、コード片のサイズに関する他のソフトウェア メトリクスと同様に、典型的なサイズがあるかもしれませんが、すべての問題は異なります。あなたの機能は本当に複雑かもしれません。ドメインを理解し、機能ファイルを確認しないと、何とも言えません。

于 2016-03-12T05:04:40.030 に答える