[Chirb] tools, already in play and coming soon

Ryan Platte ryan.platte at gmail.com
Fri Jun 20 08:49:13 EDT 2008


I'm sorry to keep everybody on pins and needles, I simply don't have  
leisure time to work up a blog post on this right now, and I'm not  
sure when I will. Apologies to all.

On Jun 19, 2008, at 10:36 PM, Jake Scruggs wrote:

> yep, at
> http://jakescruggs.blogspot.com/2008/06/disconnecting-rspec-from- 
> database.html
>
> I mostly just talk about my experiences with NullDB and call out  
> Ryan to talk about UnitRecord.
> -Jake
>
> On Thu, Jun 19, 2008 at 6:14 PM, Nate Kirby <natebkirby at yahoo.com>  
> wrote:
> Jake,
>
> Did this blogging ever take place?  I am also quite interested.
>
> Does UnitRecord play nice with Story Runner?
>
> Blessings,
> Nate
>
> Ryan Platte wrote:
>>
>> Go for it, Jake. I'm interested to see what you'll write.
>>
>> On Thu, Jun 12, 2008 at 7:23 PM, Jake Scruggs  
>> <jake.scruggs at gmail.com> wrote:
>> I haven't had any problems with NullDB, but failing silently is  
>> its thing (Null Object Pattern and all) so be careful.  I think  
>> the tagging bit you describe as coming soon to RSpec is pretty cool.
>>
>> I'm probably going to blog about this soon and will quote some  
>> things from Ryan and David's responses -- unless of course either  
>> of you object.
>> -Jake
>>
>>
>> On Wed, Jun 11, 2008 at 10:08 AM, David Chelimsky  
>> <dchelimsky at gmail.com> wrote:
>> Hey Jake - thanks for sharing this. Couple o' comments below:
>>
>> On Jun 11, 2008, at 9:26 AM, Jake Scruggs wrote:
>>> I've been using the NullDb (http://agilewebdevelopment.com/ 
>>> plugins/nulldb) plugin to disconnect RSpec from the database.
>>
>> The only drawback I've heard about NullDb is that it fails  
>> silently in certain cases - has led to some painful debugging.  
>> Have you had that experience?
>>
>>> I don't like the global disconnect (for all specs everywhere)  
>>> that the web page suggests, so I set up this in my spec_helper:
>>>
>>> describe "Unit Spec", :shared => true do
>>>   before :all do
>>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>>   end
>>>
>>>   after :all do
>>>     ActiveRecord::Base.establish_connection(:test)
>>>   end
>>> end
>>>
>>> and then say this inside any describe block I want to disconnect  
>>> from the db:
>>>
>>> require File.dirname(__FILE__) + "/../spec_helper"
>>>
>>> describe User do
>>>   it_should_behave_like "Unit Spec"
>>
>> This is cool that it works, but using it_should_behave_like feels  
>> odd to me in this case. The User should not behave like a Unit  
>> Spec, the examples should be disconnected.
>>
>> You can do this instead if you like:
>>
>> share_as :Disconnected do
>>
>>   before :all do
>>     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>   end
>>
>>   after :all do
>>     ActiveRecord::Base.establish_connection(:test)
>>   end
>> end
>>
>> describe User do
>>   include Disconnected
>> ...
>>
>> Right now we don't have an arbitrary tagging mechanism but it's  
>> something we've talked about. This gives me an idea that I'd like  
>> to implement, and everything is pretty much in place to support  
>> this, where the options hash is available to you in the before and  
>> after blocks, so you could do this (CAREFUL - THIS DOES NOT WORK  
>> TODAY):
>>
>> Spec::Runner.configure do |config|
>>   config.before(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:adapter => :nulldb)
>>     end
>>   end
>>   config.after(:all)
>>     if example_group_options[:disconnected]
>>       ActiveRecord::Base.establish_connection(:test)
>>     end
>>   end
>> end
>>
>> Then you'd be able to say:
>>
>> describe User, :disconnected => true do
>>   ...
>>
>> WDYT about that?
>>
>> Cheers,
>> David
>>
>>
>>
>>>
>>> .
>>> .
>>> .
>>>
>>> using nested describes to separate my unit (don't hit the db)  
>>> from my functional (do hit the db) specs
>>>
>>> -Jake
>>>
>>> On Wed, Jun 11, 2008 at 8:37 AM, Ryan Platte <ryan at platte.name>  
>>> wrote:
>>> Here are some Rake tasks I created to use RSpec with UnitRecord.  
>>> I set the default task to first run spec:fast, then spec:slow, so  
>>> if the fast ones fail we don't have to wait on the slow ones to  
>>> set up and run.
>>>
>>> The fly in the ointment is that schema.rb has to be current.
>>>
>>> namespace :spec do
>>>
>>>   desc "Run all fast specs in spec directory (excluding plugin  
>>> specs)"
>>>   Spec::Rake::SpecTask.new(:fast) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files = FileList['spec/**/*_fast_spec.rb']
>>>     #t.ruby_opts = ['-r spec/spec_helper', '-rubygems', '- 
>>> runit_record', "-e 'ActiveRecord::Base.disconnect!'"]
>>>   end
>>>
>>>   desc "Run all non-fast specs in spec directory (excluding  
>>> plugin specs)"
>>>   Spec::Rake::SpecTask.new(:slow => spec_prereq) do |t|
>>>     t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
>>>     t.spec_files = FileList['spec/**/*_spec.rb'].exclude('spec/**/ 
>>> *_fast_spec.rb')
>>>   end
>>>
>>> end
>>>
>>>
>>> On Wed, Jun 11, 2008 at 1:36 AM, David Chelimsky  
>>> <dchelimsky at gmail.com> wrote:
>>> On Jun 9, 2008, at 11:31 PM, David Chelimsky wrote:
>>>
>>> Hey Chirb,
>>>
>>>
>>> Lastly, I may have mis-spoke about rails loading up columns from  
>>> schema.rb - I'm looking into it and will follow up when I learn  
>>> the truth. So Ryan - keep using unit-record for now :)
>>>
>>> I definitely mis-spoke. I don't know where I got that in my head,  
>>> but it seems I did.
>>>
>>> I don't recall who said it, but unit_record does the column  
>>> caching I thought rails did. So now it's off to figure out how to  
>>> get rspec to play nice w/ unit_record.
>>>
>>> More soon.
>>>
>>>
>>> Cheers,
>>> David
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>>
>>>
>>> -- 
>>> Ryan Platte
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>>
>>> _______________________________________________
>>> ChicagoGroup-Members-List at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>>
>>
>>
>> -- 
>> Ryan Platte
>> _______________________________________________
>> ChicagoGroup-Members-List at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list
>
> _______________________________________________
> ChicagoGroup-Members-List at rubyforge.org
> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20080620/eb1feb20/attachment-0003.html>


More information about the ChicagoGroup-Members-List mailing list