4

アプリケーション用の一連のブラックボックス自動テストを作成しています。私は同じデザインの問題にぶつかり続けているので、ここの人々がそれについてどう思うか疑問に思っていました.

基本的に、これは単純な CRUD システムです。議論のために、ユーザー アカウントを作成、表示、編集、および削除する画面をテストしていることを見てみましょう。私がやりたいことは、ユーザーの作成が正しく機能することをテストする 1 つのテスト、ユーザーを表示すると最初に入力したデータと同じデータが表示されることを確認する別のテスト、ユーザーの編集が機能することを確認する別のテスト、そして最後にユーザーの削除がOKであることをテストします。

問題は、そうすると、テストを特定の順序で実行する必要があり、そうしないと機能しないことです。(たとえば、まだ作成されていないユーザーを削除することはできません。) 現在、テスト セットアップでテストに必要なものをすべて作成し、ティアダウンでシステムを一貫した状態に戻す必要があると言う人もいます。しかし、考えてみてください... Create User テストは後でそのユーザーを削除する必要があり、Delete User テストは最初にユーザーを作成する必要があります... したがって、2 つのテストは同じコードになり、唯一の違いは次のとおりです。そのコードがセットアップ/本体/ティアダウンにあるかどうか。それは間違っているようです。

要するに、私はいくつかの選択肢に直面しているように見えますが、それらはすべて壊れているようです:

  1. setup を使用してユーザーを作成し、teardown を使用してそれらを削除します。これにより、ユーザーの作成およびユーザーの削除のすべてのテスト コードがセットアップ / ティアダウン コードとして複製されます。
  2. テストを特定の順序で強制的に実行します。これは、テストは独立して動作し、任意の順序で実行できるという原則に違反しています。
  3. ユーザーの作成、ユーザーの表示、ユーザーの編集、ユーザーの削除をすべて 1 つの巨大なモノリシック ブロックとして行う 1 つの巨大なテストを記述します

ユーザーの作成は簡単なことではないことに注意してください。かなり多くのステップが含まれています。同様に、ユーザーを削除するときは、割り当てられたプロジェクトなどをどうするかを指定する必要があります。これは決して簡単な操作ではありません。

これがホワイト ボックステストである場合、ユーザー アカウント オブジェクトをモックしたり、オブジェクトを保持するデータベースをモックしたり、実際のデータベースをディスク上に作成したりすることもできます。ただし、これらはブラック ボックステストであり、外部のユーザーに表示されるインターフェイスのみをテストします。(つまり、画面上のボタンをクリックします。) アイデアは、[明らかに GUI コマンドを除いて] 変更せずに、システム全体を端から端までテストすることです。

4

1 に答える 1

4

同じ問題があります。私たちは2つの道を歩んできました。テストの 1 つのスタイルでは、テストに必要なデータ (ユーザー、チケットなど) を作成するために提案されたように、セットアップとティアダウンを使用します。もう 1 つのスタイルでは、データベース内の既存のテスト データを使用します。したがって、たとえば、テストが の場合、AdminShouldBeAbleToCreateUserどちらも実行しません。それがテスト自体であるためです。ただし、テストが の場合、ExistingUserShouldBeAbleToCreateTicketテスト データで事前定義されたユーザーUserShouldBeAbleToDeleteOwnTicketを使用し、テストが の場合、事前定義されたユーザーを使用してセットアップでチケットを作成します。

于 2013-07-13T14:40:26.327 に答える