RubyKaigi 2024 Proposal
code:markdown
### Title (limited to 60 characters)
Unlocking Potential of Property Based Testing with 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.
### 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.
- 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.
- 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.
- 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.
### Bio (~500)
Rubyist working on a banking system and a card payment system at SmartBank, Inc.