製品を開発してから 2 か月が経ちましたが、単体テストのカバー率が高くなっています。私たちのほとんどは、最初にテストを書き、その後にコードを書いています。これは、赤が先、緑が後というアプローチを使用しているため、テストを信頼できることを意味します。
これまで、私たちは手作業でお客様に機能のデモを行ってきました。しかし、ますます多くの要件をカバーし始めると、機能テストを使用してこれらの要件をカバーすることが必要になりました。
現在、機能テストはありません。
要件を処理するチーム メンバーがいますが、彼は機能テストを作成するのに適していると思います。ただし、私の懸念は、機能の開発と機能テストの作成が同期していないことです。つまり、機能が完全に実装される前にテストが作成されるとは限りません。
今後、機能テストは機能の前に作成するという規則を設ける必要がありますか? 赤が先、緑が後ということです。または、他のアプローチがあります。
あなたが到達したいと説明している方法論は、ビヘイビア駆動開発 (BDD) と呼ばれます。基本的に、機能テストのテスト駆動開発に似ています。要件または動作 (またはユース ケースまたはシナリオ。ただし、自分のショップで要件を指定するかどうかは自由です) は、機能テストの形式で記述され、入口条件と出口条件が完備されており、それを達成するために TDD が繰り返し使用されます。システム内の動作。
BDD をサポートする単純化された (そして軽量な) オープン ソース フレームワークの 1 つは、FitNesseと呼ばれます。これは、要件をキャプチャするための wiki スタイルのエディターです。各要件に要求と結果の例の表を含めると、Fitnesse が自動的にサービスを呼び出してテストします。これは最高のツールではありませんし、拡張性も低いと思いますが、すぐに使い始めることができます。もう 1 つのツール (FitNesse よりも優れていると聞いたことがあります) はsoapUI です。 これははるかに完全であり、欠落しているサービスの代役、負荷テストの実行、テストの編成などを行うことができます。
TDD と BDD の違いの 1 つは、BDD では、動作の性質に応じて、機能テストが完全に自動化されている場合とそうでない場合があることです。自動化すればするほどよいのですが、人間がスクリプトを実行したり、結果を確認したりする方が簡単な場合もあります。BDD に必要なテスト環境も、実際のデータベースとサービスを組み込んだ、より複雑なものになる可能性があります。これは、現実的な方法で動作の完全なテストを実行できることを意味しますが、アプリケーションが依存するリソースでいっぱいのテスト環境を用意する必要があることも意味します。それは悪いことではありません。テストが実際に行われる場所です。
パターンがうまくいかない場合は、自分自身をパターンに閉じ込めるべきではありません (たとえば、最初に赤、後で緑)。あなたの場合、すでに適切な単体テストの範囲が整っているため、機能テストを行う前に機能を整備しても問題はないと思います。
しかし、それは私だけです。筋金入りの TDD:ers は同意しないでしょう。