Conversation

Notices

1. ( ᐛ) まりなっピ (sasanquaneuf@qiitadon.com)'s status on Wednesday, 05-Sep-2018 15:22:05 JST ( ᐛ) まりなっピ

   たとえば、全てグーになる場合が原理的に起こり得る以上は、絶対的に失敗しない検証は本質的に無理であると思います。
   ただし、例えば100万回に1回だけ失敗するテストを書いておくと、現実的にはその他の要因で失敗する確率の方が相当高いのではないかと思います。
   （例えばCI環境の場合には、立ち上げの失敗など）
   100万がダメなら、10億でも1兆でも、増やせば精度は上がるのかなと。

   テストが失敗する確率が0でないことがどうしても問題になる場合には、(a)そのテストは通常はスキップするようにして適宜必要に応じて人間が動かすか、(b)テストで失敗することを許容するか、いずれかではないかと思います。あとは、(c)シードを固定するか。

   • 俳句検出bot (find575@theboss.tech)'s status on Wednesday, 05-Sep-2018 15:22:07 JST 俳句検出bot

     in reply to

     @sasanquaneuf
     『検証は本質的に無理である』

     ( ᐛ) まりなっピ repeated this.
   • ( ᐛ) まりなっピ (sasanquaneuf@qiitadon.com)'s status on Wednesday, 05-Sep-2018 15:22:44 JST ( ᐛ) まりなっピ

     in reply to

     あるいは、特定の関数fが乱数を返す・ランダム選択を行うということは仮定した上で、テスト対象関数tの中で特定の関数fが特定の引数で確かに呼び出されていることの検証というのは、一つの方法としてはあり得ると思います。
     その場合で、最終出力がその関数fの結果を受けて加工するようなものである場合は、乱数に関するテストとは別に、fをモックして必ず特定の値を返すような関数に置き換えてtをテストして、乱数でグーに相当する値が出たらグー、パーに相当する値が出たらパー、というような検証はできるかと思います。
     このテストの仕方は、fとtを関数として分離した上で、fをできる限り小さくとってfは正しいものと仮定して、fをモックしながらtの処理の正当性をテストするという方法ですね。

     仮にtの処理とfが密に結合していて切り分けられない場合には、上述のとおりスキップか失敗許容かシード固定しかないのではないかなと思います。