Yandexでのテスト：合成テストデータを記述および生成するObjectBuilder

こんにちは 私の名前はデニス・チェルニレフスキーです。 Yandexでは、ディスプレイ広告システムの自動化テストグループを率いています。 Yandexと以前の場所での作業の過程で、10人以上のチームを率い、プロセスを確立し、さまざまなシステムのテストを自動化するアプローチを考え出しました。 そして、これらのプロジェクトのそれぞれで、テストデータの準備について考える必要があったのです。 かなり長い熟考の結果に基づいて、一般にこの問題を解決し、さまざまなプロジェクトに適用できるアプローチが考案されました。 テスト環境で説明するという事実に加えて、ここで詳細を説明することにしました。



ちなみに、テスター向けのイベントに参加できない場合は、11月30日（土）11:00に放送が始まります。







この記事は、Yandexディスプレイ広告システムのテストを自動化するプロセスで、合成テストデータの複雑なセットを準備する問題を解決した経験に基づいています。 もちろん、このようなタスクに最初に遭遇したわけではありません。そのため、まず、既存のアプローチとソリューションを分析しました。 その結果、ソリューションはObjectBuildersライブラリ（Python）であり、階層的に関連するデータセットを作成する必要があるプロジェクトで使用できます。 これらの関係、パラメーター、およびプロパティを設定できます。 また、副作用としていくつかのボーナスを提供します。



以下では、このツールの操作をわかりやすい例で説明し、表示しようとしますが、最初に、解決しようとしている問題とその解決策の可能性について詳しく説明します。

目的：ディスプレイ広告システムをテストする必要があります。

したがって、「テストのために、多対多、多対1、1対多、1対1、および10のいずれかによって相互接続された30（50、100 ...）オブジェクトをシステムに作成する必要がある場合の対処方法20、40 ...）それぞれのプロパティ？ ''



ここで、すぐに予約を行います。それは、機能的なブラックボックステストを確立することです-単体テストまたはロードなし。



それで、どのようにそれを解決しますか。 OK どのようなシステムがありますか？ ええ、広告キャンペーンに関するデータを含むデータベース、広告コンテストを実施して統計をカウントするためのバックエンド、httpリクエストを受け入れ、特定の形式で回答を提供するフロントエンド。



たとえば、インフラストラクチャを構築し、スタンドを立ち上げ、CIをセットアップし、テストをPythonで記述すれば、すべてうまくいきます！ Python以来、テストにはPyTestを選択します。便利で美しいJUnit形式のレポート、プラグインの形で機能を簡単に拡張できます。 それだけです、テストを書くことができます！ 現実には、もちろん、数年で上記のすべてを取りましたが、今はそれについて話していません。



すべてが簡単なようです：さまざまなパラメーターで1つまたは複数の広告キャンペーンを開始し、システムを起動し、httpリクエストをプルし、応答を受信し、期待どおりに待機していることを確認し、おそらくログ、統計などのいくつかの副次的なことをチェックしましたd。



システムに少なくとも1つのバナーを表示させようとして、 1日が1 週間を経過しました。 システムで1つの広告キャンペーンを作成し、少なくとも1つのバナーを表示するには、それぞれが15個のパラメーターを持つ30個のオブジェクトをデータベースに打ち込む必要があり、それらが互いに正しく接続され、異なるテストデータが互いに影響を与えないようにする必要があることが判明しました。 まあ、また、テストを連続して数回実行できることが望ましいです！



しかし、結局のところ、各テストでは、さまざまな広告キャンペーン、さらにはいくつかの、さらにはさまざまな設定が必要です。







そして、それは私たちがヒットしているようです。 しかし、あなたは何かをする必要があります。



考えて、作成手順とテストデータ自体の要件の次のリストを作成しました。

1. 作成されたデータは、システムの正しい動作を保証する必要があります。
2. 接続のロジックまたはオブジェクトのパラメーターを変更するとき（たとえば、新しい機能を開発するとき）、これらのオブジェクトを使用してすべてのテストを簡単かつ迅速に修正できる必要があります。 将来的には軽いテストのサポートが必要です。
3. あるテストのデータが別のテストの動作に影響を与えることはありません。
4. テストを数回再起動することができるはずです。 したがって、データは毎回元の状態に戻すか、再生成する必要があります。
5. このデータの説明から、それらが他のすべてのケースとどのように正確に異なるのか、なぜこのテストにそのような設定が必要なのかを理解できるはずです。

ソリューションオプション

実稼働システムから既存のデータを取得することはできません。

• それらは変化する可能性があり、テストは予期せず動作します。 これらの変更に気付くことは困難です（テストは引き続き機能しますが、必要なものはチェックしません）。
• それらは消えるかもしれません-テストは完全に動作を停止します。
• 1つのテストで別のテストで使用されるデータを変更できます
• 一般に、各テストで何がどのように使用されるかは明確ではありません
• このソリューションの唯一の利点は、データを実際に準備するためのコストがないことです。

特定のテストごとに事前にデータを含むデータベースを準備するオプションも適切ではありません。

難しい：パラメーターとオブジェクトが多すぎる

• データを作成するときに簡単に間違いを犯す可能性があり、そうするとエラーを見つけるのが難しくなります。
• 特定のデータセットのどのパラメーターがテストの動作に影響するかを正確に理解することは困難です（テストが何を、なぜチェックするのかを理解することは困難です）
• テストを再開することはできません-元のデータセットのパラメーターを変更できます。開始するたびにデータをリロードする必要があります。
• テストされた製品のロジックを変更する場合、変更によって影響を受ける各オブジェクトは異なるテストで発生する可能性があるため、手動で変更する必要があります。
• オプション1と比較すると、このソリューションには1つの利点があります。テストが互いに影響しないように、独立したデータを準備できます。

これらのオプションはほとんどの要件に違反しているため、すぐに拒否しました。 Builderパターンを使用することをお勧めします。 その長所と短所をより詳細に検討してください。

ビルダーパターン、またはなぜそれをまだ使用しなかったのか

Builderは、オブジェクトの構築とプレゼンテーションを分離できるデザインテンプレートです。 詳細は説明しません。 彼の主なアイデアは、直感的なインターフェイスを介して他のクラスのオブジェクトを作成できるクラスを作成することだけだと言えます。 したがって、ビルダーはオブジェクトの作成と構成のロジック全体をカプセル化します。



Wikiの例から、このアプローチがすべての要件を満たしていることは明らかです。

• 作成されたデータは、システムの正しい動作を保証しますか？ はい、ビルダー内のオブジェクトの構成のロジックを正しく記述することで、作成されたオブジェクトが正しい関係とパラメーターを持っていることを確認できます
• 接続のロジックまたはオブジェクトのパラメーターを変更するときに、これらのオブジェクトを使用してすべてのテストを簡単かつ迅速に変更することは可能ですか？ はい、ビルダーでオブジェクトを作成するロジックがカプセル化されているため、このロジックは1か所でのみ変更できます。つまり、別のレイヤーで選択します。
• 1つのテストからのデータは、他のテストの動作に影響しませんか？ はい。ビルダーの助けを借りて、各テストの開始時に独自のオブジェクトセットを生成し、既存のオブジェクトを使用しないためです。
• テストを数回再開することは可能ですか？ はい、ビルダー内で、たとえば一意の名前またはIDを与えるたびに、一意のオブジェクトを作成するロジックを実装できます。
• これらのデータを記述して、他のすべてのケースとどのように異なるのか、このテストにこのような設定が正確に必要な理由を理解することは可能ですか？ うーん、ほとんど。 一部のオブジェクトの作成は、ビルダーを使用して一連のメソッドを呼び出すように見えます。 適切なネーミングにより、構成内容を直感的に理解できます。

いいね！



さらに、Builderを使用して複合オブジェクトを作成できます。 つまり、単一の論理オブジェクトとして解釈できる関連オブジェクトのグラフ全体。 相互に異なるタイプの関係を持つ多数のオブジェクトを作成し、オブジェクトのツリー全体とその個々のコンポーネントのパラメーターを単一の方法で構成する必要があります。



すべてがうまくいくように見えますが、これらのパターンには欠点があります。オブジェクトのタイプごとに 、独自のビルダーと、場合によっては独自のコンポジットを個別のクラスの形式で実装する必要があります 。 また、作成するオブジェクト、それらの関係、およびプロパティを変更できるメソッドを記述する必要があります。



怠け者なので、Builderが機能し、それを簡単に変更できることに基づいて、データモデルを何らかの形で正式に記述することは素晴らしいことだと考えました。



その結果、PythonのObjectBuilderと呼ばれる小さなライブラリができました。 関連するオブジェクトのグラフを作成し、オブジェクト自体の関係とプロパティを管理し、パッチの形でデフォルト設定に適用された変更を記憶し、将来再利用できます。

少しの理論とアプローチの説明

前述のように、テストシステムは、特定のパラメーターセットを持つ相互接続されたオブジェクトセットで動作します（これがほとんどのシステムの動作です）。 これらのオブジェクトとその接続は、グラフまたはツリーの形で表すことができます（頂点-オブジェクト、エッジ-オブジェクト間の接続）。 実際、私たちのタスクは、特定のテストごとにオブジェクトとそのパラメーターのグラフを作成することです。



ここで次の事実が役立ちます。テストを慎重に記述し、各テストで機能のごく一部のみをテストすると、ほとんどのテストでグラフがテスト対象のパラメーター/リンクに一致します。



さらに、テストでは、その動作に影響するすべてのパラメーターの値を常に設定する必要があります。他のすべてのパラメーターは気にしません-主なことは、それが機能することです。 そうではなく、まだ影響を与えるパラメーターがある場合は、前の段落を参照してください-それらを設定する必要があります！ テストで一度に多くの機能をチェックする場合、多くの影響力のあるパラメーターがありますが、特定の機能をテストする場合は十分ではありません。

これは、最も一般的に使用されるグラフテンプレートとパラメーターの一部を事前に修正し、各テストで少しだけ「パッチ」（パッチ）できることを意味します。



さらに、構成に関する知識を蓄積し、さまざまな組み合わせでグラフの「パッチ」を再利用することは素晴らしいことです。 システムに関する知識を蓄積します。これにより、将来（忘れた人または知らなかった人）が入力時にシステムに提供されたデータを使用してシステムがどのように動作するかを理解できるようになります。



実際、Builderパターンを「裏返し」にすることを決定し、特定のオブジェクトの作成ではなく、それらからの接続されたグラフの後続の構築を記述し始めましたが、このグラフとその頂点および接続に変更を適用して、オブジェクトのグラフの構築を開始しました。

簡単な例-自動車工場

広告システムをテストする最初のタスクはかなり面倒で、ほとんどの人にとって理解できない用語が多いため、次の例を使用してライブラリの作業をさらに説明します。



自動車工場があるとします。 それをテストする必要があります。つまり、コンベア制御コンピューターに車の構成を提出し、組み立てられて何が出力されるかを確認する必要があります。



入力にさまざまな車両構成を提供します。 各構成は次のパーツで構成されています：シャーシ（乗用車、クロスカントリー）、エンジン（タイプ：ディーゼルまたはガソリンと容量）、車輪（車輪の数、直径、鋳造または刻印）、車体（セダン、クーペ、コンバーチブル、全地形型車両）、ギアボックス（手動、自動）。 理想的には、可能なすべての正しい組み合わせをチェックする必要があります（TKで禁止されている組み合わせを除く）。

工場で異なる車を生産できることは明らかですが、一部の車は他の車よりも一般的です。 一般的なロジックと市場の要件に基づいて、ほとんどの場合、4輪、セダン、15インチの刻印付き車輪、1.6ガソリンエンジン、およびマニュアルギアボックスを備えた車を所有すると想定するのは理にかなっています。



少なくとも4％のホイールとセダンのボディが90％になります！ これが基本設定になります。 残りのパラメーターは、同じ原則に従って選択されます。



また、各構成の機能の範囲を検討する価値があります。つまり、ほとんどのチェックが何らかの構成に該当する場合、それを基本構成として選択する必要があります。 言い換えれば、市場の要件にもかかわらずテールとたてがみでSUVをテストする場合、この構成はテストで最も頻繁に発生するため、基本的な構成になります。



さらに、基本構成の一部のパラメーターのみを変更すれば、さまざまな車を取得できます。 ライブラリでこれらの原則がどのように実装されているかを見てみましょう。

ObjectBuildersライブラリの実装と使用

ツールは2つのレベルで機能します。

1. 構成 -オブジェクト間の関係を設定し、オブジェクト自体を生成するためのツールを提供します。
2. 修飾子 -オブジェクトのグラフにパッチ（修飾子）を記述して適用するためのツールを提供します。

修飾子は、次の2つのタイプに分けられます。

1. InstanceModifiers-オブジェクト修飾子。
2. ConstructModifiers-修飾子を作成します。

たとえば。

class Bar: bar = 1 class Foo: baz = 10 bars = Collection(Bar) my_foo = Builder(Foo).withA(NumberOf(Foo.bars, 5)).build()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、 bars = Collection(Bar)



の構築はレベル1です。クラスFooには、BarのN個のオブジェクトを含めることができると言います。 これらのオブジェクトにはmy_foo.bars[i]



介してアクセスできます。 また、 NumberOf(Foo.bars, 5)



コンストラクトNumberOf(Foo.bars, 5)



はレベル2です。5つのBarオブジェクトが内部にあるFooオブジェクトを取得します。



デフォルトでは、2つのオブジェクトのグラフが作成されます。Fooと、1つの要素で構成されるネストされたBarオブジェクトのコレクションです。

NumberOf(Foo.bars, 5)



はNumberOf(Foo.bars, 5)



つのBarオブジェクトがFooオブジェクトに埋め込まれるようにグラフに適用できる修飾子です。



自動車工場に戻りましょう。

オブジェクトモデル

最初に、ファクトリが操作するオブジェクトのクラスとそのプロパティを記述する必要があります。

 CHASSIS_LIGHT = 0 #  CHASSIS_HEAVY = 1 #  ENGINE_PETROL = 0 #  ENGINE_DIESEL = 1 #  WHEEL_STAMPED = 0 #  WHEEL_ALLOY = 1 #  BODY_SEDAN = 0 #  BODY_COUPE = 1 #  BODY_CABRIO = 2 #  BODY_HEAVY = 3 #  TRANSMISSION_MANUAL = 0 #  TRANSMISSION_AUTO = 1 #  # class Chassis: type = CHASSIS_LIGHT # class Engine: type = ENGINE_PETROL volume = 1.6 # class Wheel: radius = 15 type = WHEEL_STAMPED # class Body: type = BODY_SEDAN number = ??? #      .         . #  class Transmission: type = TRANSMISSION_MANUAL # #       .  -   /    . class Spoiler: foo = None
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いいね！



ここで、クラスのフィールドを初期化する値は、最も一般的な構成に基づいて選択されました。 現在、オブジェクトと動的パラメーターの間には十分な接続がありません。個々の部品が車内でどのように組み立てられているかを示し、パラメーターを指定する必要があります。



たとえば。

 chassis = Chassis() wheels = [Wheel() for _ in range(4)] engine = Engine() body = Body() ... chassis.wheels = wheels chassis.engine = engine engine.chassis = chassis chassis.body = body body.number = random() ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

小さなグラフの場合、これは簡単です。 グラフに数十のオブジェクトと多くのパラメータがある場合、非常に高価になります。 これを容易にするために、ObjectBuildersはコンストラクトを提供します。

構築物

上記では、Collection（）構造を使用した短いFoo-Barの例が既にありました。

私たちのライブラリには、さまざまなニーズに応じて、いくつかの異なるタイプのデザインがあります。

クラスコレクション（typeToBuild、number = 1）

タイプtypeToBuildのオブジェクトのコレクション。 Builder.build（）を呼び出した後、この構造はtypeToBuild型のオブジェクトのリストに変わります。 デフォルトでは、オブジェクトの数= 1

クラスUnique（typeToBuild）

Builder.build（）を呼び出した後、typeToBuild型の一意のオブジェクトに変わります。 グラフのどこかにtypeToBuild型のオブジェクトが既に存在する場合でも、新しいオブジェクトを生成するという意味でユニークです。

再利用クラス（typeToBuild、ローカル= False、キー= []）

Uniqueコンストラクトとは対照的に、グラフにtypeToBuild型のオブジェクトが既に存在する場合はそれが使用され、存在しない場合は新しいオブジェクトが作成されます。 この場合、keysパラメーターを使用して、オブジェクトを同じと見なすためにtypeToBuildクラスのどのフィールドが一致する必要があるかを指定できます。

たぶんクラス（構築）

この設計では、別のオブジェクト（およびこのオブジェクト自体）との通信が存在する場合と存在しない場合があります。 デフォルトでは、 Builder.build()



呼び出すとBuilder.build()



Noneに変換されます。 これは、以下で説明するEnabled()



修飾子によって有効になります。

クラスRandom（開始= 1、終了= 100500、パターン=なし）

build()



ステージでのこの構造は、開始から終了までランダムなintに変換されるか、パターンが指定されている場合は文字列に変換されます。 パターンには1つのマーカー％dが含まれている必要があり、その代わりに開始から終了までの乱数が置き換えられます。

クラスUplink（）

foo.bar.foo = fooのように、双方向のオブジェクトの接続を設定できます。



オブジェクトの相互関係に関する情報が含まれるように、Constructsを使用してモデルを書き換えてみましょう。

 # class Chassis: type = CHASSIS_LIGHT **engine = Unique(Engine)** **body = Unique(Body)** **wheels = Collection(Wheel, number=4)** **transmission = Reused(Transmission)** # class Engine: type = ENGINE_PETROL volume = 1.6 **transmission = Reused(Transmission)** # class Wheel: radius = 15 type = WHEEL_STAMPED **transmission = Reused(Transmission)** # class Body: type = BODY_SEDAN number = **Random()** #      .         . spoiler = **Maybe(Unique(Spoiler))** #     . - . #  class Transmission: type = TRANSMISSION_MANUAL # class Spoiler: foo = None
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、次のことを説明しました。

• シャーシに取り付け：エンジン、ボディ、ホイール、トランスミッション。
• いくつかのホイールが接続されています-4（デフォルトでは、後で動的に変更することが可能です）。
• シャシー、エンジン、ホイールはトランスミッションを自分自身に取り付けます。 そして、まったく同じです。 これは、再利用された設計によって証明されています。
• スポイラーをボディに取り付けることができます（オプションとして、デフォルトでは存在しません）。
• 車体番号は、車両の組み立て中に生成されます。
• 他のすべてのパラメーターはデフォルトで設定されています（ただし、後で動的に設定することもできます）。

これで何をするのでしょうか？ これで、1回の呼び出しで本格的な車を入手できます！ 基本に忠実。

 car = Builder(Chassis).build()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、オブジェクトタイプはシャーシです。

 >>>car.engine.volume 1.6 >>>car.wheels[0].radius 15 >>>car.body.spoiler None
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあなど。



つまり、実際には、シャーシタイプのオブジェクトに加えて、シャーシタイプのオブジェクトに関連付けられているすべてのオブジェクト（エンジン、ホイールx 4、ボディ、トランスミッション）が作成されます。 デフォルトでは、Construct Maybe（）はオブジェクトを作成しませんが、Noneに変換されるため、Spoilerオブジェクトは作成されません。



一般に、任意の部分（グラフの最上部）から車の組み立てを開始し、任意のクラスをBuilder（typeToBuild）に渡します。

しかし、グラフには有向エッジがあるため、グラフは最初の頂点から到達できる頂点のみで構築されます。



現在の実装では、シャーシ上部からすべてのピーク、エンジン上部からトランスミッションのみ、およびボディ上部からスポイラーのみに到達できます。



たとえば、次のとおりです。

 >>>engine = Builder(Engine).build() >>>engine.trasmission.type == TRANSMISSION_MANUAL True >>>engine.transmission.engine AttributeError: Transmission instance has no attribute 'engine'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、これらの2つのオブジェクトのみが作成されます。



いずれかの部品から本格的な自動車の組み立てを開始できるようにするには、双方向の通信に合格する必要があります。

 # class Chassis: type = CHASSIS_LIGHT engine = Unique(Engine) body = Unique(Body) wheels = Collection(Wheel, number=4) transmission = Reused(Transmission) # class Engine: type = ENGINE_PETROL volume = 1.6 transmission = Reused(Transmission) **chassis = Uplink()** **Engine.chassis.linksTo(Chassis, Chassis.engine)** # class Wheel: radius = 15 type = WHEEL_STAMPED transmission = Reused(Transmission) **chassis = Uplink()** **Wheel.chassis.linksTo(Chassis, Chassis.wheels)** # class Body: type = BODY_SEDAN number = Random() #      .         . spoiler = Maybe(Unique(Spoiler)) #     . - . **chassis = Uplink()** **Body.chassis.linksTo(Chassis, Chassis.body)** #  class Transmission: type = TRANSMISSION_MANUAL **chassis = Uplink()** **engine = Uplink()** **Transmission.chassis.linksTo(Chassis, Chassis.transmission)** **Transmission.engine.linksTo(Engine, Engine.transmission)** # class Spoiler: foo = None **body = Uplink()** **Spoiler.body.linksTo(Body, Body.spoiler)**
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、Builder（typeToBuild）.build（）を呼び出すときに、どの部分からでも車を組み立てることができます！ この場合：

 >>>engine = Builder(Engine).build() >>>engine.transmission.chassis.engine == engine True >>>engine.transmission.chassis.wheels[0].transmission.engine == engine True
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ビルダーは、接続（アップリンクを含む）を通過して、必要なすべてのオブジェクトを作成し、モデルの使用を簡素化します。

たとえば、エンジンタイプのオブジェクトを使用する場合、Builder（エンジン）を使用する方が便利ですが、同時に必要なオブジェクトがすべて作成され、相互にリンクされます。



そのため、テストシステムのオブジェクトモデルを車全体で構築して、便利に記述する方法を検討しました。 しかし、この車はまだベースにあります。

修飾子

ObjectBuildersライブラリのオブジェクトのグラフの基本設定を変更するために、いくつかのタイプの修飾子が提供されています。 前述のように、修飾子はInstanceModifierとConstructModifierの2つのタイプに分けられます。

• InstanceModifierを使用すると、値で表されるオブジェクトのフィールドを変更したり、完成したオブジェクトに対していくつかのアクションを実行したりできます。
• ConstructModifierを使用すると、クラスの一部のフィールドに割り当てられているConstructsオブジェクトのパラメーターを変更できます。

すべての修飾子とその機能のリストを検討してください（それらの作業は例を使用して説明します）。

クラスInstanceModifier（classToRunOn）

実際、最初で唯一の（これまでのところ）InstanceModifierレベル修飾子。 オブジェクトのフィールドの値を変更したり、オブジェクトに対して何らかのアクションを実行したりできます。 Builder.build()



を呼び出すと、オブジェクトグラフのclassToRunOnタイプの各オブジェクトで実行されます。



2つの方法があります。

• def thatSets(self, **kwargs)
  
  
  
  -オブジェクトのフィールドの値を変更できます。 key = valueのペアは引数として渡されます。keyは、値の値を割り当てる必要があるclassToRunOn型のオブジェクトのフィールドの名前です。
• def thatDoes(self, action)
  
  
  
  -classToRunOnタイプのオブジェクトに対して何らかのアクションを実行できます。 action-classToRunOn型のオブジェクトを引数として取るメソッド。

クラスEnabled（what）

ConstructModifierレベル修飾子。 Maybeをアクティブ状態にして、Builder.build（）を呼び出したときにオブジェクトの作成を開始できるようにします。 何 -多分構築します。 たとえば、車に関するこの例のBody.spoiler。

与えられたクラス（構築、値）

ConstructModifierレベル修飾子。 グラフを作成する段階で、Construct（what）を特定のオブジェクトまたは値（value）に置き換えることができます。

クラスHaveIn（what、*インスタンス）

ConstructModifierレベル修飾子。 コレクションの構築（what）で使用され、特定のオブジェクト（*インスタンス）をそれらに追加できます。

または、*インスタンス要素の1つがintの場合、コレクションのサイズはこのintの値だけ増加します。 この場合、Collectionデザインによって生成されたオブジェクトの数は、明示的に追加したオブジェクトの数だけ減少します。

クラスNumberOf（何、量）

ConstructModifierレベル修飾子。 コレクションの構成（what）で使用され、サイズによってサイズを変更できます。

クラスOneOf（what、*修飾子）

ConstructModifierレベル修飾子。 コレクションの構成（what）で使用され、コレクション内のオブジェクトの1つに一連の修飾子*修飾子を適用できます。 実際、現時点では-これは利用可能な修飾子のセット全体です。 グラフの基本設定のほとんどすべての変更を簡単に説明できます。



Builder.withA（*修飾子）メソッドを呼び出すことにより、アセンブリ段階でオブジェクトのグラフに修飾子が適用されます。



例とともに修飾子の機能を検討してください。



例1.スポイラー付きの車が欲しい！

 spoiler_option = Enabled(Body.spoiler) car = Builder(Chassis).withA(spoiler_option).build() >>>car.body.spoiler is not None True
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例2. 6リットルのディーゼルエンジンを搭載した自動車が必要です。

 big_diesel = InstanceModifier(Engine).thatSets(type=ENGINE_DIESEL, volume=6.0) car = Builder(Chassis).withA(big_diesel).build() >>>car.engine.volume == 6.0 True >>>car.engine.type == ENGINE_DIESEL True
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

InstanceModifier.thatDoes（）を使用して同じことができます。

 def make_big_engine(engine): engine.type = ENGINE_DIESEL engine.volume = 6.0 big_diesel = InstanceModifier(Engine).thatDoes(make_big_engine)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

make_big_engineメソッドでは計算を実行したり条件を実装したりできるため、通常、テスト実行段階で何らかの方法でパラメーターを動的に計算する必要がある場合に使用されます。



例3. 6つの車輪と重いプラットフォームが必要です。

 six_wheeled_heavy_chassis = [NumberOf(Chassis.wheels, 6), InstanceModifier(Chassis).thatSets(Chassis.type=CHASSIS_HEAVY)] car = Builder(Chassis).withA(six_wheeled_heavy_chassis).build() >>>len(car.chassis.wheels) == 6 True >>>car.chassis.type == CHASSIS_HEAVY True
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Builder.withA（）メソッドは、1つのModifierオブジェクト、そのようなオブジェクトの配列、または任意の深さのネストされた配列を持つ配列として受け入れることができるという事実に注意する価値があります。

例4 私たちは、大きなボディとたくさんの車輪を備えた強力な全地形型車両を求めています。

 rover_capabilities = [big_diesel] + \ six_wheeled_heavy_chassis + \ [InstanceModifier(Body).thatSets(type=BODY_HEAVY)] rover = Builder(Chassis).withA(rover_capabilities).build()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

重要な点は、すでに記述したbig_dieselおよびsix_wheeled_heavy_chassis修飾子を再利用したことです。 そのため、実際の生活では、作成するテストの数が多いほど、既製の修飾子が多くなります。 これには3つの利点があります。

1. 必要なデータを準備する方法ではなく、テスト方法を考えて、修飾子を再利用してテストをより速く書くことができます。
2. 正しい修飾子名により、テストで使用されるデータとその構成方法を正確に理解しやすくなります。
3. システム構成の変更（たとえば、開発者がオブジェクト間の接続を変更する機能を作成した）を使用すると、すべてのテストを1か所で簡単に修復し、誤った修飾子のみを修正できます！

例5.車輪の1つが14インチ、1つが16インチ、もう1つが4〜15インチの半径を持つ場合、全地形型車両がどのように進むかを確認します。

 def wheel_radius(radius): return OneOf(Chassis.wheels, InstanceModifier(Wheel).thatSets(radius=radius)) car = Builder(Chassis).withA(rover_capabilities) .withA(wheel_radius(14), wheel_radius(16)) .build()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例6.最後の2つの未使用タイプの修飾子、HavingInとGivenがあります。 これらは、CollectionコンストラクトでHaveInが使用され、完成したオブジェクトをその場所に配置するために他のすべてのコンストラクトで指定されるという点でのみ異なります。



例でHaveInのみを検討してください。 すでに最後の車のホイールが1つ残っていて、新しいホイールに取り付けたいとします。

 wheel = Wheel() car = Builder(Chassis).withA(HavingIn(Chassis.wheels, wheel)).build()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

指定された修飾子は同様に機能します。



ただし、完成したオブジェクトをそこに渡すと、その中に接続は作成されず、何も変更されず、そのままのグラフに置き換えられるため、これらの修飾子の使用には注意が必要です。



Builder(typeToBuild).withA(*modifiers).build()



を呼び出すアルゴリズムを検討してください。

1. タイプtypeToBuild
   
   
   
   の現在のオブジェクトtypeToBuild
   
   
   
   
2. Construct修飾子が*修飾子リストにある場合、それらは現在のオブジェクトのプロパティにある対応するタイプのConstructオブジェクトに適用されます
3. 現在のオブジェクトのプロパティにあるすべてのConstructオブジェクトは、個々のConstructのルールに従ってオブジェクトに変換されます
4. InstanceModifier(currentObjectType).thatSets()
   
   
   
   *修飾子リストにある場合、それらは現在のオブジェクトに適用されます
5. 変換されたコンストラクトから取得したすべてのオブジェクトに再帰的に降りて、ステップ2からアルゴリズムを繰り返します。
6. InstanceModifier(clazz).thatDoes()
   
   
   
   *修飾子リストにある場合、構築されたグラフのclazzタイプのオブジェクトに適用されます

以上です！ このシンプルなライブラリの助けを借りて、私たちは生活を大幅に簡素化し、多くの工数を節約することができました。

一番下の行：私たちには何があり、なぜこれがすべて必要なのですか？

1. ObjectBuildersは、オブジェクトモデルによって記述されたデータのプロパティを簡単かつ読みやすく記述し、このデータを動的に生成する機能を提供します。
2. オブジェクトとその変更間の関係のロジックは、別の論理レベルに割り当てられます。これにより、前述のデータ構成を再利用でき、必要に応じて、データが使用されたすべての場所で修復するのではなく、1つの場所で接続およびデータ構成のロジックを簡単に修復できます。
3. テストでは、必要なすべての「サイド」設定とオブジェクトを気にせずに、テストの動作に実際に影響するプロパティのみを記述することができるため、データとシステムの動作（テスト内のテスト）の関係を簡単に理解できます。

ただし、実装の現在の段階でのアプローチには欠点があります。

• ラージオブジェクトモデルの場合、すべての関係を正しく記述することは非常に困難になります。
• モディファイヤの「パッケージ」が大量に蓄積されると、既存のモディファイヤを再利用するよりも独自のモディファイを作成する誘惑が高まります。
• 多数の修飾子をグラフに適用すると、エラーが発生した場合にデータの不整合に気づく/見つけるのが困難になります。

通常、モデルはほとんど変化しないか、わずかに変化するため、最初のマイナスはそれほど重要ではありません。 2番目のマイナスは、開発中のコードに固有のものです（コピーペースト愛好家はどこにでもいます）。 3番目のマイナスは、既製の（「デバッグ済み」と呼ばれる）モディファイアパッケージの蓄積と次第になくなり、さらに、受信したデータのテスト中に不整合が見られるようになります。



すべての欠点を考慮に入れても、テストを作成し、テストをサポートし、データに依存するシステムの動作がどのように構成されているかを正確に把握する必要がある場合、時間を節約できます。 一般に、先に述べたすべてのことは、Pythonを起動するときにメモリ内のオブジェクトについて語られたものであり、実際にシステムに入るデータとは関係ありません。 しかし、これはプラスです。テスト中のシステムに生成されたデータを直接作成するさまざまなアルゴリズムを実装したり、他のニーズにこのデータを使用したりできます。



たとえば、生成されたデータをXMLRPC APIまたはSQL Alchemyを介してテスト対象のシステムにロードできるようにするレイヤーを実装しました。 また、ObjectBuilderを使用して、サーバーリクエストのデータをJSONおよびXML形式で生成します。 ObjectBuilderは、データを操作するためのかなり抽象的なメカニズムであるため、かなり幅広い用途があります。 読者の何人かがこのツールを興味深く有用なものと考え、その開発に参加することを本当に願っています。 私たちは常に新しいアイデアや提案を歓迎します。



Githubプロジェクトコード。

pypiの準備完了パッケージ。



健康に使用してください！