私はBertrand Meyer による印刷された記事に出くわしました。彼は仕様からテストを生成できると述べています。私の開発チームはこのようなことはしていませんが、検討するのに良いテクニックのように思えます。仕様からどのようにテストを生成していますか? この方法でプログラムの障害を発見できたことについて、どのように説明しますか?
4 に答える
これは、一連の要件としてテストを開発する非常に賢い方法であるRSpecへの参照である可能性があります。私はまだそれに慣れていますが、何をする必要があるかを定義し、それを確実に実行するのに非常に便利です.
@BertrandMeyerのTimSullivanは、Eiffelにのみ関連付けることができます:)
彼はESpecについて話していると思います。Ruby FolkからRSpecという名前が付けられているので、「非常にインスピレーションを得た」というラベルを付けることができると思います。
スペック次第だと思います。仕様から完全な単体テストを作成するのに十分な仕様である場所では、まだ作業を行っていません。詳細レベルがそこになかっただけです。私のマネージャーは、私たちがそのレベルに指定すれば、スペックをインドに出荷して、安価でコード化できるといつも言っていました;)
それを行うには、私が「アートフォーム」と見なすもの(必ずしも優れたアートではない)から、形式仕様から数学的に導き出されたテストまで、さまざまな方法があります。一日の終わりに、開発チームは、作業しているスケジュールに基づいて何ができるかを決定する必要があります。そうは言っても、仕様に対してソフトウェアをテストできることは良いことです。
あなたのチームだけがあなたのテストの「深さ」を測ることができます、そしてそれはおそらくあなたのスペックがどれだけ良いかによって決まるでしょう。彼らが「ログインUIはキャンセルボタンとログインボタンを提供する必要があり、それらが機能する必要がある」のようなことを言うなら、あなたのテストはかなり一般的なものになるでしょう。ただし、覚えておいてください。非常に一般的なテストでさえ、良いことです。テストは良いことです。あまりにも多くの開発者がテストに関して悪い態度をとっていますが、結局のところ、あなたはうまくいくはずのソフトウェアを出荷しているのです。私にとって、それは多くのことを意味します。
プログラムの障害を見つける際にテストが持つ効果は、テストに入力した詳細によって異なります。テスト手順を仕様に書き込むことの特に優れている点は、各ビルドを前のビルドと同じ詳細レベルでテストできることです(通常は回帰テストと呼ばれます)。