こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
プロパティベーステストは関数型プログラミング言語界隈で発展してきた経緯もあり、ユニットテストやファジングと比較するとあまり浸透していないのが現状です。
テストが色々とある中でプロパティベーステストはどんな意義がありどんな位置付けなのか。 本イベントでは、書籍『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』で取り上げられている問題を主に訳者である、山口 能迪 さんに解説いただき、和田卓人さんにはたくさんのテストがある中でのプロパティテストの意義などをお話しいただきます。
会の様子
プロパティベーステストの意義
t-wadaさんからプロパティベーステスト(Property-based Testing)の位置づけに関して話がありました。
最初にテスト(Testing)は、「Checking + Exploring」と表せるという話から、その上でExploringは一体誰がやるのか？という問題提起がありました。
伝統的には、これはテストエンジニアの仕事だという考え方があり、テストエンジニアは前提を共有しないことで既知の領域から積極的に出て探索することに意義があるということですが、これはすなわち開発とテストの分業を促進することになり、テスト可能性が損なわるといったデメリットも発生するということでした。
そこで、普遍性と契約という観点からコードについて考えさせてくれるきっかけを作ってくれるProperty-based Testing(Known unknownなテスト)が有効になってくるということで、これがまさにProperty-based Testingの位置づけになるということです。
なお、Property-based Testingはt-wadaさんの意見としては製品を批評する技術面/ビジネス面両方のテストだということでした。
実践プロパティベーステスト概要
続いてymotongpooさんから、以下の本に関する概要の紹介がありました。
『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』www.lambdanote.com
著者のFred HebertさんはErlangのrebar3のメインコントリビューターであり、Property-based Testingがよく使われている関数型言語で溜められたエッセンスを紹介するような本になっているということでした。
まず、EBT/Fuzzing/PBTに関する説明がありました。
- EBT...事例ベーステスト。期待する出力結果と実際の出力結果を比較する
- Fuzzing...Fuzzerが自動的にテスト対象に対して値を入力し、あるタイミングでパニックやクラッシュが起きないかを発見する
- PBT...プロパティベーステスト。例えばリファクタリング前の関数をプロパティとして出力させ、リファクタリング後の関数をその出力結果と比較する
本の内容としては、第一部でジェネレーターやプロパティに関する基礎を説明した後、第二部でステートレスなプロパティに対してまずはテストを書いていこうという話*1をし、第三部でより実践的なステートフルプロパティに関するテストの話*2がされているということでした。
最近のテスト手法のトレンドは？
t-wadaさんの回答としては、まずトレンドはないということでした。(そもそも本質的にはテストコードの書き方にトレンドがあってはいけないとt-wadaさんは思っている。テストのやり方は枯れていて安定している必要がある)
その中で敢えてトレンドを言うなら、最近話題に出ているCopilotにテストコードを書いてもらおうという話や、テストコードの保守性に関する研究がトレンドになっているということでした。
新サービスの品質向上のために二人が取り組んでいることは？
まず、t-wadaさんは、CI&CDをなるべく早く構築することだというお話がありました。
ymotongpooはオブザーバビリティを高め、ユーザーにインパクトがある指標を取ろうという話を意識しているということでした。
Q&A
最後にQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきました。
新規実装する場合はプロパティをどう用意するのか？
- プロパティベーステストはものがあると有用なものだと思うので、新規実装する場合はEBTを使うのが良いのではないか？と思う。
- プロパティベーステスト駆動とかいう話があるのは面白いが、一般的にはそんなにおすすめできない
- この本はプロパティベーステストのHOWが書かれているのが非常に価値が高い。ただ、他言語ではうまく動かない点がある可能性があるのは注意。
EBTとPBTの使い分けを教えてほしい
PBTは確率的に動くので、あくまでもEBTの補完的にテストするものである。
PBTはビジネスロジックでも使えるのか？いわゆるutilにしか使えないイメージがある
使える。10章を読むと、イメージがすごく変わるはずなのでぜひ読んでほしい。
PBTはテスト自体にロジックが色々入るようですが、そのロジックが正しいかどうかを担保するのが難しそうだと思った
その通り。ただ、本でそのような自体を防ぐために避けるべきノウハウが本書には散りばめられているので、ぜひ読んでほしい。
PBTを「どのくらい」導入すると、投資対効果がちょうどよくなるか？また「ちょうどよい」をどのように確かめていくポイントがあれば知りたい
PBTは問題があるだろうなあと思っているがどこに問題があるかわからない場所で役立つ話なので、EBTが十分な部分に投資すると効果が高いと思う。
プロパティベーステストを広める上で難しい点は？
- 言語によってはフレームワークがなかったり貧弱だったりする点は課題だと思っている
- プロパティも実装しないといけないため、テスト実装コストが高い
- 長期間走らせる必要があるため、テスト運用コストが高い
フロントエンドの目線でプロパティベーステストをどのように使うか？
BFFみたいなものを使っていないのであれば、ステートフルプロパティテストでバグがないかをテストしたりはできる。
会全体を通した感想
プロパティベーステストの位置づけが話された後に、具体的なHOWが話されるという順番で話され、頭にすっと入ってくる構成になっていたのが印象的でした。
EBTができていない状態でプロパティベーステストに対して過度な期待をしないというのが一番ポイントとして心に残りました。
