On Thu, Apr 16, 2009 at 11:23 PM, Lenny Marks wrote:
>
> On Apr 15, 2009, at 11:23 AM, Lenny Marks wrote:
>
>> Just tried it out. Something missed?
>>
>> -lenny
>>
>> > cat t.rb
>>
>> describe 'test' do
>> it "should not fail" do
>>['A'].should include('A')
>> end
>> end
>>
>> > spec -v
>>
>
On Apr 15, 2009, at 11:23 AM, Lenny Marks wrote:
Just tried it out. Something missed?
-lenny
> cat t.rb
describe 'test' do
it "should not fail" do
['A'].should include('A')
end
end
> spec -v
rspec 1.2.4
> spec t.rb
F
1)
NoMethodError in 'test should not fail'
undefined method `help
On Thu, Apr 16, 2009 at 1:15 PM, svoop wrote:
>> What do you mean by it blocks refactorings? This isn't any different
>> from the first example, with the exception that you provide a value
>> instead of letting the default kick in...
>
> article = Article.new
> article.fetched # => false (due t
> What do you mean by it blocks refactorings? This isn't any different
> from the first example, with the exception that you provide a value
> instead of letting the default kick in...
article = Article.new
article.fetched # => false (due to default)
article = Article.new(valid_attributes.exce
Hi,
I too am experiencing the "can't activate , already activated
cucumber-0.3.0" error when running
rake spec
OR
rake gems:unpack:dependencies GEM=cucumber
Was the fix described by Aslak in the 0.3.0 release? What is the gem source
that I should use to load aslakhellesoy-cucumber gem?
Thanks,
Yes that does help, thanks! I didn't know about shared example groups.
On Thu, Apr 16, 2009 at 2:12 PM, Pat Maddox wrote:
> What is the thing that's being done in a callback and also sometimes
> called by clients? Usually the semantics are different and you don't
> want to treat them exactly
Maybe I'm missing something...I've started getting timeout errors due to
"perform_delivery_smtp". I've checked environment.rb and test.rb, and they
look fine. Any ideas why these tests are trying to send actual messages and
timing out? Needless to say, with timeout errors things run really slow...
Thanks. I did that after finding the gem section on your site.
Things look better now.
Thanks,
Nick
On Wed, Apr 15, 2009 at 10:26 PM, David Chelimsky wrote:
> On Wed, Apr 15, 2009 at 11:10 AM, vanweerd wrote:
> > I'm the getting the following error when running rspec on a rails
> > project.
> >
On Thu, Apr 16, 2009 at 10:43 AM, svoop wrote:
> Hi
>
> I'm not sure what would be best practise to treat this case.
>
> Migration:
> t.boolean :fetched, :null => false, :default => false
>
> Model:
> validates_inclusion_of :fetched, :in => [true, false]
>
> Spec:
> it do
> article = Article.new(
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
What is the thing that's being done in a callback and also sometimes
called by clients? Usually the semantics are different and you don't
want to treat them exactly the same...
At any rate, you can be creative with shared example groups to get rid
of the duplication. Something like
describe "do
Errr... before callback. I've been spending too much time with controllers.
:-)
On Apr 16, 2009 1:34 PM, "Barun Singh" wrote:
In many of my models, I have callback methods like this:
class MyModel < ActiveRecord::Base
before_save :do_something
def do_something
some code here...
en
In cases like this I write tests for the method, in your case do_something,
and then spec the behavior that a filter exists which calls that method. No
more, no less. You can safely assume that ActiveRecord itself has tests to
ensure a properly declared before filter will be called when the model i
Oh, and I suppose the third option here could be to so something like:
[:do_something, :save].each do |method_name|
it "should satisfy some spec when we call the #{method_name} method" do
x = MyModel.new
x.call(method_name)
x.should ... (whatever the condition is here)
end
end
I use this so
Hi
I'm not sure what would be best practise to treat this case.
Migration:
t.boolean :fetched, :null => false, :default => false
Model:
validates_inclusion_of :fetched, :in => [true, false]
Spec:
it do
article = Article.new(valid_attributes.except(:fetched))
article.should have(1).error_on(
In many of my models, I have callback methods like this:
class MyModel < ActiveRecord::Base
before_save :do_something
def do_something
some code here...
end
end
The do_something method is a public method that is sometimes called on its
own, and also called whenever the model is sav
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
wow! even shorter :-)
2009/4/16 Matt Wynne
>
> On 16 Apr 2009, at 14:06, Joaquin Rivera Padron wrote:
>
> thanks matt,
>> yes, the regexp in the step matcher is a good one to dry it up
>>
>> So I end up with this one:
>>
>> Then /^I (should|should not) see the people search form$/ do |maybe|
>>
On 16 Apr 2009, at 14:06, Joaquin Rivera Padron wrote:
thanks matt,
yes, the regexp in the step matcher is a good one to dry it up
So I end up with this one:
Then /^I (should|should not) see the people search form$/ do |maybe|
people_search_form_should_exist maybe == "should"
end
and the m
> 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
> I thought he meant ruby setup.rb installed it.
Thanks for reading my message :-)
The problem is that it seems spicycode-rcov installs itself as an ersatz
of rcov with same names, so I cannot grep or locate spicycode-rcov
specific files, and I don't want to mess up my gem system. I tried to
l
aslak hellesoy wrote:
How can I uninstall a manually installed spicycode-rcov gem? I'd like to
install it using the rubygems management tool.
gem --help
gem help commands
gem uninstall spicycode-rcov
I thought he meant ruby setup.rb installed it.
I would either find it and yank it ou
On Thu, Apr 16, 2009 at 3:36 PM, Fernando Perez wrote:
> Chad Humphries wrote:
> > Githubs recent gem builder changes have caused some issues with
> > this. We are looking into it today in more detail. Pulling it down
> > and manually building should definitely work in the meantime.
>
> How can
Chad Humphries wrote:
> Githubs recent gem builder changes have caused some issues with
> this. We are looking into it today in more detail. Pulling it down
> and manually building should definitely work in the meantime.
How can I uninstall a manually installed spicycode-rcov gem? I'd like to
thanks matt,
yes, the regexp in the step matcher is a good one to dry it up
So I end up with this one:
Then /^I (should|should not) see the people search form$/ do |maybe|
people_search_form_should_exist maybe == "should"
end
and the method:
def people_search_form_should_exist it_should_exist
> @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
On 16 Apr 2009, at 11:22, Joaquin Rivera Padron wrote:
at the moment I do it this way, hiding the complexity out of the
steps:
Then /^I should see the people search form$/ do
people_search_form_exists
end
Then /^I should not see the people search form$/ do
people_search_form_exists "not
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(
> What's up will nullDB? I once saw the developper post a few message on
> the mailing-list. Anyone using it with success?
I saw a post by Pat Maddox and he talked about Sqlite in-memory, so I
decided to give it a try using this tutorial:
http://www.mathewabonyi.com/articles/2006/11/26/superfast
at the moment I do it this way, hiding the complexity out of the steps:
Then /^I should see the people search form$/ do
people_search_form_exists
end
Then /^I should not see the people search form$/ do
people_search_form_exists "not"
end
and then the method:
def people_search_form_exists ne
hey there,
this here may be a little too general, and maybe is only a though sharing,
but would be nice to hear what you think.
What is your opinion about expectation steps that negates another
expectation step?
for example: let's say I have a step that specs something:
Then /^I should see the p
Joaquin Rivera Padron wrote:
> hey there,
> maybe you should take a look at solutions that fake your database in
> memory
> for such cases, saving your time doing all that stubbing and mocking
Yeah you are right. I am refactoring (messing up?) code because I have a
DB constraint, so instead of re
hey there,
maybe you should take a look at solutions that fake your database in memory
for such cases, saving your time doing all that stubbing and mocking, I
don't remember right now but I think I saw some projects for such approach,
maybe someone knows better than I do :-)
hth
joaquin
__
By the way in Rails I am now finding myself replacing:
update_attributes, create! and their friends with something that looks
like:
new(...)
save!
Then in the spec I stub the save! method so that it doesn't hit the DB,
and then I can easily compare the object attributes if they are as
expecte
> So to recap, I would test this behavior via the Paypal examples,
> because that's where the behavior originates. I may or may not mock
> the call to order.update_from_paypal depending on how complex it is.
>
> Does that make sense?
Argh! I had sent you an answer but for some reason my session
43 matches
Mail list logo
