# RubyKaigi 2024 Proposal: Unlocking Potential of Property Based Testing with Ractor

https://cfp.rubykaigi.org/events/2024

### Title (limited to 60 characters)

Ideas

- ✅ Unlocking Potential of Property Based Testing with Ractor
- Enhancing Ruby Testing with Property Based Testing and Ractor

### Abstract (limited to 1000 characters)

>A concise, engaging description for the public program. Limited to 1000 characters.

Ruby's ease in test-writing and its rich ecosystem are widely acclaimed. However, traditional testing methods, relying on developer-created cases, often miss edge-case bugs. This talk introduces a testing method and a tool to generate numerous cases automatically, known as 'property based testing'. It's not only a transformative solution to detect bugs but also a nice use case of Ractor because the tool generates dozens to hundreds of cases that can run in parallel.

I'll explore how Ractor enables efficient execution of property based testing through parallel processing. This combination promises faster, more comprehensive testing, reducing reliance on developer expertise for bug detection. This talk aims to unlock Ruby's full testing potential by shedding light on the not-well-known test method.

- Rubyはとてもテストが書きやすいしエコシステムも充実してるが、テストケースの記述はプログラマーのスキルに依存する
- property based testingの大いなる力、テストケース自動大量生成がその課題の解決になるのではないか
- テストケースは個々に独立した実行単位であり大量に並列実行したい... Ractorの出番では！？
- Ractor firstなproperty based testingツールを作ってみよう

### Details

>Include any pertinent details such as outlines, outcomes or intended audience.

#### Intended audience

- Intermediate or above Ruby programmer with several years of testing experience
- People who are particularly interested in bug detection and quality improvement

- 並行・並列の基礎は説明しないので、中級以上を想定
- バグ検出に興味がある...全員では？という気もするがトピックに応じて絞っておく

#### Outline: What this talk covers

1. Introduction of property based testing (10min)
- Which do your unit tests does, checking or testing?
- Most unit tests are checking. Bugs are created when incorrect assumptions are introduced.
- What property based testing is. It's a tool that complements unit tests to detect bugs.
- Core concept: Property, Generator, Shrink
- Automatic generation of hundreds of cases for a single test target.
- Learn from other languages like Haskell, Erlang, Elixir, Go.
2. Parallelism unlocks property based testing possibility (8min)
- Generated cases are small processing units and do not interfere with each other. They can run simultaneously.
- In case of failure, it performs shrink to narrow down the minimum failure case.
3. Property based testing tool implementation (12min)
- Let's build a minimal, high-performant property based testing tool.
- Here's the one: https://github.com/ohbarye/pbt
- How does Ractor contributes to high-performant property based testing?
- Ractor has some limitations. How they affect to the test tool?

#### Takeaways

After this talk audience shall be able to explain:

- What property based testing is and what issue it resolves.
- How to try property based testing in Ruby.
- Possibility of building a high-performant property based testing tool.

### Pitch

>Explain why this talk should be considered and what makes you qualified to speak on the topic.

I propose to deliver a talk at RubyKaigi that delves into the untapped potential of property based testing in Ruby's robust testing ecosystem.

#### Why software testing topic?

Despite Ruby's intuitive and efficient testing tools, there's a gap in updates regarding testing methodologies. Even experienced programmers can embed incorrect assumptions in test cases. This is where property based testing shines as a complementary approach, filling gaps left by traditional unit testing.

#### Why RubyKaigi?

Firstly, it's not just about introducing a new testing method. It's also about showcasing a practical use case for Ractor in parallel processing. Ractor, while powerful, is yet to be widely adopted, partly due to a lack of compelling real-world applications. Property based testing, with its need for numerous independent execution units, stands out as an excellent use case for parallel processing in Ruby.

Furthermore, exploring the synergy between Ractor and property based testing aligns with RubyKaigi's ethos of pushing the boundaries of what's possible with Ruby. Actually, while implementing a prototype of such a test tool, I found limitations in Ractor that make it difficult to enhance the tool. It would be a more meaningful talk if I could suggest language feature extensions to upstream. This talk isn't just about improving testing; it's about finding how we utilize Ruby's capabilities to solve real-world problems more efficiently.

#### Is this talk about speeding up existing tests?

As mentioned above, unlike past talks below, the main theme of this talk is not speeding up of existing tests with parallelization. I would like to introduce an additional testing method for the Ruby community, and the fact that it is a good use case of Ractor.

- https://rubykaigi.org/2023/presentations/koic.html
- In this talk, the speaker explained how to utilize existing test code and speed it up by parallelizing it. It does not mention efficient testing method to detect bugs.
- https://rubykaigi.org/2021-takeout/presentations/vinistock.html
- This talk introduced a new testing framework based on Ractor. This approach required migration from existing test code. But property based testing doesn't require such a migration, we can add it as a new test case into current existing test codebase.

#### なぜテスト手法の話をするのか？
- Rubyのテストツールエコシステムは非常によくできている。短い記述で直感的に意図したテストを書けるのはプログラマにとってハッピーだし生産性が高い。
- ただしテスト手法に関するアップデートはツール側からは出てきていない。プログラマが自ら学ばなければならない。熟練のプログラマでも誤った仮定をテストケースに記述してしまうことがある。
- このようなユニットテストの問題を補完するアプローチの1つとして、property based testingが有効だと信じる。
- しかしまだRubyコミュニティにおいて市民権を得ているとはいえないので、ここらで一つ提案してみたい。

#### なぜRubyKaigiでこの講演を行うのか？
- この講演は単なるテスト手法の紹介ではなく、Ractorによる並列処理の現実的なユースケースの提示でもある。
- Ractorも未だ広く利用されているとは言い難いが、その理由の1つに現実の問題を解決するユースケースがまだ多く発見されていないことがあると考えている。
- 独立した小さな実行単位を大量に持つproperty based testingはRubyにおける並列処理の優れたユースケースになりうる
- このように言語の持つ機能の最大限の活用可能性を探るのはRubyKaigiらしい講演だと考える。
- また、プロトタイプを実装するにあたり、実装の妨げになるRactorの制限が発見している。言語機能の拡張をupstreamに提案できればより意義のあるtalkとなるであろう

#### 既存のテストの高速化/並列化の話？
- 違う。

### Bio (~500)

Rubyist working on a banking system and a card payment system at SmartBank, Inc.

---

## メモ

### 調査しないといけないこと

- 既存のPBT in ruby
- https://github.com/Qqwy/ruby-prop_check
- Elixir界隈の人が作者？ふつうによくできてそう
- これをforkして並列化に挑戦するのでもいいのかも
- Ractorの制限
- Procやら色々渡せないので、ユーザーの書くテストコードとツールを繋ぐのがむずい
- assertionとかexpectとか渡せない
- M:Nスケジューラが活きるのかどうか
- 活かすにはもっと大量に生成しないといけない？
- テスト全体の並列化
- ファイル単位
- すでに事例がたくさん。2023のkoicさんの話
- この枠組みを提供する必要はない
- ファイル内のケース単位
- 並列化しようとするとテストフレームワークを作らないといけない
- 2022のvinistockさんの話
- 面白いが普及は現実的でない
- 既存資産やテストコードがあるので移行モチベーションがない
- フレームワークがなんであろうとあとからテストを足せるぐらいがちょうどよい

### 参考

端的な説明
https://speakerdeck.com/twada/intro-to-property-based-testing

### RubyKaigi過去事例

#### https://rubykaigi.org/2023/presentations/koic.html#day2

- テスト高速化全般の話
- minitest
- デフォルトでは直列だが、`parallelize_me!`を呼ぶとマルチスレッドで実行できる
- rails
- 6以降でデフォルトで並列実行になった
- minitestの仕組みに乗っかりつつ、マルチスレッドではなくマルチプロセスのテストになる
- 並列数はコア数依存
- RSpecではサポートされていない
- parallel_tests
- parallel gemに依存
- テストをファイルごとに分割
- 実行時間に偏りがあると一番おそいものにひきづられる
- test-queue
- https://github.com/tmm1/test-queue
- RSpecにも対応できる
- workerは空いたキューに詰めていくスタイル
- masterからforkした別プロセスが解析して詰める
- UNIXServer or TCPServerで通信

#### https://rubykaigi.org/2021-takeout/presentations/vinistock.html

- Ractorベースで実行できるテストフレームワーク
- https://github.com/vinistock/loupe/blob/main/lib/loupe/ractor_executor.rb
- Ractorをプロセッサーの数だけ作っている
- M:Nスケジューラーがない時代なのでそうしている？
- 今はあまりメンテナンスされてないんだなぁ

### M:Nスレッドとの関係

https://gihyo.jp/article/2024/01/ruby3.3-mn-threads

M:Nスケジューラを有効化すると、スレッド生成が速いしネイティブスレッド数が抑えられてトータルで良いパフォーマンスになる

プロポーザルとの関わりでいうと...
property based testing (PBT) では1テストあたり100個のケースが自動生成され、並列実行可能。このとき100のネイティブスレッドを生成する必要がなくなり恩恵は受けられそう。ここはgood。
ただ、手元で有効化しても速度面での差はほぼ見られなかった。10^4とかのオーダーじゃないと明らかな差は出ないのかも

1テストあたりのケースを10000に近づけていってもバグ検出における費用対効果は逓減していくのでこれは良いユースケースとはいえない。
100テストを並列実行し、それぞれが100ケースで構成されるなら10^4ケースの並列実行になるのでめちゃめちゃ恩恵を受ける (だろう) し、最高のユースケースといえる

となると目指すべきPBT toolの機能にはテストの並列実行も含まれるのかもしれない。rspecやminitestに乗っかる必要はなく、あくまでPBTだけが並列実行されればいいので、既存テストの並列化よりは楽かも