Rails - Jan 2006 - Unit Testing - Persistence of Destroyed Objects?

I was doing some unit testing today and came across something that surprised
me.  Either I am confused, or destroyed objects persist in memory when doing
unit testing.

To explain: I have a model, Author, which ''has_many
:web_resources''.   One
type of "web resource" for an Author is the authors website.  So, to
facilitate easy creation/lookup of websites for authors, I did the following
in author.rb (simplified):

def website=( str )
   wr = self.web_resources.first
   # We delete the first web resource if str is nil/empty
   if str.nil? || str == ""
       wr.destroy
       return
   end
   # Otherwise, create/modify website
   <snip>
end

def website()
    self.web_resources.first
end

Now, I was unit testing this today, and something unexpected (to me)
happend.

@author.website=''''
# The following test fails
assert_equal nil, @author.website
# However, if I do this, it does *not* fail
assert_equal nil, Author.find( @author.id ).website

Calling @author.website='''' is indeed destroying the object,
but in the unit
test calling @author.website the object persists, but if I do a brand new
Author.find(), it is not there.  Am I missing something here?

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060106/2ad337c0/attachment.html

> Calling @author.website='''' is indeed destroying the
object, but in the unit
> test calling @author.website the object persists, but if I do a brand new
> Author.find(), it is not there.  Am I missing something here?
>
> -Matt
Calling #destroy removes the row from the database, but the ruby object stays:
>> a = Article.find :first
=> #<Article:0x238be9c
@attributes={...snip...}>
>> a.id
=> 1
>> a.destroy
=> #<Article:0x238be9c
@attributes={...snip...}>
>> a.title # title attr is still available
=> "Welcome to Mephisto"
>> a.id   # id attr is still available
=> 1
>> Article.find_by_id 1
=> nil     # not in the db anymore however

--
rick
http://techno-weenie.net