1 ポイント 投稿者 GN⁺ 2024-07-06 | 1件のコメント | WhatsAppで共有
  • プロパティベースドテストは、30年以内に主流として定着したまれな学術研究の例である。
  • 「テストを書くのではなく生成せよ」というスローガンのもと、さまざまなプログラミング言語コミュニティで支持を得ている。
  • もともとHaskellのライブラリであるQuickCheckのWikipediaページには、他言語での57件の再実装が列挙されている。

プロパティベースドテストライブラリの調査

  • 現在もっとも広く使われているプロパティベースドテストライブラリを調査し、15年前(2009年)の最先端技術と比較している。
  • ほとんどのライブラリは、最先端のプロパティベースドテスト機能を提供していない。

なぜプロパティベースドテストライブラリはこのような悲しい状況にあるのか?

状態ベースおよび並列テストは純粋テストほど有用ではない

  • 状態ベースモデリングには訓練が必要である。
  • クローズドソースが産業界での採用を助けるという主張。

状態ベースモデリングには訓練が必要である

  • 状態ベースおよび並列テストは、一般的なテストとは異なる考え方を要求する。
  • 新しいユーザーにこうしたツールを提供する際には、適切な訓練が必要である。

クローズドソースが産業界での採用を助けるという主張

  • オープンソースではうまくいかず、クローズドソース製品と関連サービスが採用を助けるという主張。

私たちにできること

  • 状態ベースおよび並列のプロパティベースドテストについて、短いオープンソース実装を提供する。
  • 開発者の訓練をあまり必要としないように、形式仕様の部分をより簡単にする。

純粋なプロパティベースドテストの要約

  • 新しい関数や機能をテストすることは、よい実践と見なされる。
  • たとえば、連結リストを逆順にする関数 reverse を書いた場合、空リストのようないくつかのリストに対してテストするのは理にかなっている。
  • ランダム入力を生成することが、プロパティベースドテストの主要な機能である。
  • ランダム入力が最終的にはコーナーケースを見つけるだろうという考え方。

状態ベースのプロパティテスト

  • 状態を持つコンポーネントをテストする際、同じ入力が同じ出力を返すとは限らない。
  • 状態ベーステストでは、入力シーケンスを生成して、システムが時間とともにどう変化するかをテストする。
  • インメモリの参照実装(モデル)を使って、状態を明示的に記述する。

例: カウンター

  • グローバルな可変変数を使ってカウンターを実装する。
  • モデルは整数で表現される。
  • テストはコマンドシーケンスを生成して実行し、実際の出力とモデルの出力を比較する。

並列プロパティベースドテスト

  • 並列テストは、状態ベーステストのモデルを再利用して競合状態を検出する。
  • 並列テストは、逐次状態機械モデルを用いて線形化可能性によって並列テストを行う。

結論と今後の作業

  • プロパティベースドテストの状況を改善するには、オープンソース実装を提供し、形式仕様をより簡単にすることが必要である。

GN⁺の見解

  • この記事は、プロパティベースドテストの歴史と現在の状況をよく説明している。
  • 状態ベースおよび並列テストの重要性を強調し、オープンソース実装の必要性を提起している。
  • プロパティベースドテストをより簡単に利用できるようにする方法を提案している。
  • 類似の機能を持つ他のプロジェクトとして、Hypothesis(Python)とPropEr(Erlang)がある。
  • 新しい技術やオープンソースを採用する際には、訓練とサポートが必要であることを強調している。

1件のコメント

 
GN⁺ 2024-07-06
Hacker Newsの意見
  • clojure.spec.alphatest.check を使った経験は良かった
    • Python の hypothesis は大規模なデータセットを処理できず、使用をやめた
  • Go 言語ではカバレッジベースのファジングが手厚くサポートされている
    • ファジングテストと不変条件の検証により、プロパティテストに近い結果を得られる
  • 研究論文がオープンソースツールで再現可能であるべきだという要求は、有用な情報を失わせる可能性がある
  • Rust の proptest を使って状態ベースのプロパティテストをよく書いている
    • 並列テストはときどき有用だが、複数のテストを並列実行するほうが簡単な場合もある
  • Quviq QuickCheck の論文を読んだが、状態ベースのテストは自分で直接書いたほうがよいかもしれない
    • StateModel は追加のフレームワークコードが必要で、効率的ではない
  • 状態機械や並列性の側面以外にも、カバレッジベースのプロパティテストのほうがより大きな影響を与える可能性がある
    • 自動シュリンキング機能を維持しつつ、値生成時にすべての不変条件を保つことが重要だ
    • Hypothesis の「内部シュリンキング」アプローチが最も効果的だ
  • Clojure にも状態ベースの QuickCheck ライブラリがある
    • 並列テストはまだ大きな問題にはなっていない
  • プロパティベースドテストは、厳密なテストを書けるなら型システムに統合したほうがよい
    • 単純な「スモークテスト」はランダム入力を使うほうが簡単だ
  • QuviQ Erlang QuickCheck の無料版である QuickCheck Mini もある
  • JavaScript でプロパティベースドテストライブラリを使い、特定の条件を満たさないランダムな値を生成できるのか気になる