Ben, Here is some great information on caching you might find interesting:
http://hawkins.io/2012/07/advanced_caching_revised/ -- Ylan Segal On Wednesday, October 8, 2014 at 4:54 PM, Ben Nelson wrote: > Yeah you can turn the feature off in testing. So far I've basically been > doing what you described but I recently got advice to do something called > Russian Doll Caching? It's something I guess I will look into soon. > > On Wednesday, October 8, 2014 3:26:29 PM UTC-7, Ylan Segal wrote: > > I am not using bullet currently, but have done so in the past. Because of > > the reasons you described, I didn’t really use the data generated during > > testing. However, I did find it very useful when working in development and > > smoke testing my app (that is, just using it) and for staging environments. > > > > > > If I recall correctly, Bullet made it very easy to ignore test data by > > either configuring it to not run or else logging in a different file (I > > forget which one, it’s been a while). > > > > -- > > Ylan Segal > > > > > > On Tuesday, October 7, 2014 at 5:02 PM, Ben Nelson wrote: > > > > > Has anyone used the Bullet (https://github.com/flyerhzm/bullet) gem with > > > RSpec to improve their app's performance? I can see the use on testing > > > just as a part of manual testing (when you get notifications about n+1 > > > queries on the webpage) but for the testing framework I've noticed that a > > > lot of calls are not really related to n+1 calls that are necessarily > > > deterring app performance. For example, one call that had an n+1 query > > > was just verifying something on a model was set correctly. It only > > > mattered within the scope of the test, outside of it that function was > > > never called in that way. Thus, many of the failures I see when I put > > > Bullet to fail my tests on n+1 queries are unrelated to my app in > > > production. > > > > > > Thoughts? > > > > > > Thanks! > > > > > > PS I'm a newbie here, just moved from Utah! Nice to meet ya'll! > > > > > > -- > > > -- > > > SD Ruby mailing list > > > [email protected] (javascript:) (mailto:[email protected] > > > (javascript:)) > > > http://groups.google.com/group/sdruby > > > --- > > > You received this message because you are subscribed to the Google Groups > > > "SD Ruby" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [email protected] (javascript:) > > > (mailto:[email protected] (javascript:)). > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > -- > SD Ruby mailing list > [email protected] (mailto:[email protected]) > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > (mailto:[email protected]). > For more options, visit https://groups.google.com/d/optout. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
