On Mon, Dec 29, 2008 at 10:59 PM, Jonathan Linowes
wrote:
> # Then /^the email_confirmation field should be cleared$/ do
> # #how to write this
> # #selector( "input[name=user[email_confirmation]")[:value].should
> be_blank
> # end
Are you using Webrat? If so try:
field_labeled("Email
> The approach I like to take is to follow the guidance of the system
> (cucumber + rspec) every step of the way. Right now there are no
> passing steps, so I'd write the code for the 1st pending step, run the
> features and find the first thing that is missing or failing.
This is one thing I don'
# Then /^the email_confirmation field should be cleared$/ do
# #how to write this
# #selector( "input[name=user[email_confirmation]")[:value].should
be_blank
# end
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/m
Tim Walker wrote:
> Question: In your quest for BDD nirvana have you broached the subject
> of setup/teardown and reuse of Setup code?
Matt Wynne has a good blog post about re-using steps in cucumber:
http://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/
> What is a clean way of estab
On Mon, Dec 29, 2008 at 7:20 AM, David Chelimsky wrote:
> I don't see any specs for the rspec-on-rails-matchers library on
> github, and no activity in 9 months, so I'm guessing that it is
> incomplete/no longer being maintained.
>
> Josh Knowles, if you're reading this, can you respond?
I unfort
This is outstanding work and very useful, very nice.
Question: In your quest for BDD nirvana have you broached the subject
of setup/teardown and reuse of Setup code?
What is a clean way of establishing a complex baseline state before
operating on it with a suite of cucumber tests and without dupl
I thought you all might be interested in my second tutorial:
http://www.ultrasaurus.com/code/2008/12/rails-2-day-4-rcov-and-bdd.html
It covers more webrat plus a trickier delete scenario, based on a
previous thread: http://www.ruby-forum.com/topic/171269
I also tried to follow Matt Wynne's refact
Thanks that worked.
Normally I would combine them into one step, but this case, one is in
a general reusable steps file, and the other is specific to a
feature. I thought the word "item" would be sufficient to distinguish
the two.
On Dec 29, 2008, at 1:07 AM, Stephen Eley wrote:
On Su
On Sun, Dec 28, 2008 at 7:19 PM, Emmanuel Pinault wrote:
> I think this is not yet implemented. I had the same issue and was told they
> are working on it but that they are doing a big refactoring so might not be
> in 0.1.13 yet
>
That's right. You have to wait for the next major release to have
On Sun, Dec 28, 2008 at 8:37 PM, aidy lewis wrote:
> Hi,
>
> I have exampled Cucumber and FireWatir here:
>
> http://code.google.com/p/cucumber-and-watir/
>
> FireWatir will run on Windows, OSX and GNU\Linux.
>
> It is on google-code as I am unfamiliar with git.
>
Thanks Aidy. I have amended Cucu
David Chelimsky wrote:
> I'm not really sure why this is stubbing find, or why the stub value
> is true instead of a model. Actually, I don't even see how this would
> specify validating uniqueness of the attribute without very specific
> setup:
>
> first = Centro.create(:nombre => "example")
> s
On Mon, Dec 29, 2008 at 5:04 AM, Juanma Cervera wrote:
> I am fighting with an error using rspec-on-rails-matchers.
>
> I have a model called "Centro" based in this table
>
> create_table "centros", :force => true do |t|
>t.string "nombre"
>t.string "cif"
>t.string "domicilio"
>
Well, it seems tha the error is indeed in the stubbing of the find
method in the class of the model.
def validate_uniqueness_of(attribute)
return simple_matcher("model to validate the uniqueness of
#{attribute}") do |model|
model.class.stub!(:find).and_return(true)
!model.valid? && mod
I am fighting with an error using rspec-on-rails-matchers.
I have a model called "Centro" based in this table
create_table "centros", :force => true do |t|
t.string "nombre"
t.string "cif"
t.string "domicilio"
t.string "codigo_postal"
t.string "poblacion"
t.str
14 matches
Mail list logo
