On Thu, Apr 16, 2009 at 10:23 AM, Pat Maddox wrote:
> On Thursday, April 16, 2009, Mark Wilden wrote:
>> On Thu, Apr 16, 2009 at 7:33 AM, Pat Maddox wrote:
>>
>>> You're setting an instance variable on a class, which is a global
>>> variable
>>
>> I wouldn't call a class instance variable global
On Thursday, April 16, 2009, Mark Wilden wrote:
> On Thu, Apr 16, 2009 at 7:33 AM, Pat Maddox wrote:
>
>> You're setting an instance variable on a class, which is a global
>> variable
>
> I wouldn't call a class instance variable global. It's accessible to
> only one object, after all.
Neither w
On Thu, Apr 16, 2009 at 7:33 AM, Pat Maddox wrote:
> You're setting an instance variable on a class, which is a global
> variable
I wouldn't call a class instance variable global. It's accessible to
only one object, after all.
> and is not garbage collected. The state you set is maintained
> ac
> This is one example of how global variables suck.
>
> Also your code doesn't make sense to me. I'd you called it twice, each
> with different users, you would get the same result which is prob not
> what you want.
Yup, that's why I corrected it. Now the method is an instance method of
User, so
On Thu, Apr 16, 2009 at 5:46 AM, Matthew Krom wrote:
> Also, just noticed your class-caching isn't keyed off user. (I'm also
> honestly not sure what @ instead of @@ means inside a self. class method;
> I'd have to look that up and write specs to test it!)
@var inside a class method is just an
You're setting an instance variable on a class, which is a global
variable and is not garbage collected. The state you set is maintained
across runs, screwing things up.
If you set config.cache_classes to false in environments/test.rb I
think it ought to reload the classes each time.
There's no w
> @expiry_date_cache ||= {}
> @expiry_date_cache[user.id] ||= find_if_expiry_date_for(user)
>From the beginning my code was silly. The cache has to be tied to an
object that only exists for the current request being processed. So I
have refactored it.
tdd/bdd/rspec/test::unit/whatever helped m
I missed that; sorry. When code uses class-cached data for performance,
I've developed a testing pattern that explicitly clears class-cached data as
part of the test data setup. It does require careful attention. I'd be
interested in what others do!
On Thu, Apr 16, 2009 at 8:20 AM, Fernando Per
Also, just noticed your class-caching isn't keyed off user. (I'm also
honestly not sure what @ instead of @@ means inside a self. class method;
I'd have to look that up and write specs to test it!)
Something like this may work better.
@expiry_date_cache ||= {}
@expiry_date_cache[user.id] ||= fin
> But I thing that I really have a flaw in my code
I confirm, my code had a big flaw.
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Matthew Krom wrote:
> Your single test may be relying on database data that is set up (and
The tests don't hit the database. Only one previous test hits the same
method and forces the class to set this instance variable.
But I thing that I really have a flaw in my code, as this class instance
v
Your single test may be relying on database data that is set up (and left
there) by a different test. (In your non-sqlite database, the data may be
sitting there as the result of previous testing activity, so the single test
may pass there and not on sqlite)
On Thu, Apr 16, 2009 at 7:51 AM, Ferna
When trying to test using sqlite in-memory in ran into a problem:
- rake test raises an error on a test
- running the failing test alone works perfectly.
So what's the problem? here is the method giving the trouble:
def self.expiry_date_for(user)
@expiry_date_cache ||= find_if_expiry_date_for(
13 matches
Mail list logo
