Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
The Secret Ingredient: How To Understand and Resolve Just About Any Flaky Test by Alan Ridlehoover Flaky tests are an inscrutable bane. Hard to understand. Annoying. And, so frustrating! My personal nemesis is Daylight Saving Time. I can’t tell you how many times I’ve tripped over it. Let’s just say I was well into the “shame on me” part of that relationship, until I discovered the secret ingredient that nearly all flaky tests have in common. Turns out they only seem inscrutable. It really is possible to understand and resolve just about any flaky test.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In the talk titled *The Secret Ingredient: How To Understand and Resolve Just About Any Flaky Test*, presented by Alan Ridlehoover at RubyConf 2023, the speaker addresses the challenges and frustrations associated with flaky tests in software development. Ridlehoover defines a flaky test as one that produces inconsistent results despite the test code and application code remaining unchanged. He emphasizes that the common culprit behind flaky tests is invalid assumptions about the test environment. Key points discussed include: - **Types of Flaky Tests:** Ridlehoover identifies three primary causes of flaky tests: non-determinism, order dependence, and race conditions. - **Non-Determinism:** Tests that rely on non-deterministic features, such as random numbers or the system clock, may yield inconsistent results. Ridlehoover advocates for mocking these elements to create deterministic tests. - **Order Dependence:** This occurs when tests pass in isolation but fail due to shared mutable state when run together in a sequence. To address this, developers should isolate the shared state or reset it between tests. Ridlehoover illustrates this with an example involving a cached value across different specs. - **Race Conditions:** These happen when multiple processes interact with a shared resource, leading to unpredictable results. To handle these, Ridlehoover suggests strategies like using `StringIO` for file operations or implementing thread-safe code. - **Debugging Techniques:** The speaker stresses the importance of tools such as RSpec's 'order random' and 'bisect' features to help identify flaky tests and their causes. - **Best Practices:** Finally, Ridlehoover shares his perspective on maintaining clear and communicative specs. He encourages avoiding overly DRY (Don't Repeat Yourself) practices in tests to facilitate easier debugging. In conclusion, Ridlehoover asserts that understanding and addressing assumptions about the test environment can significantly mitigate flakiness in tests, allowing for more reliable software development. He encourages attendees to remember that documentation through tests is crucial, and practicality should guide testing approaches.
Suggest modifications
Cancel
