Each sub-resources I add to an API representation introduces an n+1. I'd like a test to fail until I adjust the eager-loading accordingly. Seems pragmatic, despite the dangers of testing for performance optimisations.
I've gone with this for the moment: https://gist.github.com/3606669 The QuerySpy helps assert that increasing the number of records fetched does not increase the number of queries: it "should not exhibit n+1" do add_thing count1 = QuerySpy.count { get "/things" } add_thing count2 = QuerySpy.count { get "/things" } count2.should <= count1 end The API could be fancier, but it does the job. I can break eager-loading and see it fail, fix it and see it pass. — Paul On 03/09/2012, at 1:59 PM, Mark Wotton <[email protected]> wrote: > I think it's a pretty bad idea to mix up benchmarking and correctness tests. > > mark > > On Mon, Sep 3, 2012 at 1:56 PM, Tim McEwan <[email protected]> wrote: >> Could you set bullet* to run in your test env and assert that you don't see >> its log output? It would slow your tests down a fair bit though. >> >> Don't worry, I'm aware this is a terrible idea - but hopefully it gets the >> ball rolling. >> >> * https://github.com/flyerhzm/bullet >> >> On Monday, 3 September 2012 at 12:34, Paul Annesley wrote: >> >> I recently read a post about writing tests to catch n+1 query regressions, >> but I have no idea where it was. >> >> I'm not sure it's a good idea (or possible to do in a non-fragile way), but >> it would be useful at this phase of an app I'm working on. >> >> Does anybody remember the post, or have any thoughts on the matter? >> >> — Paul >> -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
