0

プロジェクトの単体テストをいくつか作成しました。

独自のユニットを持ついくつかのクラスを取得しました。しかし、多くのテスト ケースは原理的には似ています。

  1. 何かを追加
  2. 追加された要素を取得する
  3. これをチェックして

例えば：

Player.add_weapon("name")
Player.get_weapons()
for w in weapons:
 - check the validity bla bla

Warehouse.add_package("name")
Warehouse.get_packages()
for p in packages:
 - check the validity bla bla

ご覧のとおり、コンテキストは異なりますが、手順は同じです。これは私の考えでした: (しかし、この処理には良いパターンが存在するかもしれません)

def mytestfunction(ut_instance, test_obj, add_method_as_string, getlist_method_as_string):
    add_obj = None
    get_obj_list = None    
    exec("add_obj=test_obj.%s" % add_method_as_string)        
    exec("get_obj_list=test_obj.%s" % getlist_method_as_string) 

    ut_instance.assertEqal(len(get_obj_list()), 0, msg="We need a empty test object")
    item = add_obj("lala")
    list = get_obj_list()

    #check this ..and so on ...
    ....
    pass

それは機能しますが、よりスマートなソリューションを知っているかもしれません。たとえば、期待を制御したり、さまざまなパラメーターを操作したりします。

4

1 に答える 1

0

問題は、テストのための非効率的なファクトリメソッドではありません。問題は、基礎となるテストパラダイムです。単体テストでは、オブジェクトの構成ではなく、オブジェクトまたはメソッドの動作をチェックする必要があります。

投稿したサンプルに基づいて、特定の値が特定のデータ構造に存在するかどうかに焦点を当てるのではなく、addメソッドとgetメソッドの境界条件を確認する必要があると思います。覚えておいてください：構成ではなく、行動。

テストは科学というよりは芸術です。YMMV。

于 2012-06-13T15:12:39.553 に答える