[rspec-users] Possible subject/its bug?
Hi I recently did a coding kata and ran into some strange behaviour. The code is here[1], the weirdness under the comment Doesn't work... RSpec bug?. Basically, all the `subject` / `its(:sequence)` examples seem to work, except the one split into the two contexts. In this case `its(:sequence)` produces an empty array. Anyone got any idea what's going on? Cheers Ash [1] https://github.com/ashleymoran/xpman_even_fib/blob/ashleymoran-seb-20102025/spec/euler_fib_spec.rb -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Issue with parameterized shared example group on ruby 1.8.6
On 20 Aug 2010, at 06:40, Myron Marston wrote: describe VCR::HttpStubbingAdapters::FakeWeb do it_should_behave_like 'an http stubbing adapter', ['net/http'], [:method, :uri, :host] end describe VCR::HttpStubbingAdapters::WebMock do it_should_behave_like 'an http stubbing adapter', %w[net/http patron httpclient em-http-request], [:method, :uri, :host, :body, :headers] end Neat! I'm interested to see applications of parameterised shared examples. I'd certainly never thought of defining optional features in that way. So...how should we deal with this? A few ideas come to mind: 1. Find a better way to fake module_exec on ruby 1.8.6. I'm not sure if this is even doable. 2. Leave things as they are...but I don't like this idea since the error message is fairly cryptic. 3. Rescue the error and raise a more clear error message. 4. Rescue the error and print a warning. I lean towards #4, because the #module_eval is only necessary to extract the instance method definitions. 4 makes sense to me iff the code does actually run correctly in all circumstances, otherwise I'd lean towards 3. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] How do you turn colour on in autotest?
On 18 Aug 2010, at 15:06, Chris Flipse wrote: Check for a .rspec file in one project, not the other. Aha! You're a genius :D I need to stop TextMate hiding stuff like that... Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Module Mixin testing strategy
On 14 Aug 2010, at 11:34, Mike Howson wrote:
Just wondered what people thoughts are to testing module's to be
included in mixin's? Seems to me there are two main approaches:-
Hi Mike
I've been doing a lot of this sort of coding lately, as I've been extracting
duplicated code into a mini-framework based on modules.
1. Test the behavior in a mixin object that includes the module because
its the behavior of the object thats important not the code structure.
2. Test the module in isolation as it potentially code be included
anywhere.
I'm not sure I know how option 2 is even possible, unless your module is all
module methods, as you can't call instance methods on a module directly.
However, it's easy to do this in RSpec with some Ruby meta-magic:
module MyModule
def foo
bar
end
end
describe MyModule do
let(:class_with_my_module) {
Class.new do
include MyModule
end
}
subject { class_with_my_module.new }
its(:foo) { should eq bar }
end
If the best approach is 2 - to test the module in isolation and the
module uses instance variables or methods from the object its being
mixed with then we would need to create a test object in the rspec test
that included the module and defined the required instance variables and
methods. Does this lead to 1 being the best approach as we are not then
forced to mock up a mixin just to test the module?
I'm not 100% sure but I *think* the snippet above is an implementation of what
you describe here. Please correct me if I misunderstood.
The question came about because I recently had to get an untested rails
module under test that was included in a number of controllers and
depended on 'request' and 'response'. I was then faced with either
testing one of the controllers that included that module but also added
further complexity or defining a new thin controller used solely for
testing the module within the spec file.
In this case, you may be able to get some mileage with the above code, but
using `Class.new(ActionController::Base)`.
You can test individual objects that include your module with shared examples,
for example:
module Fooable
def foo
bar
end
end
class Baz
include Fooable
# Oops - this is overriding Fooable#foo
def foo
quux
end
end
shared_examples_for a Fooable object do
# Optional
before(:each) do
unless respond_to?(:fooable)
raise You must provide instance method fooable
end
end
it should have a foo of 'bar' do
fooable.foo.should eq bar
end
end
describe Baz do
subject { Baz.new }
it_should_behave_like a Fooable object do
let(:fooable) { subject }
end
end
My recommendation at the moment is to make the shared examples work
fully-integrated (ie, no mocks). I've run into issue where shared examples
rely on mocks, which I haven't solved yet (at least not in my code - it's my
next TODO).
Currently I'm doing both the above. The isolated module spec proves the module
enchants objects with the correct behaviour, the shared examples double-check
that you haven't broken that behaviour in concrete classes.
See also the recent thread Evaluating shared example customisation block
before shared block from 30th July onwards (it goes on to talk about passing
parameters to shared example groups, which is possible in RSpec-2 master).
HTH
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Autotest does not start
On 13 Aug 2010, at 22:16, Don French wrote: Not sure what you meant by did you turn it off and on again? Ah, I just meant I was running out of ideas[1]. The other information is here: http://pastie.org/1091155 All I can suggest is maybe updating RVM and trying in Ruby 1.9.2 with a fresh gemset and bundle install? Other than that I'm out of ideas... Ash [1] http://www.youtube.com/watch?v=QpmLrz_lSuE -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Autotest does not start
On 14 Aug 2010, at 18:49, Don French wrote: Thought that was what you meant, but did not want to leave anything untried. I have updated to 1.9.2-rc2. same problem. I am going to have to do an update to snow leopard soon, may try it and put new code on not just restore. I wish I could help more, but I'm flat out of ideas. I don't think I'd be able to do any more without being at your machine. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Autotest does not start
On Aug 12, 2010, at 11:09 pm, Don French wrote:
yep: Autotest.add_discovery {rspec2}
in the base project directory
I'm at the point of asking did you turn it off and on again? :-/
Can you give your Ruby installation details? (versions etc, ideally the output
of `rvm info` and `gem list` and/or your Gemfile)
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Name collision - how would you handle this?
On 12 Aug 2010, at 04:30, David Chelimsky wrote: I think they should all be registered in the same place, in rspec-core. Or are you saying that rspec-rails would take the responsibility of registering the names for rspec-rails, rails, test/unit and minitest? That makes sense to me, as long as they're all using RSpec::Core::register_reserved_name (or whatever). What do others think of this idea? I'm willing to take a stab at implementing this if there is support for it. I'm still not sold on this idea yet. Seems like a lot of complexity for not much benefit. I've already taken care of the message issue by encapsulating the assertion libs in a separate scope. Anybody else have opinions on this? The idea sounds interesting, but sounds like it could lead to a nasty dependency down the line. Is there any way of doing the core of this as an external gem, that all interested projects could use? I'm only following the edge of this thread, but by dependency radar went off - it's a bit oversensitive. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Autotest does not start
On 11 Aug 2010, at 19:44, Don French wrote: Any help on this. I think I have read all posts related to autotest but still do not have the answer. Is there something that works better with Rspec that autotest? When you say and a prompt (back) ... do you mean autotest exits in both situations and doesn't run any tests? (I'm running autotest with RSpec 2 fine, BTW.) Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Recognising RSpec files in the Textmate bundle
On 9 Aug 2010, at 17:37, Rick DeNatale wrote: Well, I'd still use a different file name suffix which I could set textmate to recognize as a spec _sspec.rb or _sgroup.rb something like that. Hi Rick, I think that was what David was saying? (If I understood you both correctly, that is.) It's not enough to treat RSpec files as Ruby because they have too many specific highlighting rules and completions etc, which we don't want mixed into plain Ruby source. My specific example is I now have three files *_contract.rb that I'd like highlighted. But if everyone chipped in with their own convention we'd probably end in chaos. I like the _sgroup.rb idea though. Or maybe _examples.rb? That's fairly generic. Or... how about an actual dot-suffix, .rspec, eg, active_record_associations.rspec, which would be designed to indicate an RSpec-loadable file (prob shared example groups), but one that doesn't make sense to run alone (or can't be)? Any legs in that idea? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Recognising RSpec files in the Textmate bundle
On 8 Aug 2010, at 21:53, Phillip Koebbe wrote: I don't think you are alone in your quest to achieve greater organization. I am guessing that in your suggested RSpec folder structure, the current folders of controllers|helpers|models|views would all live under examples? I might go for that. I think some (many?) might say that it's an unnecessary level, but I think I'd prefer that. I might even look into doing that anyway :) After all, my Cucumber folder structure is cuke/ features/ steps/ support/ And I use subfolders under features and steps just like I do in RSpec. Right. I wouldn't want a particular structure to be forced upon me, so I'd rather not see that happen to anyone. The biggest problem I can see is the RSpec TMBundle's Alternate File command, which I would probably sacrifice a finger to keep*. Autotest is easy enough to reconfigure to look in different spec subdirs. If only there was some way of integrating Alternate File and Autotest mappings... Ash * But since I'm still typing 9-fingered after I trapped one under a weight in a gym, I consider this pre-payed. So nobody mess with Alternate File!!! Until my finger is better anyway. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Order guarantees of let
On 9 Aug 2010, at 13:49, David Chelimsky wrote: Yes, eval'd in order. No, not explicitly stated, but I think it should be. Want to submit a patch with a spec for this? Sure - I've made an action to write a spec for this. I guess the implementation is not likely to change any time soon so I'll do it when I find a convenient 10 mins... Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Recognising RSpec files in the Textmate bundle
On 10 Aug 2010, at 15:03, Rick DeNatale wrote: And easy to add yourself by just editing the bundle. I've tried this before. Unfortunately, it just leads to pain when you try to update the bundle via Git Or... how about an actual dot-suffix, .rspec, eg, active_record_associations.rspec, which would be designed to indicate an RSpec-loadable file (prob shared example groups), but one that doesn't make sense to run alone (or can't be)? Any legs in that idea? I don't think I like that. For one thing most folks don't include the dot suffix in require 'statements'. Good point, I forgot about that. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Order guarantees of let
Hi
I was just about to replace a `before` block along the lines of:
before(:each) do
@cti_b_id = service.create(name: Item-B)
@cti_z_id = service.create(name: Z-Item)
@cti_a_id = service.create(name: Item-A)
# ...
end
with
let!(:cti_b_id) { ... }
let!(:cti_z_id) { ... }
let!(:cti_a_id) { ... }
But then I wondered - since the spec depends on the order they are created in
(it proves ordering is independent of creation order) - is the run order of
`let!` guaranteed? I imagine they run in the order I expect (ie top to
bottom), but I wondered if that was an explicitly stated property of RSpec?
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec 2 autotest file
On Aug 08, 2010, at 12:00 am, David Chelimsky wrote: Yes: http://github.com/rspec/rspec-core/commit/c2e8a3947321e501b84113c1b2b1049df4868f4b Cool, ta :) I'll update my code shortly. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Recognising RSpec files in the Textmate bundle
On Aug 08, 2010, at 2:17 am, Phillip Koebbe wrote: I have developed a system in which I require model_helper.rb in model specs, controller_helper.rb in controllers, and (you guessed it!) view_helper.rb in view specs. Each of those then require spec_helper.rb. I did this because I wanted fine-grained control over what gets loaded when, which started when I decided I wanted to use Remarkable for model specs only and didn't want it available during other specs. Plus, I keep customizations out of spec_helper.rb, which is a very good thing. I think the way I worded by question may have made it sound like I was expecting everyone using TextMate to use put require 'spec_helper' at the top of the file... I didn't mean that! I was just suggesting that if a file starts with that require, then TextMate should see it as an RSpec file. As you've pointed out, this won't get all files, like your custom helpers. But I imagine it'd get a fairly high proportion. This is probably like trying to swat a fly with Mack truck, but what if all files under spec/ were considered RSpec files? Or possibly some variation of that? I just double checked, and spec_helper.rb isn't considered an RSpec file - and actually, I don't think it should be. Also, I have a spec/support folder in most projects, with matchers etc. They aren't RSpec files either. So this route would probably give a lot of false positives. It might work better if this was the default folder structure: spec/ examples/ spec_helper.rb support/ Then you could glob everything under examples. I actually do this with Cucumber, where my folder structure is: features/ descriptions/ step_definitions/ support/ But apparently I'm alone in the world not wanting to mix .feature files in with the support folder! Either way, I'm not convinced using the folder structure is the best solution. It forces TextMate users to structure there project a certain way. If you wanted a rails app like this: acceptance/ app/ integration/ spec/ (or whatever) then path matching wouldn't work. On Aug 07, 2010, at 11:44 pm, David Chelimsky wrote: I think it's good to do things that help end users, but we'd need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions? Actually, I'm stuck :-/ I didn't think it'd be hard to identify RSpec example group files! I'm not much of a TextMate developer though. Anyone else got ideas? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Name collision - how would you handle this?
On 8 Aug 2010, at 12:05, Matt Wynne wrote: And you override it using let(:foo), which would be a perfectly reasonable way to handle it. In fact, it would be the way I would handle in instinctively, because now I don't have to wrote my own memoization handling into the method. I instinctively agree with ashley, but I see your point too David. Would it be awful to make let even more magic, and do something with #caller to forward the message to MiniTest if it didn't come from the code in your example block? Maybe the method defined by let could even have a __hidden name, and then RSpec can forward the message to that __hidden method if the message was sent from within the example block. Sounds pretty horrible, doesn't it? Hmmm, sounds like it could create a pretty nasty coupling to MiniTest. Maybe there's a general solution like: define_example_method do # or maybe define_helper ? # some stuff that only gets called from examples end I'm not sure I'd be keen on let embedding this magic, but maybe as a general concept it makes more sense, as a way of isolating helper code in example groups. There's another side to the debate, which is that in shared example groups, I prefer the precondition-check style to the templatemethod-fail style, ie rather than: def foo raise you need to define a foo method ... end I'd prefer to write: unless respond_to?(:foo) raise you need to define a foo method ... end But that would involve evaluating the configuration block first :) Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Name collision - how would you handle this?
On 7 Aug 2010, at 22:10, David Chelimsky wrote: So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. While I fully agree if you `def` a method that already exists, you should be expected to deal with it yourself (that's just the way things are in Ruby), does the same apply to `let`? I can actually see an argument that you should only be able to `let` a method that doesn't already exist, and also only do it once (which is just a consequence of not being able to override a method, given the current implementation). Can you think of any downsides of preventing RSpec users from overriding existing methods with `let`? Are there any popular names already taken? Or other problems? To me, `let` is magic. I don't think of it, first and foremost, of defining a method. I see the things it creates as more like local variables, and just remind myself that they're methods if I wonder why it works. I'm not sold either way on this, but I think it's one worth a debate. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] RSpec 2 autotest file
Hi I've tried using the autotest file from RSpec 2 (lib/autotest/rspec2.rb) but I've found a problem with it, that I think is a bug. The file contains two sections * an Autotest `Autotest.add_hook :initialize` block * an Autotest class Autotest::Rspec2 In one project I'm working on, the code in Autotest::Rspec2 is really useful to me, but the :initialize hook contains setup that interferes with my project structure (I don't want a lib folder. Unfortunately, it appears that Autotest's `clear_mappings` can't stop the :initialize mappings making it into the final setup. This means that to use Autotest::Rspec2, I've had to copy-paste the contents into my own autotest file, rather than subclassing. Is this a bug? (ie, is there no workaround for the coupling between the two blocks?) If so, can it be fixed? Alternatively (or as well), is it time to drop autotest and use watchr instead? I noticed RSpec 2 uses that, and it seems really fast and simple, both of which go down very well with me... Any thoughts? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Recognising RSpec files in the Textmate bundle
Hi Did the RSpec TMBundle ever have multiple ways of recognising RSpec files? I'm convinced it user to look for spec_helper on the first line. The Ruby bundle does something similar, as it looks for firstLineMatch = '^#!/.*\bruby'; The reason I ask is because I now have several files that end _contract.rb. Conceivably I might have other shared example files with different suffices. But it's fairly safe to say they will all start with require 'spec_helper'. WDYT? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 guess it could cause trouble
if you did this, or similar:
shared_examples_for a foo container do |foo, options = {}|
it has a #{foo} do; end
end
describe Bar do
it_should_behave_like a foo container, 1, foo: 2
end
I'll probably play with this idea in my own code. There's definitely no need
worry about it now, being able to pass arguments to shared example groups is
90% of the win for me.
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 not to me. The only thing you can't do is use class methods in shared example descriptions, but you don't need to do that any more now anyway. Next release will FINALLY have parameterized shared groups. Sweet! Brilliant :-) What's the current release plan? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Macros and accessing block-variables (rspec2)
On Aug 06, 2010, at 1:24 am, Myron Marston wrote: It's the difference between an instance variable of a Class instance (since Classes are objects, too), and an instance variable of an instance of a class. I talked a .Net dev friend of mine through instance ivar + class ivar + class variables last weekend. His response was something along the lines of Woah! :) Gudleik - the simplest, readable change I can think of is to make the answer a constant[1]. The answer is really a property of the spec, not of the examples, so it doesn't belong in the `before` block. But I suspect the example you've given is a simplified version of something more complex, so real-world solution may be different. HTH Ash [1] http://gist.github.com/511087 -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] New bie question: Why use assert_equal when there are comparison operators in Rspec?
On Aug 06, 2010, at 3:52 am, ct9a wrote: Reading up on the Rspec's main site, the main example in http://rspec.rubyforge.org/rspec/1.3.0/ does not show any use of assert_equals. Rather it just uses the == comparison operators. Here's an extract: assert_equals is part of Test::Unit, not RSpec. You can't use assert_equals in RSpec unless you also have Test::Unit loaded. The default Rails test suite setup is based on Test::Unit, so you have access to both. (RSpec it designed to integrate with it.) There's no reason to use assert_equals unless you want to, and personally I'd avoid miking the two styles. HTH Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Cucumber Development
On 6 Aug 2010, at 18:28, Subhash Mishra wrote: Cucumber has its own mailing list/user group: http://groups.google.com/group/cukes. I'd recommend asking there, though you'll probably want to be a bit more specific about your question. Cheers, David Thanx, Well as far as concern of my problem is only this much that i want to parse argument of cucumber sentence before calling sentence definition e.g. suppose i have a cucumber sentence When I press some argument and there corresponding definition When /^I press ([^\]*)$/ do |arg1| ruby code end where ever above cucumber sentence will be encountered, the actual ruby code is going to be called and some argument is going to be passed in 'arg1'. i want to do some operation on this some argument before being supplied to arg1. :-) Here we go again. Sigh I think what David meant is that you should ask on the Cucumber list, as that's where the Cucumber developers hang out. They are the people you need to ask to get an authoritative answer. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 examples.
Maybe I just need to reword the shared examples, to write something like this:
it_satisfies_contract container of, :children, :child, Child.name
(Obviously, if I had an inflection library in place, you could drop the last 2
args)
This is just Ruby. It bugged me for a while too, but mostly because I kept
forgetting. Now I'm completely accustomed to it and def and define_method
seem quite the same to me.
Maybe. Perhaps then Ruby needs a neater closure-based method syntax eg:
foo = 1
defc my_method(bar)
foo + bar
end
or some such...
This was a mis-alignment between names in the group and its examples
(example_group.describes == example.described_class), but is now fixed (you
can refer to described_class in both
cases):http://github.com/rspec/rspec-core/commit/b236a8d8927da108097fed7982d1450e4701939d
Works for me! Ta :)
shared_examples_for foo do
raise gotta define entity_class unless
public_instance_methods.map{|m|m.to_s).include?(entity_class)
end
Aye, I guess I'm just in love with DSLs...
If I feel the need I might write a simple DSL and see if it's worth it.
And also, if it's defined as a `let` in the host, you can't use it in the
descriptions in the shared example group (which you couldn't before, of
course).
Right - the only thing available to descriptions is going to be the params
you pass in.
I have a feeling this will cause a misalignment, but maybe not. I'll work
through some more practical examples and see how it plays out.
BTW any idea when the next beta will go out, so that this is in a released gem?
I've got it working, but I had no luck using Bundler's :path option so I ended
up having to build and install the gems into my project gemset. That's
probably just a RubyGems/Bundler issue though.
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 so far. I need to write a lot more of these to know though. I only got as far as this one example before deciding to shave the shared example yak before moving on. 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 2, and VCR supports ruby 1.8.6, 1.8.7 and 1.9.1. If we remove ruby 1.8.6 support from RSpec 2, I'd have to migrate back to RSpec 1.x so that I can continue to run the spec suite on 1.8.6. I imagine there will be plenty of other libraries that will want to upgrade to using RSpec 2 after the final release, while still supporting 1.8.6. Cool, if it's possible to maintain 1.8.6 support in RSpec 2 then by all means do so. I wasn't aware that such a large amount of code needed to run on 1.8.6, I assumed most had moved to 1.8.7. Doesn't look like it takes too much to monkeypatch 1.8.6 up to spec anyway. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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] Collection:,
:children,
item_name: child,
class_name: Child.name
Currently that would mean rewriting the contract like this:
contract [Entity] Collection: do |collection_name, options|
# ...
describe #{collection_name} do
describe Helper methods: do
describe #new_#{options[:item_name]}, #get_#{options[:item_name]} do
# ...
WDYT about RSpec automatically translating keyword options to methods? They'd
need to be defined as singleton class methods and instance methods to have the
same availability as block parameters.
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 you've got.
In general, yes, this is a massive improvement! I've realised some things that
never occurred to me before, though. Maybe you have some thoughts...
I've put everything on a Gist[1] (which needs a few tweaks here and there, but
I think it's a reasonably example). Notes:
* DomainLib is my holding module for everything I've extracted out of the
project source. Anything inside that is generic, analogous to eg ActiveRecord
(eg Entity - AR::Base)
* I've only pasted the specs, and only the contract-based ones at that (the
implementation is not very interesting, nor is the interaction spec).
* I don't like the word contract any more, at least not here. It needs a
better name, probably something that would fit if you wrote a similar spec for
ActiveRecord's has_many.
Some things I ran into:
First, I found that you can't use the block variables in local helper methods.
Because Ruby methods aren't closures, I've had to replace methods like:
def entity_dot_new_collection_member(*args)
entity.send(:new_#{item_name}, *args)
end
with:
define_method :entity_dot_new_collection_member do |*args|
entity.send(:new_#{item_name}, *args)
end
Not a big deal, but it's not as readable as it was before. (Not that it was
exactly large-print Winnie the Pooh to start with, given the abstract nature of
the shared examples.)
Second, you can't refer to `described_class` in the descriptions. I don't know
why I though you'd be able to, but it would be nice if it worked :) (You can
see the place where my failed attempt was, where I left described_class.)
Finally, I realised something when I added another example. I should say
though, that all this time, I was only using the shared examples with one
collection on the entity, and I added another a few minutes ago just for fun,
and it just worked... I like :) But it raised a point about things that are
common to all shared examples, and parameters to individual uses. In my
example case, `entity_class` and `entity` are relevant to both of the
collection shared example groups, but `collection_name`, `item_name`,
`class_name` are parameters to the shared examples individually.
With the current setup, there's no way to require that a host group provides eg
`entity_class`. And also, if it's defined as a `let` in the host, you can't use
it in the descriptions in the shared example group (which you couldn't before,
of course).
So I think this solves 90% of the problems I had before, and is certainly a
workable solution to the specs I'm trying to write. I'd love to hear your
thoughts on the rest though.
The issue of the evaluation order is still up for grabs, but this now
supports params to shared groups in Ruby = 1.8.7.
Well, I deliberately didn't check what order you ended up using! Whatever it
is works for me now, although I guess future experiments could change that...
Cheers!
Ash
[1] http://gist.github.com/507140
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] RSpec 2 Ruby 1.8.6 support (was Evaluating shared example customisation block before shared block)
On Aug 01, 2010, at 11:52 pm, David Chelimsky wrote: re: 1.8.6, we've got a home-grown implementation of instance_exec that runs in 1.8.6 (although I just discovered that it's broken - fix coming shortly). I could a) add such a thing for module_exec as well, though I haven't quite figured out how that works yet. b) only support parameterized shared groups in ruby 1.8.7 or better c). the most drastic option, would be to drop support for 1.8.6 entirely, but I don't think that's really feasible yet. Hmmm. If you're working on a Rails project with RSpec 2 (which I'm not, but I'm guessing that will be a very common case), you need 1.8.7 anyway, as Rails 3 won't run on anything less. If you're not using Rails, I can't imagine anyone starting a new project on 1.8.6 now. (All my new stuff is on 1.9.2.) Is 1.8.6 support in RSpec 2 *really* necessary? Any thoughts from anyone? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RSpec 2 Ruby 1.8.6 support (was Evaluating shared example customisation block before shared block)
On 2 Aug 2010, at 1:08 PM, David Chelimsky wrote: But what about people who are, for what ever reasons, stuck with Ruby 1.8.6 and want to upgrade? Also, there are a few rspec-2 + rails-2 efforts in the works, and there will be a solution for this sometime this fall. We need to support 1.8.6. Ah fair enough. I didn't imagine there were many people stuck in that situation - I thought 1.8.6 was largely obsolete now. I also didn't know there were any RSpec-2/Rails-2 solutions in progress, I thought that was going to be unsupported. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 be useful in some situations, so I'm fine with it as long as the implementation allows you to skip the `|a|`: [:foo, :bar].each do |arg| it_should_behave_like Something, arg do # no need to declare the |a| parameter since we already have it in arg. # I find this to be less confusing. end end Agreed - requiring the block parameter to be declared in the host group is putting the onus back on the user, not the author, of the shared examples. I think we need a way to implement the second version. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 Backports under Ruby 1.8.6. It's not my opinion that it should (I don't have one), but I'm interested to know the implications. Would that solve any design problems inside RSpec? Would that cause any problems for users? Would the problems solved outweigh the problems used? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 overriding a shared example group helper method would be useful (and better than an alternative design)? My gut feeling is that, as David suggested, being able to override these is creating a class hierarchy of example groups. It feels to me unnervingly like overriding private methods. I wait to be proved wrong though, I just can't think of an example myself of wanting to do this. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 elegant solution (elegant in Ruby 1.9 anyway, I had to monkeypatch Ruby 1.8 to make it work) to the class method problem. (It was exactly what I said before.) So I *think* all the technical problems for this feature are solved, and the question is just how the it should actually behave... Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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:
shared_examples_for blah do |options|
it blah #{options[:a]} do
..
end
end
it_should_behave_like blah, :a = 1
Now you can do this:
[1,2,3].each do |n|
it_should_behave_like blah, :a = n
end
And we can still use the customization block to define methods, hooks
(before/after) and let(). Now it just feels like the rest of RSpec.
Thoughts?
One thought: me.facepalm :)
The only thing it lacks is a DSL to define the requirements. Would it still be
desirable to be able to write:
shared_examples_for blah do |options|
require_argument options[:a]
it blah #{options[:a]} do
..
end
end
Or some such?
Also, after staring at this for a while, I'm puzzled by something. In this
code:
it_should_behave_like blah, :a = 1
how does :a = 1 get passed to the options block, as `shared_block` in the
code is never called with arguments? Would this need another code change?
(Apologies if I'm being thick, it's late and I should probably go to bed, but I
wanted to review this first...)
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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? I think it's a good trade-off to put that burden on the group (and it's author) rather that the consumers of the group. Agreed, it'd cause a lot of duplication of effort the other way round. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] rspec 1 - nested examples (in an each block) use the final block variable 4 times instead of each of the 4 once
On 31 Jul 2010, at 2:08 AM, nruth wrote:
If I want to set up a context to run some examples in (models created
with machinist, associations, etc) then the before block makes it
clear that that's the state the examples are running against, and the
@vars give me a (quick and dirty?) hook to refer back to parts of that
setup (e.g. associated models) in the spec examples.
Of course, this can be done with let as well, but since they are lazy-
evaluated you can end up with your examples running in the wrong
context. For example: http://gist.github.com/501517
Hi Nick
I've been bitten by that too :) However, RSpec 2 comes to the rescue with
`let!`, which evaluates the block immediately, so you don't have to call the
method to get it evaluated.
It's interesting though, I'll have to sit down some time and think through what
the semantics of `before`, `let` and `let!` mean to me...
back to op briefly, I ended up with this approach for the specs
instead:
describe #add_question_set_of_type('Abstract Reasoning') do
let(:subtest) {'Abstract Reasoning'}
it_should_behave_like adding a question set
end
describe #add_question_set_of_type('Decision Analysis') do
let(:subtest) {'Decision Analysis'}
it_should_behave_like adding a question set
end
etc…
perhaps not ideal if another test is added in later, and I wanted
coverage of that too for free, but it avoided the immediate problem
is more clear what's going on.
Hmm, without seeing the rest of your code it's hard to say, but this looks like
a case of Control Couple. Is there a case statement inside? If not is there
any reason not to have methods #add_abstract_reasoning_question_set,
#add_decision_analysis_question_set? If you're not branching on the parameter,
how does the different behaviour come about?
I certainly prefer let and subject to @vars for shared examples -
again both work, but I find subject lets provide a clear interface
for the shared example groups which I felt was lacking when passing
@variables around.
I agree. I'm going to see if I can tighten this up today with a DSL to
explicitly name the requirements of a shared example. (See the thread
Evaluating shared example customisation block before shared block.)
Re: error / warning message, at the same scope (i.e. an accident, as
in the op) then yes that could be quite useful for spotting mistakes.
I'm not so sure about in different blocks though, it's probably
intentional there (different context).
Re: redefining vs refactoring - I like what you're saying (reminds me
of dry vs non-dry specs, and I find myself refactoring a lot of my old
spaghetti specs lately), but wonder if there are (edge) cases where
it's useful or necessary. Maybe there's some discussion dating back to
when the feature was added. It may be stylistic though, rather than
enforceable?
Re: LSP, food for thought, nothing to add at present unfortunately.
Not sure what angle you're approaching shared examples from with that
though, do you mean redefining lets inside of the shared example
groups, or something else?
Redefining lets anywhere actually. The case for doing it within an example
group is probably stronger, as you wrote (or can manage) all the examples
yourself. I guess if RSpec raised an error when a shared example accidentally
redefines something from the host group, that would be noise, and force you to
change your own code unnecessarily. Hopefully, if shared examples can say I
require these things to be set up, that issues won't arise. We'll see :)
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] rspec 1 - nested examples (in an each block) use the final block variable 4 times instead of each of the 4 once
On 31 Jul 2010, at 2:08 AM, nruth wrote: Re: error / warning message, at the same scope (i.e. an accident, as in the op) then yes that could be quite useful for spotting mistakes. I'm not so sure about in different blocks though, it's probably intentional there (different context). I forgot to add: David - think it's worth one or other of us filing a ticket for this? Is this check something that is likely to make it into RSpec? -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 way, or guesses about which
ones to define that way (and potentially guesses wrong).
I wonder if this will happen in practice? I can't think of an example off the
top of my head, which isn't to say it won't matter, but it may be better done
pull-based, when the need arises.
If we go the route of having the customization block evaluated first,
then I like the idea, but I'm generally wary of adding more DSL
methods to RSpec. I think we should be careful to only add new DSL
methods that many people will find useful. If you find it useful,
it's very easy to use it in your project without it being part of
RSpec: just define default_helper in a module, and use config.extend
YourModule in the RSpec.configuration block. (Note that I'm _not_
against adding this to RSpec: I just want to be sure we don't add a
bunch of DSL methods that have limited usefulness.)
This is a fair point. I'm going to the effort of implementing this spike in
rspec-core itself because I *really* want to see if there is value in re-usable
shared examples (my own, admittedly small, side-project already suggests there
is). But I'm fairly sure it's not a pattern in wide use, at least not with
Ruby testing libraries.
Looking back at the initial example that prompted the thread, it looks
to me like the primary use case for evaluating the customization block
first is so that you can parameterize the shared example group's
example descriptions. (There may be other use cases for defining a
class-level helper methods, but none springs to mind). I also do this
frequently. Often times I have something like this:
[:foo, :bar, :baz].each do |method|
it does something for #{method} do
subject.send(method).should ...
end
end
In this case I'm using the method parameter at the class level (to
interpolate into the description string) and at the instance level
(within the example itself).
If we evaluated the customization block first, it would allow this,
but you'd have to define both an instance and class helper:
it_should_behave_like something do
def self.method_name; :foo; end
def method_name; :foo; end
end
I think this is a clunky way to essentially pass a parameter to the
shared example group.
Funny you mention this. While I've been working on my patch[1] I came to the
same conclusion. This (heavily trimmed down - I may have broken it cutting
bits out for email purposes) example demonstrates it:
module RSpec::Core
describe SharedExampleGroup::Requirements do
it lets you specify requirements for shared example groups do
shared_examples_for(thing) do
require_class_method :configuration_class_method, message
it lets you access #{configuration_class_method}s do
self.class.configuration_class_method.should eq
configuration_class_method
end
it lets you access #{configuration_class_method}s do
configuration_class_method.should eq configuration_class_method
end
end
group = ExampleGroup.describe(group) do
it_should_behave_like thing do
def self.configuration_class_method
configuration_class_method
end
end
end
group.run_all.should be_true
end
end
end
However, I found a serious issue with class methods, namely that they are being
defined in a persistent class, not a transient ExampleGroup subclass. I
haven't investigated this yet*, but I've left a pending spec at the appropriate
point.
* Random thought after seeing your code: using `class self; end` over `def
self.x; end` may be a partial answer?
Better would be something like this:
it_should_behave_like something do
providing :method_name, :foo
end
The instance of the shared example group provides :foo as the value of
the method_name parameter. providing simply defines a class and an
instance helper method with the given value.
I've written up an untested gist with a start for the code that would
implement this:
http://gist.github.com/502409
Thanks for writing this - it's an interesting piece of code. Certainly it also
gets around the class/instance scope divide. But I don't think it can enforce
that the parameter is provided? One of my hopes is to make the errors
completely self documenting.
Aside: one design decision I've made is to make every error due to a missing
requirement fail at the example level, rather than abort the whole spec run.
This is because RSpec-formatted requirements are MUCH easier to read than a
random stacktrace in a terminal. To do this, you need to specify the class
[rspec-users] Evaluating shared example customisation block before shared block
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 Etymology do
def self.after_foo
bar
end
end
end
It's because of the current implementation of
ExampleGroup.define_shared_group_method, which evaluates the shared example
block before the customisation block:
shared_group = describe(#{report_label} \#{name}, shared_block)
shared_group.class_eval(customization_block) if customization_block
(This is behaviour I found surprising.)
However, with a little more metaprogramming jiggery-pokery, you can have them
evaluated in the other order:
module RSpec
module Core
class ExampleGroup
# ...
def self.define_shared_group_method(new_name, report_label=nil)
report_label = it should behave like unless report_label
module_eval(-END_RUBY, __FILE__, __LINE__)
def self.#{new_name}(name, customization_block)
shared_block = world.shared_example_groups[name]
raise Could not find shared example group named
\#{name.inspect} unless shared_block
compound_block = lambda do |*args|
module_eval customization_block if customization_block
module_eval shared_block
end
shared_group = describe(#{report_label} \#{name},
compound_block)
shared_group
end
END_RUBY
end
# ...
end
end
end
Would this be a useful improvement to RSpec 2? Any opinions on the order of
the block evaluation for shared examples?
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Evaluating shared example customisation block before shared block
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 group describes it accurately anyway. Cheers Ash [1] http://github.com/rspec/rspec-core/issues/issue/99 -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] rspec 1 - nested examples (in an each block) use the final block variable 4 times instead of each of the 4 once
On 30 Jul 2010, at 10:00 PM, nruth wrote:
http://gist.github.com/501296
I don't think anything needs to change, though a wrapper function
(each + an inner describe) might help flag it as a possible pitfall.
Hi Nick
I think the before + ivar pattern (below) is on its way out. At least, I
consider it deprecated in my head:
describe before do
before(:each) { @foo = bar }
before(:each) { @foo = baz }
it does this do
@foo.should eq baz
end
end
But the new syntax does indeed let you redefine `let` blocks.
describe let do
let(:foo) { bar }
let(:foo) { baz }
it does this (currently) do
foo.should eq baz
end
end
Arguably, this is not the most desirable behaviour, as it leads to
silent/confusing failures, as you've seen. Maybe it would be better if this
raised an error? (Which is only an option with `let`, not with ivars.)
Also, when combined with shared examples, this could conceivably be used to
violate the Liskov Substitution Principle (if the LSP applies to specs). While
Ruby as a language lets you redefine stuff at will, I'm not sure that's
appropriate here. I can't imagine wanting to redefine a let, instead of
factoring it out properly. Anyone got any thoughts on that?
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] RSpec 2 example group block scope
Hi again
As part of the refactoring I'm doing, I'm writing out quite a bit of
metaprogramming. The easiest way to prove constant lookup is working is to
create a new class in an example group, and use its name. But the scope of the
example group definition appears to be the containing module, which gives the
following behaviour:
module MyModule
describe MyClass do
class TestClass; end
# This passes
it has access to the test class do
expect {
TestClass
}.to_not raise_error
end
# This fails
it hides the test class somewhere? do
TestClass.name.should_not eq MyModule::TestClass
end
end
end
module MyModule
describe MyClass doing something else do
# This fails
it has a different scope to the example above do
expect {
TestClass
}.to raise_error(NameError)
end
end
end
I've got a few questions:
* Is this intended behaviour, or just merely the way RSpec 2 happens to work?
* Would a more unique scope be useful? (To me it would, obviously... don't know
about the tradeoff in general though)
* Has this changed since RSpec 1.3? (I guess I could install and find out...)
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Formatting shared example descriptions with test data
On Jul 26, 2010, at 8:55 am, Wincent Colaiuta wrote: Seems to me that including the same shared example group twice in the same describe block is a bit of an abuse, to be honest. I don't think it was ever really intended to be used in that way. You're right, it clearly wasn't intended for this. I'm trying to find the best way to express the behaviour I want without bending the current syntax of RSpec too much. This is indeed a toy example, so let me explain the real situation in more detail. I'm doing a small side project to make a checklist app. As part of that, I'm trying to extract out a library similar to Naked Objects[1]. One of the things that can be factored out is collections inside entities. So I currently have, as examples: class User extend DomainLib::Entity::ClassExtensions include DomainLib::Entity::InstanceExtensions collection :checklist_templates, of: :checklist_template, class_name: ChecklistTemplate end and class ChecklistTemplate extend DomainLib::Entity::ClassExtensions include DomainLib::Entity::InstanceExtensions collection :items, of: :item, class_name: ChecklistTemplateItem end Now one of the thing that bugs me about using ORM (eg ActiveRecord, DataMapper) features for this is you're then faced with the dilemma of do you do an integration test of the collection functionality, which duplicates a lot of the testing effort put into the ORM, or do you mock this out, and risk having false positives because the ORM behaves differently than your test setup assumes? The solution I'm playing with is to extract shared contract (ie shared example groups) that you can mix into a spec for a host class (eg User, Checklist) above to prove the feature (here collections) works, without reference to the implementation. (The specs inside DomainLib prove the general case.) With the help of this spec_helper incantation: module SpecHelperObjectExtensions def contract(name, block) shared_examples_for(name, block) end end include SpecHelperObjectExtensions RSpec.configure do |c| c.alias_it_should_behave_like_to(:it_satisfies_contract, 'satisfies contract:') end I've already been able to extracted contract, which is for Representation (basically, a view object that isn't much more than a Struct): # Params: # * representation_class # * properties contract Representation do # ... # Setup and other examples omitted # ... describe #== do it is true for Representations with the equal attributes do representation_class.new(default_attributes).should eq representation_class.new(default_attributes) end it is false if any property is different do properties.each do |property| representation_class.new(default_attributes).should_not eq( representation_class.new(default_attributes_with_different_value_for(property)) ) end end end end This is fine for a class, but the behaviour I want to prove with a Collection needs to be mixed in once per collection, eg (the last two are made up): describe User do it_satisfies_contract Entity Collection, for: checklist_templates it_satisfies_contract Entity Collection, for: groups it_satisfies_contract Entity Collection, for: delegated_actions end describe Integer do [1, 2].each do |i| describe i do it_should_behave_like 'Comparable' end end end ... I know you probably have some real example in mind hiding behind that toy example, but I believe anything you want to test can be written in the same way (ie. without needing to inject the i into your shared examples). So as you can see, in the real (non-toy) example there's no object to be described: it's an aspect of behaviour of the test subject, and one than can occur N times. I'm aware that I'm twisting RSpec quite a bit to try to achieve this. If you (or anyone) have any thoughts though, I'd love to hear them. This one is messing with my head a bit :) Cheers Ash [1] http://www.nakedobjects.org/ -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Formatting shared example descriptions with test data
On Jul 26, 2010, at 3:44 pm, Wincent Colaiuta wrote:
Personally I wouldn't do this. It makes it harder for anybody coming to your
project to understand what's going on, because they see this contract 'foo'
do construct and don't know what it is unless they dig into your
spec_helper. If you really want the word contract to appear in there I would
just write the shared examples like this:
Actually, this doesn't bother me. All the commercial development I do is
pair-programmed, so it doesn't take long for anyone new to a project to pick
things like these up. I prefer to improve the semantics at the expense of some
initial learning cost. (As it happens, this isn't a commercial project anyway,
it's just something I'm doing on the side for my own benefit.)
So if I'm reading you correctly, this is where the aspect of behavior that
can occur N times comes in, right? AFAIK the typical way to do this is via
macros (ie. generating examples on the fly, typically keeping to examples
of one assertion per iteration of the loop). So it's just a minor tweak of
what you've got there:
properties.each do |property|
it is false if #{property} is different do
...
end
end
If you mean by using a custom matcher in there, then yeah, I get you. But as
this is more extensive, shared examples (which prove many individual pieces of
behaviour) seemed a better fit than a matcher (which are intended to prove just
one).
But alas, this pattern won't work with shared example groups. I don't know of
any way to pass the properties variable in this case, and even if you could
it wouldn't work anyway because, AFAIK, the shared example group is itself
only evaluated once when the file is first read. It isn't re-evaluted each
time it is included in another example group. At least, that's my
understanding of it. I might be wrong about that. So, looks like you're stuck
with having multiple assertions inside a single it block.
Hmmm, if that's the case, then this approach won't work anyway. But I'll
investigate... it depends on the implementation. This is one of the things I
want to find out.
This is fine for a class, but the behaviour I want to prove with a
Collection needs to be mixed in once per collection, eg (the last two are
made up):
describe User do
it_satisfies_contract Entity Collection, for: checklist_templates
it_satisfies_contract Entity Collection, for: groups
it_satisfies_contract Entity Collection, for: delegated_actions
end
Here the standard way of parametrizing this would be via blocks (standard
in inverted commas because the ability to pass a block here is such a recent
addition to RSpec).
Yeah, I'm doing that to get the necessary objects inside the shared example.
But as you pointed out, the scope inside example groups and inside the examples
themselves are very different.
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problem running RSpec tests with Rails
On Jul 26, 2010, at 5:12 pm, Bruno Cardoso wrote: Not sure if this is a RSpec problem or Rails but I believe is more a RSpec situation. What happens is that when I run my RSpecs tests all the BD is recreated, ... Anyone know how to resolve this? Hi Bruno Are you running `rake spec` as opposed to the spec command? The default Rails spec task depends on the db:test:prepare task, which bombs your DB. I fixed this in my project with a file lib/tasks/rspec_fixes.rake: class Rake::Task def overwrite(block) @actions.clear enhance(block) end end Rake::Task['db:test:prepare'].overwrite do # We don't want to run migrations or load the schema!!! end HTH Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problem running RSpec tests with Rails
On 26 Jul 2010, at 6:36 PM, Bruno Cardoso wrote: What both solutions (from Ashley and David) do is not modify the BD in anyway, so nothing gets dropped and nothing is created. This resolves the problem but what if I want a clean installation in each test run? Is there a way to keep my schema_migrations table or remove the check for migration scripts? I would still like to recreate the rest of the tables. One way is to avoid rake entirely - you could run the specs with `spec spec` or even just use autotest[1]. If you want to just empty the data from the tables you need database_cleaner[2]. If you want the database rebuilt as necessary when migrations change, you could use my database_resetter[3], plug plug :D Let me know if you're trying to do something other than one of these. (It's late, I have a habit of talking nonsense when I'm tired...) HTH Ash [1] eg http://ph7spot.com/musings/getting-started-with-autotest [2] http://github.com/bmabey/database_cleaner [3] http://rubygems.org/gems/database_resetter -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] rspec-orm and _not_ mocking models
On 21 Jul 2010, at 10:28 PM, Costa Shapiro wrote: (Surprisingly?) I find mocking AR (DM less so) in specs extremely tedious _and_ intrusive. Yeah, I know what you mean, I just don't do it any more. I find the pain isn't worth it on the stuff I do. I think the README there pretty much cuts it, so I'd just welcome the comments here. One very minor point, you're got a comment to maybe empty the database afterwards. It's more useful to empty it before, as then you've still got the data in the database after a failing example. Also, if you haven't seen it, Ben Mabey wrote a tool for this[1]. Oh and I wrote one for rebuilding your database if migrations change[2], plug plug :D Ash [1] http://github.com/bmabey/database_cleaner [2] http://rubygems.org/gems/database_resetter -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] newbie: how to preserve NoMethodError under stubbing?
On 24 Jul 2010, at 2:52 PM, Wincent Colaiuta wrote: How about this: f.stub.existing(:bar) That's probably RR influencing me there, which employs things like stub.proxy and so on. So maybe not such a good idea for rspec-mocks. Another option might be to deprecate #stub! as an alias for #stub and then bring it back as an equivalent to `stub.existing` above. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Parameterised shared examples / metadata in examples (RSpec 2)
Hi
Warning: this goes on quite a bit. It contains early-morning caffeinated
ramblings and many hmmm I wonder what this does... snippets.
I'm looking for the best way to parameterise shared examples. Imagine (as an
academic example...) you were doing it for subclasses of Struct instances (a
more realistic example might be ActiveRecord subclasses, or DataMapper
resources), such as:
class MyStruct Struct.new(:a, :b)
end
class MyOtherStruct Struct.new(:foo, :bar)
end
I've seen it done with #let, eg:
shared_examples_for a Struct do
it has methods do
properties.each do |property|
struct.should respond_to(property)
end
end
end
describe MyStruct do
let(:struct) { MyStruct.new }
let(:properties) { [:a, :b] }
it_should_behave_like a Struct
end
describe MyOtherStruct do
let(:struct) { MyOtherStruct.new }
let(:properties) { [:foo, :bar] }
it_should_behave_like a Struct
end
Which is not a bad solution, but does feel a bit too much like using (scoped)
global variables for my liking. There's no explicit association between the
shared examples and their parameters (and the arguments actually passed in each
example group.
So I started to wonder if this could be done with metadata. My first naive
stab was this:
describe MyStruct do
it_should_behave_like a Struct, properties: [:a, :b]
end
But this fails:
Could not find shared example group named {:properties=[:a, :b]}
Anyway, I dug in a bit and found that the metadata is only available to the
example group anyway, not the examples themselves. So you can't do:
describe MyStruct, properties: [:a, :b] do
let(:struct) { MyStruct.new }
it has methods do
metadata[:properties].each do |property|
struct.should respond_to(property)
end
end
end
But (more digging), you can do this:
describe MyStruct, properties: [:a, :b] do
let(:struct) { MyStruct.new }
it has methods do
example.metadata[:properties].each do |property|
struct.should respond_to(property)
end
end
end
Which means I can get this close to my original dreamed-up syntax:
shared_examples_for a Struct with metadata do
it has methods do
example.metadata[:properties].each do |property|
struct.should respond_to(property)
end
end
end
describe MyStruct, properties: [:a, :b] do
let(:struct) { MyStruct.new }
it_should_behave_like a Struct with metadata
end
I don't object so much to having struct floating around, as it's fairly safe
to say all the shared examples will depend on #struct being available.
Although, arguably, #subject would be better:
shared_examples_for a subject Struct with metadata do
it has methods do
example.metadata[:properties].each do |property|
subject.should respond_to(property)
end
end
end
describe MyStruct, properties: [:a, :b] do
subject { MyStruct.new }
it_should_behave_like a subject Struct with metadata
end
or even:
shared_examples_for a subject Struct with metadata do
metadata[:properties].each do |property|
it { should respond_to(property) }
end
end
describe MyStruct, properties: [:a, :b] do
subject { MyStruct.new }
it_should_behave_like a subject Struct with metadata
end
I tried to be a bit clever to see if I could clean up the example definitions
in the shared spec, but I got this far before hitting weirdness that was beyond
my understanding of RSpec (and the reach of my spade...). But, this was a bit
of a tangent anyway:
shared_examples_for a subject Struct with metadata do
metadata[:params].each { |key, value| define_method(key) { value } }
p self.inspect # outputs nil (!!!)
properties.each do |property|
it { should respond_to(property) }
end
end
describe MyStruct, params: {properties: [:a, :b]} do
subject { MyStruct.new }
it_should_behave_like a subject Struct with metadata
end
So... after all this, I just wondered if anyone had any ideas what the best
way to achieve this is, and how it could be extended.
For example, would there be any merit in being able to write:
it_should_behave_like a Struct, properties: [:a, :b]
?
Also I figure that as the metadata system is new, it's potentially unfinished
and/or in flux. What are the plans/intentions/opportunities for expansion for
it?
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Parameterised shared examples / metadata in examples (RSpec 2)
On Jul 23, 2010, at 8:57 am, Wincent Colaiuta wrote:
Recently commited (RSpec 2.0.0.beta.18) was the ability to pass a block to
it_should_behave_like, making the relation clearer; eg:
describe MyStruct do
it_should_behave_like 'a Struct' do
let(:struct) { MyStruct.new }
end
end
I did ask about parametrizing that explicitly via metadata, but David feels
that the block based approach is better; see the full thread here:
http://github.com/rspec/rspec-core/issues/71
And I only just tweeted about that ticket too! I didn't review it all though,
I just saw the aliasing (which I currently do by hand).
That's in beta 18 then? Pretty sure I just got that when I updated this
morning. Will play around with it later...
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] How are people speccing Rails 3 ActiveRecord queries?
On 17 Jul 2010, at 4:37 PM, doug livesey wrote: At the minute I'm chaining a load of should_receive calls on mock relation objects I've found this can cause pain in so many ways: * Your tests end up coupled to the database structure (as that's how most associations are inferred) * You're at the mercy of the implementation of the association proxy (I've found this more problematic with DataMapper, whose associations haven't always behaved quite how I expected them to...) * You can easily end up with a lot of setup duplication I've had enough pain from this that I now refuse to mock *any* ActiveRecord (the library or the pattern) code. It's arguably a violation of Don't Mock Types You Don't Own anyway. HTH Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] How are people speccing and cuke-ing Paperclip (with S3)?
On 17 Jul 2010, at 5:58 PM, Steve Klabnik wrote: You don't need to test Paperclip's ability to put files to S3 It depends on your confidence in Paperclip (s/Paperclip/X random library) and the severity of problem it could cause if it doesn't work. To me, at least, it's more a risk/value judgement than a binary decision. If millions of pounds rested on Paperclip uploading files to the right place, I'd test the hell out of it before using it in my own app! Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] How are people speccing and cuke-ing Paperclip (with S3)?
On 17 Jul 2010, at 5:43 PM, doug livesey wrote: Please tell me they're doing *some*thing, as I'm using S3 storage, which would really slow my tests down if I just did nothing. I'm starting to think of all sorts of horrible solutions, like making the storage strategy dependent on the environment, like using the file system if it is a test or cucumber env. For absolute confidence, you can use S3 for a full integration test. You only need one of these for each type of interaction with S3 though. For faster local integration tests, you could write a mock implementation of S3. I've not used Paperclip, but it looks like it works as a DSL embedded into ActiveRecord class definitions. That'll make it a lot harder to separate out the file handling that if you were writing it out explicitly. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] [ANN] ShRUG 8, Mon July 12th: Introduction to RSpec
Hi all Reposting this for the benefit of anyone who may be able to attend but wouldn't normally see ShRUG announcements. ShRUG is the Sheffield (UK) Ruby User Group. ShRUG July 2010 is now confirmed. Ashley Moran (that's me) of PatchSpace Ltd (that's also me, really) will be running an introduction to RSpec, a powerful and mature BDD/testing library for Ruby*. No RSpec or unit testing experience is necessary, as we will be starting from first principles, but knowing basic Ruby will help. We're at the new GIST Lab in Sheffield, which is part of the Workstation. Turn up at 6.30pm for a 7.00-9.00pm presentation. Followed by general pubbage activity as usual. Details and map available on the ShRUG site: http://shrug.org/meetings/shrug-8/ You can keep updated via our Twitter account too: http://twitter.com/shruggers If you're going please sign up for a ticket here: http://shrug8.eventbrite.com/ You don't have to get a ticket, but we like to know who's planning to turn up to predict numbers. See you there! Cheers Ash BTW - We're always looking for people to run sessions (short or long). If you have an idea please drop me a line. * You all know that :) This announcement was originally prepared for the local mailing lists... -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] [ANN] database_resetter 0.1.0
Hi all Apologies for cross-posting and spam in the same post. Hopefully you'll let me off this once... I just released my first gem (woo!), database_resetter[1]. It's designed to completely rebuild your Rails/Merb etc database before a Cucumber/RSpec every time a migration changes. Basically it prevents you seeing unknown column etc errors because you forgot to migrate the DB before a test run. It's complementary to, not a replacement for, database_cleaner. database_resetter runs 0-1 times per Cucumber/RSpec run, whereas database_cleaner runs 0-1 times per Cucumber scenario / RSpec example. I've been using it for a year or two, but only just got round to packaging it up. It doesn't do much, but over hundreds of database rebuilds the time savings add up to a fair bit. I've used it untested* until now, but I spent today putting some Cucumber features around it. They aren't perfect, but they sanity check most of what it does. There's a ReadMe in the gem with full instructions (they're as good as I could manage after a long day). The official source is in a darcs repo hosted on Patch-Tag[2]. Feedback gratefully received - let me know if you find it useful, and please contact me with bug reports / feature requests. Like I say, this is my first gem, so I'm not expecting it to work well in the wild... Cheers Ash [1] http://rubygems.org/gems/database_resetter [2] https://patch-tag.com/r/ashleymoran/database_resetter/home * it works on my machine -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Colour support in RSpec 1.3 with Spork
Hi I can't find any reference to this being a known issue or not. I'm having to work on a Rails 2.3 project for a bit, so I'm back with RSpec 1.3. I've got Spork working and I'm running it with this command: ruby -S spec --drb --colour --format progress -o spec/spec.opts ... But I only get a monochrome output. Any idea what might be going on? Thought I'd ask here as it seems more RSpec- than Spork-based. Cheers Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Spork
On Mar 29, 2010, at 9:04 pm, David Chelimsky wrote: How wide-reaching are your changes? i.e. how many files, etc? I think it's only really the Runner stuff that's changed. I've split it into InProcess and DRbProxy or some such... although I think really the DRb stuff belongs higher up. This is an interesting catch 22. The dependency appears to be from Spork to RSpec (i.e. RSpec doesn't know about Spork), but RSpec needs to commit to an API so support Spork, which is very likely the only tool that needs this API. I wonder if we got the dep backwards? i.e. why not have Spork expose and API and have RSpec hook into it? Yep catch 22 indeed! It's a circular dependency. The way it works is Spork defines a DRb interface that takes arguments and the output streams. RSpec and Cucumber are both using this the same way. Seems like a stable interface so this dependency isn't a problem. Prob is that then Spork needs to know what to do to use RSpec. Currently that involves (and Cucumber does the same) just passing the ARGV along. Which felt weird to write - because at the point you want to pass the ARGV along you've already parsed it to find out if it's a --drb run*. But in theory you could pass anything as the args as long as the `Rspec.my_stable_api` call accepts it. One thought I had was that maybe the join should be separate... ie have independent gems rspec-core and spork, and spork-rspec, spork-cucumber, spork-testunit etc that depend on both. The prob with this is that while Spork is open to extension to new test frameworks, it doesn't provide an easy way to register them before Spork loads**. Seems to come down to *is* Spork the only thing that would need this API? Would you maybe want to run specs directly in eg Redcar? If not then I think you've talked me round that the dep is backwards. But Spork would need refactoring for RSpec to be able provide its own Spork adapter. Any thoughts based on that? If I'm wrong about this, I'd prefer to make it RSpec, since that's the name of the book and all :) Anybody have insights/opinions on this? That's why I asked now, incase RSpec 3 changes it again and the circular dep bites once more ;) Cheers Ash * I'm not sure it's an easy one to solve because you have to figure out when to read in spec.opts. ** Sorta like how gem subcommands (eg gemedit) work. I'd love to know how that mojo does its stuff :) -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Spork
Hi Hopefully I'll get chance to finish Spork integration with RSpec 2 this weekend. I've got two questions... (1) What's the best way to merge my changes back in? My shockingly bad Git-fu has made it impossible to rebase on top of master. I suspect having a (now disabled) Textmate macro to clean EOL whitespace has not helped. I've restructured some code - I plan to do a proper refactoring when it all joins up (ie when I see Rails 3 working) but I'd rather get Spork merged as soon as it's runnable in case I make life even harder for myself. I know know that the Spork interface expects you to provide an argv and out/error streams when you call its DRb interface. It then calls the CLI interface to RSpec. This is one reason RSpec 2 integration is harder than I thought, because that RSpec API has been rewritten (and is much better now I've seen both). So... (2) Is there a stable API call we can settle on for this going forward? I was thinking along the lines of `Rspec.run(argv, err, out)` or `Rspec.run_command(argv, err, out)` or something. Any ideas? (2.5) Any reason why the new RSpec module is Rspec not RSpec? /grammarnazi Cheers Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Spork in RSpec 2
Hi I've just started using RSpec 2 in Rails 3 and I'm incredibly frustrated by the time it takes to boot Rails, it's a real TDD bottleneck. The obvious solution is Spork, which is currently not possible with RSpec 2 because it lacks DRb support[1]. I've cloned RSpec and I'm about to start working on DRb in RSpec 2, but I thought I'd fire this off to ask... * is anyone else also working on it? I don't want to duplicate effort. * are there any potential issues that people with RSpec 2 knowledge can forsee? I don't want to lose time on known gotchas. If the answer to both is no I'll dive in :) Cheers Ashley [1] http://github.com/rspec/rspec-core/issues#issue/2 -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Spork in RSpec 2
On Mar 10, 2010, at 1:46 pm, David Chelimsky wrote: AFAIK, no. Please add a comment to the issue saying you're working on it. Done. * are there any potential issues that people with RSpec 2 knowledge can forsee? I don't want to lose time on known gotchas. * You will need the other gems installed in order to work on rspec-2. Think I have that all sorted. BTW when did you start using watchr? It's new to me. I notice it runs specs blindingly fast, which I like :-) Why that over (the new ZenTest-free) autotest? There is no concept of a CommandLineRunner yet, nor does there necessarily need to be. i.e. don't add one just because that's how rspec-1 dealt with Drb, but if that seems like an easy direction and it solves the problem cleanly, go for it. I'll see what seems to fit. Don't expect me to come up with a good design first time though. Thanks for taking up the cause! No probs - I'll end up stabbing myself in the eye with a real spork if I have to watch Rails boot one more time =) Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] RSpec 2 / Rails 3 autoload
Hi For the last 18 months I've been used to writing specs like this, which was written with Merb 1.1.0.pre and RSpec 1.3: module LanguageRepository describe DataMapperAdapter do it_should_behave_like Contract: LanguageRepository def language_repository DataMapperAdapter.new end end end This will happily find and instantiate ::LanguageRepository::DataMapperAdapter from the models/language_repository folder. However, using Rails 3.0.0.beta from master and Rspec 2.0.0.beta.2, I get the following error: 1) LanguageRepository::DataMapperAdapter storage and retrieval can store a Language and retrieve it by code Failure/Error: DataMapperAdapter.new uninitialized constant Rspec::Core::ExampleGroup::NestedLevel_8::DataMapperAdapter I have to change it to this to make it work: def language_repository LanguageRepository::DataMapperAdapter.new end Now, having just changed two moving parts (RSpec and web framework) I'm not sure what correct behaviour is on anything. I don't know how Rails code auto-loading works, or how RSpec interacts with it. Is the above behaviour a bug or a misunderstanding on my part? Cheers Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rails3 + RSpec2 sample project?
On 7 Feb 2010, at 8:41 PM, David Chelimsky wrote: The a5 release only supports model and request (integration - a la merb) specs, but controllers, views and helpers will be coming soon. Well chop chop then, anyone would think you were working for free ;o) On a more serious note, I think the Rails 3 beta is the final trigger for me to switch from the (I'm sad to say) increasingly rusty Merb to Rails 3 / Ruby 1.9. It's clear there are a plenty of integration issues to work out. I'm currently spending at least half my time working on a project of my own, but I can't see that moving forwards until I have RSpec/Cucumber in place. So feel free to point me to relevant RSpec tickets and I'll work on those instead, in the mean time. Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] CRITICAL: Rspec gem install spec command not found!
On Feb 02, 2010, at 8:58 am, Kristian Mandrup wrote: Where should the spec command be found? Did you find it? -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] CRITICAL: Rspec gem install spec command not found!
On Feb 02, 2010, at 8:58 am, Kristian Mandrup wrote: Using brew as package manager kristian-mandrups-macbook-pro:rspec-coding kristianconsult$ spec -- help -bash: spec: command not found $ If you're using Homebrew[1] (?) you'll need to figure out where it's storing binaries. Run find / -name spec to locate the command. Then run echo $PATH and check that the directory containing spec is in the list. If not you'll need to add it in your .bashrc or something (I don't use bash). HTH Ashley [1] http://github.com/mxcl/homebrew -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Can I set an expectation that a method invokes super?
On Jan 28, 2010, at 5:49 pm, Rick DeNatale wrote: I'd like to write a spec to ensure that this doesn't regress, but my imagination is failing me as to how to do it. Any ideas? Yes: don't use inheritance for implementations. The bug you describe is arguably a violation of the Liskov Substitution Principle, ie the derived class changed the functionality it inherited in a way that broke the expected behaviour of all derived classes. If you can write a spec (possibly shared examples) that defines the contract you expect *all* controllers to follow - eg display an error page in this situation - you can run that against all your controllers. Checking that you call `super` doesn't necessarily give you this security. If you want to post #rescue_action_in_public there might be another way, depending on your code. I'm no Rails guru though. BTW if this sounds like a rant, it is :) I am constantly stamping my feet over the way controllers in Rails, Merb etc are implemented, as they make writing specs extremely difficult. Let me know if this is not clear as I've thrown the email together in a hurry before going home for the night... Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Message expectation that verifies result of passed block
On Jan 28, 2010, at 1:29 pm, Paul Hinze wrote: I believe the lack of ability to use this notation comes down to a ruby limitation, but I'm not sure. If that's the case, then we would need a specific argument expectation (along the lines of my suggestion) that executes in a context in which it can call the block. I can't find a solution, I suspect Ruby 1.8 can't do this, but I'm guessing. Can I ask why you want to do this though? As another example, it would be unusual to spec something like: @array = [1, 2, 3] @array.should_receive(:map).with(block_that_doubles_values) You'd instead check that the array that came out was [2, 4, 6]. Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Singleton classes
On Jan 19, 2010, at 2:33 pm, Juanma Cervera wrote: Yes, I mean the Singleton Pattern. I am not an expert with OO, but I supposed this pattern was what best fits my needs of a class that represent a unique resource in the system, in this case it's something like a queue of jobs that I have to administrate in real time. Am I right? What would be the implications of *not* using a singleton? Bear in mind that if you're writing a webapp, you will at some point have two of these objects simultaneously in different processes. What is the responsibility of the object itself, and where does the responsibility for enforcing that the resource is only used by one client at a time live? Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] default to just call the method?
On Jan 18, 2010, at 9:31 am, Pat Maddox wrote: define_simple_predicate_matcher :rise_from_the_ashes? As an extension, how about: define_simple_predicate_matcher :risen_from_the_ashes = :rise_from_the_ashes? Also, in general, I think specs look better without ? symbols on methods, my preference though Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] default to just call the method?
On Jan 18, 2010, at 3:12 pm, David Chelimsky wrote: I'd rather not add a new DSL for the few cases in which we want to essentially delegate a predicate. We can already do this with the matcher DSL: I think Pat was just suggesting Roger try this in his own code. It's not something I especially want in RSpec, that was just a suggestion how Roger could play with the macro idea. Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] default to just call the method?
On 14 Jan 2010, at 17:02, Rick DeNatale wrote: -1 You can already say a.should include(1:4) which is clearer IMHO. I assume Roger was referring to the general case though (which I still don't like) - and just happened to pick an example with an existing matcher. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] default to just call the method?
On Jan 12, 2010, at 10:49 pm, rogerdpack wrote: a.should include?(1:4) # if there's no matcher called include? then just call include? Am I right thinking that this would mean writing a method_missing that creates a matcher for every unhandled message on the example object (whatever scope the #it block runs in)? If so, that could produce surprising behaviour if methods were silently turned into matchers and ignored. Maybe if you restricted it to ? methods it would not be so bad. But then, that's the point of the be_* handler. The only problem is that #include? is a verb not an adjective/noun. Can't say I've come across many of them, so it might be better in these cases to just write a method #a_container_for? ? Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Testing .Net Newbie
On Jan 14, 2010, at 12:15 pm, David Chelimsky wrote: re: Integration testing, everybody has a different definition. Before Rails came along, the prevalent definition that I was aware of was testing the behaviour of two non-trivial components together. More recently, the definition that makes most sense to me comes from Growing Object Oriented Software [1]. I don't have the book in front of me, but from memory it is something like testing your code with other code that you don't have any control over. Because we need a database for all levels of Rails testing, this suggests that all Rails testing is Integration Testing. And yet, JB Rainsberger sticks absolutely uncompromisingly to the first definition[1]. I wonder if you could take it to yet another extreme and include tests for objects with private methods as integration tests. The thing I got most from GOOS is to protect all domain code with adapters. If all Rails testing is integration testing, that means a lot of duplication and coupling that could be reduced... I have yet to do it for real though. But GOOS is the book that convinced me it's worth trying. Ashley [1] http://www.infoq.com/presentations/integration-tests-scam -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Testing .Net Newbie
On Jan 14, 2010, at 1:17 pm, John Polling wrote: I think this is the part that I'm confusing myself with as most Cucumber information talks about using scenarios to drive the code out. So Cucumber comes first, whereas I used to do the Acceptance testing after all the other TDD stuff. Maybe that is me doing it wrong though. The book David mentioned earlier - before the one he wrote himself :) - GOOS[1] has a diagram on p40 that shows how the unit test cycle fits inside the acceptance test cycle. You can extend this to as many layers as you like. I wrote a blog post which has a pretty picture of the idea[2]. Ignore the text, it's long and rambling and is about something else. I thought it was a great insight, until I realised Kent Beck wrote about self-similarity something like 5+ years ago[3]. Ashley [1] http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 [2] http://blog.patchspace.co.uk/2009/12/customers-input-and-russian-doll-of.html [3] http://www.goodreads.com/book/show/67833.Extreme_Programming_Explained_Embrace_Change -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Problem with should_not when passing a multipleargs to a matcher
On 7 Jan 2010, at 19:15, David Chelimsky wrote:
Cool. I'm not sure when I'll get to this, but I'm pretty sure this would work
for you for now (untested):
Spec::Matchers.define :include_all do |*expected|
match do |actual|
expected.all? {|e| actual.include?(e)}
end
end
Spec::Matchers.define :include_any do |*expected|
match do |actual|
expected.any? {|e| actual.include?(e)}
end
end
Hi Ben/David
If it's any help, I've been using three extra matchers for a while now:
* include_all_once
* include_all_at_least_times
* include_any
I've put them in a gist[1], as the code to produce the error messages makes
them a bit verbose.
HTH
Ashley
[1] http://gist.github.com/271475
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] more verbosity for be_an?
On 30 Dec 2009, at 20:19, David Chelimsky wrote: What about something like: expected #Class:2158174640 = Fixnum to be a kind of Fixnum That is more aligned with other failure messages. WDYT? I like that. You have to read the current message _very_ carefully to see what it's actually saying. Thinking about it though, isn't the current format wrong anyway? Fixnum is the kind of 1 sounds (torturously) correct. For want of ability to say what I mean in terms of types, here are examples instead: Integer is a kind of Object* Object.new is an (instance of) Object Integer is a(n instance of) Class Fixnum is a kind of Integer 1 is a(n instance of) Fixnum Gets a bit harder with modules though: [] is an (instance of) a Class that includes Enumerable [] is Enumerable (second one only works if the module name is an adjective) * Actually, this satisfies both definitions, as Integer is an instance Class, which is an Object... And just out of curiosity, Roger, what's your use case? I can't remember ever using be_a/be_an, at least not in any code that has survived. Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Submitting a Custom Matcher: gem or other method?
On 29 Dec 2009, at 15:59, David Chelimsky wrote: I started http://wiki.github.com/dchelimsky/rspec/matcher-libraries. Please feel free to modify/add. I like! A wiki solves 90% of problems like this with 2% of the effort. I hadn't realised the wiki had moved along - unlike Cucumber, I still see the static site as the primary reference. Wasn't expecting you to drop everything and build a matcher hosting platform :) Cheers Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Submitting a Custom Matcher: gem or other method?
On 28 Dec 2009, at 16:27, David Chelimsky wrote: For most users, gems are the easiest answer. By all means, host source on github if you want people to contribute, or have a place to inspect code, but you don't need a public source repository in order to push gems to gemcutter. A standard location for RSpec matchers would be pretty handy though, WDYT? -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] no should raise_exception
On Dec 20, 2009, at 6:07 am, Elliot Winkler wrote:
raise_error already catches any type of exception, error or not:
class BlahException Exception; end
class BlahError StandardError; end
lambda { raise BlahException }.should raise_error(BlahException)
lambda { raise BlahError }.should raise_error(BlahError)
lambda { raise blah }.should raise_error(RuntimeError, blah)
Although it would be unusual to catch non-Error Exceptions in most cases? Most
indicate unrecoverable failure; only the SignalException looks like something
you might want to catch - I don't know, though. I assume you'd normally
register a handler for that.
Ashley
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] State-based expectations (as per jMock in GOOS)
On 18 Dec 2009, at 14:46, Tom Stuart wrote: Can you elaborate? From a position of no knowledge, the most obvious question to me is: why would I care about the state of O? Either the change in O's state is observable through its behaviour (in which case I specify that behaviour) or it's not (in which case I don't care). On further investigation (aka reading up to chapter 24) it's apparent that this state-based testing is effectively a flexible form of message expectation ordering. What's clever is that it gives an intermediate level between no ordering and sequential ordering. It's like ordering sets of expectations, at least that's how it appears to me at first glance. Worth more investigation, I think... Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] State-based expectations (as per jMock in GOOS)
Hi all I'm working my way through Growing Object-Oriented Software[1], currently at the start of chapter 15. Chapter 14 introduces a concept I haven't seen before, state-based expectations based on sent messages. The principle appears to be object O has sent message M = O is in state S followed by O is in state S = (expectation E met) passes spec O is not in state S = (expectation E met) violates spec Has anyone tried this with RSpec (mocks) yet? Just wondered if it was doable with the current syntax support or would need an extension. I thought I'd fire this off now to get ideas, as I won't be coding using this technique until I've finished the book (a week at least, I imagine). Cheers Ashley [1] http://www.amazon.co.uk/gp/product/0321503627/ -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] State-based expectations (as per jMock in GOOS)
On Dec 18, 2009, at 2:46 pm, Tom Stuart wrote:
Can you elaborate? From a position of no knowledge, the most obvious question
to me is: why would I care about the state of O? Either the change in O's
state is observable through its behaviour (in which case I specify that
behaviour) or it's not (in which case I don't care).
The example given is for an auction sniper (S). So,
Given S has just notified one of its listeners that it's bidding
When S is informed that a bid has been made by a competitor
And the auction is closed
Then S should notify its listeners that it lost the auction
Given S has just notified one of its listeners that it's bidding
When S is informed that its bid is highest
And the auction is closed
Then S should notify its listeners that it won the auction
The last one looks like the code below in Java[1], but note this is further on
from the code in chapter 14.
Interestingly, writing it as GWT transforms the style of the expectations. eg,
When S is informed that a bid has been made by a competitor
replaces (something like)
Allow S to notify its listeners that it's in the bidding state
Am I making sense? Not sure if these examples capture the essense.
Ashley
@Test public void
reportsWonIfAuctionClosesWhenWinning() {
allowingSniperBidding();
allowingSniperWinning();
ignoringAuction();
context.checking(new Expectations() {{
atLeast(1).of(sniperListener).sniperStateChanged(
new SniperSnapshot(ITEM_ID, 135, 135, WON));
when(sniperState.is(winning));
}});
sniper.currentPrice(123, 12, PriceSource.FromOtherBidder);
sniper.currentPrice(135, 45, PriceSource.FromSniper);
sniper.auctionClosed();
}
private void allowingSniperBidding() {
allowSniperStateChange(BIDDING, bidding);
}
private void allowingSniperWinning() {
allowSniperStateChange(WINNING, winning);
}
private void allowSniperStateChange(final SniperState newState, final String
oldState) {
context.checking(new Expectations() {{
allowing(sniperListener).sniperStateChanged(with(aSniperThatIs(newState)));
then(sniperState.is(oldState));
}});
}
[1]
http://github.com/sf105/goos-code/blob/master/test/unit/test/auctionsniper/AuctionSniperTest.java
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] should_receive(:x).at_most/exactly... ignored when method is previously stubbed?
On Dec 01, 2009, at 4:46 pm, Lenny Marks wrote: This seems dangerous to me. Assuming I hadn't initially stubbed in the before block and everything worked as expected, if someone later stubs :lookup in the before block because they are adding new examples that don't care about it, my explicit example becomes misleadingly useless. Does this surprise anyone else? Hi Lenny Yes it does, so much so that I filed a ticket[1] :) Well, I think it's the same issue. If so, maybe you'll find the discussion between me and David useful. HTH Ashley [1] https://rspec.lighthouseapp.com/projects/5645/tickets/618-exactlyntimes-incorrectly-failing-for-n-actual -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] should_receive(:x).at_most/exactly... ignored when method is previously stubbed?
On Dec 01, 2009, at 7:34 pm, Lenny Marks wrote: Thanks Ashley. I added my 2 cents to the ticket. Just had a look over your comments. It's a complicated issue... I hope David can reconcile it. I'm not sure what the best solution is. Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] surprising...
On Nov 29, 2009, at 6:33 am, rogerdpack wrote: It is somewhat surprising to me, as a newbie, to have to assert a.should be_a(Hash) Hi Roger Once you see the matcher (ie be_a) as something that returns a matcher object, it makes a lot more sense. My brain is now wired to give much more weight to the thing on the right. You might find it instructive/enlightening/life-changing (possibly) to have a go at writing some custom matchers. From the RSpec docs[1]: bob.current_zone.should eql(Zone.new(4)) becomes - bob.should be_in_zone(4) which is implemented with - Spec::Matchers.define :be_in_zone do |zone| match do |player| player.in_zone?(zone) end end Although I've just realised that RSpec's dynamic be_* matcher actually gives you that for free... HTH Ashley [1] http://rspec.rubyforge.org/rspec/1.2.9/classes/Spec/Matchers.html -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Introductory recommendations?
On Nov 25, 2009, at 6:38 pm, Matt Wynne wrote: +1 And have a coding dojo ASAP. It's much easier to learn when you're having fun. On 25 Nov 2009, at 18:07, Pat Maddox wrote: Pair with them. How big's the team? Lots of ways you can do this. +2 +1 For the pairing, it's the most efficient way to share knowledge. But I suggest making it clear it's training. I've done it where the other person was under the impression that the point of the exercise to produce production code, and became frustrated with how slow it is. +1 For the Coding Dojo (which involves pairing anyway). Had no idea how much fun these are until I ran one. It's especially valuable for the amount of cognitive dissonance it generates - pretty much every line of code is a point of discussion. I think that given the task of training a team of 5 now, I'd give serious thought to a Coding Dojo on a Friday, then pairing with each developer the next week. Or maybe, facilitating pairs pulled and rotated from the team (ie three people at a workstation). Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Using Mock / Datamapper / Associations
On Nov 13, 2009, at 6:04 pm, Arco wrote: Is there a way to mock the Org object, without having to require it in my test setup ?? Hi Arco Are you running the spec through something that loads a code loader (eg: for my specs, spec_helper.rb starts Merb in the test environment), or just running that one file on its own? That's the simplest way I can think this would be failing. Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] lambda Should Change Behavior Failing When Checking Time
On Nov 08, 2009, at 10:39 am, Rodrigo Rosenfeld Rosas wrote: @post.published_at.should be_nil @post.publish! (Time.now - @post.published_at).should have_at_most(1).second FWIW, this is what I do too, although I normally use should or be_close, but the idea is the same. You only need to worry about more accuracy than that if it's time-critical. Also, I've found meddling with Time breaks RSpec's timing - don't know if that's still the case. For times when I really care about timing, I've made a Clock class, and have everything use that, instead of Time directly. Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] at_exit in spec file?
On Oct 28, 2009, at 9:42 pm, David Chelimsky wrote: Sorry about that :( And thanks, Ashley, for righting (and writing) my wrong. No probs. I'm trying to answer the straightforward technical questions, at least non-Rails ones. To people who have clearly tried to help themselves first of course :) Hopefully will free up other people's time. But, is it me, or is rspec-users quieter than it used to be? I'm sure when I was learning the volume of questions was much higher. Are there fewer people using RSpec? Or is it just more stable and well- documented now? (Maybe I'm just imagining it anyway.) Ashley -- 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
Re: [rspec-users] HOWTO: Background tasks during test (ugly)
On Oct 29, 2009, at 3:09 am, Student wrote: I am writing a script that reads connection information from a config file, and based, on what it finds, connects to multiple mysql servers and performs tasks. To test this script, I need to set up test servers, but getting them running without causing the tests to be rerun when they stop is a bit..tricky. I cannot say that I'm proud of it, but here is how I did it: Is this because of autospec? If so, you can modify the files autotest watches. Or, you could do the server stuff in a tmpdir[1] directory. Let me know if I'm off-target - I can't see the definition of `datadir` in your snippet. Ashley [1] http://www.ruby-forum.com/topic/169054 -- 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
Re: [rspec-users] HOWTO: Background tasks during test (ugly)
On Oct 29, 2009, at 12:28 pm, Student wrote: No autoscript here. I don't doubt that there are wrappers that might handle it, I was going for a solution in a bare rspec environment. Still not sure I understand the problem. Can you explain what you mean by getting them running without causing the tests to be rerun when they stop is a bit..tricky? Can you paste output to illustrate this? Ashley -- 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
Re: [rspec-users] at_exit in spec file?
On 29 Oct 2009, at 13:58, Tom Stuart wrote: On 29 Oct 2009, at 13:46, Stephen Eley wrote: Everyone's busy programming. 8- I imagine the book helps a bit, too. The book pretty much replaces the slides I did for my mocking presentation, and may do the same for the rest of my consulting work =) Burn all the copies! And print the PDFs out and throw them on the fire!!! Ashley -- 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
Re: [rspec-users] spec failing to run specs when spec.opts is present on 1.2.9
On 29 Oct 2009, at 08:28, Paul Carey wrote: If I create a new merb app (1.0.12) and model and then run rake spec, all is well. However, if I copy its spec_helper into my own app, the problems listed above appear. So I think the source of the issue lies somewhere else. Have you upgraded the old app to Merb 1.0.12? If not, what version is it on? Ashley -- 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
Re: [rspec-users] at_exit in spec file?
On 28 Oct 2009, at 20:42, Student wrote: So now I'm back to the undefined method `after' for main:Object (NoMethodError) problem. I think it was just a typo on David's part. Does the following work? Spec::Runner.configure do |config| config.after(:suite) do # shut stuff down here end end And I had no idea you could do before/after :suite... Ashley -- 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
Re: [rspec-users] Unable to use Rspec Framework in Watir
On 26 Oct 2009, at 07:10, abhisheksreepal wrote: Thanks. There were a few other things odd about your code though. You don't need to use global variables ($), and you're including thinks into the global namespace object. RSpec is heavily block-oriented, and it makes life a lot easier if you understand what it's doing with them. For example, you can do this: Spec::Runner.configure do |config| config.include(MyModule) end If you're coming to Ruby from another language, it would probably pay off quickly to study blocks and modules in more detail. It'll save a lot of pain later on. Ashley -- 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
Re: [rspec-users] Unable to use Rspec Framework in Watir
On Oct 23, 2009, at 2:47 pm, abhisheksreepal wrote:
describe 'should Navigate to Gmail Login Screen' do
it 'Enter username'
$ie = Watir::IE.new
$ie.goto($email)
$ie.text_field(:id, 'Email').set($username)
#$ie.text.should ('Aidy Lewis')
end
You missed the block delimiters:
describe 'should Navigate to Gmail Login Screen' do
it 'Enter username' do
$ie = Watir::IE.new
$ie.goto($email)
$ie.text_field(:id, 'Email').set($username)
#$ie.text.should ('Aidy Lewis')
end
end
Ashley
--
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
Re: [rspec-users] Stub that returns hash values
On 21 Oct 2009, at 19:18, Stephen Eley wrote: On Wed, Oct 21, 2009 at 1:12 PM, Carl Graff cagr...@cox.net wrote: In truth, due to my inexperience and confusion, mocks seem to slow my development more than just creating real objects. But since there has been so much effort to put these into testing frameworks, I think it must be important to try and learn when it is appropriate to use them. That is a fallacious line of reasoning. A lot of effort has also gone into American football, every Michael Bay movie, and Windows Vista. QED. To be fair, Carl did say he wanted to learn when it is appropriate to use them as opposed to just using them indiscriminately. And the answer may be never. I suppose it's quite possible that mocks do suck, and we just haven't realised yet. But that's ok, they suck less than inspecting instance variables, so I'm happy, at least. What I would suggest is to not try to learn how to use mocks on production code*, unless you have pretty thorough means of integration testing. Incorrect mocking leads to brittle specs* and that leads to hidden bugs* and thrashing during refactoring*. In fact, if you don't use a tool such as Cucumber, I'd recommend learning that over mocking first. (You don't need to use Cucumber, but it's more suited for high-level descriptions than RSpec.) As RSpec lets you refactor without risk of breaking units of code, Cucumber lets you refactor your code and specs across units. That gives you a metric on how well you're using mocks - unexpected Cucumber failures indicate a faulty assumption somewhere. Of course, that assumes your Cucumber features are solid... Just my coin of small denomination. Other learning strategies are available. Ashley * which was my situation -- 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
Re: [rspec-users] spec failing to run specs when spec.opts is present on 1.2.9
On 22 Oct 2009, at 16:28, Paul Carey wrote: Outside of the old merb app, I wasn't able to duplicate this issue. I also copied the spec_helper from a newly created merb app (1.0.12) into the old app, but the issue persisted. Perhaps a library conflict might be to blame? Hi Paul I use Merb extensively. Can you post your spec_helper? I may be able to help... Ashley -- 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
