<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Joey Schoblaska</title>
    <description>The latest articles on DEV Community by Joey Schoblaska (@joeyschoblaska).</description>
    <link>https://dev.to/joeyschoblaska</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F121797%2F0c9e29c8-25cf-4856-aa59-c8e7dd9ef93a.png</url>
      <title>DEV Community: Joey Schoblaska</title>
      <link>https://dev.to/joeyschoblaska</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/joeyschoblaska"/>
    <language>en</language>
    <item>
      <title>Make Your Specs Faster With Sleep Study</title>
      <dc:creator>Joey Schoblaska</dc:creator>
      <pubDate>Fri, 11 Jan 2019 21:50:01 +0000</pubDate>
      <link>https://dev.to/joeyschoblaska/make-your-specs-faster-with-sleep-study-1ff</link>
      <guid>https://dev.to/joeyschoblaska/make-your-specs-faster-with-sleep-study-1ff</guid>
      <description>&lt;p&gt;There are a lot of reasons why test suites for large applications become slow. One of them - errant &lt;code&gt;sleep&lt;/code&gt; statements in your code - is easy to fix and, with the &lt;code&gt;rspec-sleep_study&lt;/code&gt; gem, easy to find.&lt;/p&gt;

&lt;p&gt;Any time you find a spec that takes a nice, round number of seconds to complete, you should immediately be suspicious. Especially when the code under test integrates with another service or makes any kind of network calls.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;Top 4 slowest examples (40.14 seconds, 96.0% of total time):
  IntercomClient::post when an error is raised when it's a retryable error retries
    20.04 seconds ./spec/services/data/intercom_client_spec.rb:45
  IntercomClient::get when an error is raised when it's a retryable error retries
    20.01 seconds ./spec/services/data/intercom_client_spec.rb:23
  IntercomClient::get when an error is raised raises the error
    0.07472 seconds ./spec/services/data/intercom_client_spec.rb:17
  IntercomClient::post when an error is raised raises the error
    0.01893 seconds ./spec/services/data/intercom_client_spec.rb:39

Finished in 41.82 seconds (files took 8.88 seconds to load)
4 examples, 0 failures
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;This is usually a sign that you have a &lt;code&gt;sleep&lt;/code&gt; somewhere in your code, and your specs are blocking while they wait for the sleeps to complete.&lt;/p&gt;

&lt;p&gt;The solution to this is generally easy: you need to stub out the sleep statements or the sleep interval in your specs. But how do you find out which specs are blocking, and where, so that you can fix them? That's where &lt;a href="http://github.com/KennaSecurity/rspec-sleep_study"&gt;Sleep Study&lt;/a&gt; comes in.&lt;/p&gt;

&lt;p&gt;Sleep Study uses Ruby's &lt;a href="https://ruby-doc.org/core-2.0.0/TracePoint.html"&gt;TracePoint&lt;/a&gt; class to wrap every C function call and return executed by your code. If it detects a &lt;code&gt;sleep&lt;/code&gt; function, it records the time spent sleeping and then prints a report showing you both the spec and the line(s) of code responsible.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;$ gem install rspec-sleep_study
$ rspec --format RSpec::SleepStudy spec/services/data/intercom_client_spec.rb

...

The following examples spent the most time in `sleep`:
  20.013 seconds: ./spec/services/data/intercom_client_spec.rb:23
    - 20.013 seconds: /opt/apps/vendor/ruby/2.5.0/gems/retryable-2.0.4/lib/retryable/configuration.rb:36
  20.001 seconds: ./spec/services/data/intercom_client_spec.rb:45
    - 20.001 seconds: /opt/apps/vendor/ruby/2.5.0/gems/retryable-2.0.4/lib/retryable/configuration.rb:36
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;Now we know that our specs are indeed blocking on sleep, and we have an idea of where to look in our code: somewhere in our client class we're calling &lt;code&gt;Retryable&lt;/code&gt;.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nc"&gt;self&lt;/span&gt;&lt;span class="o"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;get&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;endpoint&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
  &lt;span class="no"&gt;Retryable&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;retryable&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="ss"&gt;:tries&lt;/span&gt; &lt;span class="o"&gt;=&amp;gt;&lt;/span&gt; &lt;span class="mi"&gt;5&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;:sleep&lt;/span&gt; &lt;span class="o"&gt;=&amp;gt;&lt;/span&gt; &lt;span class="no"&gt;RETRY_SLEEP&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="k"&gt;do&lt;/span&gt;
    &lt;span class="no"&gt;JSON&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;parse&lt;/span&gt; &lt;span class="no"&gt;RestClient&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;get&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;endpoint&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="no"&gt;HEADERS&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
  &lt;span class="k"&gt;end&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;

&lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nc"&gt;self&lt;/span&gt;&lt;span class="o"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;post&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;endpoint&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;data&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
  &lt;span class="no"&gt;Retryable&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;retryable&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="ss"&gt;:tries&lt;/span&gt; &lt;span class="o"&gt;=&amp;gt;&lt;/span&gt; &lt;span class="mi"&gt;5&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;:sleep&lt;/span&gt; &lt;span class="o"&gt;=&amp;gt;&lt;/span&gt; &lt;span class="no"&gt;RETRY_SLEEP&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="k"&gt;do&lt;/span&gt;
    &lt;span class="no"&gt;JSON&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;parse&lt;/span&gt; &lt;span class="no"&gt;RestClient&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;post&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;endpoint&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;data&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;to_json&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="no"&gt;HEADERS&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
  &lt;span class="k"&gt;end&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;And now that we've found that, we can make our specs run way faster by stubbing that &lt;code&gt;RETRY_SLEEP&lt;/code&gt; constant:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="n"&gt;before&lt;/span&gt; &lt;span class="k"&gt;do&lt;/span&gt;
  &lt;span class="n"&gt;stub_const&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s2"&gt;"IntercomClient::RETRY_SLEEP"&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="mi"&gt;0&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;





&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;Top 4 slowest examples (0.08328 seconds, 4.3% of total time):
  IntercomClient::post when an error is raised raises the error
    0.0358 seconds ./spec/services/data/intercom_client_spec.rb:39
  IntercomClient::get when an error is raised when it's a retryable error retries
    0.02302 seconds ./spec/services/data/intercom_client_spec.rb:23
  IntercomClient::get when an error is raised raises the error
    0.0135 seconds ./spec/services/data/intercom_client_spec.rb:17
  IntercomClient::post when an error is raised when it's a retryable error retries
    0.01096 seconds ./spec/services/data/intercom_client_spec.rb:45

Finished in 1.94 seconds (files took 7.54 seconds to load)
4 examples, 0 failures
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;40 seconds shaved off our build time with a one-line change!&lt;/p&gt;

&lt;p&gt;It's important to note that putting trace points around every single C function isn't free, and Sleep Study WILL make your specs run more slowly. Only use it once in a while to find new sleeps that have snuck into your code. Stub those sleeps out, open a PR showing how much faster you made your tests, and then do a victory lap around the office and collect your high fives.&lt;/p&gt;

</description>
      <category>ruby</category>
      <category>rails</category>
      <category>testing</category>
    </item>
  </channel>
</rss>
