複数のテストで使用される仮説戦略をインスタンス化する必要がありますか？

Question

組み込みの仮説戦略は、機能を介して提供される（例えば、実際の戦略ではなく、integersは戦略を作成する関数である）。それは、戦略オブジェクトが内部状態を持っていることを私に示唆しています。上記の二つの偽のテストでは

@given(integers()) 
def test_foo(n): 
    assert n > 0  
@given(integers()) 
def test_bar(n): 
    assert n < 100 

、各テストはintegersの異なる呼び出しから（異なる戦略オブジェクトを取得し、私は、このように私自身の戦略作成する場合：使用後、...

positive_integers = integers().filter(lambda x: x > 0) 

をこれと同じテストのために：。

@given(positive_integers) 
def test_foo(n): 
    assert n > 0  
@given(positive_integers) 
def test_bar(n): 
    assert n < 100 

彼らは同じ戦略オブジェクトを共有し、それは間違っているかもしれないようにこれは私に聞こえるが、それはexamples in the docsがSでそれを行う方法ですオーム症例（NodeStrategyおよびNodeSetの定義を参照）。私はのような機能で戦略組成をラップすることによってこの問題を回避する必要があります

positive_integers = lambda: integers().filter(lambda x: x > 0) 
#... 
@given(positive_integers()) 

Answer 1

私はsource codeを見ていた、とあなたはテスト全体で同じ戦略オブジェクトを共有するために問題ないはずのように見えます。戦略のために異なるパラメータを渡すことができるように、関数を呼び出すようです。

私はあなたがこのいずれかを行うことができます意味を考える：私はレンジの境界を越えて状態のいずれかの証拠を見ることができなかった

positive_integers = integers(min_value=0) 

@given(positive_integers) 
def test_foo(n): 
    assert n > 0  
@given(positive_integers) 
def test_bar(n): 
    assert n < 100 

：

@given(integers(min_value=0)) 
def test_foo(n): 
    assert n > 0  
@given(integers(min_value=0)) 
def test_bar(n): 
    assert n < 100 

またはこれを。

def do_draw(self, data): 
    return d.integer_range(data, self.start, self.end) 

は、しかし、私は唯一の仮説を少しプレイしましたので、私は確かに間違っている可能性：実際には、BoundedIntStrategyは、パラメータとして渡された検索データを取得しているようです。