Rails core - Oct 2011 - Making after_commit hooks testable with transactional fixtures

It''s sort of annoying not to be able to test after_commit hooks with
transactional fixtures.  Mat Brown came up with this solution:

http://outofti.me/post/4777884779/test-after-commit-hooks-with-transactional-fixtures

I am pretty uncomfortable having this monkey patch in my app given its
scope, so I''m wondering if there might be some way to fix this in
Rails proper.  Before putting any time into this I wanted to get Core
feedback as to whether the essence of Mat''s solution would be
acceptable, or if you anticipate too many problems, or if there is an
alternate approach worth pursuing...

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

What''s wrong with turning off transactional fixtures in the tests that
check after_commit/after_rollback functionality ? You can check what
you need and clean the db yourself in the test or teardown.

Robert Pankowecki

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Massive overhead in instantiating the fixtures each time.  If I were
to start from scratch I would certainly not depend on a large fixture
set, but at this point we depend on transactional fixtures for
performance.

On Oct 11, 2:00 pm, Robert Pankowecki <robert.pankowe...@gmail.com>
wrote:
> What''s wrong with turning off transactional fixtures in the tests
that
> check after_commit/after_rollback functionality ? You can check what
> you need and clean the db yourself in the test or teardown.
>
> Robert Pankowecki
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

You can turn transaction fixtures off for an individual set of tests though, and
still run the rest of your test suite quickly.

I was actually asking if anyone wanted after_commit/rollback in their tests a
few days ago, in the thread about transactional fixture bloating.  No-one seemed
to be interested though, so I didn''t implement it.


On 13/10/2011, at 10:35 , Gabe da Silveira wrote:
> Massive overhead in instantiating the fixtures each time.  If I were
> to start from scratch I would certainly not depend on a large fixture
> set, but at this point we depend on transactional fixtures for
> performance.
> 
> On Oct 11, 2:00 pm, Robert Pankowecki <robert.pankowe...@gmail.com>
> wrote:
>> What''s wrong with turning off transactional fixtures in the
tests that
>> check after_commit/after_rollback functionality ? You can check what
>> you need and clean the db yourself in the test or teardown.
>> 
>> Robert Pankowecki
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
> 
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Wed, Oct 12, 2011 at 11:53 PM, Will Bryant <will.bryant@gmail.com>
wrote:
> You can turn transaction fixtures off for an individual set of tests though
Exacyly what I mean.

class Test < ActiveSupport::TestCase
 self.use_transactional_fixutures = false
end

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I am interested at least. I use after_commit heavily with resque and
database cleaner is slower than transactional fixtures.

On Oct 13, 12:53 am, Will Bryant <will.bry...@gmail.com>
wrote:
> You can turn transaction fixtures off for an individual set of tests
though, and still run the rest of your test suite quickly.
>
> I was actually asking if anyone wanted after_commit/rollback in their tests
a few days ago, in the thread about transactional fixture bloating.  No-one
seemed to be interested though, so I didn''t implement it.
>
> On 13/10/2011, at 10:35 , Gabe da Silveira wrote:
>
>
>
>
>
>
>
> > Massive overhead in instantiating the fixtures each time.  If I were
> > to start from scratch I would certainly not depend on a large fixture
> > set, but at this point we depend on transactional fixtures for
> > performance.
>
> > On Oct 11, 2:00 pm, Robert Pankowecki
<robert.pankowe...@gmail.com>
> > wrote:
> >> What''s wrong with turning off transactional fixtures in
the tests that
> >> check after_commit/after_rollback functionality ? You can check
what
> >> you need and clean the db yourself in the test or teardown.
>
> >> Robert Pankowecki
>
> > --
> > You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Core" group.
> > To post to this group, send email to
rubyonrails-core@googlegroups.com.
> > To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> > For more options, visit this group
athttp://groups.google.com/group/rubyonrails-core?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.