再帰テスト

再帰を使用しない理由はいくつかありますが、これは再帰をまったく使用しない理由ではありません。 プログラムは、第一に、プログラマーのためにプログラマーによって作成され、第二に、コンピューターのためにプログラマーによって作成されます。 その結果、準備のできていない人々はいくつかの適切なプログラムを使用できます。 再帰には、反復よりも明確な利点が1つあります-可読性です。 プログラマーが自分の種類のプログラムを作成する場合、再帰は反対のことが証明されるまで存在する権利を持ちます（つまり、コンピューターで起動されず、実際のデータで窒息します）。

実際、テストとは、プログラマーが開発されたアプリケーションで克服できない複雑さの限界を押し上げることを可能にするプログラムのためのプログラムの作成です。 先日、再帰的なメソッドの単体テストを作成する必要性に直面したとき、テスト済みのメソッド自体を濡らす必要性に不愉快な驚きを覚えました。 別の方法は、1つのテストメソッドですべての再帰分岐をテストできるような入力データを作成することです。 将来、それは迫り来る複雑さの減少ではなく、むしろ複雑さの増加でした。 インターネットを介して大騒ぎして、私は再帰が良くないことに関する多くの情報、再帰から反復に切り替える方法に関する多くのヒントを見つけましたが、私が探していたものをロシアの形で見つけることができませんでした-再帰的な方法をテストする方法。 コードを3回パスするためのテストデータを準備することは、克服できないほど複雑ではないと判断したため、このタスクを朝まで延期しました。 カットの下で、ソリューションは一晩で思い浮かび、再帰的メソッドのテストを部分に分割することができました。

再帰的方法

public function foo($arg1, $arg2) { //... $out = $this->foo($in1, $in2); //... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラクタルラッパーメソッド

メソッドのラッパーを作成し、メソッド自体がラッパーのみを呼び出すようにし、ラッパーはメソッドを呼び出します。

 public function foo($arg1, $arg2) { //... $out = $this->fooRecursive($in1, $in2); //... } public function fooRecursive($arg1, $arg2) { return $this->foo($arg1, $arg2); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ラッピングモック

 public function test_foo() { /* create mock for wrapper 'fooRecursive'*/ $obj = \Mockery::mock(\FooClass::class . '[fooRecursive]'); $obj->shouldReceive('fooRecursive')->once() ->andReturn('out'); /* call recursive method 'foo' */ $res = $obj->foo('arg1', 'arg2'); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、決定は非常に簡単ですが、多分誰かが便利になるでしょう、そして彼はもっと有用なものに彼の夜を過ごすことができるでしょう。