Re: [rspec-users] RSpec with devise test helpers
Can you provide a gist of your spec helper, controller spec, and controller implementation? On Wed, Oct 16, 2013 at 3:17 PM, Paul Ols li...@ruby-forum.com wrote: I've set my Rails (engine) project to include devise and other tools like FactoryGirl. I'd like to write some tests with contexts around anon/authenticated users. In my spec_helper.rb's RSpec.configure block, I have this: config.include Devise::TestHelpers, type: :controller Which gives me this, when running rspec: 1) PropertiesController GET 'index' returns http success Failure/Error: Unable to find matching line from backtrace TypeError: no implicit conversion of nil into Hash # /Users/phendrick/.rvm/gems/ruby-2.0.0-p0@hendrickdev.brightnest /gems/devise-3.0.0/lib/devise/test_helpers.rb:31:in `merge!' # /Users/phendrick/.rvm/gems/ruby-2.0.0-p0@hendrickdev.brightnest /gems/devise-3.0.0/lib/devise/test_helpers.rb:31:in `block in warden' # /Users/phendrick/.rvm/gems/ruby-2.0.0-p0@hendrickdev.brightnest /gems/warden-1.2.3/lib/warden/manager.rb:23:in `initialize' ... Without the TestHelpers module included, the specs run (obviously none of them have devise logic in them just yet). Any ideas what's causing this error and how I can resolve it? thanks. -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Preferred way to predict behavior in controller spec?
On Fri, May 4, 2012 at 7:14 PM, Patrick J. Collins
patr...@collinatorstudios.com wrote:
So, I have an action like this:
def destroy
if purchase.user == current_user purchase.refund
redirect_to purchase
else
flash[:error] = t(purchases.refund.failure)
render :show
end
end
... I wanted a controller test to verify the following:
1. It's the correct user
2. The refund was successful
3. User is redirected
...
Initially, I thought this would go something like this:
describe #destroy do
let(:purchase) { create_purchase }
it refunds the buyer do
subject.stubs(:current_user).returns purchase.user
purchase.stubs(:refund).returns true
put :destroy, { :id = purchase.id }
response.should be_redirect
end
end
WRONG!
Obviously, that is not cool because purchase.stubs(:refund) will not be the
right object in the context of the controller.. So since my controller
is actually doing the following:
def destroy
if purchase.user # etc...
end
private
def purchase
@purchase ||= Purchase.find(params[:id])
end
I could do:
subject.stubs(:purchase).returns(purchase)
.. However, now that kind of defeats the purpose of put :destroy, { :id =
purchase.id }...
So I didn't really like that-- I am no longer verifying it's the right record,
so maybe the things I wanted to test were actually:
1. It finds the purchase
2. It's the correct user
3. The refund was successful
4. User is redirected
So I ended up making my test do:
describe #destroy do
let(:purchase) { create_purchase }
def do_destroy
put :destroy, { :id = purchase.id }
end
it refunds the buyer do
subject.stubs(:current_user).returns purchase.user
Purchase.any_instance.stubs(:refund).returns true
do_destroy
response.should be_redirect
end
subject.stubs(:current_user).returns purchase.user
Purchase.any_instance.stubs(:refund).returns true
do_destroy
response.should redirect_to purchase.offer
end
it does not refund the buyer when it fails do
subject.stubs(:current_user).returns purchase.user
Purchase.any_instance.stubs(:refund).returns false
put :destroy, :id = purchase.id
response.should_not be_redirect
end
it does not refund the buyer when it's the wrong user do
subject.stubs(:current_user).returns create_user
Purchase.any_instance.expects(:refund).never
do_destroy
response.should_not be_redirect
end
end
But then I heard the voice of an old friend in my head, saying (with a long
trailing echo) any_instance is terrible practice.. never use it!
So I am curious if anyone has suggestions on how this might be improved?
Instead of any_instance you could stub the interaction with
Purchase.find in your spec:
Purchase.stubs(:find).with(purchase.id).returns purchase
HTH,
Zach
Thank you.
Patrick J. Collins
http://collinatorstudios.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
--
@zachdennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Simple code dosn't work
On Wed, Apr 11, 2012 at 12:47 PM, Alex Chaffee a...@stinky.com wrote:
j.even?should be true
j.even?.should be true
j.even?.should be_true
Not to ignite a flame war, but this is my biggest problem with RSpec: Unless
you're an expert at Ruby syntax already, it's really easy to make
punctuation mistakes.
If you make syntax errors then you won't get to far with
insert-language-here. While it is possible to make syntax errors
with RSpec it's also possible to make them outside of RSpec.
Your experience may be different than mine, but I don't recall making
more typos in RSpec because of its syntax as opposed to making typos
in a variety of languages (irregardless of if its a testing
framework). But it's entirely possible that my memory is rewriting
history.
And of course, it should be
j.should be_even
(though following Skitt's Law, I probably got that wrong)
- A
P.S. In Wrong, it's
assert { j.even? }
Yep, that's another way of doing it. It's not this little guy that
keeps me from test/unit, it's its cousins.
Zach
--
Alex Chaffee - a...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
--
@zachdennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] [OT] Using Git / Pivotal Tracker? Want improved open source tooling around the two?
We're taking a survey for Git / Pivotal Tracker integration related to open source tooling. There's been a certain pain point in the tools that are out there or that lack integration (or flexibility to easily add integration). If you're using both would you be kind enough to check out this survey? https://docs.google.com/a/mutuallyhuman.com/spreadsheet/viewform?formkey=dF83bzVYTm1oSmxyNUd4U01KR20wNmc6MQ Thanks, -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Asserting on a yield
On Sat, Mar 17, 2012 at 7:52 PM, Justin Ko jko...@gmail.com wrote:
On Mar 17, 2012, at 3:51 PM, Myron Marston wrote:
I've been thinking about this a bit ever since Zach Dennis brought up
the issue on another rspec-expectations ticket [1]. I've come up with
a proof-of-concept matcher that works pretty well, I think [2].
Here's how you use it:
expect { |b| 3.tap(b) }.to yield_value(3)
Thanks for thinking about this some more. I don't think this will work
but I've commented on the Gist with a couple examples which help help
narrow in the implementation. St. Patty's night can be rough on the
mind so I'm not going to pretend that I can code right now.
I'll follow up tomorrow if someone doesn't beat me to it!
Zach
The argument passed to the expect block is a little weird, given that
no other block expectations take a block argument like this. But I
don't see a way around it--for the matcher to detect whether or not an
argument is yielded (and what the argument is), it needs to control
the block passed to the method-under-test. One big win here over some
of the other suggestions I've seen is that it works just fine with the
current rspec-expectations API (in contrast, some of the other
suggestions I've seen would special-case this matcher so that `expect`
takes multiple arguments for it to work). I also like that it's built
as a block expectation; to me it is in the same category of matchers
as the change, raise_error and throw_symbol matchers: it's something
that happens as the result of running a bit of code.
If enough people like this we can work on getting it into rspec-
expectations as an officially supported matcher. If we did, I'd want
to beef it up to be significantly more flexible:
# for methods that yield multiple arguments to the block...
# yield_value would accept a splat of args, and yield_values would
# be a more-grammatically-correct alias.
expect { |b| foo.fizz(b) }.to yield_values(:a, 15)
# I'd advocate the matcher using the === operator w/ the given values,
# so either of these would work
expect { |b| abc.gsub(a, b) }.to yield_value(String)
expect { |b| abc.gsub(a, b) }.to yield_value(/a/)
# for cases where you need more control over matching the yielded
value, pass a block
expect { |b| foo.fizz(b) }.to yield_value { |val| val.should
be_fizzy }
Love this.
Thoughts?
[1] https://github.com/rspec/rspec-expectations/pull/119#issuecomment-4520633
[2] https://gist.github.com/2065445
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
--
@zachdennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can some one please explain why one of those two examples fails?
On Thu, Mar 15, 2012 at 8:46 AM, Mohamad El-Husseini
husseini@gmail.com wrote:
Thanks, Mike. I appreciate the explanation. It's tricky knowing what runs
when, and what variable is in what scope. It seems like code smell to add
an instance variable to the before block.
I don't understand what advantage one approach has over the other. What
would you use, the first, that was broken, or the second?
I am assuming you're asking about what the advantage of using #subject
vs. just #user is? If so, here are some advantages of using #subject
IMO:
RSpec will provide an implicit #subject already and in many cases you
don't need to construct a new one. This gets rid of an unnecessary
line in those instances. Here's an example from the docs:
describe Array do
it should be empty when first created do
subject.should be_empty
end
end
See
https://www.relishapp.com/rspec/rspec-core/docs/subject/implicitly-defined-subject
for more info.
Rspec's one liner syntax uses #subject, straight out of the docs is a
great example:
describe Array do
describe with 3 items do
subject { [1,2,3] }
it { should_not be_empty }
end
end
See
https://www.relishapp.com/rspec/rspec-core/v/2-8/docs/subject/implicit-receiver
for more information.
Also see
https://www.relishapp.com/rspec/rspec-core/v/2-8/docs/subject/attribute-of-subject
Since #subject is an RSpec convention when writing shared example
groups they are often set up to expect subject to be defined by the
including example group. Here's an example practically from the docs:
shared_examples a measurable object do |value|
it should return #{value} from #length do
subject.send(:length).should ==value
end
end
describe Array, with 3 items do
subject { [1, 2, 3] }
it_should_behave_like a measurable object, 3
end
See
https://www.relishapp.com/rspec/rspec-core/v/2-8/docs/example-groups/shared-examples
for more info.
And since #subject is an RSpec convention, it always implies the
thing under test. So, if you want to know what you're testing you
can either do a visual scan for a subject block or simply look at the
class/module being described.
Those are the reasons I find #subject to have advantage. By
themselves, none of these are huge reasons, but combined, and over
time, I have found relying on convention and getting a few extra
niceties in my specs outweighs going against the convention and trying
to reinvent conventions when I hit things like one-liners or shared
examples/contexts.
My 2 cents,
Zach
On Tuesday, March 13, 2012 9:24:03 PM UTC-3, Mike Mazur wrote:
Hi,
On Wed, Mar 14, 2012 at 07:55, Mohamad El-Husseini
husseini@gmail.com wrote:
The following are what I believe two ways of doing the same thing. Only
the
first example fails, while the latter passes.
In your failing example:
context generates a unique password_reset_token each time do
let(:user) { FactoryGirl.create(:user) }
before do
user.send_password_reset
last_token = user.password_reset_token
user.send_password_reset
end
its(:password_reset_token) { should_not == last_token }
end
The `last_token` variable is in scope in the before block, but not in
the its block. You can fix this by changing it to an instance
variable:
context generates a unique password_reset_token each time do
let(:user) { FactoryGirl.create(:user) }
before do
user.send_password_reset
@last_token = user.password_reset_token
user.send_password_reset
end
its(:password_reset_token) { should_not == @last_token }
end
Another gotcha is: what is the its expression making assertions on?
The its method requires a subject to be defined.
RSpec defines an implicit subject based on the described class. I
imagine at the top of your .spec file you have something like:
describe User do
# stuff
end
RSpec will generate a subject by calling `User.new`.
`password_reset_token` is then called on this new user instance in the
its block. You most certainly wanted to call `password_reset_token` on
the user object defined by the `let` statement.
So I think this should do the trick:
context generates a unique password_reset_token each time do
let(:user) { FactoryGirl.create(:user) }
subject { user }
before do
user.send_password_reset
@last_token = user.password_reset_token
user.send_password_reset
end
its(:password_reset_token) { should_not == @last_token }
end
You can read more about RSpec's subject here:
https://www.relishapp.com/rspec/rspec-core/docs/subject
Hope that helps,
Mike
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] how to refactor signin process for re-use?
On Thu, Mar 8, 2012 at 10:38 PM, David Chelimsky dchelim...@gmail.com wrote:
On Thu, Mar 8, 2012 at 5:15 PM, S Ahmed sahmed1...@gmail.com wrote:
In my authenticate_pages.spec (requests) I do the following to test if the
signin worked:
describe with valid information do
#let(:account) { FactoryGirl.create(:account) }
let(:user) { FactoryGirl.create(:user) }
before do
fill_in Email, with: user.email
fill_in Password, with: user.password
click_button Sign in
end
it { should have_link('Sign out', href: signout_path) }
it { should_not have_link('Sign in', href: signin_path) }
end
Now in my other controllers that assume the user is signed in, how can I
refactor this and put it somewhere that I can just call to make the user
signed in so I can test pages that assume the user is already signed in?
Here's one pattern I've seen (and used):
def login_as(user)
fill_in Email, with: user.email
fill_in Password, with: user.password
click_button Sign in
end
describe things do
before { sign_in_as(FactoryGirl.create:(user) }
describe GET /thing do
# ...
end
end
Where #sign_in_as and #login_as in David's example should be the same method.
Zach
HTH,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
--
@zachdennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Sufficiently tested?
On Fri, Mar 9, 2012 at 8:06 AM, U. M. li...@ruby-forum.com wrote: Hi everybody, Hello! I have a general question about how many different cases have to be covered in one Example. Considering the famous Fizzbuzz program, you should test if your output is either Fizz, buzz, Fizzbuzz or just the number (between 1 and 100). Pretty simple. However, I often see solutions of testing multiples of 3 only by looking at some relevant values like 6, 9 etc. it should return 'fizz' when number is divisible by 3 do @fizzbuzz.calculate(3).should == 'fizz' @fizzbuzz.calculate(6).should == 'fizz' @fizzbuzz.calculate(9).should == 'fizz' end So far, so good. But what if I claim that the test will fail in case of 12? Then add an example for this and make that change. I might update the spec to look like this: describe #calculate do it returns 'fizz' when number is divisible by 3 context (exceptions to the divisible by 3 rule) do it returns nil when number is 12 end end It's actually not covered and we are just assuming, that all further multiples will work as well, because these do. My idea was to check all multiples right away in a loop. it should return Fizz if number is divisible only by 3 do (1..100).each do |number| @fizzbuzz.calculate(number).should == Fizz if number % 3 == 0 number % 5 != 0 end end This is more complicated then it needs to be and suffers the same problem that you are trying to avoid. Here you are testing a larger data set, but numbers are infinite... so while 100 numbers is more than 3, it's still a far cry from covering a large amount of the available set of numbers (which is infinite). Similar to David, I try to write examples that show the implementation working, but once I am confident that the examples I have are proving that implementation is working then I move on. Given that the calculate method works fine, both ways will pass. But my question is: Does my solution more than it actually needs to or is the first one in fact a little too lazy? What do you think? Zach ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] testing sessions
On Sun, Mar 4, 2012 at 4:46 PM, S Ahmed sahmed1...@gmail.com wrote:
great thanks.
should a var created in a block be reachable outside the block?
Nope, not unless you defined the variable outside of the block to start with.
it do
expect { session = Session... }.not_to change(Session, :count)
session.guid.should
end
I tried that but was a bit confused, whatever is in the expect block is
isolated right?
Correct. Currently your session variable is only scoped to the block
that is passed to expect. Anything outside of that block doesn't
know anything about the session variable.
Zach
On Sun, Mar 4, 2012 at 1:34 PM, David Chelimsky dchelim...@gmail.com
wrote:
On Sun, Mar 4, 2012 at 7:40 AM, S Ahmed sahmed1...@gmail.com wrote:
I want to test if my sessions logic works.
Session:
id
user_id
When I create a new session, if there was a previous session row in the
db
with user_id = xxx, it should delete it first, then create a new row.
How could I test this scenerio?
So far I have:
require 'spec_helper'
describe Session do
let(:session) { FactoryGirl.create(:session) }
subject { session }
it { should be_valid }
describe a new session do
s1 = FactoryGirl.build(:session)
s2 = FactoryGirl.build(:session)
user = FactoryGirl.create(:user)
s1.user_id = user.id
s1.save!
#should change(Session, :count).by(1)
end
end
I can't seem to figure out how to use the should change Session count
by
1.
First - read the docs at
http://rubydoc.info/gems/rspec-expectations/RSpec/Matchers:change to
learn how to use the `change` matcher properly. Also look at
http://rubydoc.info/gems/rspec-expectations/RSpec/Matchers:expect so
you'll understand my suggestion below.
Second - you say above When I create a new session, if there was a
previous session row in the db with user_id = xxx, it should delete it
first, then create a new row. This suggests that you want
Session.count _not_ to change at all:
user = FactoryGirl(:user)
session = FactoryGirl(:session, :user_id = user.id)
expect { session.save! }.not_to change(Session, :count)
HTH,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
--
@zachdennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Testing Signin for Admin_Employee
On Sat, Feb 25, 2012 at 9:25 AM, J. B. Rainsberger m...@jbrains.ca wrote: On Thu, Feb 23, 2012 at 22:45, Justin Ko jko...@gmail.com wrote: Hello, what you want is shared examples/context: https://gist.github.com/1894922 I commented there, too. I commented there as well. -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec Requestable Examples
I forgot to answer your question more directly. I see things in the requestable/selectable approach which I would like to continue to explore and see if it pans out. So far I like the requestable/selectable approach for the reasons I mentioned in the other email. In short term practical use there are no giant reasons why you should avoid using macros. They provide a valuable utility. As mentioned in the other email I think there are benefits (both short and long term) of not using them in favor of an approach that integrates more consistently and at the same communication level as RSpec. Currently, I think the requestable/selectable has the potential to be that (or maybe help lead a discussion and exploration which becomes that). But it's an experiment that so far has worked a few times. I would hardly say it's time tested or community tested at this point. And if macros are working well for you and my thinking is persuasive, then so be it, just keep on doing what helps you craft good software. Zach On Mon, Jan 30, 2012 at 11:46 PM, Zach Dennis zach.den...@gmail.com wrote: On Sun, Jan 29, 2012 at 3:04 PM, Lenny Marks le...@aps.org wrote: On Jan 27, 2012, at 9:56 PM, Zach Dennis wrote: I would be interested to hear any thoughts from the community about the ability to request specific examples from a shared example group as expressed in the rspec-requestable-examples gem. Here's the post that introduces them: http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples Git repository: https://github.com/mhs/rspec-requestable-examples I've successfully used macros to get similar results, like in the gist below: # macros approach to requestable examples https://gist.github.com/1700352 Curious if you see any big advantages over the macros approach. Both approaches can get the job done technically speaking. Here were some goals of rspec-requestable-examples: 1. allowing individual examples to be selected from a shared set of examples 2. when a user selects a non-existent example communicate that to them so they can implement the example or fix their typo 3. be consistent and complementary with RSpec's forms 4. be consistent with RSpec method of delivery (communication) With these goals macros let's you technically do #1 and #2: * modules allow you to create shared sets of methods which can be shared * when referring to a non-existent method Ruby will yell at you But it fails for #3 and #4: * RSpec has a shared example group form already. Modules are not needed at this level because RSpec provides a higher level concept which provides the utility of sharing examples (it just didn't have baked in the ability to select individual examples). Plain old Ruby modules breaks away from this form and does not complement what RSpec is doing. * RSpec communicates to the user in terms of nice spec output for passing, failing, and pending examples. It is less work for a user to stub out an example which is not yet implemented as they write their spec and to move on, then to have to see low-level Ruby undefined method errors and have to go stub it out right then and there. I would rather have an unknown example be pending so the user could take care of it at the time they were ready. And even though using extend ... and ruby methods are easy to do (and they do technically work) I find it complicates my specs because they exist at a different level of language and communication than all of the other components in my specs. I prefer the language and forms I use to be as consistent as I can make them in my specs. For me, this helps my rhythm of creating software. There is a level of consistency and continuity I want my code to have and in the rspec-requestable-examples approach I try to find that with what RSpec already provides and how it is already being used. I feel like the macro approach attempts to shoehorn in a solution and that's what I've done that in the past, but I think the requestable/selectable examples is better now for reasons above mentioned. In the original blog post it may have sounded like we hit problem A and then in 5 minutes we came up with a solution. When really that's not the case. I've done the macro approach a number of times in the past and never felt comfortable with it, but it worked and we didn't have a better way. But this time, we finally found a way to make do it a little better (at least in our opinion). -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com -- -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec Requestable Examples
On Sat, Jan 28, 2012 at 5:56 PM, David Chelimsky dchelim...@gmail.com wrote: On Fri, Jan 27, 2012 at 8:56 PM, Zach Dennis zach.den...@gmail.com wrote: I would be interested to hear any thoughts from the community about the ability to request specific examples from a shared example group as expressed in the rspec-requestable-examples gem. I love the service it provides, and the consuming API (i.e. :examples = [...]). It clearly communicates to the spec reader what is going on. As for the setup API, how about requestable_example instead of requestable_it. In fact, I think selectable would be a more accurate descriptor than requestable, so selectable_examples_for and selectable_example would read better for me. I agree with you, selectable seems like a better fit, but this may not apply in its entirety given your next suggestion... I haven't looked at the implementation yet, but I wonder if you could implement the same feature using metadata. Something like this, using selectable rather than requestable (seems better aligned with what it's doing IMO): shared_examples_for variable things, :selectable do it does one thing sometimes, :selectable do # ... end it does another thing sometimes, :selectable do # ... end it does one other thing all the time do # ... end end That way we don't need a new method name to worry about and my issue with the name requestable_it goes away. WDYT? I like what you're suggesting here as well. One reason I had went with a new method name for this was to not conflict with RSpec itself, but given your feedback I will investigate what you propose above. Thanks for taking the time to review and to respond, Zach Here's the post that introduces them: http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples Git repository: https://github.com/mhs/rspec-requestable-examples -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Looking for a fellow human: Agile, Mobile, Web, Rails Developer
Not to spam the list, but I thought the RSpec and Cucumber communities may be appropriate to tap into. We're looking for agilist web/mobile developer(s) over at Mutually Human. RSpec/Cuke creds hold special places in our hearts. http://mutuallyhuman.com/blog/2011/07/28/looking-for-a-fellow-human-agile-mobile-web-rails-developer -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] class/type coercion in ruby blog post
Not to spam, but I a colleague did a write up on coercion in Ruby, and I thought it was interesting and fresh, so I thought I'd share with the community: http://mutuallyhuman.com/blog/2011/01/25/class-coercion-in-ruby -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Why does this stub doesn't work?
On Sun, Oct 24, 2010 at 11:21 AM, Haim Ashkenazi
haim.ashken...@gmail.comwrote:
Hi
I wonder why this stub doesn't work:
# ruby 1.8.7, rspec 2.0.1
require 'rubygems'
require 'rspec'
Rspec.configure do |c|
c.mock_with :rspec
end
class SayHello
def say_hello
hello
end
end
describe test string do
it should interpret stub correctly do
SayHello.stub!(:say_hello).and_return('NO')
sh = SayHello.new()
sh.say_hello.should eql('NO')
end
end
In your example you are stubbing a class method. In your implementation you
have defined an instance method. To have this work for your given
implementation you need to know about the instance you are working with, ie:
it should interpret stub correctly do
sh = SayHello.new()
sh.stub!(:say_hello).and_return 'NO'
sh.say_hello.should eql('NO')
end
Hope this helps,
Zach
The result is:
tryouts ➤ rspec -f n test_spec.rb
test string
should interpret stub correctly (FAILED - 1)
Failures:
1) test string should interpret stub correctly
Failure/Error: sh.say_hello.should eql('NO')
expected NO
got hello
(compared using eql?)
# ./test_spec.rb:18
Finished in 0.0016 seconds
1 example, 1 failure
Any ideas?
Bye
Haim Ashkenazi
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD
training)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] new syntax question and mocking HTTP_AUTHORIZATION
On Wed, Oct 20, 2010 at 11:19 PM, David Chelimsky dchelim...@gmail.comwrote:
On Oct 20, 2010, at 9:56 PM, oren wrote:
I am specing a sinatra app.
it should send non-valid user to /login do
get '/'
last_response.headers['Location'].should == '/reports'
end
this is working fine but I would like to know how to convert it to the
new syntax or if there is a better way to do that.
before(:each) { get '/' }
subject { last_response }
its(:status) {should == 302}
require 'ap'
its(:headers) {should include('/login')}
This is not the new syntax. It is simply an alternate syntax that has
been around for over a year and works well for a small subset of things you
might want to specify like initial state:
describe Array do
context when first created do
subject { Array.new }
its(:length) { should eq(0) }
end
end
It is not in any way an all-purpose replacement for more specifying
_behaviour_.
another question:
it should send valid user to /reports do
get '/', { 'HTTP_AUTHORIZATION' = 'Basic
c2cvbGFuOmFBITExMQ==' }
last_response.headers['Location'].should == '/reports'
end
when i debug my method I see that request.env[HTTP_AUTHORIZATION] is
nil,
so the header was not sent with it. how to mock it?
I think you are passing your headers in as the request params. I believe
you're using rack-test under the covers and the api for #get is:
get(uri, params = {}, env = {}, block)
I think env is where you want your headers. so maybe:
get '/', {}, { 'HTTP_AUTHORIZATION' = 'Basic c2cvbGFuOmFBITExMQ==' }
I haven't written a Sinatra app in a while, but I hope this helps,
Zach
I don't have any personal experience w/ Sinatra yet (I know, I know, but
there are only so many hours in a day), so I'll leave it to someone else to
comment on how to approach the Sinatra questions.
Cheers,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD
training)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Good practices on spec'ing views?
On Fri, Apr 30, 2010 at 4:26 AM, Stefan Kanev stefan.ka...@gmail.comwrote: Hey guys. I've been doing RSpec for more than a year by now, yet I cannot help but feel that I've never got a single view spec right. I can see that I have very few view specs and that my views tend be a lot messier than everything else. I've read the chapter in the RSpec book about spec'ing views, but I still think I'm not getting it right. Assuming that I'm a view spec noob, would you guys care to share your experience with writing them? What works and what doesn't? What should I avoid at all cost? And most importantly, how does the process of writing view specs feel? Before Cucumber came onto the scene view specs were a lot more prevalent and relevant. Cucumber does an excellent job of allowing us to drive the implementation the views based on what our scenarios need. When Cucumber is not being used, I find view specs do offer a benefit, but when using Cucumber, I find that takes the cake to driving the view implementation. These days, I always use Cucumber though, so it's been a while since I've written view specs. In The Rspec Book, section 24.6 (chapter 24), When I write view specs offers some tips for determining when to write view specs. Have you read this section? Zach -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [Cucumber:4066] Cucumber vs, RSpec
behaviour. My intent for the statement about Cucumber provides flexibility wasn't to encourage folks to drop unit-level examples because they have supreme flexibility with Cucumber. It was to encourage folks to take a step back and explore with a spike what they're attempting to accomplish, so they can come back and make a better decision moving forward. I would love to rid the world of unnecessary examples, brittle examples, impossible to read/maintain examples. Spikes put folks in a better position to make bette decisions in that regard so I feel like my encouragement and observations are still accurate and relevant. And as Joseph said it's all project, client, and context specific. My 2 cents. :) -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [Cucumber:4095] Cucumber vs, RSpec
On Wed, Apr 21, 2010 at 7:05 PM, Pat Maddox mailingli...@patmaddox.comwrote: Cucumber features are the best tool I know of for capturing requirements from my customer. RSpec specs are the best tool I know of for communicating intent and gauging code quality among the developer team. I'm not sure how exactly you're quantifying a 90/10 or 80/20 split. I would expect that there would be a lot of overlap in coverage. That is, any given line of code is likely to have some cucumber and some rspec coverage. Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely on what my customer wants. If we discuss a new feature or bug fix and they feel I know exactly what they're talking about and don't need a cucumber test for it, I don't write the cucumber test. Cukes are for teasing out requirements, which is most important when there's domain complexity that I don't understand, because I'm a programmer and not a domain expert. Every line of code I write gets RSpec coverage. That's how I personally feel confident that my code does what I think it does, and also helps me keep my dependencies under control. It's true that you can change out all the underlying code and cucumber tests still pass. But you should be able to change out a lot of code and have your specs still pass, as well. If you're changing the API then some specs might no longer be valid, or need to be moved, or whatever. That's just a part of refactoring. Although to be honest I think focused specs help me refactor more than other people, because I take really small steps when I refactor. When most people refactor they tear out a bunch of shit and see if it still works. Cucumber tests tend to take longer because they're written at a much higher level. That requires more setup, and more steps through the codebase. For that reason, Cucumber isn't particularly good at giving me rapid feedback. I want feedback in 10 seconds rather than 10 minutes. The best mantra I have for using Cucumber RSpec in harmony is, RSpec lets me know my code works right, Cucumber lets me know my code is doing the right work. +1 -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] get to a different controller
also gotten into a groove for writing my own little shared macros and it makes it super simple to build new classes which re-use that functionality and know it actually works. What I now prefer to do is keep the interface between a module (or even an abstract class) and the class it's mixed into quite clean, and specify that re-usable unit in isolation, with an example using a temporary class created in the test. I might have one or two specs in the class which mixes in the module to prove that the module is mixed in and working, but most of the specs for the behaviour of that module itself will live alongside the module and run only once. This is excellent advice regardless of using shared examples, although it isn't always practical (clean interfaces are always practical, what isn't is creating new specs with test classes). Some modules are simply a grouping of certain behaviour that relies on other behaviour existing on an object. Creating a new test class to put in a spec can require a good amount of time and thinking based on the functionality and where what you're module's functionality falls into the overall chain of dependencies. There are times to be disciplined and put in that time and thinking. At other times, it's important to not misplace a bunch of time and energy if what you're working on doesn't warrant it. Unfortunately, making knowing when to make good decisions often comes from making bad ones. So as Corey Haines would suggest, practice practice practice! As David said earlier there are strengths and weaknesses to both approaches so you have to find your own path here. I just wanted to share my experience. Ditto. -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Cucumber and IP PBX testing
On Wed, Nov 18, 2009 at 6:26 PM, Robertico Gonzalez li...@ruby-forum.com wrote: Hi, I am new to Cucumber. I am a test engineer for an IP PBX. Has anyone tried to use Cucumber to test such application? Some of the actions that I need to perform are: Given: a) Configure parameters on a web site to change phone behavior b) Configure parameters on a web site to change trunk behavior c) Configure parameters on a web site to change system wide behavior When: a) Make a call from phone A to phone b b) Press Transfer or Conference softkey c) Configure Call Forward All from phone Then: a) Verify audio between two phones b) Verify phone displays c) Verify phone status prompt I imagine I need to translate these steps into Ruby to see if they pass or fail. I don't have control over the code that developer write for features, since I am just a tester. We write scripts in TCL to automate our test cases. Any pointers or suggestions are welcome. A while back I looked at using Twilio to do automated integration testing a phone system. I started talking with some of their engineers, but then the conversation just stopped. I didn't know if they got busy or thought I was crazy. :) You can setup twilio accounts, one as a receiver and one as the dialer. I got a proof of concept working with Cucumber as the driving force, but I haven't worked on that application in a while. Perhaps twilio has provided some tools for this by now. This probably isn't what you were looking for, but thought I'd share the idea in case anyone has interest, Regards, Robertico -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] ruby file.spec?
On Thu, Nov 12, 2009 at 7:34 PM, rogerdpack rogerpack2...@gmail.com wrote: perhaps this has been discussed before and you can point me to the right thread, but is it possible to run specs from the command line using just ruby? ruby arguments_spec.rb and it just run (like test/unit seems to)? I can't think of a great reason why this would be useful, other than not having to remember which command is which to run files--you only have to type ruby (and IDE's that aren't spec aware would be easier to run with). You want to use spec to run files directly. If you have your heart set on running files from ruby then you'll need to load spec/autorun to actually execute the specs. Note using the following will not work on ruby 1.8.x (see thread http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/334942 ) but it should work on 1.9.x. ruby -rubygems -rspec -rspec/autorun file_spec.rb -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] ruby file.spec?
On Thu, Nov 12, 2009 at 10:28 PM, Stephen Eley sfe...@gmail.com wrote: On Thu, Nov 12, 2009 at 8:36 PM, Zach Dennis zach.den...@gmail.com wrote: You want to use spec to run files directly. If you have your heart set on running files from ruby then you'll need to load spec/autorun to actually execute the specs. After giving the original querent a hard time, it surprises me to have to tell you that you're wrong. At least if you're running any spec file written with the typical Railsish convention of requiring 'spec_helper.rb' at the top. If for some reason you have spec files that *don't* require the framework one way or another, you'd be correct, but...why wouldn't you? Otherwise, it works fine. And in that case spec_helper.rb still needs to load spec/autorun for this to work. (How do I know? I went into one of my projects, then into a spec directory, and typed 'ruby user_spec.rb' and watched it work. At first I didn't think that trying things before posting to a mailing list about them was an extraordinary act, but now I'm wondering if I ought to get a medal for courage.) -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Model spec for file upload with paperclip and fastercsv
In the example that is failing, should build 3 new Products you have: it should build 3 new Products do # I have to tag this pending, this results in a weird error I don't have time for yet # full stack testing with cucumber succeeds, human testing does too # pending Product.should_receive(:new) do_save Product.count.should == 3 end You are setting up an expectation with should_receive(:new), and you're not supplying anything to be returned so it is defaulting to nil. This is why you get the NoMethodError calling nil.save... because your local variable product is nil for the duration of this example. I don't think you want to be using mocking down in the model spec like you are doing. For example, does it really matter that #foreach was called? Or that Product#new was called? Or that product#save was called? These can all be inferred if you have a CSV file, save the import ,and then suddenly you have products. No need to worry about them directly IMO. Using mocks in this example happen to make this spec brittle, and it doesn't add any value. For example, say you changed from using fastercsv to some other csv library that had a different API, but it properly parsed the CSV files. All of the behaviour of importing products the CSV file still worked, but suddenly your examples fail because #foreach isn't be used. When focusing on the Import model focus on the behaviour you want out of it. Based on the pastie you made it seems like you want it to import products from a CSV after save. So, you can write an example for ensuring the right number of products were created. You might also want to write an example to ensure the write fields from the CSV ended in the right attributes on a product. Picking one or two products should be enough to gain confidence. I've done a quick edit of your original spec to show what I was thinking when I quickly read your spec: http://pastie.org/693775 Hopefully this helps! On Wed, Nov 11, 2009 at 8:48 AM, Ray K. li...@ruby-forum.com wrote: Now I have another weird error. My Products doesn't save in the specs, but it does in cucumber tests and human tests. I'd be glad if someone could look into this. http://pastie.org/693611 Ray -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Stub named_scope with params
On Thu, Nov 5, 2009 at 5:10 PM, Elza Di Sirio
elza.more...@tagview.com.br wrote:
I need some help to stub this method of my controller
�...@users =
User.accessible_by(current_user).paginate(
:conditions = conditions.to_sql,
:include = :user_channels,
:order = build_sort_conditions(:name, true),
:page = get_param(:page, :integer),
:per_page = 10
)
end
My rspec is
describe 'GET /index' do
##
should_require_login :get, :index
##
describe authenticated user do
##
before do
login_as_user
check_session_expiration
@user = mock_model(User)
@users = [...@user]
User.stub_chain(:accessible_by, :paginate).and_return(@users)
end
##
it 'should load the users' do
User.should_receive(:paginate).with(
:conditions = ['active = ?', true],
:order = :name,
:page = nil,
:per_page = 10
).and_return(@users)
do_get
assigns[:users].should == @users
end
end
end
##
The error I get is
Spec::Mocks::MockExpectationError in 'UsersController GET /index
authenticated user should load the users'
User(id: integer, name: string, email: string, crypted_password: string,
password_salt: string, persistence_token: string, role: string, active:
boolean, password_last_changed_at: datetime, created_at: datetime,
updated_at: datetime)
(class) expected :paginate with ({:per_page=10, :conditions=[active =
?, true], :order=:name, :page=nil}) once, but received it 0 times
./spec/controllers/users_controller_spec.rb:269:
*
How should I stub a named_scope with params(accessible_by(current_user)),
following a stub to paginate.with(...).
In your example User does not receive the #paginate call, the return
value of #accessible_by does. It looks like you're having both of
those methods return @users in your spec by default. Try updating your
spec to say...
@users.should_receive(:paginate)...
instead of
User.should_receive(:paginate)...
I can not change my controller
In case you can change your controller... this controller action seems
pretty vanilla. I would probably add some good model-level specs
around #accessible_by, and then have a few cucumber scenarios ensure
whatever it was that pulled up this page was working (I like scenarios
for pagination as well). To make things easier I would assign the
default PER_PAGE to a configuration setting or a constant so it can be
easily changed in a scenario. This can reduce scenario running time
and necessary setup whilst still ensuring behaviour.
Just an idea with the very little I know from what you pasted,
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] spec-ing private methods?
Hello Joaquin, On Wed, Oct 14, 2009 at 5:22 PM, Joaquin Rivera Padron joahk...@gmail.com wrote: hello 2009/10/14 Ashley Moran ashley.mo...@patchspace.co.uk On 14 Oct 2009, at 20:49, Scott Taylor wrote: On Oct 14, 2009, at 3:36 PM, Joaquin Rivera Padron wrote: private def complex_method... def other_complex_methods ... and the two complex methods can get really tricky to get right, I would like to be able to write specs for them, how do you do that? I mean I cannot do: object.some_private_method You have a few options: 1. Make the method public in the object you are testing 2. Make the method public in the test case 3. Don't test the method 4. Use __send__ or (send) to call it. 5. Refactor private methods to a new object, and make the methods public in that object. Most of those options suck (esp. 1, 2, 3, 4) - usually it represents a design flaw (you are doing too much in your class). I'm with Scott, this usually indicates a design flaw, and 5 is usually the solution. The clue is in the names you gave them - you shouldn't have complex methods, especially private ones. Can you post any of the code so we can see where the complexity/problem is? hey ashley, the code itself is not very interesting, it's some fast hacking I'm doing dumping chess positions into a string, and then the methods given the character index on that string should translate it to two-dimensional vectors in the board, boring: mainly math calculations multiplying columns by some number and adding row numbers and such, and during the spec-ing of the public method the question arose... I might shift my focus from whether or not these methods should be made public or moved to another class and first make sure I had written examples that focused on the behaviour I was interested in. I have found that having those tend to be a good help when thinking about making private methods public. Even if you find you don't need these methods to be public you will find the examples afford you a great deal of freedom to refactor that code in a number of ways or by simply leaving them as private methods all while leaving the examples intact. and yeah, I think 5 it my favorite at the moment, they don't have to be private anyway, also IMHO testing private methods through the public API it's not in general applicable (only thinking here, no code sample)... but anyway I wanted to hear what you guys think about it Behaviour first. That will help you identify if you're dealing with different responsibilities which might push you to extract a new object, or if you're dealing with logic that goes together (in which you might keep well-named private methods), or if you want to pull out some of the dry and boring math calculations out into a method on some utility class. If you put good examples in place you'll be able to change your mind later without having to maintain *brittle* specs while having a great deal of freedom for re-organizing the implementation in a number of imaginable ways. -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] spec-ing private methods?
On Wed, Oct 14, 2009 at 7:07 PM, Ashley Moran ashley.mo...@patchspace.co.uk wrote: On 14 Oct 2009, at 22:48, Matt Wynne wrote: By the way, Sprout Class comes from 'Working Effectively with Legacy Code' (Feathers), which is probably the best book I've read on TDD (Admittedly I've yet to read The RSpec Book). Highly recommended. I've heard good things about this book too. Do you also recommend xUnit Patterns? It's been a while since I've read that book. From what I remember it had a lot of great information, but there were many sections I don't find applicable for my coding practices. I think a lot of the typical xUnit styles of testing are heavily influenced from heavier weight languages (like Java for instance). I think that is reflected in much of the material in the book. I did enjoy reading it over a few month period because of the wealth of information, but I would consider many of the techniques dated given where the current state of tools (RSpec and Cucumber), the flexibility of our ruby, and the philosophy of BDD have put us. So if you're looking to read it for immediately applicable techniques I would say don't bother, but if you're an information-whore and want to gain a wealth of knowledge, and want to see a lot of thinking and techniques that have influenced a lot of today's tools and thinking, then read it, for sure, but don't expect to read it in a weekened or even a week... that would be information overload -- your brain would explode. Zach Bizarrely, I'm including xUnit patterns as a reference in a presentation on mocks I'm giving tomorrow[1], despite never having read it. (Only because I know it contains some mocking definitions I refer to...) Incidentally, the mocking section of the RSpec Book is very good. Which is to say I agree with what it says :) Ashley [1] http://nwrug.org/events/october09/ -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran http://aviewfromafar.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Grabbing the controller name before a new test case
Your name has intrigued me. Do you really hate underscores? :) Zach On Wed, Sep 30, 2009 at 7:56 PM, Hates_ richard.e.h...@googlemail.com wrote: I currently have: describe Publishers::PagesController I want to be able to grab the path publishers/pages/ and use that to generate a load of tests automatically. Problem is I can't figure out how to do it outside of my it block. Any help is greatly appreciated. Richard ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] describe block proc parameter as alternative to before blocks?
On Sun, Sep 20, 2009 at 8:34 PM, nruth nick.rutherf...@gmail.com wrote:
David
Thanks for the reply.
I think I wasn't clear with my original post: before blocks work fine,
this is just a readability/comprehension/maintenance concern.
We're using a describe (or context) block to name (or document) a
state, then using a separate before block to set up that state
(context). If that before block were to go astray the documentation
would cease to be correct.
It seems better to have this done in one place rather than two, as
separate description statements and setup code could lead to confusion
or errors through fragmented example groups.
I'm not sure how helpful it would be if the setup takes more than half
a line of code. Referencing a definition elsewhere wouldn't help
readability, though would still make it clear that the describe was
for that particular setup state.
Before blocks do have the same effect, and if positioned sensibly
should avoid these problems.
before blocks are also limited in where you can put them. They must be
specified very close the context in which they are to be applied. If
you provide a helper method as the context you create the need to
further separate an important part of an example from its context. I
also feel you lose a lot in what you describe and how you describe it
when you restrict it to ruby method names.
It's not a big deal, and the onus should probably be on the spec
author rather than the tools to produce clean and consistent specs?
I think it's important for people to pay attention when they write
code. Based on some of the code I've seen over the past few years I'm
not sure everyone would agree with me. :)
I'm not surprised it's come up before, but I didn't find anything
searching the group.
Cheers
Nick
On Sep 20, 9:56 pm, David Chelimsky dchelim...@gmail.com wrote:
On Sun, Sep 20, 2009 at 9:38 AM, nruth nick.rutherf...@gmail.com wrote:
I've been reading through the Rspec book to see if I missed any
tricks, and the discussion of before block use for context setup in
sec 12.6 struck me as interesting and something I had a knee-jerk
reaction to.
I think that when you are using nested examples to describe a context
change it is bad practice to allow any example within that group to
run outside of that context. This could happen simply because you
forgot to copy and paste (ouch) the setup code into your expectation.
before blocks solve this problem, but they are so tightly coupled to
the describe call in this case, why not make them a describe method
parameter? Ideally they would be the block passed to describe, but we
can't do that since the example group is using that already.
So I would propose something like this sketch:
describe a new capacity 10 stack, :context = lambda {...@stack =
Stack.new(:capacity = 10)} do
describe with 4 pushed ints, :context = lambda { 4.times { @stack
rand(:int) } } do
it should allow push and return the new size do
�...@stack.push(rand(:int)).should == 5
end
end
end
And the :context would just be executed as if it were a before block.
Of course you can arrange your specs so that the before block is
directly after the describe, or similar, but this seems a nice
alternative to me.
The order of the before blocks, relative to the examples, is
irrelevant. An example group loads up all of its examples and before
and after blocks before anything is run. In other words, these two
will have the same effect:
describe Thing do
before(:each) { @thing = Thing.new }
it does something do
@thing.should do_something
end
end
describe Thing do
it does something do
@thing.should do_something
end
before(:each) { @thing = Thing.new }
end
This is not the first time your idea has come up, and I've not
included it before because I want to avoid assigning specific meaning
to keys in the hash passed to describe(). rspec-2 will be using that
hash as part of a plugin API, so the more I can leave available, the
better. I'll be posting more about that soon, but first things first -
gotta get the book off to the printer :)
Cheers,
David
It's a nubile idea though. Thoughts?
___
rspec-users mailing list
rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] describe block proc parameter as alternative to before blocks?
@thing.should do_something
end
end
describe Thing do
it does something do
@thing.should do_something
end
before(:each) { @thing = Thing.new }
end
This is not the first time your idea has come up, and I've not
included it before because I want to avoid assigning specific meaning
to keys in the hash passed to describe(). rspec-2 will be using that
hash as part of a plugin API, so the more I can leave available, the
better. I'll be posting more about that soon, but first things first -
gotta get the book off to the printer :)
Cheers,
David
It's a nubile idea though. Thoughts?
___
rspec-users mailing list
rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] explanation of describe vs context...
On Sat, Jul 11, 2009 at 3:29 PM, Chris Sundch...@silhouettesolutions.net wrote: Hey everyone, This is a noob question. I'm not grasping the difference between describe and context in my spec file. As an example, what's the difference with this... describe Game do context starting up do it should send a welcome message do �...@messenger.should_receive(:puts).with(Welcome to Mastermind!) �...@game.start(%w[r g y c]) end And this describe Game do describe starting up do it should send a welcome message do �...@messenger.should_receive(:puts).with(Welcome to Mastermind!) �...@game.start(%w[r g y c]) end Is this just preference, or are the serious differences? There is no technical difference. context is aliased to describe. However, you can use them in combination to write more expressive specs. For example: describe Game do describe #join_game do context when the game has not startedd o it should allow a player to join end context when the game has started do it should not allow another player to join end end end ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Integrate or isolate views?
On Wed, Jul 1, 2009 at 1:10 PM, Pat Maddoxpat.mad...@gmail.com wrote: On Sun, Jun 28, 2009 at 11:56 AM, Sarah Allensa...@ultrasaurus.com wrote: I find that testing views independently is useful just to catch HTML errors that can sometime creep in during a re-factor. These check important details that would be more tedious using cucumber +1 +1 as well. The last sentence here really nails it on the head for me, Pat ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Integrate or isolate views?
On Sun, Jun 28, 2009 at 10:32 AM, Jesse Crockettli...@ruby-forum.com wrote: Hello, I've been trying for two years to pick up BDD. I'm making progress, have just read through the chapters in The RSpec Book on spec'ing views and controllers. What is the difference between using integrate_views and doing what seems to be a lot of extra work to test the views in isolation? When I use integrate_views, can I write view spec in what would otherwise be isolated controller spec? Yes you can do this. Personally, I find it a benefit in discovery, maintenance, and readability to have simple and focused focused view and controller specs rather than a controller spec trying to do it all. There is less of a barrier when writing an isolated view spec then there is when writing a integrated controller spec. I read that I'm encouraged to do these in isolation, but IMHO the chapter on spec'ing views is not very convincing in its own right, it tells me that it's good, but doesn't show me as much, compared to the examples and descriptions of circumstance that make several other chapters very convincing. Cucumber does a great job of providing a way to drive a lot of what's in your views (especially forms). There are many times when Cucumber is sufficient. However, there are plenty of times where your views have details or a some view logic where it may not be covered with your Cucumber scenarios or it may not be clear. In these cases a very simple view spec can be a quick and effective way to drive your views. In my opinion if view specs are hard to write and difficult to maintain you're doing it wrong, either in what you're spec'ing or what you're trying to implement. Writing view specs quickly and effectively requires that you get into a groove for writing simple views that drive methods into existence on other objects. Of course, finding that groove may mean rethinking how you're writing views, and understanding and knowing what rspec and webrat gives you. And this is one of the major goals of the Rails Views chapter. To get you comfortable with how to drive a view spec and understanding what the tools provide for you. It does provides some insight into the what/when/why, but that's not its major focus at this time, more of the focus is the how. Based on my experience driving things from the views on down led to more robust code. Even though it's a simple practice, I spent less time revisiting controllers and models because the views defined what was required before I even got there. It also forced me to think outside the box and recognize the value of presenters. Presenters are one thing not covered in the book, and I'm not sure how widespread they are, but I for one find them simple and powerful tool in my toolbox. If you're interested here's a link: http://wiki.github.com/mhs/caching_presenter Thank you for sharing your frustration about this. It seems to have spurred a lot of good input, and hopefully the Rails Views chapter will be able to be updated to tackle some of the challenges you found as a reader, Please help. thanks Jesse -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Driving Out A View - Am I specifying too much?
On Fri, Jun 5, 2009 at 11:54 AM, Leelee.longm...@googlemail.com wrote: I am driving out a view that renders a list of items with which a logged in member is associated. Against each item, one or more links may be rendered according to the member's role with respect to the item (item owner, item administrator, regular user etc). Each link represents a type of function that the member can perform on the item (edit, delete, invite etc), and the range of functions may differ across the items according to the member's role for each item. When specifying the view, should I include examples to specify which links should appear against an item for each potential role of a member? Or is this going too far? I don't think it's going to far. If certain links should not show up in some cases, but should in others, I would provide an example for those. If it's important enough to hide, it's important enough to make sure it's hidden for the right reasons. Here is an example list for a member: item 1 view edit delete (member is the owner of this item) item 2 view edit invite (member a regular user of this item) item 3 view (member has no role association with this item but can view it) I would probably drive these with a view spec that looked like this describe your/view do it should always have a link to view the item context when the member owns the item do it should have a link to edit the item it should have a link to delete the item end context when the member owns the item do it should have a link to edit the item it should have a link to invite ... end end Thanks. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Does rspec support something like Assumptions in JUnit 4.4?
On Mon, Jun 1, 2009 at 7:26 AM, mortench morte...@gmail.com wrote: Correction for last msg: before(:all) do �...@org_root_prop = java.lang.System.getProperty(root) # abort all examples and after action if condition is not meet: ensure_that !...@org_root_prop.nil? @org_root_prop.strip.length0 end You could do this check outside of the example? ie: describe do def self.ensure_that(condition, blk) yield if condition end def self.root_property_is_not_blank org_root_prop = java.lang.System.getProperty(root) org_root_prop.nil? org_root_prop.strip.length0 end ensure_that root_property_is_not_blank do it do end end end /Morten ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Any way to continue on Assertion Failure
On Wed, May 27, 2009 at 4:07 AM, Matt Wynne m...@mattwynne.net wrote: On 27 May 2009, at 03:38, Julian Leviston wrote: On 27/05/2009, at 9:33 AM, Gary Lin wrote: Hi, I wonder if there is any way to tell the test script to continue even when encountering an assertion failure? The reason I am asking this is because I have a test flow that can take a long time to run and it would be very useful if I can perform all verification at the end of test flow in one shot rather than fail one and exit immediately. Of course, I could break each verification point into separate test case, but then it will double or triple the overall execution time. Does RSpec support this? Isn't this usual behaviour? Julian. Yeah I'm a little confused by the question (and David's response) so maybe I've misunderstood something. Normal RSpec test runs will catch all the test failures and report them at the end of the run. I wonder whether the OP is talking about a situation where the interaction with the system takes a long time, so that using lots of examples of the desired behaviour causes that interaction to be run several times making the whole run very slow. I also wonder whether he's just thinking in the test/unit mindset, which I see a lot, where you have examples like this antipattern it should do foo and bar do set_up_state do_something_to_system_under_test assert_that_foo_was_done assert_that_bar_was_done end /antipattern I don't know that I would call this an antipattern unless set_up_state is duplicated across examples. I usually don't factor things out of an example unless it's duplicated in another example (then I extract to a before) or I'm working in a specific context (which I always give a before since it provides meaning of the context in an explicit way). Here's my normal RSpec flow: before(:each) do set_up_state do_something_to_system_under_test end it should have done foo do assert_that_foo_was_done end it should have done bar do assert_that_bar_was_done end Most of the time I would leave the do_something_to_system_under_test inside each example. I find it easier to read, and a more useful example (since you don't have to go look else where to see how the method is called), and it becomes easier to maintain should the object change in a way that requires a specific pre-condition to be introduced that aren't needed by the other examples (you don't have to modify every other example). another 2 cents to throw in the water fountain, if set_up_state and/or do_something_to_system_under_test take ages, you could use a before(:all) block instead, but that comes with obvious leaky state disadvantages. Matt Wynne http://beta.songkick.com http://blog.mattwynne.net ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [webrat] failing feature step when have_selector uses block
On Wed, May 20, 2009 at 5:30 AM, doug livesey biot...@gmail.com wrote: Hi -- I have a strange bug. The following step will pass: Then /^I should not see any options for the properties$/ do response.should have_selector( table thead ) end But this will fail: Then /^I should not see any options for the properties$/ do response.should have_selector( table thead ) do |thead| thead.should_not contain( Options ) end end The strange thing is that it isn't the inner specification that fails, but the outer one that is (or should be) identical to the first example (which is just a reduced version of the second to investigate what was failing). This is the second weird thing I have seen with nested blocks in have_selector (the first was nested calls to have_selector only checking immediate descendants of the block parameter). Is there something about their use that I'm not understanding? Are you using selenium or just with webrat? Cheers, Doug. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups webrat group. To post to this group, send email to web...@googlegroups.com To unsubscribe from this group, send email to webrat+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/webrat?hl=en -~--~~~~--~~--~--~--- -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] List Split
On Mon, May 18, 2009 at 10:13 AM, Lee Hambley lee.hamb...@gmail.com wrote: I'm honestly sure that nobody cares, but this list needs to split, I can't handle the volume of `junk` that is completely irrelevant because I am subscribed looking for to keep up to date with cucumber wisdom; I'm going to see how this message is received, and unsubscribe myself later today. The SNR ratio is absurd, and the list users should really consider a split. Thanks for the things I've learned, and the tips and tricks that I have been fortunate enough to pick up. Over the entire weekend I received a little over 30 messages on this list. I wouldn't exactly consider that high-volume or absurd. I use both RSpec and Cucumber and I don't personally mind them being on the same list as it allows me participate in discussions that pertain to the full cycle of outside-in development. I can see where you are coming from though since you only seem to care about the Cucumber aspect of things. If the lists are split I will simply subscribe to both. A nice thing about having the two ML's combined at this point is that discussions and questions which span the entire BDD process can be asked and answered. The down-side of this is that not all folks who use Cucumber use RSpec (or even Ruby). I don't encourage the split, but I think it is becoming inevitable. Cucumber itself is becoming large and wide. I can't think of a good reason for Java programmers who want to use Cucumber to join the RSpec ML. - Lee ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] helpers for examples?
On Fri, May 15, 2009 at 9:04 AM, Denis Haskin de...@haskinferguson.net wrote: Where's the recommended place to put helper methods etc for examples? I've started putting them in spec/spec_helper.rb but that's going to get awfully cluttered. I'm thinking maybe a spec/lib, and add that to include path? Or just put them in lib? I notice restful_authentication (I think) put AuthenticatedTestHelper there. I make a spec/spec_helpers/ directory and put them in there. I try to namespace them in the module SpecHelpers to avoid conflict and/or confusion with other modules in the app. I would not use spec/lib/, because a rails app has a lib directory, and convention would have someone assume spec/lib/ are specs for objects in RAILS_ROOT/lib/. Thx, dwh ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] helpers for examples?
On Fri, May 15, 2009 at 12:29 PM, Zach Dennis zach.den...@gmail.com wrote:
On Fri, May 15, 2009 at 9:04 AM, Denis Haskin de...@haskinferguson.net
wrote:
Where's the recommended place to put helper methods etc for examples?
I've started putting them in spec/spec_helper.rb but that's going to get
awfully cluttered. I'm thinking maybe a spec/lib, and add that to include
path? Or just put them in lib? I notice restful_authentication (I think)
put AuthenticatedTestHelper there.
I make a spec/spec_helpers/ directory and put them in there. I try to
namespace them in the module SpecHelpers to avoid conflict and/or
confusion with other modules in the app.
I would not use spec/lib/, because a rails app has a lib directory,
and convention would have someone assume spec/lib/ are specs for
objects in RAILS_ROOT/lib/.
Forgot to add in my spec_helper.rb I load all ruby files in spec/spec_helpers/
Dir[File.dirname(__FILE__) + '/spec_helpers/**/*.rb'].each { |f require f }
and then in my spec config I include specific ones I need:
Spec::Runner.configure do |config|
config.include SpecHelpers::MyApplicationMatchers
config.include SpecHelpers::ControllerMacros, :type = :controller
end
Thx,
dwh
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Unable to post to an update action in a controller spec
On Thu, May 14, 2009 at 6:23 AM, Fernando Perez li...@ruby-forum.com wrote:
put :update, :item = 1 etc.
I tried that but didn't work. I managed to get it working by simply
doing:
post :update, {:id = 'dummy', :item = {'1' = ...}}
For some reason, I previously tried with :id = 'update' but Rails
didn't like it.
I don't get the impression you're very familiar with RESTful routing
in Rails. You may want to look read about it in the Agile Web
Development w/Rails book and/or Rails guides:
http://guides.rubyonrails.org/routing.html#restful-routing-the-rails-default
It should give you a better overview of when/where to use ids, puts, posts, etc.
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] How To Drive Out AJAX Functionality in Rails' Views?
On Tue, May 12, 2009 at 8:31 AM, Lee lee.longm...@googlemail.com wrote: I am new to RSpec and have just started to drive out my first view using a spec. I have used the The RSpec Book (beta) to do the basic stuff like testing for the presence of a field but I am unsure where to start for driving out some AJAX functionality. In the view, I will have a text field that a user can enter a name into and then click on a link to check the availability of this name or otherwise. I plan to implement the check as an AJAX request, returning an HTML snippet or 'available' or 'not available'. I would appreciate some help on what sort of examples one might write and the various mocks, stubs and helpers etc that can be used. Or alternatively a pointer to some existing information/tutorials on this topic. For end to end coverage you'll need to utilize something like Selenium or Watir. Webrat has built-in Selenium support which I know folks are using successfully (we are at MHS). It is not as polished as the simulated support that Webrat has using an in-memory DOM, but that is starting to change. Selenium and Webrat have a bright future ahead (and a little longer term so does Watir IIRC). For isolated and/or complex client-side logic in JS you can utilize a JS-based testing framework like Screw.Unit or JSSpec: * http://github.com/nkallen/screw-unit/tree/master * http://jania.pe.kr/aw/moin.cgi/JSSpec Sorry I don't have any links to any tutorials, maybe others can provide. For me it was a largely dive-in and figure it out with Selenium a few years back, and I personally haven't taken the time to dump what I've learned to the world. The RSpec Book will include a chapter on automating Cucumber scenarios in the browser with Selenium, although I know that chapter has not been released yet. -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Test JSON with Cucumber
On Mon, May 11, 2009 at 5:31 PM, Bill Kocik bko...@gmail.com wrote:
On Mon, May 11, 2009 at 4:32 PM, Ben Mabey b...@benmabey.com wrote:
Well.. IIRC ActiveSupport::JSON.decode will return a ruby hash of the JSON,
correct? So you should be able to make expectations on it just like a
regular hash object.
You're absolutely correct - I think I did a poor job of asking my
question. Maybe a more concrete example would help. Suppose I have
this JSON:
response:{code:'200',requestId:'1234'}
I want to have a scenario like this in my Cucumber feature file:
When I go to the statuses JSON url
Then I should find . # ['response']['code']
And I should find . #['response']['requestId']
With a step definition like:
Then /^I should find ([^\]*)$/ do |the_string|
json = ActiveSupport::JSON.decode(@response.body)
assert_not_nil .. #(something with the json obect and the_string)
end
I don't know what goes in those blanks. Cucumber is going to give me a
string it found with the regex, but I don't know what the string would
look like in my Then I should find line in my feature file, nor what
to do with it in my assert line in the step definition. I'm not even
sure any of this is possible.
Consider if I were dealing with XML instead of JSON - I could put an
XPath expression in my Then I should find line, and in my step
definition I could search the XML with the given XPath expression
using hpricot or something. With JSON and it's resultant hash, I have
no idea where to start...
Another options is to call #to_xml on the JSON hash returned by
#decode, and then use XPath since you seem to already know it,
--
Bill Kocik
http://bkocik.net
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] question re: stubbing out validations
On Mon, May 11, 2009 at 12:05 PM, Barun Singh baru...@gmail.com wrote: Suppose a User has many widgets, and that we have a method in the User class that does something like: def update_widgets x = ... code to do some calculations ... if x 5 new_widget = widgets.new new_widget.save! else widgets.first.destroy end widgets.reload end How would one spec this without having to worry about the validations for new_widget? It seems pretty important that update_widgets is able to produce actual widgets. I would use actual models here rather than try to stub/mock something out. After all the whole method is about creating (or destroying) the widgets. It seems pretty central to the behaviour of the method. However, if what you shared is the dumbed down version of your code for us on the ML then perhaps there is something complicated going on that makes it a good candidate to be designed differently. Is there any way in the spec to tell it to replace instances of save! with instances of save(false) or something along those lines? Using message expectations is difficult in this case because the new_widget doesn't exist before the method is called, so there's not object that can ahead of time expect to receive the save! method. Are you telling us the full story? In the above code you shared you don't pass any attributes into widget.new. So, how does it create valid widgets in the actual app? Thanks.. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Where to spec authentication and roles-based permissions?
On Fri, May 8, 2009 at 5:33 AM, doug livesey biot...@gmail.com wrote: Hi -- I'm writing an app that both requires authentication via a logon, and also has roles-based permissions (using acl_system2), and was wondering where to verify that both are happening. I've started out putting them in a special cucumber feature for authentication permissions, but this is becoming a real drag, as I'm writing a scenario for each case (anonymous, lacking permissions, permitted) by each controller action. Can anyone advise me on a better way to organise this? Would it be possible to write a security feature for each controller, with scenarios for each action? Maybe like this: Scenario: Different users trying the index Given user is not logged in When I go to the controller-a index Then I should see Access Denied Given basic user is logged in When I go to the controller-a index Then I should see Insufficient Permissions Given super user is logged in When I go to the controller-a index Then I should see Welcome, my lord Any advice is very appreciated -- as you can probably tell, this is getting messy! I went down the route of using Scenario Outlines for this, and it still became messy. There are simply too many cases to cover and the tables you build up become long and redundant. After a while they all look start to blur together and look alike. I think these kind of things belong in controller specs where you can be confident resources are being protected, but you can also extract out nice little macros. For example, you might end up with: desribe PeopleController, GET index do should_allow_logged_in_access_to :superuser end You could use a convention of the controller description to determine the method and the action to hit, or you could parametrize your macro: should_allow_logged_in_access_to :get, :index, :roles = [:superuser] I'd recommend not specifying the roles that are denied since if you had one you'd have to do potentially change every controller spec in your app. Rather I'd have the macro try a non-allowed role to ensure it didn't work for other roles. In the Rails Controllers chapter in The RSpec Book there is a section on extracting out a should_require_login macro which walks through step by step the same technique I'd use for writing the macro you want. Cheers, Doug. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] rspec_scaffold and mocha
On Thu, May 7, 2009 at 7:40 AM, jevado jeroenvdo...@gmail.com wrote: Hi All, I have a question about the rspec_scaffold and if it's compatible with other mocking frameworks. I just created a blank application and a scaffold of a very basic model. The specs run fine untill I choose to use mocha in the spec_helper. Can somebody please tell me if this is ment to be and if so if there's an easy way to make the scaffold work with mocha ? RSpec scaffold is not set up produce scaffold for all of the various mocking libraries. It does so just for what comes with RSpec. I do not know of a way to simply replace scaffolding w/o providing more scaffolding (ones for each mocking library) and then adding a flag to the script/generate command to produce scaffolding for rspec+default, rspec+mocha, rspec+rr, etc. Also, in addition to this the normal script/generate rspec command could be used to take the same options so it would configure your spec_helper to run with the appropriate libraries. I think your idea for scaffolding with different mocking libraries is a good one. Please open a ticket on lighthouse and let's see if we can get some more input from others in the community as well as the core team. http://rspec.lighthouseapp.com/ Thanks in advance! Jeroen ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Using Rails observers and testability
On Mon, May 4, 2009 at 1:57 PM, BJ Clark b...@aboutus.org wrote: Fernando, They are easier to spec with Pat Maddox's no peeping toms plugin. http://github.com/pat-maddox/no-peeping-toms/tree/master I use Pat's no-peeping-toms plugin as well. It's a great tool in Rails toolbox. Brandon Keepers has made some additional enhancements which are nice: http://github.com/collectiveidea/no-peeping-toms/tree/master I don't know if he has requested Pat to pull them in, but Pat if you're listening please check them out and consider pulling them in. As much as I like the ability to fork there's something to be said about having a consistent *official* home for plugins. ;) BJ Clark On May 4, 2009, at 5:33 AM, Fernando Perez wrote: Hi, Before I do anything stupid, I'd like to know if there are any gotchas when using Rails observers instead of writing my own methods or callbacks? Are they easy to spec/test or will I run into troubles? Are they easily mockable? -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] cucumber/webrat, need to set user in session, can't stub or mock. Fixtures?
On Mon, Apr 27, 2009 at 5:24 PM, doug livesey biot...@gmail.com wrote: Refactoring the current_user method a little, then stubbing the find method in there did it. # ApplicationController def current_user User.find( session[:user_id] ) rescue nil end # Scenario step Given /^that a user is logged in to the session$/ do User.stub!( :find ).and_return( true ) end You probably want to return a User, no? Returning true is entirely different than the normal find API w/ActiveRecord. It seems to be misleading and I can see where it would cause problems where controller or view code that relies on #current_user expects a User, Cheers, Doug. 2009/4/27 doug livesey biot...@gmail.com Except I'm now struggling with how it should work, sorry. The step for the scenario looks like this: Given /^that a user is logged in to the session$/ do controller.stub!( :current_user ).and_return( true ) end However, when I try to puts the value of current_user as called from the ApplicationController#authorise method, it returns nil. I've tried just stubbing out the authorise method, too, but that doesn't seem to work, either. Am I approaching this the wrong way? cheers again, Doug. 2009/4/27 doug livesey biot...@gmail.com that nailed it, cheers man! Doug. 2009/4/27 doug livesey biot...@gmail.com Please be sure to clip the relevant parts when responding - all of that is only meaningful if I look at the other email in this thread. Easy on my desk top. Not so easy on my phone. Bit too used to gmail threads, sorry! Doug. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Select box with Webrat
On Thu, Apr 23, 2009 at 4:34 AM, mikej mikejerem...@gmail.com wrote: Thanks for the response. I think I tried that one, still get the response: The 'Pollution' option was not found in the temp_aspect_topic_id select box (Webrat::NotFoundError) Any more thought? Do you only have one select box on the page with that id (hidden or showing, maybe new and/or edit forms) ? Mike ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) @zachdennis (twitter) ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Depot app, Demeter's law and troubles cleanly spe cing
On Thu, Apr 23, 2009 at 2:19 PM, Fernando Perez li...@ruby-forum.com wrote:
Rails definitely entices you to break Demeter's law just so often.
Now how to cleanly spec:
@comment = @article.comments.build(params[:comment]) ?
You think that's bad, I've seen many a code that looks like:
project.tasks.map(:responsible_party).group_by{ ... }.mapsort
Mocking and stubbing is starting to get ugly now.
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Style issue
On Thu, Apr 23, 2009 at 3:59 PM, Mark Wilden m...@mwilden.com wrote:
On Thu, Apr 23, 2009 at 12:05 PM, James Byrne li...@ruby-forum.com wrote:
When /currency exchange rate transfer file should contain rates/ do
found = false
fx_code = 'USD'
File.open(FOREX_XFR_FN).each do |line|
found = true if
/.*fx_target#{fx_code}.*fx_rate(\d+\.\d{4}).*/.match(line)
break if found
end
fail(ArgumentError, Exchange Rate not found for #{fx_code}) if not
found
end
I find this more straighforward and easy to understand:
When /currency exchange rate transfer file should contain rates/ do
fx_code = 'USD'
File.open(FOREX_XFR_FN).each do |line|
return true if
/.*fx_target#{fx_code}.*fx_rate(\d+\.\d{4}).*/.match(line)
end
fail(ArgumentError, Exchange Rate not found for #{fx_code})
end
I'd even vote for the more concise form:
When /currency exchange rate transfer file should contain rates/ do
fx_code = 'USD'
IO.readlines(FOREX_XFR_FN).any?{ |line|
line.match /.*fx_target#{fx_code}.*fx_rate(\d+\.\d{4}).*/
} || fail ArgumentError, Exchange Rate not found for #{fx_code} unless found
end
///ark
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Style issue
On Thu, Apr 23, 2009 at 8:11 PM, Zach Dennis zach.den...@gmail.com wrote:
On Thu, Apr 23, 2009 at 3:59 PM, Mark Wilden m...@mwilden.com wrote:
On Thu, Apr 23, 2009 at 12:05 PM, James Byrne li...@ruby-forum.com wrote:
When /currency exchange rate transfer file should contain rates/ do
found = false
fx_code = 'USD'
File.open(FOREX_XFR_FN).each do |line|
found = true if
/.*fx_target#{fx_code}.*fx_rate(\d+\.\d{4}).*/.match(line)
break if found
end
fail(ArgumentError, Exchange Rate not found for #{fx_code}) if not
found
end
I find this more straighforward and easy to understand:
When /currency exchange rate transfer file should contain rates/ do
fx_code = 'USD'
File.open(FOREX_XFR_FN).each do |line|
return true if
/.*fx_target#{fx_code}.*fx_rate(\d+\.\d{4}).*/.match(line)
end
fail(ArgumentError, Exchange Rate not found for #{fx_code})
end
I'd even vote for the more concise form:
When /currency exchange rate transfer file should contain rates/ do
fx_code = 'USD'
IO.readlines(FOREX_XFR_FN).any?{ |line|
line.match /.*fx_target#{fx_code}.*fx_rate(\d+\.\d{4}).*/
} || fail ArgumentError, Exchange Rate not found for #{fx_code} unless
found
end
Whoops, make that...
When /currency exchange rate transfer file should contain rates/ do
fx_code = 'USD'
IO.readlines(FOREX_XFR_FN).any?{ |line|
line.match /.*fx_target#{fx_code}.*fx_rate(\d+\.\d{4}).*/
} || fail(ArgumentError, Exchange Rate not found for #{fx_code})
end
///ark
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Controller spec: testing that scope is set
On Sun, Apr 19, 2009 at 6:41 PM, Michael Schuerig mich...@schuerig.de wrote:
On Sunday 19 April 2009, Zach Dennis wrote:
On Sun, Apr 19, 2009 at 2:09 PM, Michael Schuerig
mich...@schuerig.de wrote:
On Sunday 19 April 2009, Zach Dennis wrote:
On Sun, Apr 19, 2009 at 12:27 PM, Michael Schuerig
mich...@schuerig.de wrote:
In a Rails controller I set the scope on a model class in an
around filter. I have defined expectations on the model classes,
and ideally, I would add a further expectation for the scope. Is
this already possible in some way? How would I go about adding
support a scope expectation?
How are you setting the said scope?
In an around filter. However, I don't want to test the around
filter mechanism, it might as well be rack middleware instead.
Sorry, I don't know what scope means to you in your app. Can you
share your around_filter?
Oops, sorry, I assumed the concept from ActiveRecord would be familiar.
If you know ActiveRecord::Base#with_scope that's really all there is. A
scope, within a block or through a proxy, defines options that are
merged with the arguments to #find et al. This merging happens behind
the scenes, therefore the scoped options are effective, but don't show
up as arguments anywhere.
I'm using this in conjunction with a generic query representation
(inspired by JSON Query) that is map through a combination of Rack
middleware and generated around_filters, see below for a glimpse.
Michael
class PeopleController ApplicationController
include QueryScope
query_scope :only = :index do
# Only allow to filter and order by the
# virtual name attribute.
# This attribute is mapped onto the real
# firstname and lastname attributes.
allow :name
condition :name =
LOWER(firstname || ' ' || lastname) :op LOWER(?)
order :name = lastname :dir, firstname :dir
end
...
Somewhere in QueryScope
def query_scope(options = {}, config_block)
model_class = extract_resource!(options)
builder = QueryScopeBuilder.new(config_block)
around_filter(options) do |controller, action|
req = builder.build_request_conditioner(controller.request)
controller.instance_variable_set(:@offset_limit, req.offset_limit)
model_class.send(:with_scope, :find = req.find_options, action)
end
end
I think I am starting to understand what you're after. You want to
ensure the scope defined in your query_scope configuration block in
the controller is used to set the scope on the controller's model.
Right?
With the assumption that that is correct, I would probably refactor
how your #query_scope method works. Right now you're implicitly going
through a QueryScopeBuilder to get a RequestConditioner, in order to
access the #find_options and #offset_limit behaviour on that
RequestConditioner. I would make your controller deal with one object,
perhaps a RequestToQueryTranslator. Your #query_scope method would
come out looking like:
def query_scope(options = {}, config_block)
model_class = extract_resource!(options)
query = RequestToQueryTranslator.translate(controller.request,
config_block)
around_filter(options) do |controller, action|
controller.instance_variable_set(:@offset_limit, query.offset_limit)
model_class.send(:with_scope, :find = query.find_options, action)
end
end
This simplifies the #query_scope method and gives you more
implementation freedom how your query is constructed. This still
leaves something difficult to spec though, you are passing your
query_scope config_block through, and I'm guessing it is
instance_eval'd. You can't be sure of what's going on in that
config_block unless you actually instance_eval inside of the
appropriate object. This limits your ability to write a clean
object-level example expecting the right query is constructed because
it requires your controller to work with real dependent objects.
Two approaches that come to mind for dealing with this are to change
how your config_block works. Rather than:
query_scope :only = :index do
allow :name
condition :name =
LOWER(firstname || ' ' || lastname) :op LOWER(?)
order :name = lastname :dir, firstname :dir
end
You could do:
query_scope :only = :index do |query|
query.allow :name
query.condition :name =
LOWER(firstname || ' ' || lastname) :op LOWER(?)
query.order :name = lastname :dir, firstname :dir
end
Now in your spec, you can write a spec against the query_scope, by
ensuring the passed in object receives #allow, #condition and #order
with appropriate arguments. Now you don't have instance eval the block
in some dependent object somewhere, you can simply pass the query your
RequestToQueryTranslator.translate method returns to the config_block.
This gives you the advantage of ensuring that the controller sets up
the proper query, and it allows you to spec your
RequestToQueryTranslator in isolation to ensure that given
Re: [rspec-users] Depot app, Demeter's law and troubles cleanly specing
On Sun, Apr 19, 2009 at 12:24 PM, Mark Wilden m...@mwilden.com wrote: On Sun, Apr 19, 2009 at 3:51 AM, Matt Wynne m...@mattwynne.net wrote: @order_presenter.product_titles do |product_title, url| %= link_to product_title, url % end The presentation of an order in most apps will be constructed from additional columns (e.g., color, size, price, extended price). These columns may well be formatted differently depending on the circumstance (e.g, printed or on-screen). Now, it might be a good idea to put this construction and formatting in a helper or presenter outside the view (though it won't be TSTTCPW). But anywhere you put it, there will be non-Demeterian code that needs to drill down into each order's items', products' information (as well as non-product information, such as line-item discount). If the underlying model changes, this code will have to change - you can't avoid it. Agreed. I think Dan Manges post is a good one on this topic as well: http://www.dcmanges.com/blog/37 His second to last paragraph: The crux of this is that webpage views aren't domain objects and can't adhere to the Law of Demeter. Clearly from the examples of behavior delegation the Law of Demeter leads to cleaner code. However, when rendering a view, it's natural and expected that the view needs to branch out into the domain model. Also, anytime something in a view dictates code in models, take caution. Models should define business logic and be able to stand alone from views. If this train-wreck method calling in your views is bothersome, there is a better solution that I will blog about later. I tend to agree his thoughts on this, but be careful how you read the sentence anytime something in a view dictates code in models, take caution. He isn't referring outside-in development practices. He's referring to adding methods in a model for strictly presentation purposes, which is bad because it dilutes the richness of the model, and makes it change for reasons it shouldn't. Here's another article which discusses why methods shouldn't be added to models for presentation purposes: http://spin.atomicobject.com/2008/01/27/the-exceptional-presenter Although if you read that article and want to try out presenters, you should know that CachingPresenter supersedes the PresentationObject library in the article. And you don't need a library to use presenters, your presenters can be POROs just like Matt Wynne posted. I tend to like the CachingPresenter library (heck I wrote it) approach so I can utilize caching, memoization, and a slightly more declarative API and list of helper methods. One technique I've employed in the past along side presenters (although it can be done w/o presenters) is to make use of partials, and actually treat them like little view objects. So you could take what you had: @order.items.each do |item| item.product.title end And transform it into two views, one that is concerned with the order, and a partial which is concerned with the product of an item. : %= render :partial items/product, :collection = @order.items.map(:product) % And then add a items/product partial and spec it in isolation. Spec'ing views (and partials) in isolation gives you the ability to have simpler view specs, and you're able to avoid feeling the awkward need to build up a network of objects. And you don't have to worry about adding a bunch of little delegate methods all over the place. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Controller spec: testing that scope is set
On Sun, Apr 19, 2009 at 6:41 PM, Michael Schuerig mich...@schuerig.de wrote:
On Sunday 19 April 2009, Zach Dennis wrote:
On Sun, Apr 19, 2009 at 2:09 PM, Michael Schuerig
mich...@schuerig.de wrote:
On Sunday 19 April 2009, Zach Dennis wrote:
On Sun, Apr 19, 2009 at 12:27 PM, Michael Schuerig
mich...@schuerig.de wrote:
In a Rails controller I set the scope on a model class in an
around filter. I have defined expectations on the model classes,
and ideally, I would add a further expectation for the scope. Is
this already possible in some way? How would I go about adding
support a scope expectation?
How are you setting the said scope?
In an around filter. However, I don't want to test the around
filter mechanism, it might as well be rack middleware instead.
Sorry, I don't know what scope means to you in your app. Can you
share your around_filter?
Oops, sorry, I assumed the concept from ActiveRecord would be familiar.
If you know ActiveRecord::Base#with_scope that's really all there is. A
scope, within a block or through a proxy, defines options that are
merged with the arguments to #find et al. This merging happens behind
the scenes, therefore the scoped options are effective, but don't show
up as arguments anywhere.
I'm using this in conjunction with a generic query representation
(inspired by JSON Query) that is map through a combination of Rack
middleware and generated around_filters, see below for a glimpse.
Michael
class PeopleController ApplicationController
include QueryScope
query_scope :only = :index do
# Only allow to filter and order by the
# virtual name attribute.
# This attribute is mapped onto the real
# firstname and lastname attributes.
allow :name
condition :name =
LOWER(firstname || ' ' || lastname) :op LOWER(?)
order :name = lastname :dir, firstname :dir
end
...
Somewhere in QueryScope
def query_scope(options = {}, config_block)
model_class = extract_resource!(options)
builder = QueryScopeBuilder.new(config_block)
around_filter(options) do |controller, action|
req = builder.build_request_conditioner(controller.request)
controller.instance_variable_set(:@offset_limit, req.offset_limit)
model_class.send(:with_scope, :find = req.find_options, action)
end
end
In your original post you asked:
How would I go about adding support a scope expectation?
Given the code you've shown it is not clear exactly what you are
expecting. Do you just want to be able to expect that you call
model_class.send(:with_scope) with the appropriate arguments?
I'm sorry if I seem dense, but you have a very clear idea of what you
want to accomplish, but it's coming out very piece meal across
multiple emails and it's quite difficult to pick up on,
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] DDL Rails 2.3 nested transactions causing problems in specs
On Fri, Apr 17, 2009 at 6:36 PM, john eagerwom...@gmail.com wrote: Mysql::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'RELEASE SAVEPOINT active_record_1' at line 1: RELEASE SAVEPOINT active_record_1 a rails ticket concerning this error which was marked invalid: https://rails.lighthouseapp.com/projects/8994/tickets/1925-mysqlerror-savepoint-active_record_1-does-not-exist-rollback-to-savepoint-active_record_1 another rails doc concerning issue: http://github.com/lifo/docrails/commit/0e6b9695aff6500ad48c4dd9ab61343d7090b030 Good grief! The issue seems to not be ActiveRecord, but limitations of MySQL. Elia Schito gave a good explanation IMO on the rails ticket. Apparently any nested transaction (ex. a create statement inside a test) will fail if you're using MySQL. still fighting it. If you create an ActiveRecord object in one 'it' block, it's still there in the next block ?!? Do you have transactional fixtures turned off? The following works fine with Rails 2.3.2: http://gist.github.com/97819 Can you provide more information about your problem? You didn't really show us what you were doing, and what you thought was failing, and what you actually expected. The only workaround I've found for the MySQL's unsupported nested transactions is the following: User.transaction do user1 = User.create(:name = Alice) User.transaction(:requires_new = true) do user2 = User.create(:name = Bob) end end This is actually emulated using save points because most databases do not support nested transactions. Some databases (SQLite) don’t support either save points or nested transactions, so in that case this works just like Rails 2.2 where the inner transaction(s) have no effect and if there are any exceptions the entire transaction is rolled back. PLUGIN SOLUTIONS that DON'T fix spec issues: http://svn.viney.net.nz/things/rails/plugins/savepoints/ http://github.com/spint/savepoints/tree/master (github version with added support for oracle) HELP, RSPEC COMMUNITY!!! ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] AfterCurrentScenario block
On Fri, Apr 17, 2009 at 12:31 PM, Aslak Hellesøy aslak.helle...@gmail.com wrote: Den 17. april. 2009 kl. 18.06 skrev Matt Wynne m...@mattwynne.net: Is there currently a way to register a block to run after the current scenario completes? After. After is used after *any* scenario completes thought, right? If you add an After block inside of a step definition, it's going to be executed from that point on, rather than clear out at the end of the scenario that ran it, correct? If not, we've implemented one. Would anyone be interested in us submitting it as a patch to Cucumber? How is this different from After? * It clears out after the current scenario. * It doesn't require to be run for scenarios that don't need it. * It allows you to cleanly place the handler next to the code that it is so closely related * It doesn't require you know the name of the scenario(s) that would need it (it's simply determined by if a step definition is run) Aslak Something like Given something that will not be rolled back after the scenario is finished do original = SomeClass.a_value SomeClass.a_value = 7 AfterCurrentScenario do # undo stuff SomeClass.a_value = original end end If you're interested, our use case is for pagination, where we explicitly set the length of a page to something much shorter than the default in a step, so that we only have to create a small number of objects to spill over onto another page. The page length value is set on a class variable, and would pollute other tests, so we want to reset it when the scenario is finished. e.g. Given the maximum number of Users to display is 2 And there are 3 Users When I view the Users page Then I should see the text see all 3 users Matt Wynne http://blog.mattwynne.net http://www.songkick.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [Cucumber] How can I pass an XML block as a parameter?
On Tue, Apr 14, 2009 at 10:37 PM, Stephen Eley sfe...@gmail.com wrote: On Tue, Apr 14, 2009 at 8:37 PM, Ben Mabey b...@benmabey.com wrote: Have you tried the pystring syntax? Given I want to have multiple lines I can pass them in with three quotes... How does that parse into a step definition? Would it be: Given /^I want to have multiple lines\n(.*)$/m do |text| Given /^I want to have multiple lines$/m do |text| Cucumber parses it and appends it to the blocks argument list---so it will always be the last argument. e.g. Given /^(\w+) want to have multiple lines$/m do |who, text| It is a cucumber PyString object, but you can treat it like a normal string. ...or would it be something else? Is the newline character necessary? Are the quotes included? And does this imply that multiline text must always be separated from from steps in lines of its own? Sorry if I'm asking dumb questions, but I was trying to look this up a few weeks ago myself to represent some example Markdown data, and eventually gave up. This isn't documented anywhere that I could find. I've also never heard of pystring syntax -- I just tried to Google that too, but all I got were references to Java libraries and no simple syntax reference. -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Mocking: brittle specs and tight coupling?
On Sun, Apr 12, 2009 at 8:23 PM, Phlip phlip2...@gmail.com wrote:
David Chelimsky wrote:
Another tip: To TDD a new feature, don't clone a high-level test which
calls
code which calls code which calls the code you need to change.
FWIW, what you propose is the exact opposite of BDD, which suggests we
start at the highest levels and work our way in.
My current day-job's most important project has a test suite that suffered
from abuse of that concept. The original team, without enough refactoring,
were cloning and modifying very-high-level tests, making them longer, and
using them to TDD new features into the bottom of the models layer. Don't do
that.
This sounds like an issue with the team.
How can you know what the lowest level code is supposed to do before
you have higher level code invoking it? You can certainly make good
guesses, and they might end up being good choices in the end, but they
tend to bind you to a pre-determined design.
That sounds like James Kanze's over-educated arguments against TDD:
Phlip wrote:
James Kanze wrote:
In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do,
I didn't bring up TDD, but if you are curious enough about it
to keep asking these entry-level FAQs,
I'm not asking anything. I'm simply stating an easily
established fact, which wishful thinking seems to cause some
people to ignore. Tests definitly have their role, but until
you know what the code should do, you can't begin to write them.
And until you've written something down in black and white, you
don't know it.
From there, he'll wander off into too smart to just try it bullshit...
Your recommendation also starts with cloning a pre-existing example,
so I'm assuming this is a very specific sort of situation, where you
have a certain amount of code in place. What about when you are
starting a project for the first time?
Programming bottom-up gives you decoupled lower layers. Top-down gives you a
way to tunnel from a new View feature into the code that supports it. The
goal is you _could_ start a new feature either way, and you get the benefits
of both techniques.
Having done both for a few years each, in my experience I've found
that outside-in gives me better decoupled layers, where each layer is
more focused on its responsibility. Inside-out usually leaked a lot of
things into outer layers, because as I was building out I was making
assumptions on what I was going to need.
Individually, each thing that leaked was small and manageable, but a
few weeks, and months later, all of those little manageable oddities
now may the code base hell to work with, slowing down progress and
making it much harder for new devs to get ramped up.
I have worked bottom-up with Java and Ruby, and I've shipped those
apps. Not all of them were webapps either. IME, the bottom up approach
works. But after sharpening my outside-in skills, I have found it to
be all around much better development approach for the apps that I
deliver.
I thought of describing that specific tip while adding any! to
assert_xhtml. It would have been too easy to start with the high-level
tests:
def test_anybang_is_magic
assert_xhtml SAMPLE_LIST do
ul.kalika do
any! 'Billings report'
end
end
assert_xhtml_flunk SAMPLE_LIST do
without! do
any! 'Billings report'
end
end
end
Some of my features indeed started there, and some of them indeed do not yet
have low-level tests.
But the entire call stack below that also at least has tests on each layer -
except the actual code which converts a tag like select! into the fragment
of XPath which matches //select[]. Oh, and that code around it had grown a
little long. So in this case, I started there, and refactored out the single
line that needed the change:
def translate_tag(element)
element.name.sub(/\!$/, '')
end
Then I can TDD translate_tag directly:
def test_any_element
bhw = assemble_BeHtmlWith{ any :attribute = 'whatever' }
element = bhw.builder.doc.root
assert{ bhw.translate_tag(element) == 'any' }
bhw = assemble_BeHtmlWith{ any! :attribute = 'whatever' }
element = bhw.builder.doc.root
assert{ bhw.translate_tag(element) == '*' }
end
...
def translate_tag(element)
if element.name == 'any!'
'*'
else
element.name.sub(/\!$/, '')
end
end
Only then I wrote the high-level tests, and they passed.
Note that RSpec requires the constructor to BeHtmlWith to be a little ...
fruity, so I wrapped it and its Builder stuff up into assemble_BeHtmlWith...
--
Phlip
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users
Re: [rspec-users] Reuse of Cucumber Features
to specify the date in the features, as there may be extra requirements like birth dates can not be in the future in addition to the generic date requirements. And I want to validate that the form checks for valid dates, displays the appropriate error message when invalid, and uses the common rules for parsing. But I don't want to copy and paste those scenarios in every feature. I think reusing steps as you mention is probably the solution but I'm stuck on how to word it and put it together in my case. Steve On Sun, Dec 14, 2008 at 8:41 AM, Matt Wynne matt at mattwynne.net wrote: On 13 Dec 2008, at 20:58, Steve Molitor wrote: What's the best way to handle a requirement that shows up as a sub-requirement requirement in other features? For example let's say users can enter dates in various forms throughout my application. There is one set of global rules specifying the formats in which dates may be entered, and how they are interpreted. I put that in one feature. In various other features, like 'Create new patient', one can enter dates, like the patient's birth date. I want to do something like 'and the date entry shall follow the normal rules' but I'm not sure how to do that in an example driven way, without copying and pasting from other features. Does my question make sense? Any suggestions? Do you know that you can call steps within steps? http://blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps/ Is that what you're looking for? Matt Wynne http://blog.mattwynne.net http://www.songkick.com ___ rspec-users mailing list rspec-users at rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users at rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users at rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users Matt Wynne http://blog.mattwynne.net http://www.songkick.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Reuse of Cucumber Features
On Thu, Apr 9, 2009 at 2:56 PM, Matt Wynne m...@mattwynne.net wrote: On 9 Apr 2009, at 17:47, Zach Dennis wrote: On Thu, Apr 9, 2009 at 9:29 AM, Williams, Wesley wesley.willi...@sabre.com wrote: Matt, Hmm, I think this is one way to do it. I will need to get my customer to think differently about defining the requirements. They really like the tables. Some times table just work best. I love writing scenarios with natural language, but I've hit many cases where the inputs and outputs are best displayed as a table, and it's easier for the customer to gr0k, then to read a short novel. This kind of re-use that you seem to need sounds like a potential feature for Cucumber. A way to utilize an external file to house a table of data. e.g.: Background Given I have the following set of flights: | foo | bar | baz | ... Would become Background Given I have the following set of flights: FromFile: flights/scheduleA And then you'd have the flights/scheduleA house: | foo | bar | baz | ... Cucumber could dump in the table data it found from the file, and print it out when running the scenarios, and it allows some sets of sample data be re-used easily, in an understandable manner. WDYT? This is a good idea - people do this with Fit (as opposed to Fitnesse) and go straight to a spreadsheet for the examples. I don't see why it needs a new Cucumber feature though - you could easily (and more flexibly) write a custom step yourself to load in the data from an external file, right? That's true, but why does everyone need to write their file loading step/code? It seems like something where flexibility really doesn't benefit anyone, unless you are doing something unique and special, which I think is different than simply being able to store example tables in an external file. Matt Wynne http://blog.mattwynne.net http://beta.songkick.com -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Testing page layouts
On Thu, Apr 9, 2009 at 2:55 PM, James Byrne li...@ruby-forum.com wrote: This is a question of technique. To what degree do projects generally test page/report layouts? Do you just check to see if the expected data is present or do you also check that the layout is presentable? We use humans to check layout and presentation since it's visual and not something that can be determined correct by a program in a reasonably maintainable way (at least IMO). We use scenarios and specs to ensure that the application is providing the right display of information from the system, and the proper form/inputs that people should be able to access through the app. We find the combination gives us a good flexibility to change the UI while being confident that the app is still doing everything it should be, -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Reuse of Cucumber Features
On Thu, Apr 9, 2009 at 3:30 PM, Zach Dennis zach.den...@gmail.com wrote: On Thu, Apr 9, 2009 at 2:56 PM, Matt Wynne m...@mattwynne.net wrote: On 9 Apr 2009, at 17:47, Zach Dennis wrote: On Thu, Apr 9, 2009 at 9:29 AM, Williams, Wesley wesley.willi...@sabre.com wrote: Matt, Hmm, I think this is one way to do it. I will need to get my customer to think differently about defining the requirements. They really like the tables. Some times table just work best. I love writing scenarios with natural language, but I've hit many cases where the inputs and outputs are best displayed as a table, and it's easier for the customer to gr0k, then to read a short novel. This kind of re-use that you seem to need sounds like a potential feature for Cucumber. A way to utilize an external file to house a table of data. e.g.: Background Given I have the following set of flights: | foo | bar | baz | ... Would become Background Given I have the following set of flights: FromFile: flights/scheduleA And then you'd have the flights/scheduleA house: | foo | bar | baz | ... Cucumber could dump in the table data it found from the file, and print it out when running the scenarios, and it allows some sets of sample data be re-used easily, in an understandable manner. WDYT? This is a good idea - people do this with Fit (as opposed to Fitnesse) and go straight to a spreadsheet for the examples. I don't see why it needs a new Cucumber feature though - you could easily (and more flexibly) write a custom step yourself to load in the data from an external file, right? That's true, but why does everyone need to write their file loading step/code? It seems like something where flexibility really doesn't benefit anyone, unless you are doing something unique and special, which I think is different than simply being able to store example tables in an external file. One more though, how would you process your example table from a file within a step? Would you do a giant eval after reading the contents? Or would you reach into the guts of Cucumber to programmatically build the right thing? Is there another way? I've never done it, so just asking how you would approach this by writing your own step, Matt Wynne http://blog.mattwynne.net http://beta.songkick.com -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] updated to latest gems, rspec not catching flash.now
On Wed, Apr 8, 2009 at 2:08 PM, doug livesey biot...@gmail.com wrote: Hi, after an update to all the latest gems, I have a controller spec failing that wasn't previously: flash[:alert].should eql( Blah blah. ) The flash is being set by flash.now[:alert] = '...' in this instance. Can anyone suggest how I can make this work again? I just submitted a patch to ticket #11834 to resolve this issue in rspec-rails: https://rspec.lighthouseapp.com/projects/5645-rspec/tickets/98-11834-fake-controller-flash-object#ticket-98-9 In the mean time you can manually patch your local rspec-rails (if you unpack rspec and rspec-rails into vendor/gems or vendor/plugins this should work fine). Or you can do Xavier suggests on that ticket and add a few lines to your spec_helper, until rspec-rails is updated. HTH, Cheers, Doug. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [Rspec] Trying to get rspec to test a controller in a namespace
On Wed, Apr 8, 2009 at 5:18 PM, TimBooher tbboo...@gmail.com wrote:
any takers? am i asking a question that is too hard or too easy and
boring?
So your SponsorsController exists inside of a Admin module namespace?
If so update your spec:
describe Admin::SponsorsController
If that's not the issue I'm not quite sure what you're using namespace
to refer to,
thanks,
tim
On Apr 7, 7:41 am, Tim Booher t...@theboohers.org wrote:
I am trying to get my workflow down and am confused on several fronts. The
first is how to get my rspec_scaffold tests to run. The problem is that i
generated my scaffold, then moved my controller into a namespace named
:admin.
So I have the following familiar code. How can i change this to avoid:
-
my error on run
-
/home/tim/.gem/ruby/1.8/gems/activesupport-2.2.2/lib/active_support/dependencies.rb:445:in
`load_missing_constant': uninitialized constant SponsorsController
(NameError)
from
/home/tim/.gem/ruby/1.8/gems/activesupport-2.2.2/lib/active_support/dependencies.rb:77:in
`const_missing'
from
/home/tim/.gem/ruby/1.8/gems/activesupport-2.2.2/lib/active_support/dependencies.rb:89:in
`const_missing'
from
/home/tim/web_apps/lovd_by_fitwit/spec/controllers/sponsors_controller_spec.rb:3
from
/home/tim/.gem/ruby/1.8/gems/rspec-1.2.2/lib/spec/runner/example_group_runner.rb:15:in
`load'
from
/home/tim/.gem/ruby/1.8/gems/rspec-1.2.2/lib/spec/runner/example_group_runner.rb:15:in
`load_files'
from
/home/tim/.gem/ruby/1.8/gems/rspec-1.2.2/lib/spec/runner/example_group_runner.rb:14:in
`each'
from
/home/tim/.gem/ruby/1.8/gems/rspec-1.2.2/lib/spec/runner/example_group_runner.rb:14:in
`load_files'
from
/home/tim/.gem/ruby/1.8/gems/rspec-1.2.2/lib/spec/runner/options.rb:97:in
`run_examples'
from
/home/tim/.gem/ruby/1.8/gems/rspec-1.2.2/lib/spec/runner/command_line.rb:9:in
`run'
from /home/tim/web_apps/lovd_by_fitwit/script/spec:5
-
sponsors_controller_spec.rb
-
require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')
describe SponsorsController do
def mock_sponsor(stubs={})
@mock_sponsor ||= mock_model(Sponsor, stubs)
end
describe responding to GET index do
it should expose all sponsors as @sponsors do
Sponsor.should_receive(:find).with(:all).and_return([mock_sponsor])
get :index
assigns[:sponsors].should == [mock_sponsor]
end
. . . .
end
___
rspec-users mailing list
rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [Cucumber] Welcome Ben Mabey to the official Cucumber team
On Tue, Apr 7, 2009 at 5:53 PM, Ben Mabey b...@benmabey.com wrote: aslak hellesoy wrote: Ben Mabey has accepted my invitation to be on the core Cucumber team. Ben has been a long time contributor to Cucumber's ecosystem and knows it inside out. Here is a quote from IRC today: mabes: Yeah but you're the cucumber God. The core Cucumber team now consists of Joseph Wilk, Ben Mabey and myself. Welcome Ben! Congrats Ben! Aslak Thanks for the welcome! Just to be clear.. I did not say that I was the cucumber God... someone said that to me. :) -Ben ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Best practices: How small to make examples?
On Mon, Apr 6, 2009 at 12:36 PM, Mark Wilden m...@mwilden.com wrote:
On Mon, Apr 6, 2009 at 8:02 AM, James B. Byrne byrn...@harte-lyne.ca wrote:
Given user myuser is authenticated
When they visit the registration page
And they provide all required registration data
And they choose register
Then they should see a registration success message
You left out the And... which I believe James used to denote
anything else that needed to be done to ensure the registration was
successful. Maybe on purpose, maybe by accident, but it seems to have
impacted your response. Maybe what you responded with was exactly what
you meant to say, but it feels like a response made with haste.
I have two issues with this:
1) How could this story be acceptable? In other words, how could
business say that it's done? The success of this scenario would not
indicate very much about the success of the application.
2) There are different levels of granularity here. There are very
specific steps ('they visit the registration page', 'they should see a
registration success message') that relate to a specific URL or page
element. Then there is the catch-all 'all required registration data.'
To me, this doesn't communicate anything meaningful to business. It's
akin to 'Then it should work'.
Obviously, a scenario is not a formal requirements document.
Nevertheless, if what it asserts is too generic, how much benefit is
there in executing it?
///ark
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] debuggin cucmber script in ruby
On Mon, Apr 6, 2009 at 12:21 PM, Ben Mabey b...@benmabey.com wrote: Anil Gollaa wrote: hi, Thanks for the information, When i run cucumber testfile.feature, I was able to halt execution at breakpoint, but when i type 'n'. it is getting in to /lib/cucumber/ast/step_invocation.rb:33 and some other lib files of cucumber. I just want to debug line by line of the script, instead of getting in to cucumber files. please help me in this regard Sorry, but I don't know of anything that will automatically allow you to skip over framework code.. Although, that would be very cool. My best suggestion would be to set multiple breakpoints and hit c to continue to the next one so you can skip through all of Cucumber's code. I will sometimes set a global variable to help me flag when to debug, if the code in question gets executed multiple times. e.g. $c = true if my_condition_is_met And then... debugger if $c -Ben ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] spec'ing theme views
On Mon, Apr 6, 2009 at 8:06 PM, jared ja...@yourelevation.com wrote: I'm using the theme support plugin on one of my apps, and I would like to spec the views for each of my themes, but having a little trouble and hoping someone can point me in the right direction. Themed views are located at /themes/my_theme/views that override the views in app/views when that theme is active. I created a themes/ my_theme/spec directory, and to spec the file at /themes/my_theme/ views/default/index.html.erb I created the following file at themes/ my_theme/spec/default/index.html.erb_spec.rb require File.expand_path(File.dirname(__FILE__) + '/../../../../spec/ spec_helper') describe /default/index.html.erb do include DefaultHelper it should render do render end end Two major questions here: 1) I'm not sure what to put for the describe parameter since I'm assuming /default/index.html.erb is referencing the app/views directory This is a textual description used to help you. It doesn't actually mean anything to rspec at this time AFAIK. RSpec is able to to treat specs found in spec/views/ as ViewExampleGroups based on the view directory naming convention, IIRC. 2) Running this spec gives: NameError in '/default/index.html.erb should render' undefined local variable or method `render' for #ActiveSupport::TestCase::Subclass_1:0x351dc24 themes/my_theme/spec/default/index.html.erb_spec.rb:11: any suggestions on how to approach this? Try passing in :type = view to your describe. e.g.: describe your/partial, :type = view do # ... end Where does that take you? Thanks! ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Best practices: How small to make examples?
On Sun, Apr 5, 2009 at 1:03 PM, Mark Wilden m...@mwilden.com wrote: On Sun, Apr 5, 2009 at 5:20 AM, David Chelimsky dchelim...@gmail.com wrote: Given I register for a conference Then my name should be on the list of conference attendees And the conference should be my list of conferences If I were describing 'register for a conference' in this scenario, then I would think it important to specify the steps that are used: Given I am logged in And I go to the registration page And I fill in the email field And I click Register Then my name should be on the list of conference attendees And the conference should be my list of conferences That's the level of detail the story would have, so that's what I want to show works. On the other hand, this could simply be describing what appears on the screen when I am registered for a conference (as opposed to how I got there). In that case, the Given would simply add a database row. But there would be a different story for the process of filling out the form. Sometimes, they can be combined. But my point is that scenarios still have to describe how the user relates to the form and 'Given I register for a conference' doesn't do that. When you do have a scenario that includes this level of detail, you don't need a view spec, IMO. And you can still code step-by-step. It seems that when developers write scenarios they often walk through everything logically and fill in every input field from a scenario. When my customers write scenarios they don't do this, they tend to think higher level. They write: Given I register for a conference. Over time I've found I lean towards the scenarios remaining higher level. When scenarios too detailed oriented for how registering for a conference is done then it becomes a maintenance burden any time how registering for a conference is updated. I like allowing my scenario to remain expressive about the behaviour of the app while leaving out the details about every form field being filled in. In a way it's parallel with refactoring a public method. You can change the details w/o changing how everything uses it. I find that's akin to scenarios. They should only change when the actual behaviour changes (or at least that's my goal to shoot for), not necessarily when the UI gets reworked, or input fields get added or removed. I also don't think the scenario should try to relate the forms on the UI to the user. There are better tools for this job: wireframes, screen mockups, and the actual UI itself. It sounds like you may have an expectation that the scenarios should read like step by step instructions for using the app? An interesting idea, but it adds an additional responsibility to the scenarios which I think will ultimately convolute the value they are trying to express. At least it has when I tried to do that months back. ///ark ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] [ANN] BDD w/Rails class in June
I apologize in advanced if this seems like a shameless plug, but it feels like an appropriate place to announce it. The first week of June I'm going to teaching a class on BDD w/Rails in sunny west Michigan: Announcement - http://mutuallyhuman.com/2009/4/3/bdd-with-rails-class Course - http://ideafoundry.info/behavior-driven-development Happy rubying, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problem with Custom matcher and Blocks
of the pieces of information it should be displaying I'm really interested in this topic as I think I've seen when Cucumber is relied on too much and I've definitely seen where it's been relied on too little. So naturally I'm interested to find out more about people's projects to help gauge where things fall on the continuum, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Good introduction to rspec
On Wed, Apr 1, 2009 at 11:50 AM, James Byrne li...@ruby-forum.com wrote: Pablo L. de Miranda wrote: @Fernando - So what material you recommend to start a study in rSpec? This might be heresy, but I suggest that you start with Cucumber and simply use RSpec matcher syntax in your step definitions. Once you have the hang of how to express expectations in the step definitions, then move on to using RSpec on its own; providing that you still want to. I really did not get the hang of any of this, TDD, BDD, Rails or Ruby until I latched on to Cucumber and started -- very, very poorly mind you -- to discover how to express behaviour and, more importantly, what behaviour to express. It was, for me, a tumultuous journey and one that I am still traveling. I am now at the point where, simply by expressing one little bit of desired bwhaviour in a cucumber scenario, I uncovered a requirement to leave Rails for a bit and implement a set of SQL triggers. This would have been discovered at some point anyway, but I rather suspect that without BDD the implementation would have been written first in Ruby for ActiveRecord only to be discarded sometime later when the need for a trigger became manifest. Peepcode is good, I have watched and learned lots there. Just recall that the episodes go far back in time insofar as Rails and RSpec are concerned. These two products have undergone extensive change since many of the episodes were recorded. Thanks for sharing James. I know when you first joined the list there were a few frustrating moments, and it's really good to hear about where you've come and how you've gotten there. This is helpful to both newbs and seasoned BDDers alike, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec makes me want to write better code
On Tue, Mar 31, 2009 at 1:10 PM, Zach Dennis zach.den...@gmail.com wrote: On Tue, Mar 31, 2009 at 5:39 AM, Fernando Perez li...@ruby-forum.com wrote: Fernando Perez wrote: Hi, Today is a big day. I officially transitioned from manually testing by clicking around in my app, to automated testing with RSpec + Autotest. 6 months since my initial post, what happened in between? - My controllers are getting anorexic, and that's good. An action typically does only 1 call to a model and behind the scenes that model will make other calls to other models and do some fancy stuff, this used to happen in the controller which was bad. Now it has become so easy to write model specs. Great! Keeping controllers simple makes life better on many fronts. - I don't spec controllers, because it's too painful to do. I don't spec views either, because I tweak them too often, and it would take me more time rewriting view specs then actually coding the views. If there is something to test for is the rendering of the css across browsers, because that's terrible! I usually let Cucumber run through the basics of the action, but I write controller specs for interesting thing that affect the behaviour of an action such as requiring logic, or a certain permission, or special error handling logic, etc. Pulling these things out into a controller macro makes re-using them extremely simple. The next beta release for The RSpec Book will cover doing that. I write view specs because they *change* so much. I don't spec the structure of the page, just the semantics of it as it pertains to information I programmatically display or don't display. IME, when apps are small there is a feeling that Cucumber can do it all, but as the app grows Cucumber can be a burden as well. Cucumber scenarios can't do it all, and when you have interesting apps, hundreds of scenarios and hundreds of steps it becomes way too time consuming to try to find exactly what and why things died and why. I prefer focused view specs for this regression rather than simply relying on Cucumber. Also cucumber step definitions can become large and unwieldy. I like focused steps which do enough to prove a scenario works as expected and I like to drop down to specs for the details of it. - I use cucumber+webrat to test that some important public pages render without a 500 error. I don't care if the view has such div except if it is a critical one. What I mean is that I won't test, all the assignments that should be on the page, as some tutorials demonstrate. This is nearly impossible to maintain. I disagree with the last two sentences here. I build my views spec first with examples that expect the result of project.name to be on the page. Only then do I actually add it to the view. I have had no issue maintaining this. Not only do I get a design benefit when its not just a simple model attribute, but perhaps a calculated field, I also get regression for free. I move swiftly, happily, and confidently on without worrying about manually verifying everything on the page is as it should be, I let my specs do that. - I can refactor my code, immediately spot areas where my code got broken, and fix it. Before some parts of my app would be broken without having me knowing about it for a long time until some cool customers report a few bugs, but this was not an acceptable situation. IMO, this is the case when people don't write view specs. Unless someone's Cucumber scenario covers everything on the view (which they don't unless its a super simple CRUD app). Half the time I wonder if people even know if their views are displaying the write things on the page over time. How would they not know w/o specs? Do they manually verify every page every time they deploy? That seems impossible to maintain. - I don't use Autotest, it sucks too much power, and it is too much distracting. From time to time I run specs to check if things look good, and always before updating the code on the server. Agreed. I loathe autotest, but I don't run specs time to time, I run my specs all the time. It's a part of my development process. Red Green Refactor. It's not just a mantra, its a discipline. Although when I don't know what I want or need to do, I spike something (without any tests), and once I figure it out I scrape the spike (or comment it out) and drive it with examples. - I have written my own Factory. It's not OOP, it could be refactored, but it works 100% as advertised, provides default values, can handle associations, etc. I am pleased with it (I tried factory girl, machinist, etc and got pissed off). I encourage anyone to write his own little factory, to get a better hang of how to write good specs. I totally got mad with fixtures, it is impossible to maintain specs/tests with fixtures. Impossible. Cool. Is it on github? I wrote my own as well, but then switched to FactoryGirl because everyone I talked to loved
Re: [rspec-users] [Rails] specifying that a layout yields?
On Sat, Mar 28, 2009 at 9:33 PM, Brandt Kurowski brandtkurow...@gmail.com wrote: I recently had a bug in a layout due to the layout not calling yield to display the actual content. I wanted to write a spec to describe what was missing, but it wasn't obvious how, so I just fixed the problem first and doubled back to spec it later. Anyway, the most succinct thing I was able to come up with was the following: # http://gist.github.com/87246 describe /layouts/application do it should show the content do class template attr_accessor :did_render_content end template.did_render_content = false render :inline = % self.did_render_content = true %, :layout = 'application' template.did_render_content.should be_true end end But I'm not quite satisfied with this, as it's not as clear and expressive as specs usually are. I thought I'd write a custom matcher for it, but it's not obvious to me what I'd even want the spec to look like. Any ideas? There's no need for a custom matcher. You just utilize the :layout option that render has. e.g. the follow example ensures the layout renders the content it is given (via a yield block): describe layouts/application.html.erb do it should render the context given do render :text = foobar, :layout = layouts/application.html.erb response.should include_text(foobar) end end Thanks, Brandt ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Cucumber step definitions vs. RSpec examples
On Sat, Mar 28, 2009 at 9:49 AM, Brandon Olivares programmer2...@gmail.com wrote: Hi, So, I'm confused. I've been trying to use Cucumber and RSpec, but step definitions and RSpec examples just seem to be overlapping. What should go in either one of these? Cucumber is intended to drive out the behaviour of the application and RSpec is used to drive out the design and behaviour for the components and objects that make up that application. Cucumber and RSpec are bound to overlap. They're providing you insights at different levels about how the application is expected to be working. For instance, let's say I'm testing if a form exists on a page. What goes in Cucumber and what goes in RSpec? Does the scenario successfully drive the implementation of the form and the page its on? If so, I would probably stick with the scenario. However, if it doesn't then I drop down to a view spec and spec whatever else the page needs that the scenario doesn't cover. Scenarios usually don't communicate well the expectations against a page for showing and hiding information, etc based on permissions or roles. RSpec works great for this. It provides a wonderful way to simply and concisely make each of those expectations clear rather than some strange side-effect of a scenario which is focused on something else. What I did for now is put Webrat methods in the step definitions, like fill_in, select, etc, without submitting since I'm not testing processing yet; and then put selector matchers in the RSpec examples. But I have no idea if that's right. How do you separate these and keep them from duplicating one another? At some level duplication will happen, especially in a web app since the way you verify the application is working is by POSTing/GETting/etc and verifying output on the page itself AND it's also what you have to do when you creating the individual views and the controllers that make up those pages and respond to those requests. You may find that a scenario drives you to make a view with a form and a controller with a #create action to process it. This may be adequate and you may be able to confidently move forward without writing a view spec or a controller spec. I know I have found this it the case many times. On the flip side, when something additional or conditional occurs that is usually a good time to drive that with an example in a spec. I use my scenarios to drive my app from the outside, and then specs to drive the implementation for each of the underlying pieces. The more I've practiced the easier and more natural it has become to know when to do or not to do something. Also, the only way to not have something feel like it's taking too long is to know your tools. These things won't just come because you want it to. It takes practice. Remember to practice. http://www.vimeo.com/3756344 -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Cucumber step definitions vs. RSpec examples
On Sun, Mar 29, 2009 at 3:47 PM, Stephen Eley sfe...@gmail.com wrote: On Sat, Mar 28, 2009 at 9:49 AM, Brandon Olivares programmer2...@gmail.com wrote: So, I'm confused. I've been trying to use Cucumber and RSpec, but step definitions and RSpec examples just seem to be overlapping. What should go in either one of these? This is a subjective judgment call that doesn't have an absolute 'right' answer. Ask a dozen programmers how they test and you're likely to get at least three dozen answers. I believe the purists would say that the duplication is a feature. The gist of this point of view is that RSpec's main strength is on the unit testing level: you want to test that model code works separate from your controller code, and your controller code separate from your view code. Then if one fails, you know exactly what class went wrong and what to fix. Cucumber's main strength is on the acceptance or integration level: you want to make sure it all comes together correctly and creates the right application behavior, which is very hard to prove with unit testing alone. But if you _only_ did Cucumber tests, your test to see if a form exists on a page (to use your example) would be too broad. If it failed, where do you look first? Is the view broken? The controller code? Do you even have a model for the view to operate on? Etc. So you need to have bot levels. You specify your overall behavior with Cucumber, then you specify the isolated behaviors of the pieces to make that work, and then you write your code. That's the full-round-trip, complete by-the-RSpec-book BDD answer. My own view... Well, my view is that I've tried that and been driven nuts by it. Writing specs for controllers and views can take me many times longer than writing the code. Mocking out the models for controllers is frustrating and fragile to me, and view specs are just obvious and tedious. I don't have any _fun_ writing those specs. And if I'm not having fun, I find myself not motivated to program. So I stopped writing those specs, and now I mostly just write model specs and Cucumber features. It usually doesn't take that long for me to look at a failing Cucumber test and figure out what went wrong -- from the failure text, a stacktrace, or sometimes just manually running the action and eyeballing it. Sometimes, if the controller action is unusual, I will write a spec for it, but only if my own instincts tell me it's warranted. (Or if something failed in an odd way and I want to make sure that doesn't happen again.) That's my current answer based on past experience. Next month I might have a different way of doing things. I'm not going to make the case here that I'm right and you should never write controller/view specs for ordinary actions. (If nothing else, doing it a bunch of times -- and getting some things wrong, then fixing them -- is a great way to learn how controllers and views really work.) I think the real answer is to try it a few different ways, decide what works within your comfort level *and* leads to good code, and let yourself experiment. And then, if you develop an effective working pattern down the road that you think makes good general sense, share it with the community as one more way of doing things. 8- I like a lot of what Steve is saying. To summarize and communicate in my own way... It is good to know how and when to do something. Like writing view specs and controller specs. If you don't know how then you'll never know when. Sometimes learning to take small steps seems ridiculous, but it's by being able to work in small steps that you can be confident about making larger ones. Here are three questions I ask myself when I get frustrated: 1 - Am I doing it wrong? 2 - Should I be doing this in the first place? 3 - Am I experiencing a skills deficiency? Usually I think it's #1 and then I quickly jump to #2 when I don't get it resolved in 5 minutes of googling. And then I find out a day later it was because of #3 and I needed to go home and practice a little more so I better understood what I was doing, why I was doing it, and how I could leverage the tools to make it easier. We all learn to make good decisions by first making bad ones, and practice lets us do that w/o putting giant turds in an application's production codebase. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [Cucumber] ANN: Cucumber with pure Java
2009/3/25 Ben Mabey b...@benmabey.com: On Mar 25, 2009, at 9:08 AM, aslak hellesoy wrote: Big news for all Java programmers out there. Now you can use Cucumber with pure Java! That's right, you don't have to write a single line of Ruby! (1) All of your step definitions can be written as annotated methods in POJOs (Plain Old Java Objects). To get a taste of what this looks like, check out the simple example in the cucumber_java project on GitHub: * README for example: http://github.com/aslakhellesoy/cucumber_java/tree/271160300da5bc9275dd67624f711c5ea6913187/examples/simple * Some sample step defs: http://github.com/aslakhellesoy/cucumber_java/blob/271160300da5bc9275dd67624f711c5ea6913187/examples/simple/src/main/java/simple/StuffSteps.java * The main page: http://github.com/aslakhellesoy/cucumber_java/tree/master By this I hope Cucumber will reach a bigger crowd. Much bigger crowd actually :-) - this will work for Scala, Clojure, Jython and all the other cool JVM languages too. (I'll be doing something similar for .NET, which will bring Cucumber goodness to C#, F# and whatever languages run on .NET. But IronRuby must catch up on speed first). I had the pleasure of going back to visit PicoContainer - a pioneering lightweight dependency injection container I developed with Paul Hammant back in 2003. It's still lightweight and a joy to use (relatively speaking - Java in itself isn't joyful). Cucumber-java uses PicoContainer to instantiate the POJOs that define the annotated step definition methods, so if you're so inclined, these classes can depend on each other via constructor DI, and PicoContainer just figures out how to instantiate the objects). So if you're working on a Java project, have been looking at Cucumber but stayed away because of all the weird Ruby, this is your chance. Here is a cuke for Duke! (::) Aslak (::) (1) You still need a tiny bit of Ruby to register step definitions: http://github.com/aslakhellesoy/cucumber_java/blob/271160300da5bc9275dd67624f711c5ea6913187/examples/simple/features/support/env.rb (This will hopefully go away in the future, with some better Ant and Maven support). Very cool stuff. It would be an interesting and informative exercise to take a JBehave tutorial and use Cucumber to drive out the same feature and then have a side-by-side comparison of the required step definitions. found this JBehave tutorial which would make a good candidate for such a comparison: http://www.ryangreenhall.com/articles/bdd-by-example.html If someone doesn't get around to this in the next couple of weeks I may take a stab at it and make a blog post of it. I'm assuming you mean w/Java, but I'd like to encourage folks who are learning BDD to walk through his example even with Ruby. I did that tonight and it was quite pleasant. The tutorial is small and focused, and it can be completed in not much time. However, the tutorial does leave out some implementation that you would need in order to actually complete it, but I find those sorts of things fun to figure out. Translating Ryan's tutorial to Ruby allows you to explore writing rspec simple matchers (or full fledged matchers) if you want to go that route, and overall I found it fun to go through it and practice my own skills. I know it's not the comparison Ben and Aslak are talking about, but for those of you who are looking for a good little tutorial to walk through and practice with, this one is pretty good if you are somewhat familiar with Cucumber, RSpec, and Ruby, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Cucumber and matcher
On Wed, Mar 25, 2009 at 7:18 PM, Emmanuel Pinault seatm...@gmail.com wrote: Hi, Is there way to generate a better error messages when I have a matcher in my step like 1.should == 0 = would fail with expected 1, got 0 I would like to add more details to that error? Especially , in my case ,I am using the include? matcher. Check out rolling your own simple matcher: http://apidock.com/rspec/Spec/Matchers/simple_matcher It can be done in only a few lines! Thanks Emmanuel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Expecting a block to return a specific value
2009/3/21 Guilherme Machado Cirne gci...@gmail.com: Hi, I have the following method in a Rails view helper: def title content_for(:title) do # some code which generates a title dynamically end end How can I spec that the code inside the block returns the correct title? My preference is to let my view helpers be rendered in my view specs, and I move the logic that constructs the title onto a presenter. Then I can say things like this in my view spec: it should render the title do thing = mock thing presenter, :title = foo assign[:thing] = thing render some.template response.should contain(foo) end And I can have a presenter spec which verifies the title is built correctly describe ThingPresenter do describe '#title' do it should return a concatenated title, user name, blah blah blah do # end end end There are more ways to accomplish this I know, but I've grown to become extremely fond of the clean separation between constructing markup and producing presentation content. It makes things easier to spec IMO, gives things a good home, and allows me to stop looking at content for instance variables dynamically generated by Rails. If interested... http://wiki.github.com/mhs/caching_presenter -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Mocking base class methods
2009/3/20 Jeroen van Dijk jeroentjevand...@gmail.com:
Huray, got it solved! Hopefully you'll agree with this solution (thanks to
mocha sorry)
describe count_by_params do
it should pass all the params and options to #scope_by_params do
params = { :foo = 1, :bar = 2 }
options = { :foo = 3, :bar = 4 }
@base = ActiveRecord::Base
@result = mock(query results, :count = 1)
@base.expects(:scoped_by_params).with(params,
options).returns(@result)
@base.count_by_params(params, options)
end
Is #scoped_by_params a public method that has its own examples? Down
at the model level I would want to know that count_by_params actually
was working as expected and not just collaborating with itself to call
an internal method. I don't know how crazy scoped_by_params is so
maybe there is a potential risk you're willing to accept given the
complexity of what it does, but this example raises my eyebrow as to
the behaviour your actually expecting and verifying.
On Thu, Mar 19, 2009 at 5:35 PM, Jeroen van Dijk
jeroentjevand...@gmail.com wrote:
Hi all,
I'm having the same problem as Tobi and I wanted to try Tobi mock solution
but unfortunately it does not work for me.
Here is a trivial example I want to test:
module ActiveRecord
class Base
def self.count_by_params(params = {}, options = {})
scoped_by_params(params).count
end
end
end
And my spec:
module ActiveRecord
class Base
include BaseClassMock
end
end
class DummyUser ActiveRecord::Base
end
it should pass all the params and options to #scope_by_params do
params = { :foo = 1, :bar = 2 }
options = { :foo = 3, :bar = 4 }
@dummy = DummyUser
@dummy.base_class.should_receive(:scope_by_params).with(params,
options)
DummyUser.count_by_params(params, options)
end
With the above example and Tobi's BaseClassMock module I'm getting
undefined method `should_receive' for #Object:0x188c164. Btw, I also get
this when I do not use Tobi be it for for #Class:0x188cdf8 instead of
Object.
Any suggestions on what I'm doing wrong or a different approach?
Cheers,
Jeroen
On Sat, Feb 21, 2009 at 10:24 PM, Tobi listacco...@e-tobi.net wrote:
Zach Dennis wrote:
+1 to composition over inheritance here. Mocking at different layers
of an inheritance hierarchy sounds like trouble and screams to pull
that thing apart.
Good point! I've already tried the composition approach. It solves the
testabilitiy problems, but it doesn't feel right in this case.
Inheritance seems to be the more natural approach. The C++ application
will call virtual methods on the base class which should be overriden in
a
derived class. So it seems to make sense to have the same inheritance
tree
in the Ruby counter parts.
If I would use composition, I would at least need to dynamically extend
the referenced base class so I can override some of the methods that are
the counter parts of the virtual C++ methods. And I would need to expose
the referenced class to the C++ code.
I've finally found a way to kinda mock the base class in some way:
module BaseClassMock
attr_accessor :base
def self.included(klass)
class klass
@@base_class = Object.new
def base_class
return @@base_class
end
end
end
def initialize(*args)
@@base_class.new(*args) if @@base_class.respond_to?(:new)
�...@base = Object.new
end
def method_missing(symbol, *args)
�...@base.send(symbol, *args)
end
end
Any base class (Swig classes in my case) should then be declared for
RSpec
like:
module Swig
class Base; include BaseClassMock; end
end
And in the specs I can then do:
Derived.base_class.should_receive(:new).with('something')
d = Derived.new('something')
or:
d = Derived.new
d.base.should_receive(:do_something)
d.do_something
Tobias
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problem spec'ing ActionMailer with attachment, body not getting rendered.
2009/3/18 Rick DeNatale rick.denat...@gmail.com: I've got a simple ActionMailer::Base subclass: class InfoMailer ActionMailer::Base def info(user, zip_name) recipients user.email subject Requested Info attachment(:content_type = application/zip, :filename = zip_name, :body = File.read(zip_name)) body(:message = Here is the Info that you Requested) end end I'm trying to spec this following http://www.rubytutorials.net/2008/02/26/small-rspec-revelations-actionmailer/ describe AssetsInfoMailer do before(:each) do �...@user = mock_model(User, :email = @user_email = somewh...@over.the.rainbow, :full_name = The Wicked Witch of the West ) ActionMailer::Base.delivery_method = :test ActionMailer::Base.perform_deliveries = true ActionMailer::Base.deliveries = [] end describe .info do before(:each) do �...@path = 'xyz.zip' �...@attachment_body = 'zip_file_contents' File.stub!(:read).and_return(@attachment_body) �...@the_mail = AssetsInfoMailer.deliver_info(@user,@path) �...@attachments = @the_mail.attachments end it should have the right body do �...@the_mail.body.should == end end The expectation of an empty string is just to see what's actually getting returned, the result is: 1) 'AssetsInfoMailer.info should have the right body' FAILED expected: , got: Attachment: xyz.zip\n (using ==) It's looking like the mail template never got rendered, and body is giving me the attachment since it's the only part. I've got one other mailer method in that mailer which doesn't contain an attachement, and it's body comes out fine. I'm not sure what's going on here, and I'd appreciate any help/insight/condolences... When sending attachments emails are sent as multipart messages. The only part being specified is the attachment. The other call to body is being ignored. Try something like: def info(user, zip_name) recipients user.email subject Requested Info attachment(:content_type = application/zip, :filename = zip_name, :body = File.read(zip_name)) part text/plain do |p| p.body(:message = Here is the Info that you Requested) end end Also when you look at the email you'll have look at its #parts otherwise @the_mail.body is going to returned the body representation of each part concatenated. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problem spec'ing ActionMailer with attachment, body not getting rendered.
On Fri, Mar 20, 2009 at 11:11 AM, Zach Dennis zach.den...@gmail.com wrote: 2009/3/18 Rick DeNatale rick.denat...@gmail.com: I've got a simple ActionMailer::Base subclass: class InfoMailer ActionMailer::Base def info(user, zip_name) recipients user.email subject Requested Info attachment(:content_type = application/zip, :filename = zip_name, :body = File.read(zip_name)) body(:message = Here is the Info that you Requested) end end I'm trying to spec this following http://www.rubytutorials.net/2008/02/26/small-rspec-revelations-actionmailer/ describe AssetsInfoMailer do before(:each) do �...@user = mock_model(User, :email = @user_email = somewh...@over.the.rainbow, :full_name = The Wicked Witch of the West ) ActionMailer::Base.delivery_method = :test ActionMailer::Base.perform_deliveries = true ActionMailer::Base.deliveries = [] end describe .info do before(:each) do �...@path = 'xyz.zip' �...@attachment_body = 'zip_file_contents' File.stub!(:read).and_return(@attachment_body) �...@the_mail = AssetsInfoMailer.deliver_info(@user,@path) �...@attachments = @the_mail.attachments end it should have the right body do �...@the_mail.body.should == end end The expectation of an empty string is just to see what's actually getting returned, the result is: 1) 'AssetsInfoMailer.info should have the right body' FAILED expected: , got: Attachment: xyz.zip\n (using ==) It's looking like the mail template never got rendered, and body is giving me the attachment since it's the only part. I've got one other mailer method in that mailer which doesn't contain an attachement, and it's body comes out fine. I'm not sure what's going on here, and I'd appreciate any help/insight/condolences... When sending attachments emails are sent as multipart messages. The only part being specified is the attachment. The other call to body is being ignored. Try something like: def info(user, zip_name) recipients user.email subject Requested Info attachment(:content_type = application/zip, :filename = zip_name, :body = File.read(zip_name)) part text/plain do |p| p.body(:message = Here is the Info that you Requested) end end I just tried my out, and while it does work because there are multiple parts specified, also re-ordering of the initial #body to come before the attachment doesn't seem to help with the original code either. I'm curious now what you do find out and which route you decide to go, keep us posted either way Rick. Also when you look at the email you'll have look at its #parts otherwise @the_mail.body is going to returned the body representation of each part concatenated. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] what's the meaning of to_param?
On Thu, Mar 19, 2009 at 8:46 AM, Zhenning Guan li...@ruby-forum.com wrote: usually, I just use this way. = @weather = mock_model(Weather) = but recently I saw this. so what's the :to_param and :save options meaning? == @weather = mock_model(Weather, :to_param = 1, :save = true) == http://www.railsbrain.com/api/rails-2.2.2/doc/index.html?a=M001952name=to_param It's a Rails thing, used when converting an object to a URL representation. -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] what's the meaning of to_param?
On Thu, Mar 19, 2009 at 9:15 AM, Zach Dennis zach.den...@gmail.com wrote: On Thu, Mar 19, 2009 at 8:46 AM, Zhenning Guan li...@ruby-forum.com wrote: usually, I just use this way. = @weather = mock_model(Weather) = but recently I saw this. so what's the :to_param and :save options meaning? == @weather = mock_model(Weather, :to_param = 1, :save = true) == http://www.railsbrain.com/api/rails-2.2.2/doc/index.html?a=M001952name=to_param It's a Rails thing, used when converting an object to a URL representation. Oops, sorry, I misread your question. mock_model will provide you with #to_param so the only thing I can think w/o knowing more is if whoever wrote the spec wanted to specifically expect, look for, or somehow use the 1 that came from to_param. They wanted to know that specific the result of @weater.to_param was being used (which will be used be number of Rails helpers). My best guess on the save call is that the implementation is going to call save, and the author of the spec by default wants it to be successful for any subsequent examples. -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Basic help
On Thu, Mar 19, 2009 at 5:28 AM, jazzez ravi li...@ruby-forum.com wrote:
Hi All,
1. Just now I installed rspec1.2.0 and dependencies
2. Tried the 2 programs mentioned in http://rspec.info/.
# bowling_spec.rb
require 'bowling'
describe Bowling do
before(:each) do
�...@bowling = Bowling.new
end
it should score 0 for gutter game do
20.times { @bowling.hit(0) }
�...@bowling.score.should == 0
end
end
# bowling.rb
class Bowling
def hit(pins)
end
def score
0
end
end
3. Run the bowling_spec.rb file
ruby bowling_spec.rb --format specdoc
4. getting error like
bowling_spec.rb:6: undefined method `describe' for main:Object
(NoMethodError)
5. So i tried to add these lines,
require 'rspec' -- no Such file to Load
require 'spec' -- No Error But also no output mentioned as per that
website.
Please anyone help to continue that program.
Try to put this at the top:
require 'rubygems'
require 'spec'
I have an environment variable set to always load rubygems on my
system so I can omit the require of it explicitly in code:
RUBYOPTS=-rubygems
Regards,
P.Raveendran
http://raveendran.wordpress.com
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [rspec] Stubbing partials in view specs
On Wed, Mar 18, 2009 at 4:35 PM, Nick Hoffman n...@deadorange.com wrote:
Hey there Evgeny. My response is inline.
I call a partial inside another partial.
_mother.haml contains:
render :partial = children/child
In mother_spec.rb file I am trying to stub the render call.
Here is a working version:
=
template.should_receive(:render)
template.stub!(:render)
render :partial = 'mother'
If you set a method expectation on an object (IE:
template.should_receive(:render) ), you don't need to stub the method
(IE: template.stub!(:render) isn't needed).
I would prefer to specify that the partial I am stubbing is children/
child,
however the following code doesn't work for me:
===
template.stub!(:render).with(hash_including(:partial = 'children/
child'))
template.expect_render(:partial = 'children/child')
render :partial = 'mother'
: Mock 'render_proxy' expected :render with ({:partial=children/
child}) once, but received it 0 times
===
Is it possible to stub the render call with specific partial name?
What I said above about method expectations and method stubs also
applies here. You should remove the call to #stub! .
However, I'd be inclined to use #should_receive rather than #expect_render :
template.should_receive(:render).with :partial = 'children/child'
render :partial = 'mother'
I haven't written many view specs though, so maybe we're supposed to
use #expect_render .
#expect_render is deprecated prior to 1.2 and it has been removed 1.2.
You don't want to use that. :)
I hope that helps. Cheers,
Nick
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [rspec] Stubbing partials in view specs
On Wed, Mar 18, 2009 at 6:18 AM, Evgeny Bogdanov
evgeny.bogda...@gmail.com wrote:
Hello,
I have a problem similar to one mentioned in this post.
I call a partial inside another partial.
_mother.haml contains:
render :partial = children/child
In mother_spec.rb file I am trying to stub the render call.
Here is a working version:
=
template.should_receive(:render)
template.stub!(:render)
render :partial = 'mother'
I would prefer to specify that the partial I am stubbing is children/
child,
however the following code doesn't work for me:
===
template.stub!(:render).with(hash_including(:partial = 'children/
child'))
template.expect_render(:partial = 'children/child')
What version of rspec are you using? #expect_render has been removed
in rspec 1.2 and has been deprecated for a while before that so you
won't want to rely on that unless you're using an old version of
rspec.
render :partial = 'mother'
: Mock 'render_proxy' expected :render with ({:partial=children/
child}) once, but received it 0 times
===
Is it possible to stub the render call with specific partial name?
You had it right, hash including should work:
template.stub!(:render).with(hash_including(:partial = children/child))
To stub all partials being rendered:
template.stub!(:render).with(hash_including(:partial = anything))
HTH,
Thank you in advance,
Evgeny
On Jan 20, 5:35 pm, Bart Zonneveld zuperinfin...@gmail.com wrote:
On 20-jan-2009, at 15:29, David Chelimsky wrote:
On Tue, Jan 20, 2009 at 7:44 AM, Bart Zonneveld
zuperinfin...@gmail.com wrote:
Hey list,
As a good BDDer I want to test my views in isolation.
Sort of. A *good* BDDer wants to *specify* views in isolation. Testing
is for testers :)
You're right! I tend to talk a lot to non-programmers, and they get
that glaze-in-the-distance look in their eyes, whenever I mention
specifiy, spec'ing, or what have you :).
And as a good rails
programmer, I separate views into partials when needed. So, when
testing my
views, I want tostubout rendering of partials in my views. I'm
working on
upgrading an app from rails 2.1.2 to 2.2.2, using the latest rspec
and
rspec-rails.
I used to throw template.stub!(:render) in a before(:each) block
and be done
with it
That sounds kinda risky because you could be ignoring partials that
get rendered that you don't want to be rendered.
It is, most definately.
, but that doesn't work anymore. I can understand why, but now I have
to do something like template.stub!(:render).with(hash_including
(:partial =
anything)). Except for when I'm testing a partial, then I need to
replace
the anything with every partial I'm rendering in my partial.
Is this the correct way,
Seems like the only way at the moment. Wouldn't call it correct or
incorrect.
I would call it ugly :). Not only do I have to remember the
hash_including part, but also the anything (and not :anything).
Conceptually, I like the template.stub!(:render). Irendera
template, on which Istuball the renders. Whether that's risky or
not is a different discussion.
or is there perhaps something like
template.stub_partials :only = [], :except = [] ?
Nothing like this exists. Seems like a reasonable idea. Feel free to
submit a feature request, or better yet, a patch to
http://rspec.lighthouseapp.com
Will do!
cheers,
bartz
___
rspec-users mailing list
rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Run rake spec with a halt-on-errors mode?
On Thu, Mar 12, 2009 at 3:38 AM, Anton analytics.goo...@allproducts.info wrote: Hello everybody! I am using rspec for quite a time now, and it is really a great tool! The only thing that I haven't figured out is how to set the spec runner to a halt-on-error mode. For example a lot of browser tests depend on Google maps and if I have no internet connection none of them makes sense. Some other errors are unwanted test dependencies - and I don't want to analyze hundrets of test or run them manually just to check what is wrong. Why not filter these specs that go to Google Maps, so you have to run them explicitly, or only when your CI server runs? We usually have a few specs and scenarios that test real-world integration, and then we stub out the external dependencies in our object-level specs. And we've added a couple rake tasks to run all of them, just one, or just the other, and then a CI rake task that runs all of them. So it would be great if I could tell the spec runner to stop on the first error in such cases. Would be a big time saver for me if someone could give me a hint... Thank you very much in advance, Anton ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [cucumber] open source projects with cucumber features
On Wed, Mar 11, 2009 at 3:03 PM, Balint Erdi li...@ruby-forum.com wrote: Hi, I was looking for some real-world cucumber features (mainly on github) to see how more complex features are built but I have not really found any. Could you point me to some? For seeing different ways to utilize scenarios and step definitions I would look at Cucumber and RSpec. They both have feature files and have good examples of different ways to utilize scenarios and step definitions: http://github.com/aslakhellesoy/cucumber http://github.com/dchelimsky/rspec -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] rspec and prawn
On Mon, Mar 9, 2009 at 11:02 PM, aa aa li...@ruby-forum.com wrote: Hi, I've just started using prawn but am at a bit of a loss how to create my view specs for it. For example, my normal view spec has things like response.should have_tag(blah) or response.body.should =~ /something/ How do I do this with prawn output? Short answer, you can't--at least not yet. PDF is not a plain text markup language like HTML so its not a problem so easily solved. I haven't spec'd a PDF, but when looking into it at one point I came across PDF Reader. http://github.com/yob/pdf-wrapper/tree Perhaps that will help you find a starting place. -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] rspec and prawn
On Tue, Mar 10, 2009 at 8:43 AM, Zach Dennis zach.den...@gmail.com wrote: On Mon, Mar 9, 2009 at 11:02 PM, aa aa li...@ruby-forum.com wrote: Hi, I've just started using prawn but am at a bit of a loss how to create my view specs for it. For example, my normal view spec has things like response.should have_tag(blah) or response.body.should =~ /something/ How do I do this with prawn output? Short answer, you can't--at least not yet. PDF is not a plain text markup language like HTML so its not a problem so easily solved. I haven't spec'd a PDF, but when looking into it at one point I came across PDF Reader. http://github.com/yob/pdf-wrapper/tree Oops wrong URL: http://github.com/yob/pdf-reader/tree Perhaps that will help you find a starting place. -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Testing for the number of occurrences of a word
On Tue, Mar 10, 2009 at 8:16 AM, Bart Zonneveld zuperinfin...@gmail.com wrote: Hey list, Quick question: How can I check that a given word appears a number of times on a page? The page in question includes some XML, rendered with lts and gts and I want to test that a given node exists 10 times on that page. You want to make sure you have 10 nodes? Or that text shows up 10 times inside of any node? You can utilize Webrat's #have_selector to count the nodes, ie: response.should have_selector(li, :count = 3) thanks! bartz ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] stubbing before filters
Can folks who write controller specs and deal with before filters read and comment on this ticket: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/724-stub_before_filters#ticket-724-2 I'm on the fence and would like others thoughts on the matter, Thanks -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Presentation Testing and CSS ids
On Mon, Mar 9, 2009 at 12:08 PM, James Byrne li...@ruby-forum.com wrote: Zach Dennis wrote: In my experience relying on the syntactic details of the page is extremely brittle and cumbersome. ... Some tags have both syntactic and semantic meaning, such as forms, labels, fieldsets, and anchor tags. Is it brittle to test for specific css selectors that are tied to page details? I think it depends on what details you're tying them to. :) A typical case is where one has a button to drive in webrat and instead of using the button text we use the associated id value instead. Does the id have meaning? Or is it something that communicates nothing about what it is? ie: click_button add_new_item vs. click_button foobar -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] response.body.should be_xml_with -- how to do nested xpath matches
Information) ]' and xpath :'label[ contains(., First name) ]' and xpath :input, :type = 'text', :name = 'user[first_name]' end end } end end ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] response.body.should be_xml_with -- how to do nested xpath matches
On Sun, Mar 8, 2009 at 2:41 PM, Phlip phlip2...@gmail.com wrote:
David Chelimsky wrote:
xpath :'legend[ contains(., Personal Information) ]' and
xpath :'label[ contains(., First name) ]' and
xpath :input, :type = 'text', :name = 'user[first_name]'
This is nice, but the abstractions are operating at different levels.
The keyword is xpath but the args passed to that look nothing like
xpath.
That's because it's a DSL. You can use raw XPath, XPath with one convenience
(:'div[ @class = content ]' as a symbol implies any descendant), or you
can use an option hash that generates XPath.
The DSL's benefit is tags like :attribute = foo will automatically escape
their strings correctly. (That's why the top line of the diagnostic was a
little cluttered!) foo could contain mixed ' and payload, and we don't
care.
How about something like:
response.body.should be_xml_with do
form :action = '/users' do
fieldset do
legend Personal Information
label First name
Because I'm not webrat?
Yes it would be kewt if label('yo') went into method_missing and came out as
//label[ contains(., yo) ]. But I have found that spot checks of
algorithmic details, such as eRB tags, are more valuable to development than
slavishly matching your tests to your HTML contents.
If you write this HTML...
form blah
input blah
input blah
input blah
/form
...and if you test it with a sequence of assertions that exactly match it...
page.should contain
form blah
input blah
input blah
input blah
end
end
...then you are not really doing TDD. You are merely replicating your code
as your test, and that will only cause irritation at upgrade time or bug
time.
This doesn't make a whole lot sense. How does the following move you
from TDD to non-TDD?
xpath :input, :name = foo
to
input :name = foo
XPath is merely the mechanism in which you're allowed to find
particular elements on a page. After typing:
xpath :input, :name = foo
xpath :input, :name = bar
xpath :input, :name = baz
I would probably write my own wrapper so I could omit the redundant
xpath call all over the place. After all, I only care that the input
is found, if it uses XPath to do it--awesome.
Here's an example from our projects at work:
get :thanks_for_purchasing
assert_xpath :'center[ . = Your order has been accepted! ]'
assert_xpath :div, :align = :center do
a = assert_xpath(:'p[ contains(., questions about your membership)
]/a')
assert{ a.text == a[:href] }
assert{ a[:href] == SubscriptionController::CUSTOMER_SERVICE_LINK }
end
Note how much that specifies in the customer acknowledgment page.
- the confirmation is centered
- the explanation div is centered (yes, we could identify it better!)
- part of the explanation div's contents contains questions...
- next to the questions... is an a
- the a contains an href matching its own text contents
- the href links to our customer service system
In my experience relying on the syntactic details of the page is
extremely brittle and cumbersome. Writing semantic HTML and semantic
view specs (whether you use rspec or assert2.0 or whatever) seems to
remove unnecessary overhead, such as caring about a div or a p tag
on the page. Some tags have both syntactic and semantic meaning, such
as forms, labels, fieldsets, and anchor tags.
Given your above assertions, if you replaced your center tag (which
is deprecated in HTML 4.01) with a div, and made it centered via CSS,
your assertion would fail. But should it? The presentation is changing
without affecting the behaviour of the view--it's still displaying the
Your order has been accepted confirmation. Why not utilize semantic
HTML to not be affected by a syntactic details that doesn't affect
whether or not your view is doing the right thing.
I'd apply the same considerations to the div and the p tags you're
making assertions against.
I call this topic XPath can see around corners:
http://www.oreillynet.com/onlamp/blog/2007/08/xpath_checker_and_assert_xpath.html
We are using XPath to pin down several elements in a page, allowing the
other elements to change freely, but forcing them to maintain their
correlations. That test would fail, for example, if the a somehow moved
away from its introductory paragraph.
Are these correlations best managed by specs? Our customers and
designers move things around on the page all of the time without
affecting behaviour, merely presentation, and having those changes
break all of the view specs is painful. It also seems unnecessary if
they move from a series of div tags to a ul with li elements.
--
Phlip
http://www.zeroplayer.com/
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http
Re: [rspec-users] Can I construct the controller myself in a controller spec?
On Fri, Mar 6, 2009 at 3:05 AM, Matt Wynne m...@mattwynne.net wrote:
On 5 Mar 2009, at 15:24, Ben Mabey wrote:
David Chelimsky wrote:
On Thu, Mar 5, 2009 at 3:31 AM, Matt Wynne m...@mattwynne.net wrote:
Maybe we should make this easier by providing some facility in the
mock framework to express the following in one statement:
@authenticator = stub('authenticator')
Authenticator.stub!(:new).and_return(@authenticator)
Sure, you could make that a one liner:
Authenticator.stub!(:new).and_return(@authenticator =
stub('authenticator')
But I mean something like:
@authenticator = Authenticator.stub!
I don't think *that* is the answer - but something that concise would be
nice.
Thoughts?
David
I like the conciseness, but it isn't very clear what it is doing IMO.
Perhaps something a little more intention-revealing like:
@authenticator = Authenticator.stub_new!
I think I must mostly use constructor injection, as I don't really seem to
have a pattern for this, but if I did I guess it would be something like
this:
extend StubbingHelpers
describe blah
before(:each) do
�...@authenticator = mock_new_authenticator( :foo = bar )
which is implemented like
def stub_new_authenticator( *args )
result = mock(Authenticator, *args)
Authenticator.stub!(:new).and_return(result)
result
end
I guess having something like that would be nice.
This is how I do it,
Zach
Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [rails] An authorization question
On Tue, Mar 3, 2009 at 11:07 AM, Andrew Premdas aprem...@gmail.com wrote: I think this discussion has gone backwards a bit. Here is what I think the index method in the invoices controller should be like def index begin invoice.get_collection rescue # decide what to do if we can't get collection end end Now clearly this needs some work to get it to work ... 1) What is 'invoice' Rails by default ties 'invoice' to a class in app/model. Usually this ActiveRecord model class, but it doesn't have to be. We can always put another layer inbetween (e.g. Presenter) if it makes our code simpler Presenters are for presentation logic, not for authorization concerns. 2) Authentication parameters Clearly these need to be passed through to get_collection. This can be done by parameters or by making the authentication available in a wider context. Authentication isn't the issue here, authorization is. 3) Exceptions We need an exception hierarchy. NotAuthorised, NotFound etc. All the controller should do is get the collection and deal with exceptions if the collection is not available. (n.b. the collection being empty is not exceptional.) Rails historically has corrupted (compromised, polluted ...) MVC by allowing concerns of how we get the collection to be included in the controller. RESTful design has highlighted the problems with this and now we end up with this situation where things like authentication and authorisation don't really have an obvious place. It is up to the controllers to know how-to ask for something, it should not know how the internals of that request work. For a controller to know what role can access a particular resource is completely aligned with a layered architecture, keeping application concerns in the right layer, and domain logic in another layer. These things - authentication, authorisation and the exception handling (for the resource) - are services which all resources need access to. They need to be seperated and applied in a cross-cutting manner. Perhaps we could do things more elegantly with an Aspect Orientated solution. Is some cases yes, but I fail to see where it benefits or adds more value then concretely identifying a role that has particular behavior. 2009/3/2 Zach Dennis zach.den...@gmail.com Forgot to mention what we did do. We ended up with the following... def index if user.has_role?(admin) user.in_role(admin).invoices elsif user.has_role?(associate) user.in_role(associate).invoices else raise AccessDenied end end To us, the change here is subtle, but important. The controller is allowed to ask for invoices from each role, but is not allowed to know how find the invoices, that's the behaviour of the role. -- - Show quoted text - Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [rails] An authorization question
On Tue, Mar 3, 2009 at 12:32 PM, Pat Maddox pat.mad...@gmail.com wrote: On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley sfe...@gmail.com wrote: On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis zach.den...@gmail.com wrote: Forgot to mention what we did do. We ended up with the following... def index if user.has_role?(admin) user.in_role(admin).invoices elsif user.has_role?(associate) user.in_role(associate).invoices else raise AccessDenied end end That seems sort of backwards to me. These aren't the user's invoices, right? They're just invoices which the user happens to be allowed to see? Chaining it this way makes it look like the invoices *belong* to the role, and seems put the user up front instead of the invoices. You also have conditional branching with hardcoded values, making the controller brittle, and some redundancy with the controller asking the model for a value and then passing the value right back to the model. Agreed. I have a similar example in a blog post: http://www.patmaddox.com/blog/2008/7/23/when-duplication-in-tests-informs-design I agree I'm taking a step back to try to make two steps forward. The heart of the exploration is more than the conditional in the action (which simply states which roles are allowed to access that action, I just made it explicit rather than using a #restrict_to call). To me this discussion is about where the behaviour for a role should go and how-to access that behaviour. The flip side of this is that models end up with redundant conditional branches to do x for RoleA or y for RoleB (for every model thats affected by a Role). I would like to collapse these conditional branches and attempt a more polymorphic approach by extracting a class representative of each role, and simply calling the method in question. e.g: FiscalAssociate.new(user).invoices FiscalAdmin.new(user).invoices Rather than the following approach. Keep in mind that roles hardly ever are limited to one model. Consider having the case statement in 20 models. Where's the redundancy now? Invoice.by_role(role_name) def by_role(role case role when associate when admin ... end -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
