On Aug 04, 2010, at 12:41 pm, David Chelimsky wrote:
What happens if the shared spec author really wants it to just be a hash? Do
you think that's a valid use case?
It could get in the way, then, I guess. You'd always have the original hash
parameter if you wanted to use the method, but I
On Aug 05, 2010, at 4:28 am, David Chelimsky wrote:
At this point, the customization block is still being eval'd after the shared
block, and I'm fairly well convinced this is the right thing, in combination
with params to the block.
I don't think it makes any different any more, at least
On Aug 6, 2010, at 3:18 AM, Ashley Moran wrote:
On Aug 05, 2010, at 4:28 am, David Chelimsky wrote:
At this point, the customization block is still being eval'd after the
shared block, and I'm fairly well convinced this is the right thing, in
combination with params to the block.
I
On Aug 06, 2010, at 11:58 am, David Chelimsky wrote:
Barring the unforeseen, I'll knock out beta.20 this weekend.
Cool, ta!
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
Ashley: thanks for posting the example. It's nice to see how this all
fits together.
Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that
useful for Rails 2.x projects on ruby 1.8.6. However, it's still very
important for gems. I just converted one of my projects (VCR[1]) to
RSpec
On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote:
I actually like contract a lot. Maybe we'll need alias_shared_examples_for_to
:)
Haha, actually that gets +1 from me! Should I file a ticket? :)
In general I like contract, I just wasn't sure it was the right word for this
usage of shared
On 4 Aug 2010, at 7:55 AM, Myron Marston wrote:
Ashley: thanks for posting the example. It's nice to see how this all
fits together.
Arguably it would have made more sense to post that example *before*, rather
than expecting you all to read my mind :)
I'm pleased with how it's working out
On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote:
One other thought I've had is keyword syntax. While currently I'm writing:
it_satisfies_contract [Entity] Collection:, :children, :child, Child.name
I prefer keyword arguments, so I'd like to write:
it_satisfies_contract [Entity]
On Aug 4, 2010, at 3:43 AM, Ashley Moran wrote:
On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote:
One other thought I've had is keyword syntax. While currently I'm writing:
it_satisfies_contract [Entity] Collection:, :children, :child, Child.name
I prefer keyword arguments,
On Aug 4, 2010, at 1:55 AM, Myron Marston wrote:
Ashley: thanks for posting the example. It's nice to see how this all
fits together.
Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that
useful for Rails 2.x projects on ruby 1.8.6. However, it's still very
important for
I wouldn't even bother to undef those methods.
If we don't undef the methods, then the semantics of the
#module_eval_with_args (or whatever we call it) will be different on
1.8.6 and other versions. On 1.8.6, a method definition in the block
would define both an instance method _and_ a class
On Aug 4, 2010, at 1:35 PM, Myron Marston wrote:
I wouldn't even bother to undef those methods.
If we don't undef the methods, then the semantics of the
#module_eval_with_args (or whatever we call it) will be different on
1.8.6 and other versions. On 1.8.6, a method definition in the block
On Aug 2, 2010, at 7:52 AM, David Chelimsky wrote:
On Aug 1, 2010, at 10:08 PM, Myron Marston wrote:
OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
came up with:
http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
It works
On Aug 3, 2010, at 6:43 AM, Ashley Moran wrote:
On Aug 03, 2010, at 12:22 pm, David Chelimsky wrote:
My inclination is to get this feature out with explicit non-support for
1.8.6, and then add support for 1.8.6 if we can get this to work. Working on
that now - should be pushing some
On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote:
Pushed:
http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe
http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1
Awesomeness!
Please do let me know if this works with what
On Aug 3, 2010, at 4:35 PM, Ashley Moran wrote:
On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote:
Pushed:
http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe
http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1
On Aug 1, 2010, at 10:08 PM, Myron Marston wrote:
OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
came up with:
http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
It works (at least in the sense that it allows the specs and
On 2 Aug 2010, at 2:04 AM, Myron Marston wrote:
I actually find the use of this to be a bit confusing:
[:foo, :bar].each do |arg|
it_should_behave_like Something, arg do |a|
# The value of the param is already bound to arg and now it's
bound to a, too.
end
end
I suppose it may
On 2 Aug 2010, at 4:08 AM, Myron Marston wrote:
Backports (a library that implements features of later versions of
ruby in 1.8.6) implements it in a similar fashion:
http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb
Conceivably, RSpec 2 could depend on
On 1 Aug 2010, at 11:52 PM, David Chelimsky wrote:
re: order of evaluation of blocks, I think I'm inclined to go one way one
minute, and another the next. Somebody convince me of one or the other.
One thing that may help clear this up is: can anyone offer a concrete example
of where
On Jul 31, 2010, at 7:06 pm, Myron Marston wrote:
I think this is a clunky way to essentially pass a parameter to the
shared example group. Better would be something like this:
it_should_behave_like something do
providing :method_name, :foo
end
After sleeping on this, I found an
On Aug 1, 2010, at 9:43 AM, David Chelimsky wrote:
On Jul 31, 2010, at 1:06 PM, Myron Marston wrote:
You can still get the same outcome, but you have to implement it in the
group like this:
unless defined?(:foo)
def foo; foo; end
end
Good point--I hadn't thought of that. The one
On Jul 31, 2010, at 1:06 PM, Myron Marston wrote:
You can still get the same outcome, but you have to implement it in the
group like this:
unless defined?(:foo)
def foo; foo; end
end
Good point--I hadn't thought of that. The one issue I see with it is
that the author of the shared
The particular issue of simple values being used in the docstrings and the
examples themselves (i.e. exposed to everything in the block scope) could be
handled like this:
shared_examples_for blah do |a,b|
...
end
it_should_behave_like blah, 1, 2
Fantastic idea. I'm sold. I'm not
On Aug 1, 2010, at 11:40 AM, Myron Marston wrote:
The particular issue of simple values being used in the docstrings and the
examples themselves (i.e. exposed to everything in the block scope) could be
handled like this:
shared_examples_for blah do |a,b|
...
end
On 1 Aug 2010, at 3:43 PM, David Chelimsky wrote:
shared_examples_for blah do |a,b|
...
end
it_should_behave_like blah, 1, 2
That wouldn't have worked with the old implementation, but it would work
perfectly well now. This would also just work with hash-as-keyword-args:
Seems like your mental model is that of a customization block being a
subclass or re-opening of the shared block. What you say makes sense in that
model, but that's not the same model I have.
My mental model is indeed that the customization block is like a
subclass. I'm not sure where I got
On Aug 1, 2010, at 5:39 PM, Myron Marston wrote:
Seems like your mental model is that of a customization block being a
subclass or re-opening of the shared block. What you say makes sense in that
model, but that's not the same model I have.
My mental model is indeed that the customization
On Aug 1, 2010, at 5:12 PM, Ashley Moran wrote:
On 1 Aug 2010, at 3:43 PM, David Chelimsky wrote:
shared_examples_for blah do |a,b|
...
end
it_should_behave_like blah, 1, 2
That wouldn't have worked with the old implementation, but it would work
perfectly well now. This would
If we do this, we should use module_exec for both blocks so they both get the
same arguments.
I actually find the use of this to be a bit confusing:
[:foo, :bar].each do |arg|
it_should_behave_like Something, arg do |a|
# The value of the param is already bound to arg and now it's
bound
OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
came up with:
http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
It works (at least in the sense that it allows the specs and features
I added in the previous commits in that branch to
On 31 Jul 2010, at 1:10 AM, David Chelimsky wrote:
You can still get the same outcome, but you have to implement it in the group
like this:
unless defined?(:foo)
def foo; foo; end
end
Maybe a DSL method while I'm working on it? Maybe:
default_helper(:foo) do
foo
end
WDYT?
You can still get the same outcome, but you have to implement it in the group
like this:
unless defined?(:foo)
def foo; foo; end
end
Good point--I hadn't thought of that. The one issue I see with it is
that the author of the shared example group may not have knowledge of
which helper
On 31 Jul 2010, at 7:06 PM, Myron Marston wrote:
Good point--I hadn't thought of that. The one issue I see with it is
that the author of the shared example group may not have knowledge of
which helper methods consumers will need to override. So he/she
either defines all helper methods that
Hi
I finally looked into why this is not currently possibly in RSpec 2 (beta 19):
shared_examples_for Etymology do
describe The etymology of foo do
it is followed by #{after_foo} do
# ...
end
end
end
describe foo, focus: true do
it_should_behave_like
On Jul 30, 2010, at 9:03 AM, David Chelimsky wrote:
On Jul 30, 2010, at 5:13 AM, Ashley Moran wrote:
Hi
I finally looked into why this is not currently possibly in RSpec 2 (beta
19):
shared_examples_for Etymology do
describe The etymology of foo do
it is followed by
El 30/07/2010, a las 16:10, David Chelimsky escribió:
Actually - maybe I spoke to soon. Ordering things this way would mean that
you couldn't do this:
shared_examples_for Enumerable do
def enumerable
raise you must provide an enumerable method that returns the object which
you're
On Jul 30, 2010, at 10:57 AM, Ashley Moran wrote:
On Jul 30, 2010, at 3:10 pm, David Chelimsky wrote:
Maybe that, or a DSL that wraps that, is the better way, so we can get the
best of both worlds?
shared_examples_for Enumerable do
require_instance_method :foo, gotta have foo
On 30 Jul 2010, at 5:00 PM, David Chelimsky wrote:
By all means.
I've started on that and filed a ticket[1].
One question I have, is I keep calling the Example Group that uses a shared
block the host group. Is there already a name for it? I never know what to
use, and I'm not sure host
On Jul 30, 2010, at 6:56 PM, Myron Marston wrote:
On Jul 30, 2:58 pm, Ashley Moran ashley.mo...@patchspace.co.uk
wrote:
On 30 Jul 2010, at 5:00 PM, David Chelimsky wrote:
By all means.
I've started on that and filed a ticket[1].
One question I have, is I keep calling the Example Group
40 matches
Mail list logo
