Talks
Take your slow tests to the doctor
Summarized using AI

Take your slow tests to the doctor

by Vladimir Dementyev

In the video titled "Take your slow tests to the doctor," Vladimir Dementyev discusses strategies to improve the speed of software tests, specifically focusing on his experiences with the AnyCable project. The talk, presented at the Balkan Ruby 2018 event, aims to address the common issue of slow tests that impede the development workflow.

Key Points Discussed:
- Introduction to slow tests: Vladimir highlights the challenges faced while running tests, especially in a collaborative environment with multiple developers making frequent changes to code.
- The impact of slow tests: He describes scenarios where test runs could take significant amounts of time, delaying the development process and causing frustration among team members.
- Advancements through parallel testing: A critical takeaway is the concept of parallel testing, where tests are executed simultaneously to save time. This reduces the bottlenecks that occur from a single build process running to completion before the next can be initiated.
- Case study of AnyCable: The project, which began in 2016, serves as a backdrop for his discussion. Vladimir shares how they identified their testing inefficiencies and implemented solutions to enhance speed, ultimately resulting in a substantial increase in the number of tests without sacrificing performance.
- Introduction of Despereaux: Vladimir presents a tool he developed called Despereaux. This collection of tools aids developers in diagnosing slow tests and offers solutions to make them faster, focusing on simplicity and efficiency.
- Profiling tools: He discusses various file profilers developed in the Ruby ecosystem that assist in pinpointing areas where tests slow down, allowing developers to optimize their code accordingly.

Conclusion:
The central message of the talk is the importance of not just increasing the number of tests but also ensuring they run efficiently to support a robust development environment. By utilizing tools like Despereaux and adopting methodologies such as parallel testing, developers can enhance their testing workflows, ultimately leading to faster and more efficient software development processes.

00:00:16.039 Yes, and smell tests actually. Okay, Mr. Kristo. My timers and the only person who stands between you and... Sorry, but I won't take a lot of time as possible.
00:00:21.650 Well, my name is Vladimir and you know about it, so let's keep it in. I came from Moscow, this riddle there eventually.
00:00:29.369 It's the same. Well, my Twitter handle is @vrb. It's not so easy to remember, so start out there. Check this out.
00:00:38.840 Maybe you can find something new for you. I'm going to talk about something even more interesting—beautiful and it's all illegal.
00:00:50.090 Mainly martial, so actually we are kind of most of us and tuning tried twelve and four big ones, small ones, United States, wherever. And that's not the interesting part. It responds to this—we do sort of stuff, we're trying to authorize source.
00:01:03.870 And this particular talk is going to be about source projects we have been working on since, oh, well, in them as far as related to testing.
00:01:12.200 Instead of it's complicated for the cost being last time the days, I'll try to make it as simple as possible. That's not with this Atari.
00:01:20.310 And another question I hope I know the answer beforehand, but let's do the right tests at least once.
00:01:28.170 This spin and try and school writing tests is one of the key features of the community.
00:01:40.150 Recently, tests were made a part of it and everything.
00:01:47.889 And if you think that your tests could be faster and you are sacrificing objects, I hope you can come back and try some techniques I am going to talk about.
00:01:53.760 And make your tests a little bit faster. Let me tell the story.
00:02:01.410 We have a project called AnyCable. It doesn't matter what it's related to and it started back in 2016.
00:02:07.619 Imagine a bottleneck situation: we spent a lot of time, actually not about the test itself, but about the real environment.
00:02:17.400 I had to spend about half an hour finishing all the stuff, just with winter's security checks or whatever, and that amount of time itself is not a good thing.
00:02:28.090 It becomes worse when you are working with a team of developers, and one is working on its own feature and pushing frequently, causing the builds to fail.
00:02:37.840 You have to wait for other builds to finish before you can finally release the feature, and sometimes it takes hours.
00:02:45.489 You start in the evening, wake up in the morning, and the original build is still ongoing.
00:02:53.200 I want to mention that we induced realization everywhere.
00:03:02.230 Especially one container to test environment.
00:03:09.010 As we learned recently from one of the keynotes, critics will become important with the solution: parallel testing.
00:03:14.319 Don't care about anything—this is how to improve the speed of your test projects.
00:03:22.900 We started working on the project, shipping new features. What will happen next? We started to write more tests.
00:03:37.840 Raymond called this. We need more tests and the number of tests increased.
00:03:42.230 So, we wouldn't do any work without tests. We would end up with the same story: one build running but containers.
00:03:53.200 What I say is that while just increasing the number of containers, we didn't want to spend so much money on testing infrastructure.
00:04:06.220 That's another way out, so it’s all about solving the problem of increasing resources.
00:04:10.100 We set out to find out why our tests were slow and tried to make them faster.
00:04:20.200 After some investigation and a little bit of work, we discovered this testing model, and three times more tests reduced the time spent on testing.
00:04:45.150 Listen to the math. It's pretty simple, but if you don't want to just trust me, we increased our test runtime by a factor of four.
00:04:54.600 It’s actually not so much about the specifics, more the methodology. And first, I would like to tell you how to get here.
00:05:10.700 I’m going to introduce you to a tool I call Despereaux.
00:05:21.400 I suggest Despereaux as a collection of tools that allows you to diagnose and fix your slow tests.
00:05:30.210 It really contains two parts, two groups of things: that's a test program and a lot of stuff inside.
00:05:39.810 It's a toolbox; it's not a fun project, but a collection of multiple techniques I've used to improve test speed.
00:05:46.470 So, from one hand, we help forefathers to identify bottlenecks, and on the other hand, we offer recipes, some small tweaks.
00:05:54.150 These allow you to easily pass your tests and make them faster without completely refactoring.
00:06:01.760 Let's start with some simple things like talking about profilers.
00:06:09.540 The first group of file profilers build on existing solutions in the Ruby world.
00:06:17.230 We got some broken Chrome and the new Arc's our be spike.
00:06:25.430 What's interesting about the center of the pipeline is that they provide side profile loading code.
00:06:33.730 However, they do not take into account the triad of probiotic tests, so they're not considering this context.
00:06:42.510 What we can do is provide execution details of your Ruby example without caring about your interests—
Explore all talks recorded at Balkan Ruby 2018
+8