Hello,
according to this post:
http://blog.davidchelimsky.net/2009/1/13/rspec-1-1-12-is-released
I should be able to write:
describe User do
it {should valdate_presence_of(:login)}
end
with rspec 1.1.12
But I got:
NO NAME
undefined method `valdate_presence_of’ for
#Spec::Rails::Example::ModelExampleGroup::Subclass_1:0x2513298
What did I do it wrong? Thanks for helping.
Yi
Sorry for the spam, I relized there was a typo. It should be
it {should validate_presence_of(:login)}
It still didn’t work
On Tue, Feb 17, 2009 at 6:25 PM, Yi Wen [email protected] wrote:
Sorry for the spam, I relized there was a typo. It should be
it {should validate_presence_of(:login)}
It still didn’t work
Scrolling up a bit …
“There are a few matcher libraries out there like
rspec-on-rails-matchers that provide matchers like this
validate_presence_of(:email)”
validate_presence_of() is not part of rspec-rails. You can find
libraries that offer comparable matchers at:
http://github.com/technoweenie/rspec_on_rails_on_crack/tree/master
HTH,
David
But I got:
NO NAME
undefined method `valdate_presence_of’ for
#Spec::Rails::Example::ModelExampleGroup::Subclass_1:0x2513298
Hi Yi,
I believe you’re looking for validate_presence_of - you missed an “i”
in validate
On Tue, Feb 17, 2009 at 8:42 PM, Yi Wen [email protected] wrote:
ah! sorry, my bad. Thanks!
No worries - I always just read the code first too 
ah! sorry, my bad. Thanks!
Yi Wen wrote:
Hello,
according to this post:
http://blog.davidchelimsky.net/2009/1/13/rspec-1-1-12-is-releasedI should be able to write:
describe User do
it {should valdate_presence_of(:login)}
end
What’s the point in testing validates_presence_of for a model? It’s
already tested in the framework, and so readable that a quick glance on
the model says it all. I would only test it if I added some bizarre
behavior with procs and so on.
What’s the community’s position about that?
On Wed, Feb 18, 2009 at 4:39 PM, Fernando P. [email protected]
wrote:
end
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
I’m with you, but there’s nothing even close to consensus on this.
A lot of people liken it to double-entry bookkeeping.
Pat
On Wed, Feb 18, 2009 at 7:39 PM, Fernando P. [email protected]
wrote:
end
What’s the point in testing validates_presence_of for a model?
IMO…
It definitely doesn’t provide any design benefits since that decision
has already been made for you, but it does provide a developer-level
example to communicate the behaviour of a model, and it covers
regression. I prefer both of these.
The flip-side would be that if you and your customer wrote scenarios
which communicated the same intent, as well as were executable then
you’d also achieve these benefits. While this works, if often doesn’t
fit the bill for a scenario very well (I prefer less verbose, higher
level declarative scenarios) and it misses out on providing developer
documentation for how a particular object should behave.
For me, a non-option is to have neither of these in place.
It’s
already tested in the framework, and so readable that a quick glance on
the model says it all. I would only test it if I added some bizarre
behavior with procs and so on.
What’s tested in the framework is that validates_presence works. What
isn’t tested is that your Item model needs to ensure it always belongs
to an :order. I’m more interested in the fact that Item always
requires an order. I expected the Rails developers to do their due
diligence to ensure validates_presence_of works in all of its
intricacies.
What’s the community’s position about that?
What Pat said.
–
Posted via http://www.ruby-forum.com/.
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
–
Zach D.
http://www.continuousthinking.com
On 19/02/2009, at 11:39 , Fernando P. wrote:
What’s the point in testing validates_presence_of for a model? It’s
already tested in the framework, and so readable that a quick glance
on
the model says it all.
Some people want the spec to stand as a contract, so you can then hand
the spec over to the proverbial trained monkeys and have them write
all the necessary code from scratch exactly the way you want it written.
These are not people I enjoy working with, so I play loose with the
specs and only spec stuff that matters to me at the time, code that
little bit, and get on with the next terribly pressing task.
Alex
On Wed, Feb 18, 2009 at 8:47 PM, Alex S. [email protected]
wrote:
On 19/02/2009, at 11:39 , Fernando P. wrote:
What’s the point in testing validates_presence_of for a model? It’s
already tested in the framework, and so readable that a quick glance on
the model says it all.Some people want the spec to stand as a contract, so you can then hand the
spec over to the proverbial trained monkeys and have them write all the
necessary code from scratch exactly the way you want it written.
I have never seen or heard of anyone who writes a spec (developer
level RSpec spec), but not the code and then hands it over to someone
else and demands that that person implements it. If you do or have
could you share, I’m interested in hearing about that experience.
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
–
Zach D.
http://www.continuousthinking.com
On Wed, Feb 18, 2009 at 7:39 PM, Fernando P. [email protected]
wrote:
end
What’s the point in testing validates_presence_of for a model? It’s
already tested in the framework, and so readable that a quick glance on
the model says it all. I would only test it if I added some bizarre
behavior with procs and so on.
Question for folks who don’t like writing any examples for this kind
of thing (including scenarios/steps). If I go tuck away some behaviour
behind a nice declarative interface, will you not care about having
examples showing that your objects utilize that behaviour?
Not testing things that have no logic makes sense. However, validation
methods have logic, it’s just wrapped up behind a nice interface.
What’s the community’s position about that?
Posted via http://www.ruby-forum.com/.
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
–
Zach D.
http://www.continuousthinking.com
On 19/02/2009, at 13:02 , Zach D. wrote:
I have never seen or heard of anyone who writes a spec (developer
level RSpec spec), but not the code and then hands it over to someone
else and demands that that person implements it.
The fun begins when you can point out two or three conflicting
requirements on the first page, such as “end date should not be null”
right next to, “a version with no end date is current for all dates
after the start date.”
Then I sat the guy down and introduced him to autotest, commited the
specification to version control, removed all but the first three
entries and showed how to build from small pieces.
So truthfully speaking, I’ve not yet worked in an environment where
RSpec was used to specify a design up front. And I certainly won’t be
introducing new managers to RSpec before introducing them to unit
testing, then testing driven development, and then behaviour driven
development. I prefer my feet intact and still attached to my legs!
Alex
On Wed, Feb 18, 2009 at 9:02 PM, Alex S. [email protected]
wrote:
Then I sat the guy down and introduced him to autotest, commited the
specification to version control, removed all but the first three entries
and showed how to build from small pieces.So truthfully speaking, I’ve not yet worked in an environment where RSpec
was used to specify a design up front. And I certainly won’t be introducing
new managers to RSpec before introducing them to unit testing, then testing
driven development, and then behaviour driven development. I prefer my feet
intact and still attached to my legs!
Why not start w/ RSpec but do it right?
On Wed, Feb 18, 2009 at 4:39 PM, Fernando P. [email protected]
wrote:
I should be able to write:
describe User do
it {should valdate_presence_of(:login)}
endWhat’s the point in testing validates_presence_of for a model?
To make sure you wrote that line of code.
///ark
On Feb 18, 2009, at 7:39 PM, Fernando P. wrote:
end
What’s the point in testing validates_presence_of for a model? It’s
already tested in the framework, and so readable that a quick glance
on
the model says it all. I would only test it if I added some bizarre
behavior with procs and so on.What’s the community’s position about that?
It shouldn’t be a test, it’s a spec. So it’s done before you write
the code. The specs describe the behavior of the application.
On Wed, Feb 18, 2009 at 7:42 PM, Mark W. [email protected] wrote:
To make sure you wrote that line of code.
and how do you make sure you wrote this one?
it {should valdate_presence_of(:login)}
On Wed, Feb 18, 2009 at 9:42 PM, Mark W. [email protected] wrote:
To make sure you wrote that line of code.
Close.
To make sure you “will” write that line of code.
On 19/02/2009, at 14:05 , David C. wrote:
Why not start w/ RSpec but do it right?
I made the mistake of showing the guy a spec from a previous project
and narrating (not showing) how the code was built from the spec. So
the manager didn’t realise that the spec was built one line at a time.
My fault entirely, the guy is now “doing it right” 
Alex
On Wed, Feb 18, 2009 at 6:06 PM, Zach D. [email protected]
wrote:
it {should valdate_presence_of(:login)}
behind a nice declarative interface, will you not care about having
examples showing that your objects utilize that behaviour?
That’s a huge “depends” but yeah, basically. I don’t really test code
that can’t possibly break. Declarative code like Rails validations or
associations can’t possibly break*, it can only be removed. Don’t
remove it unless you need to then, right?
I came to this conclusion re: validations/assocations by observing the
evolution of how people write specs for them. You start off doing
something like:
describe User do
it “should require a name” do
User.new(:name => ‘’).should have_at_least(1).error_on(:name)
end
end
and after you write a bunch of those you look for a way to DRY up your
specs a bit so you write some kind of custom matcher. Make it nice
and concise and you end up with shoulda macros:
describe User do
should_require_attributes :name
end
You could literally write a couple lines of adapter code that would
take this specification and generate the production class!
def describe(klass, &block)
(class << klass; self; end).class_eval do
alias_method :should_require_attributes, :validates_presence_of
end
klass.class_eval &block
end
What does it give you?
I’m looking at the shoulda examples and chuckling at how ridiculous
the AR ones are (controller ones are nice, they use macros for stuff
that you can’t program declaratively).
class PostTest < Test::Unit::TestCase
should_belong_to :user
should_have_many :tags, :through => :taggings
should_require_unique_attributes :title
should_require_attributes :body, :message => /wtf/
should_require_attributes :title
should_only_allow_numeric_values_for :user_id
end
and in AR (not 100% sure this makes it pass, I’m just writing, you get
the idea)
class Post < ActiveRecord::Base
belongs_to :user
has_many :tags, :through => :taggings
validates_uniqueness_of :title
validates_presence_of :body, :title
validates_format_of :message, :with => /wtf/
validates_numericality_of :user_id
end
There are two types of specification that I’ve found useful:
declaration and example. Rails association and validation macros are
specification by declaration. RSpec gives us specification by
example. Effectively this means that a class’s specification is split
between its implementation (declarative parts) and RSpec examples.
If your code is specified declaratively, you don’t need to write
examples.
Not testing things that have no logic makes sense. However, validation
methods have logic, it’s just wrapped up behind a nice interface.
Sure but can that logic break?
Pat
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs