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!
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:
Now you prepared to write faster tests or fix your existing slow codebase!