1

私たちは最近、テストに関する議論を始めました。私たちが望むタイプのテストの 1 つは、ある種の機能テストまたは受け入れテストです。希望は、無駄な開発を削減し、自己検証も行うソフトな生きたドキュメントを持つことです。概念実証として思いついた例は、http クライアントを構築することでした。これを選択したのは、非常に複雑になる可能性があり、注意を怠ると、小さなエッジ ケース ハンドラーなどを追加して数日間開発することになる可能性があるためです。 .

これを念頭に置いて、必要なものだけをカバーする機能のリストを作成しました。この「仕様」を見ると、インターフェイスの抽象化や構成などは含まれていません。実際、優れた流暢なインターフェイスであれば、ほとんどの項目がリストから外れます。

そのため、プロンプトが点滅していて、何を書くべきかわかりません。以前に単体テストを行ったことがありますが、より大きなオブジェクトや、何らかのシナリオを作成してそれが成功することを確認するよりまとまりのある方法でテストするには、これらが不足していることがわかりました。これを単体テストに対する打撃と誤解しないでください。単体テストよりも、私たちに関係があると思います。Anyhoo

頭のてっぺんから、私は次のことを考えています。

  • シナリオを書きます。例は次のようになります。

    Create a new http request. 
This request should should be a GET request.
It should have no body.
It should have reasonable defaults already defined.

  • シナリオを実装します。

    var request = 
new httpRequest().UsingMethod(HttpMethods.Get)
                 .WithDefaultHeaders();

ただ、これには懸念があります。一方で、それは完璧に機能します。私はシナリオを満たしました。さらにシナリオを追加して、他の要件を確認することができます。一方、私は通常、最初にすべてを開発してからテストするので、機能アーキテクチャの制御を失っているように感じます.

私が見つけようとしているのはこれです：

  • このタイプのテストは正常ですか、人々はそれを使用しますか、名前はありますか?

  • 私は正しい道を進んでいますか、それとも大規模なアーキテクチャの仮定を立てることで終わるのでしょうか?

  • この種のテストや仕様を行う場合、アーキテクチャはどこに適合しますか。上記のように完了の定義があるのはいいことですが (仕様は満たされています)、どこかで何らかのアーキテクチャを正しく行う必要がありますか?

ついに。このツールにとらわれないようにしたい。私たちは C# と xUnit を使用しており、ベースラインを把握している間はこれ以上複雑にしたくありません。

4

1 に答える 1

0

それは私にはコンポーネントテストのように聞こえます。HTTP リクエストで考慮すべきことの 1 つは、OK レスポンスを探すだけでなく、簡単なコンテンツ チェックも行うことです。適切な形式の HTML が返されることを期待している場合は、静的なエラー ページに表示される一意の単語またはフレーズを探すか、JSON または XML を期待している場合は、適切な応答がエラーの詩のように見えると考えてください。

于 2013-02-05T17:47:46.933 に答える