この記事では、
データベースのモッキング機能に関する実例を示しています。
Id、Name、および Address で構成される Customer トランザクションがあるとします。また、新しい顧客をデータベースに挿入するための情報を受け取るプロシージャーもあります。このプロシージャーは、いくつかのチェックを実行し、操作が完了しなかった場合にブール値とエラーメッセージを返します。
これまでに用意したオブジェクトは次のとおりです。
次に、 [ ユニットテストを作成 ] オプションを使用してプロシージャーのユニットテストを作成し、有効な新規顧客、無効な ID (重複) 、空のアドレス、名前など、異なるテストケースを定義します。
テストには特定のデータベース状態が必要になり、実行の間に維持する必要があります。たとえば、有効な顧客を挿入するテスト ケースの場合、最初にテストを実行すると、ID が 36 の顧客が存在しないことを確認したため、テストに合格します。しかし、もう一度実行すると、次のようになります。
ID 36 の顧客を何らかの方法で削除する必要がありますが (いくつかの方法があります) 、テストを実行するたびに同じ操作を行うのではなく、プロシージャー内のチェックが正しいことをテストする必要があります。この場合、データベーススクリプトや手動設定は処理しません。
これがデータベースモッキングの真価です。データを準備したら、テストで [ モックデータを記録 ] オプションを選択します。実行が完了すると、KB に新しいファイルオブジェクトが作成されたことが出力ログに通知されます。この新しいファイルには、データベース レコードに依存しなくても済むようにするモックデータが含まれています。
テストを再度実行して、実行結果が同じであることを確認します。これ以外の場合、「ID 36 の顧客は既に存在します」というエラーが表示されます。
テストの準備ができたら、変更を GeneXus Server にコミットできます。パイプラインスクリプトの構成に応じて、ローカルで記録したモックデータを使用してテストを実行できますが、継続的インテグレーション環境では、結果はコンピューターで取得したものと同じになります。
テーブル構造またはナビゲーションが変更された後は、DB 構文が異なるため、モックデータを更新する必要があります。たとえば、テスト対象のオブジェクトの DB アクセス数が異なる場合や、異なる数の項目属性を変更する場合にも、同じことが当てはまります。モック記録を再実行するために必要な条件を作成する必要があります。