<div dir="ltr">Hi Jon, <div><br></div><div>That's all very useful stuff, thanks very much. Interesting to hear people are going from Fixtures, to Factories and back to Fixtures again! Factories are definitely slow, but I guess as long as your fixtures are managed carefully they're not exactly as evil as they've been made out to be. </div>
<div><br></div><div>Interesting points on making your unit tests independent of Rails, I hadn't considered the class reloading aspect. Does this interfere very badly? Is it avoidable at all? Or was the cost of maintaining all the requires simply too high? </div>
<div><br></div><div>Thanks again</div><div><br></div><div>Tom</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 5 December 2013 09:04, Jon Leighton <span dir="ltr"><<a href="mailto:j@jonathanleighton.com" target="_blank">j@jonathanleighton.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tom,<br>
<div class="im"><br>
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>
<br>
</div>Glad you like it!<br>
<div class="im"><br>
> With regards to the factories, what do you recommend instead? Simpler<br>
> objects with less coupling to Rails?<br>
<br>
</div>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" target="_blank">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 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>
<div class="im"><br>
><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>
</div><div><div class="h5">> <mailto:<a href="mailto:j@jonathanleighton.com">j@jonathanleighton.com</a>>> wrote:<br>
><br>
> Hello there,<br>
><br>
> On 04/12/13 22:20, Mr Jaba wrote:<br>
> > I've recently taken ownership of a new project with a large test suite<br>
> > (2000ish tests), and the overall run time is around 30 minutes<br>
> which is<br>
> > certainly less than ideal!<br>
> ><br>
> > Now I know the general approach to "Fast Rails Tests" but taking the<br>
> > time to refactor the whole test suite is a bit too much right now. I'm<br>
> > wondering if anyone has experience of transforming a test suite of<br>
> this<br>
> > magnitude to something a bit speedier? If so how did you go about it?<br>
> > 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>
><br>
> I think you need to provide some more information :) What's making it<br>
> take so long - the sheer number of tests or what the tests are doing? Do<br>
> you have certain types of tests that are taking a large portion of the<br>
> time (e.g. Capybara tests?) Are you using factories? In my experience<br>
> 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 suite.<br>
> For example in the application I work on, we have unit/integration tests<br>
> which run in about 25 seconds on my machine. I frequently run these<br>
> during development and they often alert me to problems. But I rarely run<br>
> the full set of capybara tests which takes several minutes - I let the<br>
> CI do that and run failing tests individually where necessary. This<br>
> 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>
</div></div>> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a> <mailto:<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a>><br>
> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
><br>
><br>
</blockquote></div><br></div>