<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Just in case some low hanging fruit hasn't been covered;</div><div><br></div><div>I’d first turn your network connection off and run the test suit to catch any stupid tests coupled to api’s and put VCR on there for the moment. I’ve picked up several apps where this has happened.</div><div><br></div><div>If you’ve got Devise in there make sure your test_helper puts the stretch time down to one; Devise.stretches = 1</div><br>If Factory Girl is being used then move as many things to use builld_stubbed; <a href="http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC4QFjAA&url=http://robots.thoughtbot.com/use-factory-girls-build-stubbed-for-a-faster-test&ei=RcSgUo3jAfHfsATMhIDYBQ&usg=AFQjCNHoJnDsTswoJ2rjEAiBZistag7Fag&sig2=bqcTK9gelhyBWIl4t3hT9A&bvm=bv.57155469,d.cWc">Use Factory Girl's build_stubbed for a Faster Test Suite</a><div><br></div><div>What version of Ruby? I’ve found vanilla 1.8.7 benefitted from moving to EE and manually controlling GC YMMV;</div><div><br></div><div><a href="http://fredwu.me/post/60441991350/protip-ruby-devs-please-tweak-your-gc-settings-for">http://fredwu.me/post/60441991350/protip-ruby-devs-please-tweak-your-gc-settings-for</a></div><div><a href="https://gist.github.com/JamesChevalier/4735441">https://gist.github.com/JamesChevalier/4735441</a></div><div><a href="http://labs.goclio.com/tuning-ruby-garbage-collection-for-rspec/">http://labs.goclio.com/tuning-ruby-garbage-collection-for-rspec/</a></div><div><br></div><div>I have gone down the route of taking my least rails coupled tests require a skinny_test_helper.rb that doesn’t load the whole rails stack and provides just enough unit test running, leaving the slow stuff to integration and controller tests, and at this stage, only the stuff you can move over really easily or you are re-factoring the wrong thing.</div><div><br></div><div>Controller tests often get a bad rap, they can add value. Ask yourself if the goal of an integration test could be achieved by testing further down the stack where it consumes less resources e.g. is a test for the presence of a widgets description actually a proxy for the controller instantiating a variable. Is an integration test actually a proxy for testing a helper, or an indication that the view code should be re-factored into some kind of view [helper | view object | presenter | whatever you call it]? </div><div><br></div><div>But now I’m getting into re-factoring which I didn’t set out to comment on: <a href="http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/">http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/</a></div><div><br></div><div><div apple-content-edited="true"><div><br></div>
</div>
<br><div><div>On 5 Dec 2013, at 10:54, Sam Livingston-Gray <<a href="mailto:geeksam@gmail.com">geeksam@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I just put a require statement at the top of the fast test file for what I'm testing, and another one for anything it depends on. When that gets to be annoying, I know I have too many dependencies. ;)<br><br>--<br>(Sent from phone. Please excuse: brevity, top posting, hilarious autocorrections.)<br><br><blockquote type="cite">On Dec 5, 2013, at 7:29 AM, Jon Leighton <<a href="mailto:j@jonathanleighton.com">j@jonathanleighton.com</a>> wrote:<br><br>Hi Tom,<br><br><blockquote type="cite">On 05/12/13 09:28, Mr Jaba wrote:<br>Interesting points on making your unit tests independent of Rails, I<br>hadn't considered the class reloading aspect. Does this interfere very<br>badly? Is it avoidable at all? Or was the cost of maintaining all the<br>requires simply too high?<br></blockquote><br>If you want to run your tests outside of Rails, you can't rely on the<br>rails autoloading mechanism (ActiveSupport::Dependencies). But if you<br>put requires all over the place, it will prevent AS::Dependencies from<br>working when you *do* want it to (i.e. code reloading in dev mode won't<br>work, because the code was loaded by a require rather than a missing<br>constant).<br><br>The solution I ended up with was basically using require_dependency<br>rather than require, and stubbing out require_dependency for my "outside<br>Rails" tests. It was nasty.<br><br>In might be possible to *just* use AS::Dependencies in your unit tests,<br>without loading the full Rails app. That's something I didn't try, but<br>with spring loading the full app is not such a big deal for me these<br>days anyway, so I don't see the benefit of having tests that can run<br>outside of the Rails app.<br><br>Jon<br><br><blockquote type="cite"><br>Thanks again<br><br>Tom<br><br><br>On 5 December 2013 09:04, Jon Leighton <<a href="mailto:j@jonathanleighton.com">j@jonathanleighton.com</a><br><<a href="mailto:j@jonathanleighton.com">mailto:j@jonathanleighton.com</a>>> wrote:<br><br> Hi Tom,<br><br><blockquote type="cite"> On 04/12/13 22:56, Mr Jaba wrote:<br>First up, thanks for Spring (amongst your many other contributions!)<br>it's a really useful gem!<br></blockquote><br> Glad you like it!<br><br><blockquote type="cite">With regards to the factories, what do you recommend instead? Simpler<br>objects with less coupling to Rails?<br></blockquote><br> Yeah I don't like the factories approach at all. Apart from often being<br> a source of test slowness, they encourage you down the path of high<br> coupling and make it too trivial to create a boat load of<br> database-backed objects. Bo Jeanes wrote a post about this:<br> <a href="http://bjeanes.com/2012/02/factories-breed-complexity">http://bjeanes.com/2012/02/factories-breed-complexity</a><br><br> There are certainly situations in a Rails app where you need to test<br> against the database. For this I use fixtures, which I find perfectly<br> adequate and much faster than factories. You do need to ensure your<br> fixtures don't get out of control, but generally I think of fixtures as<br> a handful of pre-inserted records that I might modify in specific tests<br> in order to achieve a certain thing (rather than creating a new fixture<br> entry for each thing, which can get out of hand).<br><br> Apart from that, it's obviously wise to avoid inserting stuff in the<br> database as much as possible, e.g. if you just want to test the logic of<br> a certain method which only interacts with a model's attributes, you can<br> just create an in-memory instance.<br><br> I have been down the path of making my "unit tests" independent of the<br> Rails app so as to avoid the boot process, and found it impractical to<br> be honest:<br><br> 1) You end up with require and require_dependency everywhere, and it's<br> hard to get this right in a way that plays nicely with Rails' class<br> reloading<br> 2) Even if you make some tests independent of Rails, you're still going<br> to need some that are not independent of Rails, so you only solve part<br> of the problem<br><br> This was part of my motivation for spring - if we can't make get rid of<br> having to boot the Rails app, let's make booting the Rails app less<br> painful.<br><br> Not sure any of these comments help with your current predicament, but<br> hopefully they're vaguely useful anyway!<br><br> Jon<br><br><blockquote type="cite"><br>Thanks for your input!<br><br>Tom<br><br><br>On 4 December 2013 22:43, Jon Leighton <<a href="mailto:j@jonathanleighton.com">j@jonathanleighton.com</a><br></blockquote> <<a href="mailto:j@jonathanleighton.com">mailto:j@jonathanleighton.com</a>><br><blockquote type="cite"><<a href="mailto:j@jonathanleighton.com">mailto:j@jonathanleighton.com</a> <<a href="mailto:j@jonathanleighton.com">mailto:j@jonathanleighton.com</a>>>><br></blockquote> wrote:<br><blockquote type="cite"><br> Hello there,<br><br><blockquote type="cite"> On 04/12/13 22:20, Mr Jaba wrote:<br>I've recently taken ownership of a new project with a large<br></blockquote></blockquote> test suite<br><blockquote type="cite"><blockquote type="cite">(2000ish tests), and the overall run time is around 30 minutes<br></blockquote> which is<br><blockquote type="cite">certainly less than ideal!<br><br>Now I know the general approach to "Fast Rails Tests" but<br></blockquote></blockquote> taking the<br><blockquote type="cite"><blockquote type="cite">time to refactor the whole test suite is a bit too much<br></blockquote></blockquote> right now. I'm<br><blockquote type="cite"><blockquote type="cite">wondering if anyone has experience of transforming a test<br></blockquote></blockquote> suite of<br><blockquote type="cite"> this<br><blockquote type="cite">magnitude to something a bit speedier? If so how did you go<br></blockquote></blockquote> about it?<br><blockquote type="cite"><blockquote type="cite">What tips, tricks and techniques can you share?<br><br>A bit more info:<br><br>- Test::Unit tests, moving to Minitest<br>- Rails 3.2.16<br>- Running parallel_tests shaved 5 mins off the time<br>- Using Spring to reduce Rails load time.<br><br>Any advice gratefully received!<br></blockquote><br> I think you need to provide some more information :) What's<br></blockquote> making it<br><blockquote type="cite"> take so long - the sheer number of tests or what the tests are<br></blockquote> doing? Do<br><blockquote type="cite"> you have certain types of tests that are taking a large<br></blockquote> portion of the<br><blockquote type="cite"> time (e.g. Capybara tests?) Are you using factories? In my<br></blockquote> experience<br><blockquote type="cite"> factories are an easy cause of a slow test suite.<br><br> One thing to think about is whether you can break up your test<br></blockquote> suite.<br><blockquote type="cite"> For example in the application I work on, we have<br></blockquote> unit/integration tests<br><blockquote type="cite"> which run in about 25 seconds on my machine. I frequently run<br></blockquote> these<br><blockquote type="cite"> during development and they often alert me to problems. But I<br></blockquote> rarely run<br><blockquote type="cite"> the full set of capybara tests which takes several minutes - I<br></blockquote> let the<br><blockquote type="cite"> CI do that and run failing tests individually where necessary.<br></blockquote> This<br><blockquote type="cite"> achieves a decent balance of fast feedback for development without<br> throwing away the safety net of proper full-stack tests.<br><br> Jon<br> _______________________________________________<br> Chat mailing list<br> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a> <<a href="mailto:Chat@lists.lrug.org">mailto:Chat@lists.lrug.org</a>><br></blockquote> <<a href="mailto:Chat@lists.lrug.org">mailto:Chat@lists.lrug.org</a> <<a href="mailto:Chat@lists.lrug.org">mailto:Chat@lists.lrug.org</a>>><br><blockquote type="cite"> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br></blockquote></blockquote>_______________________________________________<br>Chat mailing list<br><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br></blockquote>_______________________________________________<br>Chat mailing list<br><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br></blockquote></div><br></div></body></html>