Speakerline
Speakers
Proposals
Events
Tags
Edit a proposal
Adam Cuppy
Ahmed Omran
Alan Ridlehoover
Amit Zur
Andrew Mason
Andrew Nesbitt
Andy Andrea
Andy Croll
Asia Hoe
Avdi Grimm
Ben Greenberg
Bhavani Ravi
Brandon Carlson
Brittany Martin
Caleb Thompson
Caren Chang
Chiu-Ki Chan
Christine Seeman
Cody Norman
Devon Estes
Eileen Uchitelle
Emily Giurleo
Emily Samp
Enrico Grillo
Espartaco Palma
Fito von Zastrow
Frances Coronel
Hilary Stohs-Krause
Jalem Raj Rohit
Jemma Issroff
Jenny Shih
Joel Chippindale
Justin Searls
Katrina Owen
Kevin Murphy
Kudakwashe Paradzayi
Kylie Stradley
Maeve Revels
Maryann Bell
Matt Bee
Mayra Lucia Navarro
Molly Struve
Nadia Odunayo
Nickolas Means
Noah Gibbs
Olivier Lacan
Ramón Huidobro
Richard Schneeman
Rizky Ariestiyansyah
Saron Yitbarek
Sean Moran-Richards
Shem Magnezi
Srushith Repakula
Stefanni Brasil
Stephanie Minn
Sweta Sanghavi
Syed Faraaz Ahmad
Tekin Suleyman
Thomas Carr
Tom Stuart
Ufuk Kayserilioglu
Valentino Stoll
Victoria Gonda
Vladimir Dementyev
Title
Tags (comma-separated, max 3)
Body
# Abstract Writing tests is a significant part of the development process, especially in the Ruby and Rails community. We don’t care about test suite performance until we find ourselves wasting too much time waiting for the green light. I’ve spent a lot of time analyzing test suites performance and developed some useful techniques and tools to make tests faster. Let's do some profiling and refactoring and get our tests healed! # Details I would like to start the talk by answering several questions, e.g., “Do you write tests?”, “How long does your test suite run?”, etc. That’s an introduction. The answers are based on the survey conducted by myself. That’s an introduction. As a warm-up, I would like to share a few real-life stories: “Our tests were slow, we did some investigation, and the reason was X.” The goes the first part of the talk. I’m pretty sure that many attendees would find this stories familiar–most slow tests suites are so due to the same reasons. Most of these reasons are related to incorrect environment configuration for tests (i.e., too verbose logging, inlined background jobs, etc.). If so, why can’t we record all the popular bottlenecks and publish them? Kind of Open Database of Slow Tests Problems. That’s exactly the idea I’m bearing in my mind, and I’m going to make this idea a reality. (Hopefully) I want to introduce a simple service/website (?) called “99 problems of slow tests”. It aims to help Ruby developers to prevent tests slowness. The end of the first part. What about the second part? There I’m going to dig deeper and show, how to find other problems with your tests, not related to the environment configuration but to the way you write tests. The second part is devoted to the tool called TestProf–a toolbox for profiling test suites and a set of ready-made recipes to write faster tests: - How and when to use TestProf’s profilers? - What are factory cascades and how to fix them? - Tests code static analysis with Rubocop. Now you prepared to write faster tests or fix your existing slow codebase!
Back to Speaker Directory