From mark at mwilden.com Sun Mar 1 01:19:00 2009 From: mark at mwilden.com (Mark Wilden) Date: Sat, 28 Feb 2009 22:19:00 -0800 Subject: [rspec-users] cucumber ambiguous match In-Reply-To: <49A9EAE4.3060704@benmabey.com> References: <49A9EAE4.3060704@benmabey.com> Message-ID: <3c30da400902282219i427a421akd7f81a6ab22ba5fb@mail.gmail.com> On Sat, Feb 28, 2009 at 5:54 PM, Ben Mabey wrote: > Joe Van Dyk wrote: >> ? ? ?Ambiguous match of "a volunteer 'Joe' from 'Cincinnati'": >> >> ? ? ?features/step_definitions/user_steps.rb:1:in `/^a volunteer '(.*)'$/' >> ? ? ?features/step_definitions/user_steps.rb:5:in `/^a volunteer >> '(.*)' from '(.*)'$/' > > Try making your captures non-greedy (with ?). Greedy or non-greedy, both regexps still match. To distinguish between them, you (basically) need to replace '.*' with '[^']*' . ///ark From matt at mattwynne.net Sun Mar 1 08:27:31 2009 From: matt at mattwynne.net (Matt Wynne) Date: Sun, 1 Mar 2009 13:27:31 +0000 Subject: [rspec-users] Rspecing an enumerator from outside-in woes In-Reply-To: <20090228212917.GA19515@devielle> References: <20090228212917.GA19515@devielle> Message-ID: <18FD4D43-0429-4977-A01D-E651D9E0CA2F@mattwynne.net> On 28 Feb 2009, at 21:29, Shot (Piotr Szotkowski) wrote: > I?m trying to spec a system from outside-in as an excercise in > ?emergent > design? ? and so far I love it; it made me think about the design for > two days before I even wrote the first spec? :) Great :) > My most-outside class seems to be a prime candidate for an #each > method. > The attached (stripped) spec carrying two of the approaches I came up > with passes, and raises the following quesitions ? any answer would be > most appreciated! > > 1. A philosophical/kosherness question: In the finished system > Decomposer#each will yield Decomposition objects, but as I?m specing > from outside-in, the Decomposition class is not yet created. In the > attached example I?m using an Array as a poor man?s Decomposition > replacement. Is this a sane approach, or should I rather create > a skeletal Decomposition#initialize instead? I think you should try to write the specs so they won't have to change when you build the real implementation. That doesn't mean creating an actual Decomposition class just yet, but it does mean that you should return something that looks enough like one for the tests to still be valid when you swap one in. > 2. The first spec shows my initial approach, with a variable polling > the > stuff yielded by #each and then validating its contents, but it seems > clumsy? I think what you're finding clumsy here is the mocking setup. You don't always have to use mock objects as your 'test doubles' and often it's much easier (and leaves behind more flexible tests) if you use stubs rather than mocks. In this case, although it's possible to create a test double for the Generators using RSpec's mocking framework, it's pretty awkward and hard to read. I would be tempted to write my own test double instead. Applying outside-in to the behaviour I want from the test double, I'd write this: http://gist.github.com/72327 I'll leave it to you to code the #each method on the FakeGenerator, but hopefully you get the idea. Notice that I just used an Array as the fake for @uv_gen - I might have missed something but I think that would provide an adequate double for the behaviour you had specified for the mock. > 3. ?so I came up with the second, Decomposer.new.to_enum approach, > which > simply validates the enumrator?s #next objects. Unfortunately, this > does > not seem to trigger #should_receive(:each) on the *_gen mocks and made > me #stub!(:each) on them instead. Is this because I?m using RSpec > 1.1.12 > with Ruby 1.9.1, or am I missing something on how message expectations > work with lazy iterators (and, thus, #should_receive fail properly)? I think you're getting too far into specifying the implementation here. I like the #each approach better. Hope that helps. Matt Wynne http://blog.mattwynne.net http://www.songkick.com From walketim at gmail.com Sun Mar 1 11:50:37 2009 From: walketim at gmail.com (Tim Walker) Date: Sun, 1 Mar 2009 09:50:37 -0700 Subject: [rspec-users] [cucumber] Cucumber and Chronic Message-ID: <1ebf5a4d0903010850l54c7ee19i58dbbc48150a9339@mail.gmail.com> This may have been discussed before but just wanted to pass along a killer one-two punch that we stumbled upon as an excellent and natural extension to our domain language around the expression and testing of complex time based constructs. Please consider: Cucumber allows you to specify behavior in natural language. Chronic is a natural language date/time parser written in pure Ruby. (http://chronic.rubyforge.org/) Example of a cucumber test: Scenario: Test control operations Given that I have have a control operation named ?set clock date time? to ?Monday Jan 1, 2009 10:00? When the control named ?set clock date time? runs Then the clock should be ?10:00? Now, this works fine, if you?re only testing that you can set the clock to "Monday Jan 1, 2009 10:00". It gets more complex quickly when you try to do much more than this. Adding chronic to the mix allows us to define and use more complex time concepts in plain language. This allows for the parsing of sentence fragments such as ?next month? and ?next Tuesday? and combine them in to complex structures such as ?next Tuesday at 9:00? in a way that our tests continue to run as time marches on. For example: >> sentence = "next tuesday at 3:00 pm" => "next tuesday at 3:00 pm" >> time = Chronic.parse(sentence) => Tue Mar 03 15:00:00 -0700 2009 Now, the scenario can use this easily express clearly ?when? the control operation runs in more complex and useful expressions, for example: Scenario: Test control operations Given that I have have a control operation named ?set clock date time? to "next tuesday at 3:00 pm" When the control named ?set clock date time? runs Then the clock should be ?next tuesday at 3:00 pm" Scenario: Test spy sweeping schedules Given that I have have a control operation named ?clean spies? that is scheduled to run ?next Monday at 8:00 AM" And the customer has excluded ?weekdays? from allowing the control operation ?clean spies? to run When the control named ?set clock time? runs Then it should log a message and quit From phlip2005 at gmail.com Sun Mar 1 12:29:15 2009 From: phlip2005 at gmail.com (Phlip) Date: Sun, 01 Mar 2009 09:29:15 -0800 Subject: [rspec-users] how to get started with cucumber and assert{ 2.0 } Message-ID: [Warning: The following is not a question] Cucumberists: One of the irons in my fires is learning a little Cuke. So I try an experiment: Feature: join In order to get premium content As an unregistered member I want to enter signup information for a new account Scenario: Proper signup Given newb is not in the user database And I go to /join Okay, now that provides the standard Given suggestion, and I convert it to this: Given /^(.*) is not in the user database$/ do |newb| Subscription.find_by_username(newb).should_not be_nil end Notice the "_not be_nil". I want to see a failure; otherwise if I see a success it might not be for the correct reason. The failure looks like this: Scenario: Proper signup # features/join.feature:6 Given newb is not in the user database # .../webrat_steps.rb:101 expected nil? to return false, got true (Spec::Expectations::Expect...) ./features/step_definitions/webrat_steps.rb:102: in `Given /^(.*) is not in the user database$/' features/join.feature:7:in `Given newb is not in the user database' And I go to /join # features/step_definitions/webrat_steps.rb:6 Now that reflects quite a bit, but the actual .should_not only reflected "expected nil? to return false, got true" So let's upgrade to assert{ 2.0 }... Given /^(.*) is not in the user database$/ do |newb| assert{ Subscription.find_by_username(newb) != nil } end Not to brag (too much), but the difference is like night and day: Given newb is not in the user database # features/step_definitions/webrat_steps.rb:101 assert{ (not(Subscription.find_by_username(newb) == nil)) } --> false newb --> "newb" Subscription.find_by_username(newb) --> nil. (AssertionFailedError) ./features/step_definitions/webrat_steps.rb:103: in `Given /^(.*) is not in the user database$/' features/join.feature:7:in `Given newb is not in the user database' Don't get me wrong - assert{ 2.0 } is for high-density tests of low-level code. Not for customer-facing verbiage. So why can't every Cucumber do-end block use RubyReflector directly? Primarily because (with current technology), the reflector re-evaluates everything more than twice at fault time, and if you put your money-line inside a do-end block and it fails, the second re-evaluations might change their value and cause a confusing output! Ruby1.9, with its built-in Ripper, will probably make this reflection easier... -- Phlip http://www.zeroplayer.com/ From shot at hot.pl Sun Mar 1 12:30:06 2009 From: shot at hot.pl (Shot (Piotr Szotkowski)) Date: Sun, 1 Mar 2009 18:30:06 +0100 Subject: [rspec-users] Rspecing an enumerator from outside-in woes In-Reply-To: <18FD4D43-0429-4977-A01D-E651D9E0CA2F@mattwynne.net> References: <20090228212917.GA19515@devielle> <18FD4D43-0429-4977-A01D-E651D9E0CA2F@mattwynne.net> Message-ID: <20090301173006.GD7432@devielle> Thanks a lot, Matt, for your reply! It?s seriously most enlightening. Matt Wynne: > On 28 Feb 2009, at 21:29, Shot (Piotr Szotkowski) wrote: >> 1. A philosophical/kosherness question: In the finished system >> Decomposer#each will yield Decomposition objects, but as I?m specing >> from outside-in, the Decomposition class is not yet created. In the >> attached example I?m using an Array as a poor man?s Decomposition >> replacement. Is this a sane approach, or should I rather create >> a skeletal Decomposition#initialize instead? > I think you should try to write the specs so they won't have to change > when you build the real implementation. That doesn't mean creating an > actual Decomposition class just yet, but it does mean that you should > return something that looks enough like one for the tests to still be > valid when you swap one in. Hmm, interesting ? so an outside-in implementation should side-step using future classes? constructors, and the implementation code should actually change when the relevant classes appear? I ended up creating a skeletal Decomposition class, but then had to add Decomposition#==(other) ? which, in turn, made me add attribute accessors ? just to be able to test against Decomposition objects in RSpec. Decomposition#== will be useful in the future, but currently it exists solely so I can use RSpec?s ?.should == Decomposition.new(?), which seems wrong. Hmm, another thing to ponder upon ? every time a new RSpec paradigm shows me something new, some other, unrelated spec begins to raise suspicions? :) > I think what you're finding clumsy here is the mocking setup. You > don't always have to use mock objects as your 'test doubles' and often > it's much easier (and leaves behind more flexible tests) if you use > stubs rather than mocks. Thanks a ton for the Array-based generators ? I haven?t thought of that; they are most interesting. I can?t use your example verbatim, as in my real code Decomposer.new takes class names and only then instantiates the relevant generators?, but it surely opened my eyes on stubbing objects with general-purpose classes rather than mocking them. I?ll see how I can use them to clean-up the specs. :) ? http://github.com/Chastell/art-decomp/commit/f9f8d3b2a3e431290d0656f7244b64f5376fab8f >> 3. ?so I came up with the second, Decomposer.new.to_enum approach, >> which simply validates the enumrator?s #next objects. Unfortunately, >> this does not seem to trigger #should_receive(:each) on the *_gen >> mocks and made me #stub!(:each) on them instead. Is this because >> I?m using RSpec 1.1.12 with Ruby 1.9.1, or am I missing something >> on how message expectations work with lazy iterators (and, thus, >> #should_receive fail properly)? > I think you're getting too far into specifying the > implementation here. I like the #each approach better. I think I agree ? but the real question was why don?t the (lazy) enumerator?s #next calls satisfy the mocks? #should_receive()s ? am I missing something fundamental, or is this simply an RSpec 1.1.12 incompatibility with Ruby 1.9.1? For reference, my original attachment: http://gist.github.com/72399 ? if you replace the #stub!()s in the second spec with #should_receive()s, the spec breaks with (allegedly) unsatisfied expectations. ? Shot -- uo???n??suo? ??pun -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From matt at mattwynne.net Sun Mar 1 13:53:38 2009 From: matt at mattwynne.net (Matt Wynne) Date: Sun, 1 Mar 2009 18:53:38 +0000 Subject: [rspec-users] Rspecing an enumerator from outside-in woes In-Reply-To: <20090301173006.GD7432@devielle> References: <20090228212917.GA19515@devielle> <18FD4D43-0429-4977-A01D-E651D9E0CA2F@mattwynne.net> <20090301173006.GD7432@devielle> Message-ID: On 1 Mar 2009, at 17:30, Shot (Piotr Szotkowski) wrote: > Thanks a lot, Matt, for your reply! It?s seriously most enlightening. > > Matt Wynne: > >> On 28 Feb 2009, at 21:29, Shot (Piotr Szotkowski) wrote: > >>> 1. A philosophical/kosherness question: In the finished system >>> Decomposer#each will yield Decomposition objects, but as I?m specing >>> from outside-in, the Decomposition class is not yet created. In the >>> attached example I?m using an Array as a poor man?s Decomposition >>> replacement. Is this a sane approach, or should I rather create >>> a skeletal Decomposition#initialize instead? > >> I think you should try to write the specs so they won't have to >> change >> when you build the real implementation. That doesn't mean creating an >> actual Decomposition class just yet, but it does mean that you should >> return something that looks enough like one for the tests to still be >> valid when you swap one in. > > Hmm, interesting ? so an outside-in implementation should side-step > using future classes? constructors, and the implementation code should > actually change when the relevant classes appear? I wouldn't suggest you did anything that meant you had to change the implementation later when you replace the fake with a real object. Assuming you wanted to keep your focus on the Decomposer class, but you knew that the concept of a Decomposition was a firm one in your design, you could define an empty Decomposition class, then stub the constructor to return a test double of some sort: class Decomposition end ... Decomposition.stub!(:new).and_return mock('Decomposition', :foo => 'bar') > I ended up creating a skeletal Decomposition class, but then had to > add Decomposition#==(other) ? which, in turn, made me add attribute > accessors ? just to be able to test against Decomposition objects in > RSpec. > > Decomposition#== will be useful in the future, but currently it exists > solely so I can use RSpec?s ?.should == Decomposition.new(?), which > seems wrong. Hmm, another thing to ponder upon ? every time a new > RSpec > paradigm shows me something new, some other, unrelated spec begins to > raise suspicions? :) I'm less fussy these days about adding a bit of code to make something testable - I think of it a bit like adding screws to let you take an appliance like a CD player apart, rather than sealing it all up with glue. Having said that, if you have to work hard to do this, there might be a smell in your design. You could consider the Decomposition with all those nasty getters all over it to be something you only use in your tests - a TestableDecomposition. One technique for creating a test double is to subclass the object you want to fake, and add extra behaviour in the subclass that make the object more testable, without adding its behaviour. Exposing some state in the form of getters, or adding #== might be an example of this. Ideally though, you really want to avoid testing state and instead think about testing the interactions between objects. If the relationship between the Decomposer and the Decomposition is for one to create instances of the other, then I would be quite satisfied writing mock expectations on the Decomposition's constructor, like this: Decomposition.should_receive(:new).with [1,2] >> I think what you're finding clumsy here is the mocking setup. You >> don't always have to use mock objects as your 'test doubles' and >> often >> it's much easier (and leaves behind more flexible tests) if you use >> stubs rather than mocks. > > Thanks a ton for the Array-based generators ? I haven?t thought of > that; > they are most interesting. I can?t use your example verbatim, as in my > real code Decomposer.new takes class names and only then instantiates > the relevant generators?, but it surely opened my eyes on stubbing > objects with general-purpose classes rather than mocking them. I?ll > see how I can use them to clean-up the specs. :) > > ? http://github.com/Chastell/art-decomp/commit/f9f8d3b2a3e431290d0656f7244b64f5376fab8f > >>> 3. ?so I came up with the second, Decomposer.new.to_enum approach, >>> which simply validates the enumrator?s #next objects. Unfortunately, >>> this does not seem to trigger #should_receive(:each) on the *_gen >>> mocks and made me #stub!(:each) on them instead. Is this because >>> I?m using RSpec 1.1.12 with Ruby 1.9.1, or am I missing something >>> on how message expectations work with lazy iterators (and, thus, >>> #should_receive fail properly)? > >> I think you're getting too far into specifying the >> implementation here. I like the #each approach better. > > I think I agree ? but the real question was why don?t the (lazy) > enumerator?s #next calls satisfy the mocks? #should_receive()s ? > am I missing something fundamental, or is this simply an RSpec 1.1.12 > incompatibility with Ruby 1.9.1? > > For reference, my original attachment: http://gist.github.com/72399 ? > if you replace the #stub!()s in the second spec with > #should_receive()s, > the spec breaks with (allegedly) unsatisfied expectations. Sorry, not sure about that one - I've not tried playing with these lazy enumerators - is this a Ruby 1.9 thing Matt Wynne http://blog.mattwynne.net http://www.songkick.com From mark at mwilden.com Sun Mar 1 14:07:18 2009 From: mark at mwilden.com (Mark Wilden) Date: Sun, 1 Mar 2009 11:07:18 -0800 Subject: [rspec-users] [cucumber] Cucumber and Chronic In-Reply-To: <1ebf5a4d0903010850l54c7ee19i58dbbc48150a9339@mail.gmail.com> References: <1ebf5a4d0903010850l54c7ee19i58dbbc48150a9339@mail.gmail.com> Message-ID: <3c30da400903011107n7057e73fy89b2913085d222c0@mail.gmail.com> On Sun, Mar 1, 2009 at 8:50 AM, Tim Walker wrote: > > Now, this works fine, if you?re only testing that you can set the > clock to "Monday Jan 1, 2009 10:00". It gets more complex quickly when > you try to do much more than this. Adding chronic to the mix allows us > to define and use more complex time concepts in plain language. This > allows for the parsing of sentence fragments such as ?next month? and > ?next Tuesday? and combine them in to complex structures such as ?next > Tuesday at 9:00? in a way that our tests continue to run as time > marches on. > > For example: >>> sentence = "next tuesday at 3:00 pm" > => "next tuesday at 3:00 pm" >>> time = Chronic.parse(sentence) > => Tue Mar 03 15:00:00 -0700 2009 Just be careful when when basing durations from "now" that daylight savings time doesn't affect anything. ///ark From lists at ruby-forum.com Sun Mar 1 14:18:23 2009 From: lists at ruby-forum.com (Jeff Bowen) Date: Sun, 1 Mar 2009 20:18:23 +0100 Subject: [rspec-users] starting a program from ruby on windows Message-ID: <024cc34d2b0cfab954fe115ffae16d42@ruby-forum.com> I simply want to start another program from this GUI and let the GUI continue doing its own thing. The other program will run independent of the GUI and should stay running if the GUI is closed. require 'fox16' include Fox class ClipMainWindow < FXMainWindow def initialize(anApp) # Initialize base class first super(anApp, "TEST", :opts => DECOR_ALL, :width => 500, :height => 300) # The CCTV button button = FXButton.new(self, 'Connect To CCTV', :opts => BUTTON_NORMAL|LAYOUT_LEFT|LAYOUT_FILL_X) Dir.chdir("\\program files\\VBrick\\StreamPlayerPlus\\") button.connect(SEL_COMMAND){`StreamPlayerPlus.exe`} #button.connect(SEL_COMMAND) {Thread.new{(`StreamPlayerPlus.exe`)}} #button.connect(SEL_COMMAND) { exec("\\program files\\VBrick\\StreamPlayerPlus\\StreamPlayerPlus.exe") } end def create super show(PLACEMENT_SCREEN) end end if __FILE__ == $0 FXApp.new("TEST", "FXRuby") do |theApp| ClipMainWindow.new(theApp) theApp.create theApp.run end end -- Posted via http://www.ruby-forum.com/. From andy at elaptics.co.uk Sun Mar 1 16:05:08 2009 From: andy at elaptics.co.uk (Andrew Henson) Date: Sun, 1 Mar 2009 21:05:08 +0000 Subject: [rspec-users] [rails] An authorization question In-Reply-To: References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> Message-ID: On 28 Feb 2009, at 22:26, Chris Flipse wrote: > > Yes! This is what I was trying (poorly) to get at. > > Responsibility issues might be a large part of why it got factored > this way to begin with. The global is bad. Really bad, which is > why I'm trying to figure out something that works better. But I > believe it was put in place so that a model can be responsible for > it's own authorization. Some of the models are used and updated > from several different controllers, so any authorization logic > external to the model would have had to be repeated in several > different locations. > > The concern with that might be an over-enthusiastic embrace of DRY. > However some of the authorization stuff is Really Really Important, > so embedding the authorization logic in the model itself was seen as > a way to ensure it's not forgotten about. > > Half of my problem right now is that I'm not even sure what layer to > put model specific authentication! If it's in the controller layer, > it's repeated logic in every controller that touches the model in > question. If it's in the model, the logic is centralized, but now > your model needs not only to know about Users in general, it needs a > specific user. You have less chance of someone doing Something They > Shouldn't due to a forgotten check in a controller, but the test > setup seems to suffer for it. > > One way or the other, the global User.current is going away -- > soon. It's just a question of what to replace it with, and where. I was only skim-reading this topic so I may be misunderstanding what you're after but I think that maybe what you're looking for is something like http://github.com/stffn/declarative_authorization/tree/master , a Rails plugin that allows you to specify the authorisation in a single place for both controllers and at the model level. I've just started using it for a project and so far it seems a good fit, though I'm trying to keep the whole app as restful resources which makes things a little easier. It also has a few test helper methods which make it really easy to use with Cucumber and RSpec. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From yi2004 at gmail.com Sun Mar 1 08:38:12 2009 From: yi2004 at gmail.com (ty) Date: Sun, 1 Mar 2009 05:38:12 -0800 (PST) Subject: [rspec-users] Is there a way to generate spec for existing controllers? Message-ID: <75cf4ca0-0e93-4b38-abda-e052dc4feac2@k19g2000prh.googlegroups.com> Hi list, We just start using RSpec and rspec_on_rails for a existing Rails project. After run script/generate rspec. It only generate the structure folders. We've got quite a few controllers and models. I wonder is it a way to auto-generate specs for them. Many thanks ty From dchelimsky at gmail.com Sun Mar 1 18:18:22 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Mar 2009 17:18:22 -0600 Subject: [rspec-users] How do you mock a local variable ? In-Reply-To: <1f285f53-7c17-443f-a928-cd7f6a6d770b@j8g2000yql.googlegroups.com> References: <1f285f53-7c17-443f-a928-cd7f6a6d770b@j8g2000yql.googlegroups.com> Message-ID: <57c63afe0903011518se9c9c0ardbc01a5b0ca6f7d5@mail.gmail.com> Sorry all - this was sitting waiting for moderation, but it's already been addressed. Cheers, David On Thu, Feb 26, 2009 at 2:43 PM, MathLef wrote: > Hi, > > I need some help to spec' a function I am developping. Note that the > function is still not complete, cause I am trying to spec' it while > working on it, as it should be ! Basically, this is what my function > should look like : > > private > def obtain_criterias(hash_params) > ?crits = {} > ?hash_params.each { > ? |key, val| > ? ?crits[key.to_sym] = StringUtils.sanitize(val).upcase if not (key > == "controller" || key == "action") > ?} > ?return crits > end > > ?- hash_params is a hash table of some parameters received by a > controller > ?- StringUtils.sanitize removes all kind of accents from the string > passed in parameters > ?- it is encapsulated in a controller > > The problem is with the local variable "crits" on which I can not seem > to have any kind of control in my rspec. Now, I am wandering, is this > (still) a good way to code from a spec point of view ?! Can you give > me ideas on ways to spec this ? > > Many thanks in advance ! > Mathieu > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From mark at mwilden.com Sun Mar 1 18:30:45 2009 From: mark at mwilden.com (Mark Wilden) Date: Sun, 1 Mar 2009 15:30:45 -0800 Subject: [rspec-users] [cucumber] Cucumber and Chronic In-Reply-To: <3c30da400903011107n7057e73fy89b2913085d222c0@mail.gmail.com> References: <1ebf5a4d0903010850l54c7ee19i58dbbc48150a9339@mail.gmail.com> <3c30da400903011107n7057e73fy89b2913085d222c0@mail.gmail.com> Message-ID: <3c30da400903011530vbf3b9b8v3ace26553e29a078@mail.gmail.com> On Sun, Mar 1, 2009 at 11:07 AM, Mark Wilden wrote: > > Just be careful when when basing durations from "now" that daylight > savings time doesn't affect anything. Along the same lines, don't write tests that assume 1.month.ago was < 29 days ago, or specs could start failing in March (as just happened with us). :) ///ark From dchelimsky at gmail.com Sun Mar 1 18:51:06 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Mar 2009 17:51:06 -0600 Subject: [rspec-users] Is there a way to generate spec for existing controllers? In-Reply-To: <75cf4ca0-0e93-4b38-abda-e052dc4feac2@k19g2000prh.googlegroups.com> References: <75cf4ca0-0e93-4b38-abda-e052dc4feac2@k19g2000prh.googlegroups.com> Message-ID: <57c63afe0903011551k77426d7fy560ba9d36736976f@mail.gmail.com> On Sun, Mar 1, 2009 at 7:38 AM, ty wrote: > Hi list, > > We just start using RSpec and rspec_on_rails for a existing Rails > project. > After run script/generate rspec. It only generate the structure > folders. > We've got quite a few controllers and models. I wonder is it a way to > auto-generate specs for them. Nope. Sorry. > > Many thanks > > ty > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From joevandyk at gmail.com Sun Mar 1 20:04:44 2009 From: joevandyk at gmail.com (Joe Van Dyk) Date: Sun, 1 Mar 2009 17:04:44 -0800 Subject: [rspec-users] testing multiple sessions in cucumber/webrat In-Reply-To: <9e50e5690902281717v7a072f78k998321c48cb87ece@mail.gmail.com> References: <9e50e5690902281717v7a072f78k998321c48cb87ece@mail.gmail.com> Message-ID: So you're saying no? :D On Sat, Feb 28, 2009 at 5:17 PM, BJ Clark wrote: > Joe, > I would test this in 2 steps. > I'd first test that whatever state change (or whatever happens when you User > A clicks the link) takes place. > Then in another test, I'd check that, given a certain state (or again, > whatever is supposed to happen), then User B sees whatever. > HTH, > BJ Clark > > On Sat, Feb 28, 2009 at 12:04 PM, Joe Van Dyk wrote: >> >> Is it possible to have a scenario where you are testing the >> interaction between two different session? >> >> i.e. >> >> Given User A clicks this link >> Then User B should see this >> >> It used to be possible, but don't know if it still is. >> >> Joe >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From lists at ruby-forum.com Sun Mar 1 21:17:30 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 03:17:30 +0100 Subject: [rspec-users] Cucumber for large projects In-Reply-To: References: Message-ID: <05103fc0825a21747e3e71ce0cd53c93@ruby-forum.com> Tom ten Thij wrote: > We will be using Cucumber for a fairly large project. Are there any > areas that cucumber is lacking when there are many scenarios? > > I believe the best candidate for showing our client the scenario > results is the html output. It strikes me that that becomes fairly > cumbersome to check with many scenarios. Methinks some javascript code > to hide all passing scenarios / features would be useful. Is there any > work being done on this? > > In which areas could we help cucumber accommodate for large projects? > > Tom. Try the progress formatter. $ cucumber -f progress -r features features -- Posted via http://www.ruby-forum.com/. From zach.dennis at gmail.com Sun Mar 1 21:14:17 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Sun, 1 Mar 2009 21:14:17 -0500 Subject: [rspec-users] testing multiple sessions in cucumber/webrat In-Reply-To: References: <9e50e5690902281717v7a072f78k998321c48cb87ece@mail.gmail.com> Message-ID: <85d99afe0903011814u434e5062rf3e4bca06a3bef9@mail.gmail.com> On Sun, Mar 1, 2009 at 8:04 PM, Joe Van Dyk wrote: > So you're saying no? ?:D It is possible, you simply have to logout from UserA and log in as UserB. Also, although it's not exposed with webrat IIRC it is possible to have selenium run to separate browsers at the same time. You could theoretically have UserA and UserB logged in concurrently doing their thing, Zach > > On Sat, Feb 28, 2009 at 5:17 PM, BJ Clark wrote: >> Joe, >> I would test this in 2 steps. >> I'd first test that whatever state change (or whatever happens when you User >> A clicks the link) takes place. >> Then in another test, I'd check that, given a certain state (or again, >> whatever is supposed to happen), then User B sees whatever. >> HTH, >> BJ Clark >> >> On Sat, Feb 28, 2009 at 12:04 PM, Joe Van Dyk wrote: >>> >>> Is it possible to have a scenario where you are testing the >>> interaction between two different session? >>> >>> i.e. >>> >>> Given User A clicks this link >>> Then User B should see this >>> >>> It used to be possible, but don't know if it still is. >>> >>> Joe >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From phlip2005 at gmail.com Sun Mar 1 22:08:23 2009 From: phlip2005 at gmail.com (Phlip) Date: Sun, 01 Mar 2009 19:08:23 -0800 Subject: [rspec-users] Is there a way to generate spec for existing controllers? In-Reply-To: <57c63afe0903011551k77426d7fy560ba9d36736976f@mail.gmail.com> References: <75cf4ca0-0e93-4b38-abda-e052dc4feac2@k19g2000prh.googlegroups.com> <57c63afe0903011551k77426d7fy560ba9d36736976f@mail.gmail.com> Message-ID: David Chelimsky wrote: > ty wrote: >> We just start using RSpec and rspec_on_rails for a existing Rails >> project. No unit tests, right? >> After run script/generate rspec. It only generate the structure >> folders. >> We've got quite a few controllers and models. I wonder is it a way to >> auto-generate specs for them. > > Nope. Sorry. Ask your goal-donor what feature they'd like to see in a spec. That is the point of specs - writing verbiage that a "product manager" or "business analyst" can review. -- Phlip From ben at benmabey.com Sun Mar 1 22:46:39 2009 From: ben at benmabey.com (Ben Mabey) Date: Sun, 01 Mar 2009 20:46:39 -0700 Subject: [rspec-users] testing multiple sessions in cucumber/webrat In-Reply-To: References: Message-ID: <49AB569F.6080800@benmabey.com> Joe Van Dyk wrote: > Is it possible to have a scenario where you are testing the > interaction between two different session? > > i.e. > > Given User A clicks this link > Then User B should see this > > It used to be possible, but don't know if it still is. > > Joe > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > Have you tried creating a new webrat session? I haven't looked into it myself, but like you said it was possible. Not much has changed with the underling rails integration session so I imagine that if you just created a new webrat session and used that for user B then you should be fine. (So, you will have to store this second session as an instance var in the other session.. kinda odd but I would try it.) I would be interested to hear if this works, so please report back. BTW, you might get some better answers on the webrat mailing list. -Ben From sfeley at gmail.com Mon Mar 2 00:07:31 2009 From: sfeley at gmail.com (Stephen Eley) Date: Mon, 2 Mar 2009 00:07:31 -0500 Subject: [rspec-users] [cucumber] Cucumber and Chronic In-Reply-To: <3c30da400903011530vbf3b9b8v3ace26553e29a078@mail.gmail.com> References: <1ebf5a4d0903010850l54c7ee19i58dbbc48150a9339@mail.gmail.com> <3c30da400903011107n7057e73fy89b2913085d222c0@mail.gmail.com> <3c30da400903011530vbf3b9b8v3ace26553e29a078@mail.gmail.com> Message-ID: <1fb4df0903012107q6d65aaf6w255fb01233064f95@mail.gmail.com> On Sun, Mar 1, 2009 at 6:30 PM, Mark Wilden wrote: > On Sun, Mar 1, 2009 at 11:07 AM, Mark Wilden wrote: >> >> Just be careful when when basing durations from "now" that daylight >> savings time doesn't affect anything. > > Along the same lines, don't write tests that assume 1.month.ago was < > 29 days ago, or specs could start failing in March (as just happened > with us). :) You wouldn't happen to be on the Microsoft Zune development team, would you? >8-> For date testing, I've just discovered and successfully used Notahat's "time_travel" plugin: http://github.com/notahat/time_travel/ It's essentially a scoped override for Time.now, so that any code you pass it executes as if the current time is frozen at whatever you tell it. This makes repeatable testing much, much simpler. This is the same guy who developed Machinist (my preferred fixture/factory tool) and not_a_mock, which I used for a little while before I abandoned mocking. >8-> So...yeah. He does good stuff. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From lists at ruby-forum.com Mon Mar 2 05:08:30 2009 From: lists at ruby-forum.com (Juanma Cervera) Date: Mon, 2 Mar 2009 11:08:30 +0100 Subject: [rspec-users] Changes in specs for routes in rspec 1.1.99.x Message-ID: <4b8a6a1f20a84f53853d62c062603af2@ruby-forum.com> Trying the next release of rspec, I have had to make changes in the existing specs for routing. I have written an script with sed that makes this automatically (two files) spec/upgrade.sed ================ /route_for/s/id => 1/id => "1"/g /route_for.*create/s/== \(["'].*["']\)/== {:path => \1, :method => :post}/ /route_for.*update/s/== \(["'].*["']\)/== {:path => \1, :method => :put}/ /route_for.*destroy/s/== \(["'].*["']\)/== {:path => \1, :method => :delete}/ and spec/upgrade ============ for f in `find controllers -name "*routing*rb" -type f`; do sed -i -f upgrade.sed $f; done You shoud make this file executable and run it I hope this helps somebody. Juanma -- Posted via http://www.ruby-forum.com/. From joe at josephwilk.net Mon Mar 2 05:31:20 2009 From: joe at josephwilk.net (Joseph Wilk) Date: Mon, 02 Mar 2009 10:31:20 +0000 Subject: [rspec-users] [cucumber] noob Q deleteing from a list. In-Reply-To: <7b0154b4-105b-4398-9b43-175c64ba95e5@17g2000vbf.googlegroups.com> References: <8d961d900902260759u7905a806h231f75aa580a9fc7@mail.gmail.com> <3c30da400902261053k65065af1y95453d6c02dc7504@mail.gmail.com> <49A6E8C7.5000909@benmabey.com> <7b0154b4-105b-4398-9b43-175c64ba95e5@17g2000vbf.googlegroups.com> Message-ID: <49ABB578.5050709@josephwilk.net> John Ivanoff wrote: > Thanks for all the help. With the > puts response.body > I was able so see what was going on. I know that I am now deleting the > third frooble!!!! > > Now when > Then I should see the following froobles: > I get this error > ---------------------------------- > Then I should see the following froobles: # features/step_definitions/ > frooble_steps.rb:12 > expected: ["description 1"], > got: "description 1" (using ==) > Diff: > @@ -1,2 +1,2 @@ > -["description 1"] > +"description 1" (Spec::Expectations::ExpectationNotMetError) > ./features/step_definitions/frooble_steps.rb:18:in `Then /^I > should see the following froobles:$/' > /Library/Ruby/Gems/1.8/gems/webrat-0.4.0/lib/webrat/core/ > matchers/have_xpath.rb:50:in `call' > /Library/Ruby/Gems/1.8/gems/webrat-0.4.0/lib/webrat/core/ > matchers/have_xpath.rb:50:in `matches_nokogiri?' > /Library/Ruby/Gems/1.8/gems/webrat-0.4.0/lib/webrat/core/ > matchers/have_xpath.rb:15:in `matches?' > ./features/step_definitions/frooble_steps.rb:17:in `Then /^I > should see the following froobles:$/' > (eval):3:in `each_with_index' > ./features/step_definitions/frooble_steps.rb:16:in `each' > ./features/step_definitions/frooble_steps.rb:16:in > `each_with_index' > ./features/step_definitions/frooble_steps.rb:16:in `Then /^I > should see the following froobles:$/' > features/list.feature:15:in `Then I should see the following > froobles:' > ---------------------------------- > > Again any help will be appreciated. > You are expecting a list in your test but you are getting back a string. > John > > On Feb 26, 1:08 pm, Ben Mabey wrote: > >> Mark Wilden wrote: >> >>> On Thu, Feb 26, 2009 at 7:59 AM, aslak hellesoy >>> wrote: >>> >>>> puts response.body >>>> >>> Another debugging technique we use is >>> >>> When /^I view the response$/ do >>> Tempfile.open("response") do |file| >>> file.print response.body >>> `open "file://#{file.path}"` >>> sleep 2 >>> end >>> end >>> >>> ///ark >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> If you are using webrat and you want to see the HTML repsonse you can >> use: save_and_open_page >> >> -Ben >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > -- Joseph Wilk http://blog.josephwilk.net From aidy.lewis at googlemail.com Mon Mar 2 08:53:38 2009 From: aidy.lewis at googlemail.com (aidy lewis) Date: Mon, 2 Mar 2009 13:53:38 +0000 Subject: [rspec-users] Cucumber for large projects In-Reply-To: References: Message-ID: <7ac2300c0903020553l77e4c8e4ub2dd6563b5382863@mail.gmail.com> Hi Tom, We have written an extension that counts your tests and provides a link(s) to the failure backtrace in the Cucumber HTML. There seem to be issues when Cucumber writes to the HTML over around 800 steps, so we are waiting for version 0.2. Aidy On 26/02/2009, Tom ten Thij wrote: > We will be using Cucumber for a fairly large project. Are there any > areas that cucumber is lacking when there are many scenarios? > > I believe the best candidate for showing our client the scenario > results is the html output. It strikes me that that becomes fairly > cumbersome to check with many scenarios. Methinks some javascript code > to hide all passing scenarios / features would be useful. Is there any > work being done on this? > > In which areas could we help cucumber accommodate for large projects? > > Tom. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From zuperinfinite at gmail.com Mon Mar 2 09:15:33 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Mon, 2 Mar 2009 15:15:33 +0100 Subject: [rspec-users] testing multiple sessions in cucumber/webrat In-Reply-To: References: Message-ID: <2B9D31AD-A815-4BB0-9882-72B8197CACE6@gmail.com> On 28-feb-2009, at 21:04, Joe Van Dyk wrote: > Is it possible to have a scenario where you are testing the > interaction between two different session? If you mean something along these lines: User A uploads a picture, User B logs in to see the picture uploaded by User A that is possible. I use this construct a lot to test-drive some revisions code I came up with. Something like: Given I am logged in And there is an article And the title of the article has been modified twice When I compare the revisions Then I should see the difference in title GIven "the title of the article has been modified twice" do Given "I am logged in as an editor" 2.times do |i| visit edit_article_path(@article) fill_in "Title", :with => "Title #{i}" click_button "Save" end Given "I am logged in as a writer" end cheers, bartz From zuperinfinite at gmail.com Mon Mar 2 09:18:55 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Mon, 2 Mar 2009 15:18:55 +0100 Subject: [rspec-users] Is there a way to generate spec for existing controllers? In-Reply-To: References: <75cf4ca0-0e93-4b38-abda-e052dc4feac2@k19g2000prh.googlegroups.com> <57c63afe0903011551k77426d7fy560ba9d36736976f@mail.gmail.com> Message-ID: <779347D0-C4BA-432F-865D-3220B3FBDEF9@gmail.com> On 2-mrt-2009, at 4:08, Phlip wrote: > David Chelimsky wrote: > >> ty wrote: > >>> We just start using RSpec and rspec_on_rails for a existing Rails >>> project. > > No unit tests, right? > >>> After run script/generate rspec. It only generate the structure >>> folders. >>> We've got quite a few controllers and models. I wonder is it a >>> way to >>> auto-generate specs for them. >> Nope. Sorry. > > Ask your goal-donor what feature they'd like to see in a spec. > > That is the point of specs - writing verbiage that a "product > manager" or "business analyst" can review. I fully agree. For views though, there is http://github.com/hashrocket/view_specify/ tree/master Haven't tried it, and never will :). cheers, bartz From zuperinfinite at gmail.com Mon Mar 2 09:20:55 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Mon, 2 Mar 2009 15:20:55 +0100 Subject: [rspec-users] be_valid (validates_format_of ..., :on => :create) In-Reply-To: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> References: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> Message-ID: <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> On 28-feb-2009, at 11:45, MAwiniarski wrote: > Greetings, > > How to write Example which will check if model's variable's > format is valid using :on => :create, like this: > > class User < ActiveRecord::Base > ... > validates_format_of :email, :with => /.../, :on => :create > ... > > Using following code is not right: > it "should ..." do > @user = users(:example_user) > @user.email = 'invalid_email_format' > @user.save > @user.should_not be_valid > end Try: it "should ..." do user = User.new # create a NEW user, instead of loading an already saved user from a fixtures file user.email = 'invalid_email_format' user.should_not be_valid user.should have(1).errors_on(:email) end cheers, bartz From apremdas at gmail.com Mon Mar 2 09:56:48 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Mon, 2 Mar 2009 14:56:48 +0000 Subject: [rspec-users] [rails] An authorization question In-Reply-To: References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> Message-ID: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> Personally I think this should be in the model layer. As you've pointed it you get alot of repetition if its in the controller layer. But putting business logic in the controller layer goes against the fundamentals of MVC, and is a bit of a Rails anti-pattern (fat controller). So given that the rules should be in the model then the question is which part of the model should have this responsibility and how do you call it. Three choices come to mind here 1) Place the rule inside User 2) Place the rule inside the affected model 3) Create a new model(s) to encapsulate this functionality. It might be helpful to think of this as a service which models can use 1) Pollutes User with additional responsibility, but you can live with this so long as things remain very simple 2) Isn't DRY if the rules apply to many different models 3) Is more complex It sounds like you have 1) and should consider moving to 3). However you might get some change out of improving 1) first if you can, by using standard refactorings Have you considered creating a spike and doing a bit of BDD on the spike. i.e write the stories you want to write, implement simple code for them and try and work out the interactions you need from there. Even if you don't use the spike code in your application this might help you get a better set of features for this piece of functionality, (not tainted by the implementation of the existing code. These features then can be applied to your legacy project and perhaps other projects as well. HTH Andrew 2009/2/28 Chris Flipse > > > On Sat, Feb 28, 2009 at 3:42 PM, Ben Mabey wrote: > >> Chris Flipse wrote: >> >>> I've actually been okay with it at the unit testing / rspec level -- I've >>> had it stubbed as you describe for a while. >>> >>> The pain point came in as I was trying to setup data for Cucumber ... >>> Which, listening to my tests, tells me that the current structure is bad. I >>> was more curious to see how others are handling that sort of situation. >>> >> >> If you are seeing state from one scenario bleed over to the next I would >> suggest something like this in your env.rb: >> >> After do >> User.reset_current >> end >> > > Yep got that. The tests are actually *working*, it's just that the setup > has gotten painful. > > >> >>> I want to get *away* from the global variable, I'm just not entirely sure >>> what the target should be. There doesn't seem to be a whole lot of talk >>> about actual implementation specifics around model level authorization. >>> >> >> I generally have a current_user method defined of my controller to return >> the logged in user. > > > Same. Authentication was originally generated using acts_as_authenticated, > so the standard conventions at the controller level are in place. > > >> Assuming that your app is only using User.current in your controllers you >> could try to move towards something like that... If you have models >> accessing User.current then it truly is being used as a global. :/ > > > It truly is being used as a global. > > >> The user will then have some permissions methods that may take other >> objects or symbols. The method will simply return a boolean telling if the >> user is authorized or not. That logic usually is based on the role(s) of >> that user or relationship with the passed in object. Having this logic in >> the user could be viewed as a responsibility issue- should the user really >> be responsible for telling if it is authorized for everything? In general I >> do this for most simple cases. Only when it starts to get complex do I move >> it out into a Manager-like object. >> > > Yes! This is what I was trying (poorly) to get at. > > Responsibility issues might be a large part of why it got factored this way > to begin with. The global is bad. Really bad, which is why I'm trying to > figure out something that works better. But I believe it was put in place > so that a model can be responsible for it's own authorization. Some of the > models are used and updated from several different controllers, so any > authorization logic external to the model would have had to be repeated in > several different locations. > > The concern with that might be an over-enthusiastic embrace of DRY. > However some of the authorization stuff is Really Really Important, so > embedding the authorization logic in the model itself was seen as a way to > ensure it's not forgotten about. > > Half of my problem right now is that I'm not even sure what *layer* to put > model specific authentication! If it's in the controller layer, it's > repeated logic in every controller that touches the model in question. If > it's in the model, the logic is centralized, but now your model needs not > only to know about Users in general, it needs a specific user. You have > less chance of someone doing Something They Shouldn't due to a forgotten > check in a controller, but the test setup seems to suffer for it. > > One way or the other, the global User.current is going away -- soon. It's > just a question of what to replace it with, and where. > > -- > // anything worth taking seriously is worth making fun of > // http://blog.devcaffeine.com/ > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Mon Mar 2 10:07:23 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 16:07:23 +0100 Subject: [rspec-users] Feature Size-Scope-Scale Message-ID: <1ef2dc9f45c1e3ec88431704451454c3@ruby-forum.com> The more I work with BDD the more I realize how different this is from my previous experience. I now consider that part of the difficulty I have lies in establishing the proper scale for the features that I propose. My question lies in that vein. What size should a feature be? I have read a great deal about scaling features in terms of hours of work. However, at my present level of inefficiency, that will probably result in features that are too small just as I now believe that the features I have now are too large. Besides which, I seem to grasp examples better than metrics when conceptualizing such things. Returning to my client case. Given that the system must permit administering clients then does one have a single feature called "System has clients..." and bundle all the activity related thereto in its scenarios. Or, as I begin to suspect, should one have separate features like "Add a new client"; "Deactivate an existing client"; Reactivate an inactive client"; "Report all active clients; ... and so forth. -- Posted via http://www.ruby-forum.com/. From zuperinfinite at gmail.com Mon Mar 2 10:19:38 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Mon, 2 Mar 2009 16:19:38 +0100 Subject: [rspec-users] Feature Size-Scope-Scale In-Reply-To: <1ef2dc9f45c1e3ec88431704451454c3@ruby-forum.com> References: <1ef2dc9f45c1e3ec88431704451454c3@ruby-forum.com> Message-ID: <493E4FB9-598B-4B80-B29D-6587308F2123@gmail.com> On 2-mrt-2009, at 16:07, James Byrne wrote: > The more I work with BDD the more I realize how different this is from > my previous experience. I now consider that part of the difficulty I > have lies in establishing the proper scale for the features that I > propose. My question lies in that vein. What size should a > feature be? It should be big enough to describe the functionality. Imagine a weblog system, with which a user can post articles. My typical approach would be 4 features, Creating/Editing/Destroying and Viewing a post. Imagine I have validates_presence for the title and contents of an article. The Creating feature would have 3 scenarios: - Creating an article - Creating an article without a title - Creating an article without the contents Updating, 4 scenarios: - Updating the title - Updating the contents - Removing the title (eg, a blank title) - Removing the contents Destroying and Viewing would be just 1 scenario. I am rather curious what other list members use though.. cheers, bartz From lists at ruby-forum.com Mon Mar 2 10:31:43 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 16:31:43 +0100 Subject: [rspec-users] Cucumber Feature Scenario critique In-Reply-To: <88fd8ddc0902250829v4cd73892qaf74892d046ab18c@mail.gmail.com> References: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> <88fd8ddc0902230757j4c4b3465m4ba5699923ebf19a@mail.gmail.com> <1fb4df0902230944x31bb96d2pd45a286037e68c8e@mail.gmail.com> <6c8eb20a0eed0ed9845666e7c8e86a5c@ruby-forum.com> <88fd8ddc0902231655y1188ecf2ub48d0d4fc0ab6546@mail.gmail.com> <88fd8ddc0902250829v4cd73892qaf74892d046ab18c@mail.gmail.com> Message-ID: <4548f1ed0b5abb573f7b0bc1c55e647d@ruby-forum.com> Andrew Premdas wrote: > James, > > I'd question whether you need to give a monkey's about 'entity'. Whilst > it maybe an essential concept in the overall legal framework that doesn't > mean it has to be in YOUR world. If your software is about recording services > provided to some client and related payments. You can simplify - you can > just choose not to model all that legal stuff. If you model everything > you'll I have been mulling this over these past few days. I now think that what is wrong, besides having as yet only vague ideas of how this is all meant to work, is that I am injecting too many implementation details into the features and scenarios. Whether or not a client is a stand-alone design element or is dependent upon a superior element of abstraction is really quite beside the point insofar as the presentation of the system to the user is concerned. I now believe that I should just be writing down whatever it is that a client has to be in order to satisfy the business requirements. If we need a higher level of abstraction to capture other attributes then that should remain invisible to the users. Of course, realizing this issue and actually dealing with it are two different things. I will probably experience a great deal of difficulty arriving at a balance between expression and implementation. -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Mon Mar 2 10:50:07 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Mar 2009 09:50:07 -0600 Subject: [rspec-users] be_valid (validates_format_of ..., :on => :create) In-Reply-To: <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> References: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> Message-ID: <57c63afe0903020750g5936966cg85cf715a5d8c980a@mail.gmail.com> On Mon, Mar 2, 2009 at 8:20 AM, Bart Zonneveld wrote: > > On 28-feb-2009, at 11:45, MAwiniarski wrote: > >> Greetings, >> >> How to write Example which will check if model's variable's >> format is valid using :on => :create, like this: >> >> class User < ActiveRecord::Base >> ... >> ?validates_format_of ? ? ? :email, :with => /.../, :on => :create >> ... >> >> Using following code is not right: >> it "should ..." do >> ? @user = users(:example_user) >> ? @user.email = 'invalid_email_format' >> ? @user.save >> ? @user.should_not be_valid >> end > > Try: > > it "should ..." do > ? user = User.new # create a NEW user, instead of loading an already saved > user from a fixtures file > ? user.email = 'invalid_email_format' > ? user.should_not be_valid > ? user.should have(1).errors_on(:email) > end +1 I might combine the first two lines: user = User.create(:email => "invalid_email_format") That reads more clearly to me because the invalid email format is assigned on create, not after. It would have an extra call to valid? but I think it's worth it for the clarity of intent in this case. Otherwise, this is the right idea, IMO. Cheers, David > > cheers, > bartz > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From zuperinfinite at gmail.com Mon Mar 2 11:23:08 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Mon, 2 Mar 2009 17:23:08 +0100 Subject: [rspec-users] be_valid (validates_format_of ..., :on => :create) In-Reply-To: <57c63afe0903020750g5936966cg85cf715a5d8c980a@mail.gmail.com> References: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> <57c63afe0903020750g5936966cg85cf715a5d8c980a@mail.gmail.com> Message-ID: <937E5EFE-C47A-433F-AD35-A76889F35434@gmail.com> On 2-mrt-2009, at 16:50, David Chelimsky wrote: > On Mon, Mar 2, 2009 at 8:20 AM, Bart Zonneveld > wrote: >> >> On 28-feb-2009, at 11:45, MAwiniarski wrote: >> >>> Greetings, >>> >>> How to write Example which will check if model's variable's >>> format is valid using :on => :create, like this: >>> >>> class User < ActiveRecord::Base >>> ... >>> validates_format_of :email, :with => /.../, :on => :create >>> ... >>> >>> Using following code is not right: >>> it "should ..." do >>> @user = users(:example_user) >>> @user.email = 'invalid_email_format' >>> @user.save >>> @user.should_not be_valid >>> end >> >> Try: >> >> it "should ..." do >> user = User.new # create a NEW user, instead of loading an >> already saved >> user from a fixtures file >> user.email = 'invalid_email_format' >> user.should_not be_valid >> user.should have(1).errors_on(:email) >> end > > +1 > > I might combine the first two lines: > > user = User.create(:email => "invalid_email_format") > > That reads more clearly to me because the invalid email format is > assigned on create, not after. It would have an extra call to valid? > but I think it's worth it for the clarity of intent in this case. Although I agree with the reasoning you display here, I'd *never* validate any attribute just on create. I'm pretty sure a user can update his email address somewhere in the site, but then his email address wouldn't be validated anymore. On a second note, I noticed rspec default generated model specs now use Model.create!(@valid_attributes) as their default "all is valid" test. What's the advantage of this approach? I just write @model.attributes = @valid_attributes; @model.should be_valid, to prevent these specs to actually hit the db, and therefore speed up my specs a bit. thanks, bartz From dchelimsky at gmail.com Mon Mar 2 11:38:46 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Mar 2009 10:38:46 -0600 Subject: [rspec-users] be_valid (validates_format_of ..., :on => :create) In-Reply-To: <937E5EFE-C47A-433F-AD35-A76889F35434@gmail.com> References: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> <57c63afe0903020750g5936966cg85cf715a5d8c980a@mail.gmail.com> <937E5EFE-C47A-433F-AD35-A76889F35434@gmail.com> Message-ID: <57c63afe0903020838g4013ac5u91637f525f046158@mail.gmail.com> On Mon, Mar 2, 2009 at 10:23 AM, Bart Zonneveld wrote: > > On 2-mrt-2009, at 16:50, David Chelimsky wrote: > >> On Mon, Mar 2, 2009 at 8:20 AM, Bart Zonneveld >> wrote: >>> >>> On 28-feb-2009, at 11:45, MAwiniarski wrote: >>> >>>> Greetings, >>>> >>>> How to write Example which will check if model's variable's >>>> format is valid using :on => :create, like this: >>>> >>>> class User < ActiveRecord::Base >>>> ... >>>> ?validates_format_of ? ? ? :email, :with => /.../, :on => :create >>>> ... >>>> >>>> Using following code is not right: >>>> it "should ..." do >>>> ?@user = users(:example_user) >>>> ?@user.email = 'invalid_email_format' >>>> ?@user.save >>>> ?@user.should_not be_valid >>>> end >>> >>> Try: >>> >>> it "should ..." do >>> ?user = User.new # create a NEW user, instead of loading an already saved >>> user from a fixtures file >>> ?user.email = 'invalid_email_format' >>> ?user.should_not be_valid >>> ?user.should have(1).errors_on(:email) >>> end >> >> +1 >> >> I might combine the first two lines: >> >> ?user = User.create(:email => "invalid_email_format") >> >> That reads more clearly to me because the invalid email format is >> assigned on create, not after. It would have an extra call to valid? >> but I think it's worth it for the clarity of intent in this case. > > Although I agree with the reasoning you display here, I'd *never* validate > any attribute just on create. > I'm pretty sure a user can update his email address somewhere in the site, > but then his email address wouldn't be validated anymore. FWIW, the OP's code says :on => :create. I also happened to see http://mawiniarski.wordpress.com/2009/02/28/rspec-validation-on-create/, which reinforced for me that this is about validating on create, not general validation. > On a second note, I noticed rspec default generated model specs now use > Model.create!(@valid_attributes) as their default "all is valid" test. > What's the advantage of this approach? I just write @model.attributes = > @valid_attributes; @model.should be_valid, to prevent these specs to > actually hit the db, and therefore speed up my specs a bit. Good point. Wanna submit a patch? http://rspec.lighthouseapp.com Cheers, David > > thanks, > bartz > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From sfeley at gmail.com Mon Mar 2 11:54:23 2009 From: sfeley at gmail.com (Stephen Eley) Date: Mon, 2 Mar 2009 11:54:23 -0500 Subject: [rspec-users] Feature Size-Scope-Scale In-Reply-To: <1ef2dc9f45c1e3ec88431704451454c3@ruby-forum.com> References: <1ef2dc9f45c1e3ec88431704451454c3@ruby-forum.com> Message-ID: <1fb4df0903020854v71571570r222dc816f762012@mail.gmail.com> On Mon, Mar 2, 2009 at 10:07 AM, James Byrne wrote: > > I have read a great deal about scaling features in terms of hours of > work. ?However, at my present level of inefficiency, that will probably > result in features that are too small just as I now believe that the > features I have now are too large. ?Besides which, I seem to grasp > examples better than metrics when conceptualizing such things. Real features for a real project I'm working on: Feature: View Episodes As a listener I want to see a list of episodes So that I can experience the joy of consuming them Feature: Create Episode As a podcaster I want to add an episode So that I don't die like Emily Dickinson Feature: Edit Episode As a podcaster I want to edit an existing episode So that my listeners can catch my mistakes for me Feature: Add MP3 Enclosure As a podcaster I want to link to an MP3 file So that people don't confuse me for a blogger ...That's my basic feature size. An atomic unit of work, and generally one that comprises a single Web interaction. I'll usually put down 2-3 scenarios when I make the feature file (critical success path, and at least one exception case) and then add more if/when I think of them. These mostly fall out to a few hours of work each, but that seems to be a natural consequence of thinking at an atomic level and not a deliberate goal I'd planned for. If one of them took days, well, it'd take days. > [ . . . ] ?Or, as I begin to suspect, should one have separate features > like "Add a new client"; "Deactivate an existing client"; Reactivate an > inactive client"; "Report all active clients; ... and so forth. Here would be my suggestion: * Start by doing it the way you think makes the most sense. * If it feels good and seems to result in better code done faster, keep doing it that way. * If it hurts, or slows you down without a quality increase, either try changing the way you're doing it, or stop doing it entirely. * Whenever you next run across something that you think might be a good improvement in your working methods, repeat steps 1-3. Penultimately it's about people and product. But people build the product, so ultimately it's about people. You need to figure out what works for you and your task at hand. Others can offer advice or experiences but they can't give you the right answers. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From mark at mwilden.com Mon Mar 2 12:07:45 2009 From: mark at mwilden.com (Mark Wilden) Date: Mon, 2 Mar 2009 09:07:45 -0800 Subject: [rspec-users] Cucumber Feature Scenario critique In-Reply-To: <4548f1ed0b5abb573f7b0bc1c55e647d@ruby-forum.com> References: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> <88fd8ddc0902230757j4c4b3465m4ba5699923ebf19a@mail.gmail.com> <1fb4df0902230944x31bb96d2pd45a286037e68c8e@mail.gmail.com> <6c8eb20a0eed0ed9845666e7c8e86a5c@ruby-forum.com> <88fd8ddc0902231655y1188ecf2ub48d0d4fc0ab6546@mail.gmail.com> <88fd8ddc0902250829v4cd73892qaf74892d046ab18c@mail.gmail.com> <4548f1ed0b5abb573f7b0bc1c55e647d@ruby-forum.com> Message-ID: <3c30da400903020907t2433a4cq785366924cbe1284@mail.gmail.com> On Mon, Mar 2, 2009 at 7:31 AM, James Byrne wrote: >?Whether or not a client is a > stand-alone design element or is dependent upon a superior element of > abstraction is really quite beside the point insofar as the presentation > of the system to the user is concerned. I like to focus on that key word, "presentation," meaning what a user sees on a screen or a piece of paper. The only truly important part of a system is its physical output. Everything else is subservient to that end. Define an output ("customer balance on web page"). Define how to make that happen, via a story/feature. Repeat. ///ark From mark at mwilden.com Mon Mar 2 12:12:14 2009 From: mark at mwilden.com (Mark Wilden) Date: Mon, 2 Mar 2009 09:12:14 -0800 Subject: [rspec-users] be_valid (validates_format_of ..., :on => :create) In-Reply-To: <937E5EFE-C47A-433F-AD35-A76889F35434@gmail.com> References: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> <57c63afe0903020750g5936966cg85cf715a5d8c980a@mail.gmail.com> <937E5EFE-C47A-433F-AD35-A76889F35434@gmail.com> Message-ID: <3c30da400903020912x1eeb7c6cmd4e0ce8d5d4b8dd0@mail.gmail.com> On Mon, Mar 2, 2009 at 8:23 AM, Bart Zonneveld wrote: > > On a second note, I noticed rspec default generated model specs now use > Model.create!(@valid_attributes) as their default "all is valid" test. > What's the advantage of this approach? I just write @model.attributes = > @valid_attributes; @model.should be_valid, to prevent these specs to > actually hit the db, and therefore speed up my specs a bit. Wouldn't it be better to go through the complete create! cycle, to make sure callbacks and database constraints (if any) are exercised? ///ark From mark at mwilden.com Mon Mar 2 12:19:26 2009 From: mark at mwilden.com (Mark Wilden) Date: Mon, 2 Mar 2009 09:19:26 -0800 Subject: [rspec-users] [cucumber] Cucumber and Chronic In-Reply-To: <1fb4df0903012107q6d65aaf6w255fb01233064f95@mail.gmail.com> References: <1ebf5a4d0903010850l54c7ee19i58dbbc48150a9339@mail.gmail.com> <3c30da400903011107n7057e73fy89b2913085d222c0@mail.gmail.com> <3c30da400903011530vbf3b9b8v3ace26553e29a078@mail.gmail.com> <1fb4df0903012107q6d65aaf6w255fb01233064f95@mail.gmail.com> Message-ID: <3c30da400903020919t65e344cdg148a91cd44d00b2a@mail.gmail.com> On Sun, Mar 1, 2009 at 9:07 PM, Stephen Eley wrote: > > For date testing, I've just discovered and successfully used Notahat's > "time_travel" plugin: > http://github.com/notahat/time_travel/ We have just been stubbing Time.now, but I'll think about time_travel. One advantage would be not having to "manually" reset RSpec mocks after each Cucumber scenario is run in After. ///ark From lists at ruby-forum.com Mon Mar 2 13:39:11 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 19:39:11 +0100 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> Message-ID: <675261bfd8ca95790d348539630b1398@ruby-forum.com> Andrew Premdas wrote: > So given that the rules should be in the model then the question is > which part of the model should have this responsibility and how do > you call it. > Three choices come to mind here > > 1) Place the rule inside User > 2) Place the rule inside the affected model > 3) Create a new model(s) to encapsulate this functionality. It might be > helpful to think of this as a service which models can use > > 1) Pollutes User with additional responsibility, but you can live with > this so long as things remain very simple > I am not sure that this is really "pollution". One of the things that was pointed out to me on the Ruby list when I first began transitioning to OO was the mantra "ask" don't "tell". It seems to me that in an OO authorization scheme one might properly ask the user instance (model) whether or not they are permitted to do "something" (controller) rather than have the "something" test to see if that user is permitted. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Mon Mar 2 13:48:19 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 19:48:19 +0100 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <675261bfd8ca95790d348539630b1398@ruby-forum.com> References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> Message-ID: <94fccb07c80c388f81351eda71aa47fd@ruby-forum.com> James Byrne wrote: > > I am not sure that this is really "pollution". One of the things that > was pointed out to me on the Ruby list when I first began transitioning > to OO was the mantra "ask" don't "tell". It seems to me that in an OO > authorization scheme one might properly ask the user instance (model) > whether or not they are permitted to do "something" (controller) rather > than have the "something" test to see if that user is permitted. Unless I have misunderstood your intent and by your third choice you are referring to an external role based model while your first choice refers to putting the actual rules inside the user model. In which case I agree with you. My comments refer to the idea that the user model makes the calls to the role model and returns whether or not they were authorized to the request. -- Posted via http://www.ruby-forum.com/. From mark at mwilden.com Mon Mar 2 14:10:28 2009 From: mark at mwilden.com (Mark Wilden) Date: Mon, 2 Mar 2009 11:10:28 -0800 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <675261bfd8ca95790d348539630b1398@ruby-forum.com> References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> Message-ID: <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> On Mon, Mar 2, 2009 at 10:39 AM, James Byrne wrote: > > I am not sure that this is really "pollution". ?One of the things that > was pointed out to me on the Ruby list when I first began transitioning > to OO was the mantra "ask" don't "tell". Actually, it's the other way around. http://www.pragprog.com/articles/tell-dont-ask ///ark From lists at ruby-forum.com Mon Mar 2 14:23:41 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 20:23:41 +0100 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> Message-ID: <068ba0be3d6da3cedfa70f9a2a0a4e99@ruby-forum.com> Mark Wilden wrote: > > > Actually, it's the other way around. > > http://www.pragprog.com/articles/tell-dont-ask Sigh... -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Mon Mar 2 14:37:34 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 20:37:34 +0100 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> Message-ID: Mark Wilden wrote: > > Actually, it's the other way around. > > http://www.pragprog.com/articles/tell-dont-ask > I have read this article and it leaves me rather more confused than not. I gather that I am missing something fundamental. Consider that when I write x.to_s I am telling the object what to give back. But then what am I doing when I write x.exists? or x.is_a?(y) or sam.authorized?(controller_or_model, action)? Is this a semantic confusion on my part? Should I consider that what I do with x.exists? is tell the object to answer a question? -- Posted via http://www.ruby-forum.com/. From phlip2005 at gmail.com Mon Mar 2 14:57:38 2009 From: phlip2005 at gmail.com (Phlip) Date: Mon, 02 Mar 2009 11:57:38 -0800 Subject: [rspec-users] [rails] An authorization question In-Reply-To: References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> Message-ID: James Byrne wrote: > Is this a semantic confusion on my part? Should I consider that what I > do with x.exists? is tell the object to answer a question? Consider... if x.exists? x.important_method() else # nothing! end Now lets upgrade the variable x. Sometimes it points to a thing that exists, and sometimes it points to a stub object whose only job is to return 'false' from exists?, and do nothing inside important_method(): if x.exists? x.important_method() else x.important_method() end Now you can take out the if! x.important_method() We are no longer asking x if it exists. We are telling it what to do, and letting it decide how to do it. That is the heart of OO programming. (There is still an 'if', somewhere - the one that populates x. But - hopefully - it's only in one place.) -- Phlip http://www.zeroplayer.com/ From r_j_h_box-sf at yahoo.com Mon Mar 2 15:22:44 2009 From: r_j_h_box-sf at yahoo.com (r_j_h_box-sf at yahoo.com) Date: Mon, 2 Mar 2009 12:22:44 -0800 (PST) Subject: [rspec-users] [rails] An authorization question In-Reply-To: References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> Message-ID: <387919.43677.qm@web31802.mail.mud.yahoo.com> ----- Original Message ---- > From: James Byrne > Mark Wilden wrote: > > Actually, it's the other way around. > > > > http://www.pragprog.com/articles/tell-dont-ask > > I have read this article and it leaves me rather more confused than not. That's the danger of oversimplification. Another way to phrase it is, don't rely on objects for things they know. Rely on them for things they know how to do. Now it boils down to who's responsible. The door's lock is responsible for reading the key, and the bolt is responsible for unlocking the door. The door is only responsible for letting me in, along with some cold air. The key is a role here, the lock is the controller, and the bolt... okay, the analogy breaks down again. But consider zones of responibility. > sam.authorized?(controller_or_model, action)? I'll suggest that it's the controllers who are responsible for telling what role or other requirements need to be satisfied to get their services, and that it's the job of the user object (maybe by delegating to some role class or objects) to provide the information as to whether those requirements are met. I smell something when I think about individual models specifying their requirements. Front-gate access through the controller actions smells more correct to me. If your actions can't be boiled down that atomically, I ask the question, "is there something else wrong?". Randy From lists at ruby-forum.com Mon Mar 2 15:59:04 2009 From: lists at ruby-forum.com (James Byrne) Date: Mon, 2 Mar 2009 21:59:04 +0100 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <387919.43677.qm@web31802.mail.mud.yahoo.com> References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> Message-ID: <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> unknown wrote: > >> sam.authorized?(controller_or_model, action)? > > I'll suggest that it's the controllers who are responsible for telling > what role or other requirements need to be satisfied to get their > services, and that it's the job of the user object (maybe by delegating > to some role class or objects) to provide the information as to whether > those requirements are met. > That is what I thought that I was doing. The Controller sends the message to the User Instance telling it to answer the question: are you authorized to perform "controller + action"?; or role, or whatever the controller sends as the criteria to be met. It seems to me necessary that the User model receive the context of the authorization call. Now the actual check on whether user x is authorized to perform the create method of the PaymentReceivedController is done in the #authorized? method of User. Is this what should be done or is there a different way? -- Posted via http://www.ruby-forum.com/. From zach.dennis at gmail.com Mon Mar 2 16:50:59 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Mon, 2 Mar 2009 16:50:59 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> References: <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> Message-ID: <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> On Mon, Mar 2, 2009 at 3:59 PM, James Byrne wrote: > unknown wrote: > >> >>> sam.authorized?(controller_or_model, action)? >> >> I'll suggest that it's the controllers who are responsible for telling >> what role or other requirements need to be satisfied to get their >> services, and that it's the job of the user object (maybe by delegating >> to some role class or objects) to provide the information as to whether >> those requirements are met. >> > > > That is what I thought that I was doing. ?The Controller sends the > message to the User Instance telling it to answer the question: are you > authorized to perform "controller + action"?; or role, or whatever the > controller sends as the criteria to be met. ?It seems to me necessary > that the User model receive the context of the authorization call. ?Now > the actual check on whether user x is authorized to perform the create > method of the PaymentReceivedController is done in the #authorized? > method of User. > > Is this what should be done or is there a different way? Today, my pair and I hit a scenario which I think maybe a good example to clarify. Let's say that you have an "admin" and "associate" role. Each role can access invoices in the system, but each role can access different subsets of invoices. In our controller, we could have something like: def index if user.has_role?("admin") Invoice.all elsif user.has_role?("associate") Invoice.by_area(current_user.area) else raise AccessDenied end end We ended up not doing this because the lines "Invoice.all" and "Invoice.by_area" is behaviour which is tied specifically to a certain role in the system. We don't want behaviour for these roles to be scattered throughout controller actions. We want it in one single location. So we create a FiscalAdmin role object and a FiscalAssociate role object. As these roles become filled out we leave the role-specific behaviour in one location, creating a well-defined cohesive class for each role. For me it's a little win, that results in big ways. :) -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From zach.dennis at gmail.com Mon Mar 2 17:16:33 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Mon, 2 Mar 2009 17:16:33 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> References: <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> Message-ID: <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> On Mon, Mar 2, 2009 at 4:50 PM, Zach Dennis wrote: > On Mon, Mar 2, 2009 at 3:59 PM, James Byrne wrote: >> unknown wrote: >> >>> >>>> sam.authorized?(controller_or_model, action)? >>> >>> I'll suggest that it's the controllers who are responsible for telling >>> what role or other requirements need to be satisfied to get their >>> services, and that it's the job of the user object (maybe by delegating >>> to some role class or objects) to provide the information as to whether >>> those requirements are met. >>> >> >> >> That is what I thought that I was doing. ?The Controller sends the >> message to the User Instance telling it to answer the question: are you >> authorized to perform "controller + action"?; or role, or whatever the >> controller sends as the criteria to be met. ?It seems to me necessary >> that the User model receive the context of the authorization call. ?Now >> the actual check on whether user x is authorized to perform the create >> method of the PaymentReceivedController is done in the #authorized? >> method of User. >> >> Is this what should be done or is there a different way? > > Today, my pair and I hit a scenario which I think maybe a good example > to clarify. > > Let's say that you have an "admin" and "associate" role. Each role can > access invoices in the system, but each role can access different > subsets of invoices. > > In our controller, we could have something like: > > def index > ? if user.has_role?("admin") > ? ? ?Invoice.all > ? elsif user.has_role?("associate") > ? ? ?Invoice.by_area(current_user.area) > ? else > ? ? raise AccessDenied > ? end > end > > We ended up not doing this because the lines "Invoice.all" and > "Invoice.by_area" is behaviour which is tied specifically to a certain > role in the system. We don't want behaviour for these roles to be > scattered throughout controller actions. We want it in one single > location. > > So we create a FiscalAdmin role object and a FiscalAssociate role > object. As these roles become filled out we leave the role-specific > behaviour in one location, creating a well-defined cohesive class for > each role. > > For me it's a little win, that results in big ways. :) > Forgot to mention what we did do. We ended up with the following... def index if user.has_role?("admin") user.in_role("admin").invoices elsif user.has_role?("associate") user.in_role("associate").invoices else raise AccessDenied end end To us, the change here is subtle, but important. The controller is allowed to ask for invoices from each role, but is not allowed to know how find the invoices, that's the behaviour of the role. > -- > - Show quoted text - > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From matt at mattwynne.net Mon Mar 2 18:17:22 2009 From: matt at mattwynne.net (Matt Wynne) Date: Mon, 2 Mar 2009 23:17:22 +0000 Subject: [rspec-users] Cucumber for large projects In-Reply-To: References: Message-ID: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> On 26 Feb 2009, at 15:33, Tom ten Thij wrote: > We will be using Cucumber for a fairly large project. Are there any > areas that cucumber is lacking when there are many scenarios? > > I believe the best candidate for showing our client the scenario > results is the html output. It strikes me that that becomes fairly > cumbersome to check with many scenarios. Methinks some javascript code > to hide all passing scenarios / features would be useful. Is there any > work being done on this? > > In which areas could we help cucumber accommodate for large projects? > > Tom. Hi Tom, At Songkick.com, we currently have 635 scenarios in our Cucumber tests, and while we've had a few issues, the ROI has definitely been worth it. At the moment, IMO, the tools for feeding back the features to non- technical people are pretty immature. My colleague Dan Lucraft wrote a tool which produces a nicely-formatted PDF document from your features folder[1] which is great, but won't work with the new version (0.2) of Cucumber when it's released as the API against which such formatters are written has undergone some significant changes for the new version. Once this stuff stabilises into the 0.2 release I expect more effort will be put into such tools, as the changes Aslak has made will make it much easier to write them. Check out the brave vision for the new HTML formatter: http://rspec.lighthouseapp.com/projects/16211/tickets/178-design-the-html-markup-for-cucumber-02 Other than that, you'll be likely to hit some issues just to do with managing the large number of specifications, but to be honest this has surprised me by being much easier than expected. The amount of code you actually write in the step definitions is minimal, especially if you're using Rails and something like factory_girl, so with a bit of regular re-factoring it's really easy to stay on top of it. We made a call early on to split our features folder into sub-folders named after the type of user, which has worked well for us: e.g. features/visitor/view_homepage.feature features/user/change_password.feature features/admin/list_users.feature That's helped us to keep things tidy, but there are obviously other ways to slice things up too. Are you planning to test the browser too (with selenium / watir / etc) or just from the HTTP requests down? Assuming you're building a web app of course... :) [1]http://www.daniellucraft.com/blog/2009/01/features_report/ Matt Wynne http://blog.mattwynne.net http://www.songkick.com From shot at hot.pl Mon Mar 2 18:32:26 2009 From: shot at hot.pl (Shot (Piotr Szotkowski)) Date: Tue, 3 Mar 2009 00:32:26 +0100 Subject: [rspec-users] Rspecing an enumerator from outside-in woes In-Reply-To: References: <20090228212917.GA19515@devielle> <18FD4D43-0429-4977-A01D-E651D9E0CA2F@mattwynne.net> <20090301173006.GD7432@devielle> Message-ID: <20090302233226.GE30550@devielle> Once again ? thanks a ton for your response! I wish ?The RSpec Book? answered my use cases; I bought it hoping I?ll learn all this stuff from it, but it seems the most interesting chapters are not written yet. :) Matt Wynne: > Assuming you wanted to keep your focus on the Decomposer class, but > you knew that the concept of a Decomposition was a firm one in your > design, you could define an empty Decomposition class, then stub the > constructor to return a test double of some sort: > class Decomposition > end > ... > Decomposition.stub!(:new).and_return mock('Decomposition', :foo => 'bar') Ah, a very good point. :) The idea of subclassing something to make it testable is also interesting; I?d rather try hard to come up with a better spec and/or design, but it?s good to remember there?s a solution to keep all the code added solely for testability in one place. > Ideally though, you really want to avoid testing state and instead > think about testing the interactions between objects. If the > relationship between the Decomposer and the Decomposition is for > one to create instances of the other, then I would be quite satisfied > writing mock expectations on the Decomposition's constructor, like > this: > Decomposition.should_receive(:new).with [1,2] And this is exactly where you hit the nail on the head. :) I think my main problem at this stage of ?getting RSpec? is the (shrinking, but still existing) inability to blur the border between the RSpec world and the world of the code under test. I happily started to use mocks and stubs, but I keep forgetting that they can be applied to the stuff from the ?other? world; I hope I?ll keep that in mind from now on. FWIW, your example on replacing ?.should_receive(:each).and_yield(?).and_yield(?).? with a fake generator struck a very nice chord with me, and I managed to side-step the problem that all three of my generator types expect a varying number of params to their #each calls: http://github.com/Chastell/art-decomp/commit/9979e3b687a33fd75e6394b6297e2200b052b354 > On 1 Mar 2009, at 17:30, Shot (Piotr Szotkowski) wrote: >> I think I agree ? but the real question was why don?t the (lazy) >> enumerator?s #next calls satisfy the mocks? #should_receive()s ? >> am I missing something fundamental, or is this simply an RSpec 1.1.12 >> incompatibility with Ruby 1.9.1? > Sorry, not sure about that one - I've not tried playing > with these lazy enumerators - is this a Ruby 1.9 thing Yes and no ? some/all of the Enumerator stuff was backported to 1.8 and is included in Ruby 1.8.7. Basically, if you have an #each method on your class, you can create an Enumerator? for its objects and then do very nice things, like having a free #with_index traversal or fetching the elements one-by-one with #next. The latter is useful for classes generating/representing infinite sequences and in cases (like my case of interdependent generators) when the cost of generating subsequent elements is rather high and it would be wasteful to generate all of them upfront. ? http://ruby-doc.org/core-1.9/classes/Enumerable/Enumerator.html ? Shot -- uo???n??suo? ??pun -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From zach.dennis at gmail.com Mon Mar 2 18:36:30 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Mon, 2 Mar 2009 18:36:30 -0500 Subject: [rspec-users] Is there a way to generate spec for existing controllers? In-Reply-To: References: <75cf4ca0-0e93-4b38-abda-e052dc4feac2@k19g2000prh.googlegroups.com> <57c63afe0903011551k77426d7fy560ba9d36736976f@mail.gmail.com> Message-ID: <85d99afe0903021536n2992c2a2tbd680c145097ba3@mail.gmail.com> On Sun, Mar 1, 2009 at 10:08 PM, Phlip wrote: > David Chelimsky wrote: > >> ty wrote: > >>> We just start using RSpec and rspec_on_rails for a existing Rails >>> project. > > No unit tests, right? > >>> After run script/generate rspec. It only generate the structure >>> folders. >>> We've got quite a few controllers and models. I wonder is it a way to >>> auto-generate specs for them. >> >> Nope. Sorry. > > Ask your goal-donor what feature they'd like to see in a spec. > > That is the point of specs - writing verbiage that a "product manager" or > "business analyst" can review. I think you're referring to business specs, and I think ty is asking about developer specs. You probably meant to refer him to writing features, no? -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From matt at mattwynne.net Mon Mar 2 18:44:28 2009 From: matt at mattwynne.net (Matt Wynne) Date: Mon, 2 Mar 2009 23:44:28 +0000 Subject: [rspec-users] Rspecing an enumerator from outside-in woes In-Reply-To: <20090302233226.GE30550@devielle> References: <20090228212917.GA19515@devielle> <18FD4D43-0429-4977-A01D-E651D9E0CA2F@mattwynne.net> <20090301173006.GD7432@devielle> <20090302233226.GE30550@devielle> Message-ID: <7A291EC8-8C1B-4ED6-90BF-33418716AE42@mattwynne.net> On 2 Mar 2009, at 23:32, Shot (Piotr Szotkowski) wrote: > Once again ? thanks a ton for your response! I wish ?The RSpec Book? > answered my use cases; I bought it hoping I?ll learn all this stuff > from > it, but it seems the most interesting chapters are not written yet. :) > > Matt Wynne: > >> Assuming you wanted to keep your focus on the Decomposer class, but >> you knew that the concept of a Decomposition was a firm one in your >> design, you could define an empty Decomposition class, then stub the >> constructor to return a test double of some sort: > >> class Decomposition >> end > >> ... > >> Decomposition.stub!(:new).and_return mock('Decomposition', :foo >> => 'bar') > > Ah, a very good point. :) The idea of subclassing something to make > it testable is also interesting; I?d rather try hard to come up > with a better spec and/or design, but it?s good to remember there?s > a solution to keep all the code added solely for testability in one > place. The idea comes from this book: http://www.amazon.co.uk/xUnit-Test-Patterns-Refactoring-Signature There are lots of other good ideas in that book. Some of them are only necessary because of the awkward things statically-typed languages force you to do, but many of them are equally applicable to and useful in Ruby. >> Ideally though, you really want to avoid testing state and instead >> think about testing the interactions between objects. If the >> relationship between the Decomposer and the Decomposition is for >> one to create instances of the other, then I would be quite satisfied >> writing mock expectations on the Decomposition's constructor, like >> this: > >> Decomposition.should_receive(:new).with [1,2] > > And this is exactly where you hit the nail on the head. :) I think > my main problem at this stage of ?getting RSpec? is the (shrinking, > but still existing) inability to blur the border between the RSpec > world > and the world of the code under test. I happily started to use mocks > and > stubs, but I keep forgetting that they can be applied to the stuff > from > the ?other? world; I hope I?ll keep that in mind from now on. > > FWIW, your example on replacing > ?.should_receive(:each).and_yield(?).and_yield(?).? > with a fake generator struck a very nice chord with > me, and I managed to side-step the problem that all > three of my generator types expect a varying number > of params to their #each calls: > http://github.com/Chastell/art-decomp/commit/9979e3b687a33fd75e6394b6297e2200b052b354 Glad it helped :) Matt Wynne http://blog.mattwynne.net http://www.songkick.com From walketim at gmail.com Mon Mar 2 20:55:53 2009 From: walketim at gmail.com (Tim Walker) Date: Mon, 2 Mar 2009 18:55:53 -0700 Subject: [rspec-users] [cucumber] Cucumber and Chronic In-Reply-To: <3c30da400903011530vbf3b9b8v3ace26553e29a078@mail.gmail.com> References: <1ebf5a4d0903010850l54c7ee19i58dbbc48150a9339@mail.gmail.com> <3c30da400903011107n7057e73fy89b2913085d222c0@mail.gmail.com> <3c30da400903011530vbf3b9b8v3ace26553e29a078@mail.gmail.com> Message-ID: <1ebf5a4d0903021755u7920e3c4r8233e54da04fd151@mail.gmail.com> Absolutely. I'd respectfully suggest that this is more a requirement of the way the step definition or test fixture that implements the feature needs to behave than the intent of describing time based logic in a natural language such that product owners, ba's etc. can write them (i.e. Cucumber, FitNesse, etc). That Chronic takes into consideration the things you mention (time zone, DST, Leap Years, etc), is simply an imperative of it. Anyway, I think it fits hand-in-glve with Cucumber and BDD in general. Just for the record, I have no vested interest in Chronic and really don't know who even authored it, but I can say it's looking pretty awesome in our own Cucumber tests. Thanks, Tim On Sun, Mar 1, 2009 at 4:30 PM, Mark Wilden wrote: > On Sun, Mar 1, 2009 at 11:07 AM, Mark Wilden wrote: >> >> Just be careful when when basing durations from "now" that daylight >> savings time doesn't affect anything. > > Along the same lines, don't write tests that assume 1.month.ago was < > 29 days ago, or specs could start failing in March (as just happened > with us). :) > > ///ark > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From sfeley at gmail.com Mon Mar 2 23:35:51 2009 From: sfeley at gmail.com (Stephen Eley) Date: Mon, 2 Mar 2009 23:35:51 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> References: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> Message-ID: <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote: > > Forgot to mention what we did do. We ended up with the following... > > def index > ?if user.has_role?("admin") > ? ?user.in_role("admin").invoices > ?elsif user.has_role?("associate") > ? ?user.in_role("associate").invoices > ?else > ? ?raise AccessDenied > ?end > end That seems sort of backwards to me. These aren't the user's invoices, right? They're just invoices which the user happens to be allowed to see? Chaining it this way makes it look like the invoices *belong* to the role, and seems put the user up front instead of the invoices. You also have conditional branching with hardcoded values, making the controller brittle, and some redundancy with the controller asking the model for a value and then passing the value right back to the model. Can a model have more than one role? If it can, you have a problem here because the 'if' will only ever *act* on one role. If it can't, life gets simple: [controller] def index @invoices = Invoice.by_role(user) rescue AccessDenied flash[:warning] = "Nope. Sorry. Nice try." redirect_to :back end [Invoice model] def by_role(user) case user.role when "admin" [whatever] when "associate" [whatever] else raise AccessDenied end end ...That could probably still be made more elegant. I'm not a huge fan of case statements, and I have in my head some idea that you could have named scopes for each role and use "send" to pick the right scope. But that could be overdesigning it, and in any case I don't really know what each role has to return in your business case. The important takeaway here is that the Invoice is responsible for figuring out what to return, based on user data passed to it at runtime; the User doesn't have to have special logic to know how to query every other model in the system. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From sfeley at gmail.com Tue Mar 3 00:01:03 2009 From: sfeley at gmail.com (Stephen Eley) Date: Tue, 3 Mar 2009 00:01:03 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> Message-ID: <1fb4df0903022101o2aeb09d8t7fc232406262300e@mail.gmail.com> On Sat, Feb 28, 2009 at 5:26 PM, Chris Flipse wrote: > > Half of my problem right now is that I'm not even sure what layer to put > model specific authentication!? If it's in the controller layer, it's > repeated logic in every controller that touches the model in question.? If > it's in the model, the logic is centralized, but now your model needs not > only to know about Users in general, it needs a specific user. My two cents: 1.) I feel authorization belongs in two places: models and views. Models need to know what they're allowed to do. Authorization becomes a scope on reads and a validation on updates. Views (specifically helper methods) need to know whether they're allowed to show that "Edit" button, etc. That's not critical path, that's navigation, maybe one step up from cosmetics. I don't see a reason why controllers need to know as long as they can handle nils coming back from the models. 2.) In both cases, you need to know who the current user is, and that's fine. Figuring it out is the job of *authentication*, not authorization. Your authentication stack just needs to give you a hook where you can ask it for the user, and your authorization stack should handle it sensibly if the answer is 'nil.' The restful_authentication plugin implements current_user as a global Application method, but that's not the only way to do it. 3.) Consider separating the authorization stuff from the core business logic of your app, and implementing it as a module on the authorizable classes instead. Then if your basic authz behavior changes, you (ideally) only have to change it in one place. And it doesn't mess up the readability of your main behavior. ...And because everyone else is doing it, here are my design notes on my own overcomplicated authorization system (which, caveat, has yet to be built, but I wrote this all down anyway to get it out of my head): http://extraneous.org/past/2009/2/6/mother_do_you_think_theyll_drop_the_bomb/ I know it looks rather overdone, and it's perfectly possible that it is, but my requirements were sincere: * it needs to handle both users and groups, and * I wanted it to be hierarchical, such that privileges on parent pages trickle down to their children. Between those two constraints, I couldn't off the top of my head think of anything more elegant. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From zach.dennis at gmail.com Tue Mar 3 00:15:39 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 3 Mar 2009 00:15:39 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> References: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> Message-ID: <85d99afe0903022115k1230ad72m6a0a66f29779b668@mail.gmail.com> On Mon, Mar 2, 2009 at 11:35 PM, Stephen Eley wrote: > On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote: >> >> Forgot to mention what we did do. We ended up with the following... >> >> def index >> if user.has_role?("admin") >> user.in_role("admin").invoices >> elsif user.has_role?("associate") >> user.in_role("associate").invoices >> else >> raise AccessDenied >> end >> end > > That seems sort of backwards to me. These aren't the user's invoices, > right? They're just invoices which the user happens to be allowed to > see? Chaining it this way makes it look like the invoices *belong* to > the role, and seems put the user up front instead of the invoices. I agree, it could be better. > You also have conditional branching with hardcoded values, making the > controller brittle, and some redundancy with the controller asking the > model for a value and then passing the value right back to the model. I would like to push down the conditional logic to a lower part of the app and there probably is a way that I haven't found yet with the technique I'm using. Right now I'm exploring some trade-offs. Put more emphasis on the responsibility of a role or on the responsibility of the model? I've been down the model route, and would like to see where the role route takes me. :) > > Can a model have more than one role? If it can, you have a problem > here because the 'if' will only ever *act* on one role. If it can't, > life gets simple: > > [controller] > def index > @invoices = Invoice.by_role(user) > rescue AccessDenied > flash[:warning] = "Nope. Sorry. Nice try." > redirect_to :back > end > > [Invoice model] > def by_role(user) > case user.role > when "admin" > [whatever] > when "associate" > [whatever] > else > raise AccessDenied > end > end > > ...That could probably still be made more elegant. I'm not a huge fan > of case statements, and I have in my head some idea that you could > have named scopes for each role and use "send" to pick the right > scope. But that could be overdesigning it, and in any case I don't > really know what each role has to return in your business case. I've been down this path many times. It has worked well when the privilege/role set was limited and fairly simple, but seems to leave models convoluted for anything else. That's what sparked me to explore concretely identifying the Role in my app, and allowing it to make decisions that are unique to it, rather than sprinkling them throughout the models. > > The important takeaway here is that the Invoice is responsible for > figuring out what to return, based on user data passed to it at > runtime; the User doesn't have to have special logic to know how to > query every other model in the system. To clarify, the User doesn't know how-to query anything. All it knows is if it can fulfill a Role. If it can it returns the appropriate role object. Each role is responsible for knowing what it can access, but it doesn't do the nitty gritty work. It calls methods on other models. For the Invoice example, the associate role calls Invoice.by_area(user.area), whereas the Admin role calls Invoice.all in each of their respective #invoices methods. Some of what has piqued my interest in exploring apps that place more emphasis on Roles and Privileges is that it it's difficult to understand what it means to be an admin when what it means to be able to to be an "admin" or "supervisor" or a "team supervisor" or an "employee" is sprinkled throughout the app. So far I have enjoyed having the responsibility of an admin in one spot, even though that Admin object doesn't deal with the details. It just knows how-to make a decision and then it tells another object to do it. It's kind of like inserting a thin-layer of roles and privileges between the application layer and the domain layer. I'd say these sit on the top end of the domain layer. As you pointed out earlier, the API for #in_role could use a little love. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From mark at mwilden.com Tue Mar 3 01:04:04 2009 From: mark at mwilden.com (Mark Wilden) Date: Mon, 2 Mar 2009 22:04:04 -0800 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> References: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> Message-ID: <3c30da400903022204j143825b2x992b633236b99fa0@mail.gmail.com> On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote: > ?@invoices = Invoice.by_role(user) It doesn't seem right to me that invoices know about users and roles. I think of invoices are being closer to the metal -- closer to the essence of the application -- than petty concerns like authorization. I would try something like user.role.invoices where Role is a model that does the traffic-cop work of deciding what invoices are available to it. ///ark From sfeley at gmail.com Tue Mar 3 01:34:21 2009 From: sfeley at gmail.com (Stephen Eley) Date: Tue, 3 Mar 2009 01:34:21 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <3c30da400903022204j143825b2x992b633236b99fa0@mail.gmail.com> References: <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> <3c30da400903022204j143825b2x992b633236b99fa0@mail.gmail.com> Message-ID: <1fb4df0903022234g61542536jdae9a4745d5c49d2@mail.gmail.com> On Tue, Mar 3, 2009 at 1:04 AM, Mark Wilden wrote: > On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote: > >> ?@invoices = Invoice.by_role(user) > > It doesn't seem right to me that invoices know about users and roles. > > I would try something like > ?user.role.invoices Heh. Which is what Zach said he wanted to do, and it isn't wrong. But it doesn't seem right to *me* that roles know about invoices. >8-> As I see it, if you go that path you end up having to inform roles about every *other* model, and consolidating all your business logic in one class. At which point you're risking drifting away from object-oriented programming and heading back to big procedures and spaghetti code. But that's a kneejerk response, and it needn't be that bad. It really comes down to taste. To-mae-to, to-mah-to. Sooner or later it's all ones and zeros. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From mark at mwilden.com Tue Mar 3 02:21:37 2009 From: mark at mwilden.com (Mark Wilden) Date: Mon, 2 Mar 2009 23:21:37 -0800 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <1fb4df0903022234g61542536jdae9a4745d5c49d2@mail.gmail.com> References: <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> <3c30da400903022204j143825b2x992b633236b99fa0@mail.gmail.com> <1fb4df0903022234g61542536jdae9a4745d5c49d2@mail.gmail.com> Message-ID: <3c30da400903022321k4d9da5b6g28ac25dc0b3944c@mail.gmail.com> On Mon, Mar 2, 2009 at 10:34 PM, Stephen Eley wrote: > On Tue, Mar 3, 2009 at 1:04 AM, Mark Wilden wrote: >> ?user.role.invoices > > Heh. ?Which is what Zach said he wanted to do, and it isn't wrong. Actually, I thought Zach was talking about a method on User called in_role. > But it doesn't seem right to *me* that roles know about invoices. Roles know about access to invoices. That's what their purpose is - to let people do some things and not let them do others. >>8-> ?As I see it, if you go that path you end up having to inform > roles about every *other* model, and consolidating all your business > logic in one class. You do consolidate all your _access_ logic in one class, just as you might consolidate all your sales tax knowledge in another class. That way you have one source of responsibility for that behavior. Otherwise, if you added, changed or deleted a role, you'd have to change every model. This is basically the Mediator pattern. Pluses and minuses, to be sure. ///ark From f.mischa at gmail.com Tue Mar 3 04:08:54 2009 From: f.mischa at gmail.com (Mischa Fierer) Date: Tue, 3 Mar 2009 03:08:54 -0600 Subject: [rspec-users] Cucumber for large projects In-Reply-To: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> Message-ID: Speed will possibly become a big issue once you get above 1-2k steps or so. Testjour was written to solve this: http://github.com/brynary/testjour/tree/master While I haven't been able to use it myself, since I work mostly from home, it apparently radically reduces the time it takes to run features. The only other tip I have for using cucumber in big projects is to make sure that you stay on top of small changes to code that don't break features, but over time end up changing what is happening to the point that, while the test passes, it is no longer testing what you think it is testing. So, like Matt said, it's a good idea to keep on top of things. However, this is a minor issue and not cucumber specific. Best, M On Mon, Mar 2, 2009 at 5:17 PM, Matt Wynne wrote: > > On 26 Feb 2009, at 15:33, Tom ten Thij wrote: > > We will be using Cucumber for a fairly large project. Are there any >> areas that cucumber is lacking when there are many scenarios? >> >> I believe the best candidate for showing our client the scenario >> results is the html output. It strikes me that that becomes fairly >> cumbersome to check with many scenarios. Methinks some javascript code >> to hide all passing scenarios / features would be useful. Is there any >> work being done on this? >> >> In which areas could we help cucumber accommodate for large projects? >> >> Tom. >> > > Hi Tom, > > At Songkick.com, we currently have 635 scenarios in our Cucumber tests, and > while we've had a few issues, the ROI has definitely been worth it. > > At the moment, IMO, the tools for feeding back the features to > non-technical people are pretty immature. My colleague Dan Lucraft wrote a > tool which produces a nicely-formatted PDF document from your features > folder[1] which is great, but won't work with the new version (0.2) of > Cucumber when it's released as the API against which such formatters are > written has undergone some significant changes for the new version. > > Once this stuff stabilises into the 0.2 release I expect more effort will > be put into such tools, as the changes Aslak has made will make it much > easier to write them. Check out the brave vision for the new HTML formatter: > > http://rspec.lighthouseapp.com/projects/16211/tickets/178-design-the-html-markup-for-cucumber-02 > > Other than that, you'll be likely to hit some issues just to do with > managing the large number of specifications, but to be honest this has > surprised me by being much easier than expected. The amount of code you > actually write in the step definitions is minimal, especially if you're > using Rails and something like factory_girl, so with a bit of regular > re-factoring it's really easy to stay on top of it. We made a call early on > to split our features folder into sub-folders named after the type of user, > which has worked well for us: > > e.g. > > features/visitor/view_homepage.feature > features/user/change_password.feature > features/admin/list_users.feature > > That's helped us to keep things tidy, but there are obviously other ways to > slice things up too. Are you planning to test the browser too (with selenium > / watir / etc) or just from the HTTP requests down? Assuming you're building > a web app of course... :) > > [1]http://www.daniellucraft.com/blog/2009/01/features_report/ > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zuperinfinite at gmail.com Tue Mar 3 04:15:37 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Tue, 3 Mar 2009 10:15:37 +0100 Subject: [rspec-users] be_valid (validates_format_of ..., :on => :create) In-Reply-To: <3c30da400903020912x1eeb7c6cmd4e0ce8d5d4b8dd0@mail.gmail.com> References: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> <57c63afe0903020750g5936966cg85cf715a5d8c980a@mail.gmail.com> <937E5EFE-C47A-433F-AD35-A76889F35434@gmail.com> <3c30da400903020912x1eeb7c6cmd4e0ce8d5d4b8dd0@mail.gmail.com> Message-ID: <66B073D3-4980-4566-878F-BF67B883651B@gmail.com> On 2-mrt-2009, at 18:12, Mark Wilden wrote: > On Mon, Mar 2, 2009 at 8:23 AM, Bart Zonneveld > wrote: >> >> On a second note, I noticed rspec default generated model specs >> now use >> Model.create!(@valid_attributes) as their default "all is valid" >> test. >> What's the advantage of this approach? I just write >> @model.attributes = >> @valid_attributes; @model.should be_valid, to prevent these specs to >> actually hit the db, and therefore speed up my specs a bit. > > Wouldn't it be better to go through the complete create! cycle, to > make sure callbacks and database constraints (if any) are exercised? Could be, but imagine I have 5 validations on my model. Only the first will throw an error on create!. And since my validations are in Dutch, I specifically test each validation to see whether it returns the correct error message. I use the following structure: class Article validates_presence_of :title end describe Article before(:each) do @article = Article.new @valid_attributes = { :title => "Title" } end it "should not be valid without a title" do @article.attributes = @valid_attributes.except :title @article.should_not be_valid end it "should be valid with all valid attributes" do @article.attributes = @valid_attributes @article.should be_valid end end From aidy.lewis at googlemail.com Tue Mar 3 05:06:00 2009 From: aidy.lewis at googlemail.com (aidy lewis) Date: Tue, 3 Mar 2009 10:06:00 +0000 Subject: [rspec-users] Cucumber for large projects In-Reply-To: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> Message-ID: <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> Hi Matt/Dan 2009/3/2 Matt Wynne : > At the moment, IMO, the tools for feeding back the features to non-technical > people are pretty immature. My colleague Dan Lucraft wrote a tool which > produces a nicely-formatted PDF document from your features folder[1] which > is great, but won't work with the new version (0.2) of Cucumber when it's > released as the API against which such formatters are written has undergone > some significant changes for the new version. > > [1]http://www.daniellucraft.com/blog/2009/01/features_report/ To me the user\customer should be involved in the creation of the stories and the acceptance criteria and by producing a pdf later in the cycle for those stakeholders to read and understand may be argued as something that is not Story-Driven-Development and more like comprehendible automated tests. Aidy From gcirne at gmail.com Tue Mar 3 08:17:06 2009 From: gcirne at gmail.com (Guilherme Machado Cirne) Date: Tue, 3 Mar 2009 10:17:06 -0300 Subject: [rspec-users] Cucumber and selenium grid In-Reply-To: <49A8918C.6010306@gmail.com> References: <21a1366d0902271335k51fb95d6n92e265bfcbcb3e0b@mail.gmail.com> <49A8918C.6010306@gmail.com> Message-ID: <21a1366d0903030517o79539416w3f851f2f302ada89@mail.gmail.com> Ok. How about the html report generation when running features in parallel? I don't suppose there would be a single merged html report, correct? Thanks, -- Guilherme Machado Cirne gcirne at gmail.com On Fri, Feb 27, 2009 at 10:21 PM, Mike Gaffney wrote: > You can configure webrat to use selenium grid. Running tests in parallel > would take having seperate test tasks or breaking them down somehow. Also > the tests need to be touching atomic data or they will interfere. > > Guilherme Machado Cirne wrote: > >> Hi, >> >> Does anybody know how to integrate cucumber features with selenium grid? >> Actually, what is needed is to run cucumber features in parallel so that >> using selenium grid helps cut down on the total time it takes to run a test >> suite. >> >> Thanks, >> >> -- >> Guilherme Machado Cirne >> gcirne at gmail.com >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > -- > -Mike Gaffney (http://rdocul.us) > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at mattwynne.net Tue Mar 3 08:49:54 2009 From: matt at mattwynne.net (Matt Wynne) Date: Tue, 3 Mar 2009 13:49:54 +0000 Subject: [rspec-users] Cucumber for large projects In-Reply-To: <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> Message-ID: On 3 Mar 2009, at 10:06, aidy lewis wrote: > Hi Matt/Dan > > 2009/3/2 Matt Wynne : > >> At the moment, IMO, the tools for feeding back the features to non- >> technical >> people are pretty immature. My colleague Dan Lucraft wrote a tool >> which >> produces a nicely-formatted PDF document from your features >> folder[1] which >> is great, but won't work with the new version (0.2) of Cucumber >> when it's >> released as the API against which such formatters are written has >> undergone >> some significant changes for the new version. >> > >> [1]http://www.daniellucraft.com/blog/2009/01/features_report/ > > To me the user\customer should be involved in the creation of the > stories and the acceptance criteria and by producing a pdf later in > the cycle for those stakeholders to read and understand may be argued > as something that is not Story-Driven-Development and more like > comprehendible automated tests. Should I expect a visit from the Extreme Programing Police Aidy? ;) I take your point, and I always try to pair with stakeholders when creating new features. I think it's also important though that when stakeholders are considering adding new features or changing existing ones that the current set of Running Tested Features is as visible as possible to them. This is one of the advantages of something like Fitnesse, where each feature is only a URL away. Matt Wynne http://blog.mattwynne.net http://www.songkick.com From jkleindl at gmail.com Mon Mar 2 17:13:13 2009 From: jkleindl at gmail.com (Jeremy Kleindl) Date: Mon, 2 Mar 2009 14:13:13 -0800 (PST) Subject: [rspec-users] Changes in specs for routes in rspec 1.1.99.x In-Reply-To: <4b8a6a1f20a84f53853d62c062603af2@ruby-forum.com> References: <4b8a6a1f20a84f53853d62c062603af2@ruby-forum.com> Message-ID: <9609f340-c246-4083-8d79-785e47c2efaf@k29g2000prf.googlegroups.com> Thank you for posting this. Is this a script to replace/add arguments to the route_for methods in my current controller routing specs? Will the changes this script affects fix the errors I get when running specs like " route_for(_whatever_)should == '/foo/1' " on :update and :destroy actions generating a :show route? I've tried adding a :method argument and passing :put and :delete - no go on these assuring the correct routes so far. I'm off to read the rspec source to figure out WTF changed... On Mar 2, 4:08 am, Juanma Cervera wrote: > Trying the next release of rspec, I have had to make changes in the > existing specs for routing. > I have written an script with sed that makes this automatically (two > files) > > spec/upgrade.sed > ================ > /route_for/s/id => 1/id => "1"/g > /route_for.*create/s/== \(["'].*["']\)/== {:path => \1, :method => > :post}/ > /route_for.*update/s/== \(["'].*["']\)/== {:path => \1, :method => > :put}/ > /route_for.*destroy/s/== \(["'].*["']\)/== {:path => \1, :method => > :delete}/ > > and > spec/upgrade > ============ > for f in `find controllers -name "*routing*rb" -type f`; do sed -i -f > upgrade.sed $f; done > > You shoud make this file executable and run it > > I hope this helps somebody. > Juanma > -- > Posted viahttp://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From jkleindl at gmail.com Mon Mar 2 17:22:37 2009 From: jkleindl at gmail.com (Jeremy Kleindl) Date: Mon, 2 Mar 2009 14:22:37 -0800 (PST) Subject: [rspec-users] Changes in specs for routes in rspec 1.1.99.x In-Reply-To: <4b8a6a1f20a84f53853d62c062603af2@ruby-forum.com> References: <4b8a6a1f20a84f53853d62c062603af2@ruby-forum.com> Message-ID: <08590a9e-5604-4201-a349-03e83d386468@b38g2000prf.googlegroups.com> GAh! easy one - I was adding the method argument to the 'route_for()' instead of the 'should ==' hash it compares the generated output with. And now I see how the script you made takes the single string argument from the old style and drops it into a hash that includes the restful method name. Thank you for providing the clue I needed to get the correct syntax. On Mar 2, 4:08 am, Juanma Cervera wrote: > Trying the next release of rspec, I have had to make changes in the > existing specs for routing. > I have written an script with sed that makes this automatically (two > files) > > spec/upgrade.sed > ================ > /route_for/s/id => 1/id => "1"/g > /route_for.*create/s/== \(["'].*["']\)/== {:path => \1, :method => > :post}/ > /route_for.*update/s/== \(["'].*["']\)/== {:path => \1, :method => > :put}/ > /route_for.*destroy/s/== \(["'].*["']\)/== {:path => \1, :method => > :delete}/ > > and > spec/upgrade > ============ > for f in `find controllers -name "*routing*rb" -type f`; do sed -i -f > upgrade.sed $f; done > > You shoud make this file executable and run it > > I hope this helps somebody. > Juanma > -- > Posted viahttp://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Tue Mar 3 10:08:38 2009 From: lists at ruby-forum.com (James Byrne) Date: Tue, 3 Mar 2009 16:08:38 +0100 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <3c30da400903022321k4d9da5b6g28ac25dc0b3944c@mail.gmail.com> References: <57c63afe0902281038w6a5d9dbas5d6179abfdfa1d5b@mail.gmail.com> <57c63afe0902281116n1a75f5f4n300519b942e8cd19@mail.gmail.com> <49A9A1C0.9050904@benmabey.com> <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> <3c30da400903022204j143825b2x992b633236b99fa0@mail.gmail.com> <1fb4df0903022234g61542536jdae9a4745d5c49d2@mail.gmail.com> <3c30da400903022321k4d9da5b6g28ac25dc0b3944c@mail.gmail.com> Message-ID: Mark Wilden wrote: > > You do consolidate all your _access_ logic in one class, just as you > might consolidate all your sales tax knowledge in another class. That > way you have one source of responsibility for that behavior. > Otherwise, if you added, changed or deleted a role, you'd have to > change every model. > > This is basically the Mediator pattern. Pluses and minuses, to be sure. > This is not where I am spending my time at the moment, but it is an area that i am going to confront sooner than later. So, I am interested in this subject. If I understand aright, it is agreed that authorization is best determined by the user model, either as a full-blown authorization method wholly contained in the User class or as a call to a subordinate Authorization class which does the heavy lifting and then returns the result to the User class. The controllers (and perhaps models) that require authorization simply call the equivalent to an "authorized?" method on the current_user passing the context, whether this be a named role or a control/action pair or a model/attribute pair. The User.authorized? method simply replies whether this current_user belongs to the named role or otherwise has the privilege of performing the desired action. If there is an Authorization class then this is where the work is done (lookups on models or tables as the case may be). Does this capture the essence? The question that I have is: If one implements an authorization system as a model or models then would this best be implemented in the user as an association rather than as a separate Authorization class? -- Posted via http://www.ruby-forum.com/. From apremdas at gmail.com Tue Mar 3 11:07:30 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Tue, 3 Mar 2009 16:07:30 +0000 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> References: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> Message-ID: <88fd8ddc0903030807k4539a94duf28fd4b4e285e53@mail.gmail.com> I think this discussion has gone backwards a bit. Here is what I think the index method in the invoices controller should be like def index begin invoice.get_collection rescue # decide what to do if we can't get collection end end Now clearly this needs some work to get it to work ... 1) What is 'invoice' Rails by default ties 'invoice' to a class in app/model. Usually this ActiveRecord model class, but it doesn't have to be. We can always put another layer inbetween (e.g. Presenter) if it makes our code simpler 2) Authentication parameters Clearly these need to be passed through to get_collection. This can be done by parameters or by making the authentication available in a wider context. 3) Exceptions We need an exception hierarchy. NotAuthorised, NotFound etc. All the controller should do is get the collection and deal with exceptions if the collection is not available. (n.b. the collection being empty is not exceptional.) Rails historically has corrupted (compromised, polluted ...) MVC by allowing concerns of how we get the collection to be included in the controller. RESTful design has highlighted the problems with this and now we end up with this situation where things like authentication and authorisation don't really have an obvious place. These things - authentication, authorisation and the exception handling (for the resource) - are services which all resources need access to. They need to be seperated and applied in a cross-cutting manner. Perhaps we could do things more elegantly with an Aspect Orientated solution. Andrew 2009/3/2 Zach Dennis > > Forgot to mention what we did do. We ended up with the following... > > def index > if user.has_role?("admin") > user.in_role("admin").invoices > elsif user.has_role?("associate") > user.in_role("associate").invoices > else > raise AccessDenied > end > end > > To us, the change here is subtle, but important. The controller is > allowed to ask for invoices from each role, but is not allowed to know > how find the invoices, that's the behaviour of the role. > > > -- > > - Show quoted text - > > Zach Dennis > > http://www.continuousthinking.com > > http://www.mutuallyhuman.com > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zach.dennis at gmail.com Tue Mar 3 12:06:32 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 3 Mar 2009 12:06:32 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <88fd8ddc0903030807k4539a94duf28fd4b4e285e53@mail.gmail.com> References: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <88fd8ddc0903030807k4539a94duf28fd4b4e285e53@mail.gmail.com> Message-ID: <85d99afe0903030906t44484148l847857fca5d55463@mail.gmail.com> On Tue, Mar 3, 2009 at 11:07 AM, Andrew Premdas wrote: > I think this discussion has gone backwards a bit. Here is what I think the > index method in the invoices controller should be like > > def index > ? begin > ?? invoice.get_collection > ? rescue > ??? # decide what to do if we can't get collection > ? end > end > > Now clearly this needs some work to get it to work ... > > 1) What is 'invoice' > > Rails by default ties 'invoice' to a class in app/model. Usually this > ActiveRecord model class, but it doesn't have to be. We can always put > another layer inbetween (e.g. Presenter) if it makes our code simpler Presenters are for presentation logic, not for authorization concerns. > > 2) Authentication parameters > > Clearly these need to be passed through to get_collection. This can be done > by parameters or by making the authentication available in a wider context. Authentication isn't the issue here, authorization is. > > 3) Exceptions > > We need an exception hierarchy. NotAuthorised, NotFound etc. > > All the controller should do is get the collection and deal with exceptions > if the collection is not available. (n.b. the collection being empty is not > exceptional.) > > Rails historically has corrupted (compromised, polluted ...) MVC by allowing > concerns of how we get the collection to be included in the controller. > RESTful design has highlighted the problems with this and now we end up with > this situation where things like authentication and authorisation don't > really have an obvious place. It is up to the controllers to know how-to ask for something, it should not know how the internals of that request work. For a controller to know what role can access a particular resource is completely aligned with a layered architecture, keeping application concerns in the right layer, and domain logic in another layer. > > These things - authentication, authorisation and the exception handling (for > the resource) - are services which all resources need access to. They need > to be seperated and applied in a cross-cutting manner. Perhaps we could do > things more elegantly with an Aspect Orientated solution. > Is some cases yes, but I fail to see where it benefits or adds more value then concretely identifying a role that has particular behavior. > > 2009/3/2 Zach Dennis >> >> Forgot to mention what we did do. We ended up with the following... >> >> def index >> ?if user.has_role?("admin") >> ? ?user.in_role("admin").invoices >> ?elsif user.has_role?("associate") >> ? ?user.in_role("associate").invoices >> ?else >> ? ?raise AccessDenied >> ?end >> end >> >> To us, the change here is subtle, but important. The controller is >> allowed to ask for invoices from each role, but is not allowed to know >> how find the invoices, that's the behaviour of the role. >> >> > -- >> > - Show quoted text - >> > Zach Dennis >> > http://www.continuousthinking.com >> > http://www.mutuallyhuman.com >> > >> >> > > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From pat.maddox at gmail.com Tue Mar 3 12:32:33 2009 From: pat.maddox at gmail.com (Pat Maddox) Date: Tue, 3 Mar 2009 09:32:33 -0800 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> References: <88fd8ddc0903020656y54888d44gb3928cc555302bcf@mail.gmail.com> <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> Message-ID: <2c7e61990903030932q353018f4v8323b4ed99366db0@mail.gmail.com> On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote: > On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote: >> >> Forgot to mention what we did do. We ended up with the following... >> >> def index >> ?if user.has_role?("admin") >> ? ?user.in_role("admin").invoices >> ?elsif user.has_role?("associate") >> ? ?user.in_role("associate").invoices >> ?else >> ? ?raise AccessDenied >> ?end >> end > > That seems sort of backwards to me. ?These aren't the user's invoices, > right? ?They're just invoices which the user happens to be allowed to > see? ?Chaining it this way makes it look like the invoices *belong* to > the role, and seems put the user up front instead of the invoices. > You also have conditional branching with hardcoded values, making the > controller brittle, and some redundancy with the controller asking the > model for a value and then passing the value right back to the model. Agreed. I have a similar example in a blog post: http://www.patmaddox.com/blog/2008/7/23/when-duplication-in-tests-informs-design Pat From zach.dennis at gmail.com Tue Mar 3 13:06:12 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 3 Mar 2009 13:06:12 -0500 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <2c7e61990903030932q353018f4v8323b4ed99366db0@mail.gmail.com> References: <675261bfd8ca95790d348539630b1398@ruby-forum.com> <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> <2c7e61990903030932q353018f4v8323b4ed99366db0@mail.gmail.com> Message-ID: <85d99afe0903031006v34236d8du5ae5b2f18da89be9@mail.gmail.com> On Tue, Mar 3, 2009 at 12:32 PM, Pat Maddox wrote: > On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote: >> On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote: >>> >>> Forgot to mention what we did do. We ended up with the following... >>> >>> def index >>> ?if user.has_role?("admin") >>> ? ?user.in_role("admin").invoices >>> ?elsif user.has_role?("associate") >>> ? ?user.in_role("associate").invoices >>> ?else >>> ? ?raise AccessDenied >>> ?end >>> end >> >> That seems sort of backwards to me. ?These aren't the user's invoices, >> right? ?They're just invoices which the user happens to be allowed to >> see? ?Chaining it this way makes it look like the invoices *belong* to >> the role, and seems put the user up front instead of the invoices. >> You also have conditional branching with hardcoded values, making the >> controller brittle, and some redundancy with the controller asking the >> model for a value and then passing the value right back to the model. > > Agreed. ?I have a similar example in a blog post: > http://www.patmaddox.com/blog/2008/7/23/when-duplication-in-tests-informs-design I agree I'm taking a step back to try to make two steps forward. The heart of the exploration is more than the conditional in the action (which simply states which roles are allowed to access that action, I just made it explicit rather than using a #restrict_to call). To me this discussion is about where the behaviour for a role should go and how-to access that behaviour. The flip side of this is that models end up with redundant conditional branches to do x for RoleA or y for RoleB (for every model thats affected by a Role). I would like to collapse these conditional branches and attempt a more polymorphic approach by extracting a class representative of each role, and simply calling the method in question. e.g: FiscalAssociate.new(user).invoices FiscalAdmin.new(user).invoices Rather than the following approach. Keep in mind that roles hardly ever are limited to one model. Consider having the case statement in 20 models. Where's the redundancy now? Invoice.by_role() def by_role(role case role when "associate" .... when "admin" ... end -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From apremdas at gmail.com Tue Mar 3 14:50:42 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Tue, 3 Mar 2009 19:50:42 +0000 Subject: [rspec-users] [rails] An authorization question In-Reply-To: <85d99afe0903031006v34236d8du5ae5b2f18da89be9@mail.gmail.com> References: <3c30da400903021110t52991e46y16a0f644a4992baf@mail.gmail.com> <387919.43677.qm@web31802.mail.mud.yahoo.com> <2ce629d2f33b1a587b46ee90413d0e77@ruby-forum.com> <85d99afe0903021350p1e79dd9cw66cf43b7f1d1184b@mail.gmail.com> <85d99afe0903021416k6d9dc768q2676db5107146065@mail.gmail.com> <1fb4df0903022035u2aadd8ek201f3f3faaeb5c88@mail.gmail.com> <2c7e61990903030932q353018f4v8323b4ed99366db0@mail.gmail.com> <85d99afe0903031006v34236d8du5ae5b2f18da89be9@mail.gmail.com> Message-ID: <88fd8ddc0903031150l4cc4acc8nc81393e8ac319a48@mail.gmail.com> Zach By saying that models need the following case statement def by_role(role case role when "associate" .... when "admin" ... end your implying that the model is represented in a different way depending on the role. So in your case of invoices the associate's view is different from the administrators. If this is the case then you have identified two distinct resources! Currently you are representing these two resources with one url e.g. /invoices However if you think of these as seperate resources then you have two url's /admin_invoices /associatie_invoices Other url schems come fo mind /admin/invoices /invoices/admin etc. Point is that you can implement these seperate resources in the standard rails way and remove any need for case statements class AdminInvoicesController before_filter must_be_admin def index Invoices.find # specify admin criteria here end end class AssociateInvoices before_filter must_be_associate def index Invoices.find # specify associate criteria here end end Andrew 2009/3/3 Zach Dennis > On Tue, Mar 3, 2009 at 12:32 PM, Pat Maddox wrote: > > On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote: > >> On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis > wrote: > >>> > >>> Forgot to mention what we did do. We ended up with the following... > >>> > >>> def index > >>> if user.has_role?("admin") > >>> user.in_role("admin").invoices > >>> elsif user.has_role?("associate") > >>> user.in_role("associate").invoices > >>> else > >>> raise AccessDenied > >>> end > >>> end > >> > >> That seems sort of backwards to me. These aren't the user's invoices, > >> right? They're just invoices which the user happens to be allowed to > >> see? Chaining it this way makes it look like the invoices *belong* to > >> the role, and seems put the user up front instead of the invoices. > >> You also have conditional branching with hardcoded values, making the > >> controller brittle, and some redundancy with the controller asking the > >> model for a value and then passing the value right back to the model. > > > > Agreed. I have a similar example in a blog post: > > > http://www.patmaddox.com/blog/2008/7/23/when-duplication-in-tests-informs-design > > I agree I'm taking a step back to try to make two steps forward. The > heart of the exploration is more than the conditional in the action > (which simply states which roles are allowed to access that action, I > just made it explicit rather than using a #restrict_to call). To me > this discussion is about where the behaviour for a role should go and > how-to access that behaviour. > > The flip side of this is that models end up with redundant conditional > branches to do x for RoleA or y for RoleB (for every model thats > affected by a Role). I would like to collapse these conditional > branches and attempt a more polymorphic approach by extracting a class > representative of each role, and simply calling the method in > question. e.g: > > FiscalAssociate.new(user).invoices > FiscalAdmin.new(user).invoices > > Rather than the following approach. Keep in mind that roles hardly > ever are limited to one model. Consider having the case statement in > 20 models. Where's the redundancy now? > > Invoice.by_role() > > def by_role(role > case role > when "associate" > .... > when "admin" > ... > end > > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Tue Mar 3 14:43:32 2009 From: rdm at cfcl.com (Rich Morin) Date: Tue, 3 Mar 2009 11:43:32 -0800 Subject: [rspec-users] Gherkin syntax notes (WIP) Message-ID: I made a start on some Gherkin syntax notes: http://wiki.github.com/aslakhellesoy/cucumber/gherkin Please look them over, fix errors, and/or send me a note about things I've missed or gotten wrong... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From pat.maddox at gmail.com Tue Mar 3 19:41:11 2009 From: pat.maddox at gmail.com (Pat Maddox) Date: Tue, 3 Mar 2009 16:41:11 -0800 Subject: [rspec-users] Cucumber for large projects In-Reply-To: <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> Message-ID: <2c7e61990903031641v5873a6dfqe344b7a0ae2fa494@mail.gmail.com> On Tue, Mar 3, 2009 at 2:06 AM, aidy lewis wrote: > Hi Matt/Dan > > 2009/3/2 Matt Wynne : > >> At the moment, IMO, the tools for feeding back the features to non-technical >> people are pretty immature. My colleague Dan Lucraft wrote a tool which >> produces a nicely-formatted PDF document from your features folder[1] which >> is great, but won't work with the new version (0.2) of Cucumber when it's >> released as the API against which such formatters are written has undergone >> some significant changes for the new version. >> > >> [1]http://www.daniellucraft.com/blog/2009/01/features_report/ > > To me the user\customer should be involved in the creation of the > stories and the acceptance criteria and by producing a pdf later in > the cycle for those stakeholders to read and understand may be argued > as something that is not Story-Driven-Development and more like > comprehendible automated tests. Not quite. Some customers don't want to sit down next to you as you write the stories. In that situation, we'll talk about features, I take notes, then I write up the features and ship them via email or wiki. They're still involved in the creation of stories and acceptance criteria, they're just not present when those criteria get entered into cucumber features. Pat From rdm at cfcl.com Tue Mar 3 20:51:33 2009 From: rdm at cfcl.com (Rich Morin) Date: Tue, 3 Mar 2009 17:51:33 -0800 Subject: [rspec-users] Cucumber for large projects In-Reply-To: <2c7e61990903031641v5873a6dfqe344b7a0ae2fa494@mail.gmail.com> References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> <2c7e61990903031641v5873a6dfqe344b7a0ae2fa494@mail.gmail.com> Message-ID: At 16:41 -0800 3/3/09, Pat Maddox wrote: > Not quite. Some customers don't want to sit down next to you as you > write the stories. In that situation, we'll talk about features, I > take notes, then I write up the features and ship them via email or > wiki. They're still involved in the creation of stories and > acceptance criteria, they're just not present when those criteria get > entered into cucumber features. In the Ontiki project, I am acting as my own initial customer and the primary customers (for at least a while) will be Ruby programmers. So, I'm playing with the use of a pre-processor which allows use of eRuby (for selection, repetition, and variable substitution), line folding, etc. This DRYs out my editable files (fe/*.fe), while generating readable and Gherkin-compliant feature (*.feature) files. This would not work well for a highly interactive situation, but it might work in a situation like the one you describe. It may also give us some useful feedback about useful extensions for Gherkin. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From rem.gagnon at gmail.com Tue Mar 3 21:21:34 2009 From: rem.gagnon at gmail.com (Remi Gagnon) Date: Tue, 3 Mar 2009 21:21:34 -0500 Subject: [rspec-users] Cucumber for large projects In-Reply-To: References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> <2c7e61990903031641v5873a6dfqe344b7a0ae2fa494@mail.gmail.com> Message-ID: Let me share my experience. On my side we do produce 3 documents before starting with rspec. 1- A web designer creates a design for a screen in conjunction with the marketing team and the analyst assigned to the this feature. The marketing dep, acts as the customer. 2-The analyst produce a "word" document containing the stories and scenarios attached to this screen. This work is done again in conjunction with the web designer cause she is also an ergonomist and the Marketing dep. The analyst has to have the approval of these stories-scenarios before he can share this info to the ruby programmers. 3- The analyst produce also a little spreadsheet defining all labels, fields and any specifities of the screen to eleminates any "second guess" of the ruby dev. As soon the ruby dep got those docs they start creating specs for this. For now we are not using cucumber yet. It is already a huge challenge for me to convience legacy programmers to learn ruby, rails OOP in the BDD way. In short term I plan to experience it. For now we are not having any tool to transfer stories-scenarios from our word doc to rspec file. If any of you have something for that, let me know. R?mi Gagnon On Tue, Mar 3, 2009 at 8:51 PM, Rich Morin wrote: > At 16:41 -0800 3/3/09, Pat Maddox wrote: > > Not quite. Some customers don't want to sit down next to you as you > > write the stories. In that situation, we'll talk about features, I > > take notes, then I write up the features and ship them via email or > > wiki. They're still involved in the creation of stories and > > acceptance criteria, they're just not present when those criteria get > > entered into cucumber features. > > In the Ontiki project, I am acting as my own initial customer and the > primary customers (for at least a while) will be Ruby programmers. So, > I'm playing with the use of a pre-processor which allows use of eRuby > (for selection, repetition, and variable substitution), line folding, > etc. This DRYs out my editable files (fe/*.fe), while generating > readable and Gherkin-compliant feature (*.feature) files. > > This would not work well for a highly interactive situation, but it > might work in a situation like the one you describe. It may also give > us some useful feedback about useful extensions for Gherkin. > > -r > -- > http://www.cfcl.com/rdm Rich Morin > http://www.cfcl.com/rdm/resume rdm at cfcl.com > http://www.cfcl.com/rdm/weblog +1 650-873-7841 > > Technical editing and writing, programming, and web development > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apremdas at gmail.com Tue Mar 3 23:30:23 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Wed, 4 Mar 2009 04:30:23 +0000 Subject: [rspec-users] Sinitra and Cucumber In-Reply-To: References: <88fd8ddc0902152239v1c96d9a0o4c3b607f9dbaf529@mail.gmail.com> <620c6d021a378669605b46bce1c93dd6@ruby-forum.com> <8d961d900902260450i344cddbey8d0381b104ba1731@mail.gmail.com> Message-ID: <88fd8ddc0903032030n54779266k14492d81399efa27@mail.gmail.com> With Cuc and Rails I'd be able to debug step definitions by putting 'debugger' in the relevant step definition. With Sinatra configured as above this doesn't work. Any tips on making this work and/or explaining whats different/ Cheers Andrew 2009/2/27 Aslak Helles?y > > > Aslak Helles?y wrote: >> >>> Rob Holland updated the wiki yesterday: >>> http://wiki.github.com/aslakhellesoy/cucumber/sinatra >>> (He reports that the $0 trick described in the blog doesn't work with >>> the latest Sinatra). >>> Rob also has an example in his fork, which I have yet to merge into my >>> repo: >>> >>> http://github.com/robholland/cucumber/commit/0e12d8100ca8541af014abe6a480c53a90b6aebd >>> >>> > This is now in my master too. > > Aslak > > > Aslak >>> >> >> Thanks, I've updated my blog to reflect. >> >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apremdas at gmail.com Tue Mar 3 23:39:30 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Wed, 4 Mar 2009 04:39:30 +0000 Subject: [rspec-users] Sinitra 0.9.1 Webrat 0.4.2 Cuc problem Message-ID: <88fd8ddc0903032039t4dad780ay628ca56bc57953c4@mail.gmail.com> Have created sample sinatra cucumber app as suggested on wiki. Tried both env.rb configurations from there and aslaks git repo. With this combination of gems I get the following error doing basic cuc tests When I visit '/foo' # features/step_definitions/general.rb:1 PATH_INFO must start with / (Rack::Lint::LintError) /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:16:in `assert' /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:178:in `check_env' /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:39:in `_call' /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:33:in `call' /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/mock.rb:70:in `request' /Library/Ruby/Gems/1.8/gems/sinatra-0.9.1/lib/sinatra/test.rb:41:in `make_request' /Library/Ruby/Gems/1.8/gems/sinatra-0.9.1/lib/sinatra/test.rb:44:in `orig_get' /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/sinatra.rb:26:in `__send__' /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/sinatra.rb:26:in `get' /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/core/session.rb:104:in `send' /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/core/session.rb:104:in `request_page' /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/core/session.rb:205:in `visit' ./features/step_definitions/general.rb:3:in `When /^I visit (.*)$/' features/basic.feature:17:in `When I visit '/foo'' Afraid I can't expand on this as I can't getting debugging working with cuc and sinatra. All best Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfeley at gmail.com Tue Mar 3 23:44:02 2009 From: sfeley at gmail.com (Stephen Eley) Date: Tue, 3 Mar 2009 23:44:02 -0500 Subject: [rspec-users] Cucumber for large projects In-Reply-To: <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> Message-ID: <1fb4df0903032044y4d976c01m9f758851dc31b0a4@mail.gmail.com> On Tue, Mar 3, 2009 at 5:06 AM, aidy lewis wrote: > > To me the user\customer should be involved in the creation of the > stories and the acceptance criteria and by producing a pdf later in > the cycle for those stakeholders to read and understand may be argued > as something that is not Story-Driven-Development and more like > comprehendible automated tests. There's more than one way to skin a ca...a cucumber. In my organization, people are definitely invested in what I intend to build, and we do discuss requirements. But if I tried to tell them, "All right, I need all of us to sit down and write scenarios in a particular text file format for all of our critical path success and failure cases," I would just get blank stares. They wouldn't Get It. And I don't see it as a necessary part of my job to drag everyone else into this culture, if I can just document my best understanding and then show them the results for feedback. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From lists at ruby-forum.com Wed Mar 4 00:35:19 2009 From: lists at ruby-forum.com (Sebastian W.) Date: Wed, 4 Mar 2009 06:35:19 +0100 Subject: [rspec-users] Testing my scripts? Message-ID: <5e257dbc314d72c9770f6aea3e14170d@ruby-forum.com> Hello RSpec mailing list, I have a question which I'm sure someone here has a "duh!" answer to. :P A lot of the Ruby programming I do is around installing servers and automating various tasks. The pattern I use goes as follows, I'm sure you'll see where the gap is. Write a failing test. Write enough Ruby code to make it pass. Continue until I have a class (or set of classes) that solve my problem. So far, so good. I then need to put this code into a script so I can run it as part of everyday automation. My approach so far has been to take green-light code and plug it into the script so that when the script gets run, it takes the arguments to the scripts and passes it to my tested code. The script runs and does what its supposed to do; all is well. Now -- there's a bug in my code somewhere, or I need to add something to the code I've written to improve it. No problem initially. First, run all tests. Green light, good. Write a failing test. Write enough Ruby code to make it pass. Happy, happy. Problem: the code in my script is not fixed! Running my spec suite does not catch the fact that there's client code in my script using bad code. So, my question is: how can I make sure that when I run my spec suite that all the code in my scripts gets tested as well? I thought about adding "--test" option to all my scripts, but that seems, well...just not the right way to do it. Anyone have any words of wisdom they'd like to share? Have I walked into an antipattern here? Thanks much! Sebastian -- Posted via http://www.ruby-forum.com/. From patnakajima at gmail.com Wed Mar 4 00:54:28 2009 From: patnakajima at gmail.com (Pat Nakajima) Date: Wed, 4 Mar 2009 00:54:28 -0500 Subject: [rspec-users] Sinitra 0.9.1 Webrat 0.4.2 Cuc problem In-Reply-To: <88fd8ddc0903032039t4dad780ay628ca56bc57953c4@mail.gmail.com> References: <88fd8ddc0903032039t4dad780ay628ca56bc57953c4@mail.gmail.com> Message-ID: <97ae2db00903032154i1b27180cp544563f1eff4c3@mail.gmail.com> For what it's worth, here's how I had to hack Webrat to get my Sinatra 0.9.1 app working properly: http://gist.github.com/73735. On Tue, Mar 3, 2009 at 11:39 PM, Andrew Premdas wrote: > Have created sample sinatra cucumber app as suggested on wiki. Tried both > env.rb configurations from there and aslaks git repo. With this combination > of gems I get the following error doing basic cuc tests > > When I visit '/foo' # > features/step_definitions/general.rb:1 > PATH_INFO must start with / (Rack::Lint::LintError) > /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:16:in > `assert' > /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:178:in > `check_env' > /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:39:in `_call' > /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/lint.rb:33:in `call' > /Library/Ruby/Gems/1.8/gems/rack-0.9.1/lib/rack/mock.rb:70:in > `request' > /Library/Ruby/Gems/1.8/gems/sinatra-0.9.1/lib/sinatra/test.rb:41:in > `make_request' > /Library/Ruby/Gems/1.8/gems/sinatra-0.9.1/lib/sinatra/test.rb:44:in > `orig_get' > /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/sinatra.rb:26:in > `__send__' > /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/sinatra.rb:26:in > `get' > > /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/core/session.rb:104:in > `send' > > /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/core/session.rb:104:in > `request_page' > > /Library/Ruby/Gems/1.8/gems/webrat-0.4.2/lib/webrat/core/session.rb:205:in > `visit' > ./features/step_definitions/general.rb:3:in `When /^I visit (.*)$/' > features/basic.feature:17:in `When I visit '/foo'' > > > Afraid I can't expand on this as I can't getting debugging working with cuc > and sinatra. > > All best > > Andrew > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Wed Mar 4 00:50:13 2009 From: rdm at cfcl.com (Rich Morin) Date: Tue, 3 Mar 2009 21:50:13 -0800 Subject: [rspec-users] Cucumber for large projects In-Reply-To: References: <2287172B-8A6F-4567-9F83-28990DF5506A@mattwynne.net> <7ac2300c0903030206g45f58270m31fc6e5ae736796c@mail.gmail.com> <2c7e61990903031641v5873a6dfqe344b7a0ae2fa494@mail.gmail.com> Message-ID: At 21:21 -0500 3/3/09, Remi Gagnon wrote: > > For now we are not having any tool to transfer > stories-scenarios from our word doc to rspec file. > If any of you have something for that, let me know. I don't have any software to offer, but I can offer a suggestion regarding process. If the "word" document is a Microsoft Word document, and the format is stable and well-defined, you may be able to have Word export a document in an intermediate format (eg, HTML, XML) that can be parsed and used as input by a mechanized process. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From rob.holland at gmail.com Wed Mar 4 04:33:28 2009 From: rob.holland at gmail.com (Rob Holland) Date: Wed, 4 Mar 2009 09:33:28 +0000 Subject: [rspec-users] Sinitra and Cucumber In-Reply-To: <88fd8ddc0903032030n54779266k14492d81399efa27@mail.gmail.com> References: <88fd8ddc0902152239v1c96d9a0o4c3b607f9dbaf529@mail.gmail.com> <620c6d021a378669605b46bce1c93dd6@ruby-forum.com> <8d961d900902260450i344cddbey8d0381b104ba1731@mail.gmail.com> <88fd8ddc0903032030n54779266k14492d81399efa27@mail.gmail.com> Message-ID: <6ea3a1b80903040133y127b1688j96a477325dd73e4c@mail.gmail.com> On Wed, Mar 4, 2009 at 4:30 AM, Andrew Premdas wrote: > With Cuc and Rails I'd be able to debug step definitions by putting > 'debugger' in the relevant step definition. With Sinatra configured as above > this doesn't work. Any tips on making this work and/or explaining whats > different/ Just use: require 'ruby-debug/debugger' where you'd normally use debugger. The difference is sinatra doesn't load ruby-debug itself. From rob.holland at gmail.com Wed Mar 4 04:43:13 2009 From: rob.holland at gmail.com (Rob Holland) Date: Wed, 4 Mar 2009 09:43:13 +0000 Subject: [rspec-users] Sinitra 0.9.1 Webrat 0.4.2 Cuc problem In-Reply-To: <97ae2db00903032154i1b27180cp544563f1eff4c3@mail.gmail.com> References: <88fd8ddc0903032039t4dad780ay628ca56bc57953c4@mail.gmail.com> <97ae2db00903032154i1b27180cp544563f1eff4c3@mail.gmail.com> Message-ID: <6ea3a1b80903040143v47d4f4fco562baff873b728b4@mail.gmail.com> My application (the one on which the wiki example is based) still runs just fine on 0.9.1, so I don't think it's related to the version change. I think the hacks Pat used are solely to do with getting selenium mode happy. From thibaut.barrere at gmail.com Wed Mar 4 05:35:38 2009 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Wed, 4 Mar 2009 11:35:38 +0100 Subject: [rspec-users] Cucumber - Performance In-Reply-To: <22FA105F-8A20-4CDB-B4EA-22C1BF506397@mattwynne.net> References: <8d961d900901070346k4e452dcfva2edd0123e2ef7c0@mail.gmail.com> <22FA105F-8A20-4CDB-B4EA-22C1BF506397@mattwynne.net> Message-ID: <4a68b8cf0903040235w512cb632odd4a7861be9183c9@mail.gmail.com> > My guess is that it's the initial start-up that's slow. This is a great > reason to use something like autotest, which will keep the process loaded > up. I wonder how that hell you could make that work with C# code though! > Watch the DLLs?! coming late on this one - if this is useful to someone, you can quite easily watch the dll's using the built-in FileSystemWatcher (http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx). cheers, -- Thibaut > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From u.alberton at gmail.com Wed Mar 4 05:54:51 2009 From: u.alberton at gmail.com (Bira) Date: Wed, 4 Mar 2009 07:54:51 -0300 Subject: [rspec-users] Writing specs for AMQP clients. Message-ID: Hello! I've been lurking in the list a while, and now I would like to ask you a somewhat "noobish" question... This is the first time I've run across this particular problem, so I'm not sure what to do. I'm sure this is so common that's in a textbook somewhere, but what is the best way to write specs for code that calls out to an external server? I've just started working on a project that will use AMQP messaging (and the "amqp" gem), and most of the code I've written so far is all about talking to a messaging server. The only alternatives I saw for writing specs were starting said server, and mocking/stubbing out all the code that would talk to it. I went witht he second one, but I feel it's a fragile approach that won't actually allow me to find bugs, since everything is mocked out. What is the best way to do this? -- Bira http://compexplicita.wordpress.com http://compexplicita.tumblr.com From tastapod at gmail.com Wed Mar 4 06:25:24 2009 From: tastapod at gmail.com (Dan North) Date: Wed, 4 Mar 2009 11:25:24 +0000 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: <8d961d900902240510s46f945f9ofb08a003395a139d@mail.gmail.com> References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <824F1590-C31C-44D9-B283-C7C0550F0D84@mattwynne.net> <6ea3a1b80902240130u3d8bcb8dyf46a2945165a776c@mail.gmail.com> <8d961d900902240510s46f945f9ofb08a003395a139d@mail.gmail.com> Message-ID: 2009/2/24 aslak hellesoy > On Tue, Feb 24, 2009 at 10:30 AM, Rob Holland > wrote: > > On Tue, Feb 24, 2009 at 9:17 AM, Matt Wynne wrote: > > > >> You can even use git commit --amend to commit on red (e.g at the end of > the > >> day) and then change that commit later. > > > > While I think commit --amend is very useful, I'm not sure why you'd > > bother to commit at the end of the day, knowing full well you were > > going to amend it first thing tomorrow morning. > > > > Because the longer you wait, the more your code will diverge from your > teammates'. If you don't commit often you rob them of the opportunity > to reduce merge hell. This is the money line for me. There's a lovely CI pattern I've seen in the centralised SCM world (with Java, but that's less important) that I'm surprised hasn't been mentioned. Before I describe it I'd like to take this back to first principles. The point of *continuous* integration is to keep each individual integration small and avoid less frequent *big* integrations, because that's where the pain happens. Syncing up once per story or feature, which could easily be several days work, strikes me as a retrograde step. The fact that DSCMs like git or hg allow you to do this doesn't make it a good thing. There are many fantastic reasons to use DSCM - modelling IBM Rational ClearCase "best practice" usage patterns shouldn't be one of them. Anyhoo, it seems to me the problem we are discussing is the coupling between checking in an unfinished scenario and failing the build. The solution I've seen - scaling to projects with tens of developers and thousands of scenarios - is to separate in-progress features from finished ones, and build everything. If an in-progress scenario fails then the build carries on. If a completed scenario fails it causes the build to fail. There is a nice corollary to this whereby you fail the build if an in-progress scenario accidentally * passes*. This is because you usually want a human to find out why. In cuke-land you would do this at a feature level rather than a scenario level since the convention is to have one feature (with multiple scenarios) per file. Marking a feature as done can be as simple as moving it between two directories (called in-progress and done), renaming the feature (from openid_login.in-progress to openid_login.feature) or having an :in_progresstag on a feature until it's done. In Java-land I prefer the first model because I can point the same junit task at either the in-progress or done directories and just change the failOnError flag. In any case, I would strongly encourage changing the build so you can integrate continuously - i.e. git push as frequently as you normally would - knowing the build will remain clean as long as you mark your unfinished work as in-progress. Lightweight, cheap branches are great for local spikes, exploration of unfamiliar code and any number of other incidental activities, but I'm deeply sceptical that they should form part of your core workflow. No doubt once this becomes the norm and Rational are laughing up their sleeves I'll live to regret saying that :) Aslak Cheers, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Wed Mar 4 08:02:56 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Mar 2009 07:02:56 -0600 Subject: [rspec-users] Writing specs for AMQP clients. In-Reply-To: References: Message-ID: <57c63afe0903040502u66f98051y55d7cfa8f9169c58@mail.gmail.com> On Wed, Mar 4, 2009 at 4:54 AM, Bira wrote: > Hello! > > I've been lurking in the list a while, and now I would like to ask you > a somewhat "noobish" question... This is the first time I've run > across this particular problem, so I'm not sure what to do. I'm sure > this is so common that's in a textbook somewhere, but what is the best > way to write specs for code that calls out to an external server? > > I've just started working on a project that will use AMQP messaging > (and the "amqp" gem), and most of the code I've written so far is all > about talking to a messaging server. The only alternatives I saw for > writing specs were starting said server, and mocking/stubbing out all > the code that would talk to it. I went witht he second one, but I feel > it's a fragile approach that won't actually allow me to find bugs, > since everything is mocked out. What is the best way to do this? I'm not familiar w/ amqp in particular, but one "good" approach is to use mock objects to evolve a protocol for this service in the language of your app, and then write an adapter for amqp with a few system level tests in place to verify happy paths. This approach does a few good things. * Keeps you focused on the business domain while writing the business objects, because you're not sidetracked by the details of messaging. * Keeps the suite of specs running fast * Makes it easy to choose a different messaging API later, because all of the code that depends directly on that API lives in the adapter. HTH, David > > -- > Bira > http://compexplicita.wordpress.com > http://compexplicita.tumblr.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Wed Mar 4 08:08:51 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Mar 2009 07:08:51 -0600 Subject: [rspec-users] Testing my scripts? In-Reply-To: <5e257dbc314d72c9770f6aea3e14170d@ruby-forum.com> References: <5e257dbc314d72c9770f6aea3e14170d@ruby-forum.com> Message-ID: <57c63afe0903040508v111afd16g8762f8415316d835@mail.gmail.com> On Tue, Mar 3, 2009 at 11:35 PM, Sebastian W. wrote: > Hello RSpec mailing list, > I have a question which I'm sure someone here has a "duh!" answer to. :P > > A lot of the Ruby programming I do is around installing servers and > automating various tasks. The pattern I use goes as follows, I'm sure > you'll see where the gap is. > > Write a failing test. Write enough Ruby code to make it pass. Continue > until I have a class (or set of classes) that solve my problem. So far, > so good. > > I then need to put this code into a script so I can run it as part of > everyday automation. My approach so far has been to take green-light > code and plug it into the script so that when the script gets run, it > takes the arguments to the scripts and passes it to my tested code. The > script runs and does what its supposed to do; all is well. > > Now -- there's a bug in my code somewhere, or I need to add something to > the code I've written to improve it. No problem initially. First, run > all tests. Green light, good. Write a failing test. Write enough Ruby > code to make it pass. Happy, happy. > > Problem: the code in my script is not fixed! Running my spec suite does > not catch the fact that there's client code in my script using bad code. > > So, my question is: how can I make sure that when I run my spec suite > that all the code in my scripts gets tested as well? I thought about > adding ?"--test" option to all my scripts, but that seems, well...just > not the right way to do it. > > Anyone have any words of wisdom they'd like to share? Have I walked into > an antipattern here? BDD means (among other things) driving development from the outside-in. It sounds like you're working in the opposite direction here. The approach we'd take with RSpec and Cucumber, would be to write Cucumber features with scenarios that drive the scripts, and then work your way down to RSpec code examples that drive the smaller bits. In case this is new to you, the Cucumber scenarios will fail until you get all of the RSpec code examples to pass. If you get to the point where all of the scenarios are passing, but you feel like you want to drive out more code in the underlying objects, take a step back and think of a new failing scenario you can add to the Cucumber features first. This approach should help you refine the work you're doing on the objects, as well as build confidence that deploying the scripts will work. HTH, David > > Thanks much! > Sebastian > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From patnakajima at gmail.com Wed Mar 4 08:47:21 2009 From: patnakajima at gmail.com (Pat Nakajima) Date: Wed, 4 Mar 2009 08:47:21 -0500 Subject: [rspec-users] Sinitra 0.9.1 Webrat 0.4.2 Cuc problem In-Reply-To: <6ea3a1b80903040143v47d4f4fco562baff873b728b4@mail.gmail.com> References: <88fd8ddc0903032039t4dad780ay628ca56bc57953c4@mail.gmail.com> <97ae2db00903032154i1b27180cp544563f1eff4c3@mail.gmail.com> <6ea3a1b80903040143v47d4f4fco562baff873b728b4@mail.gmail.com> Message-ID: <7A967D15-A777-4314-A5F2-46BC3331F1E8@gmail.com> Rob, Is your Sinatra app using the "classic" style? If so, I think it would work without need for modification. If your app is a class that inherits from Sinatra::Base, you're likely to see issues unless you take the steps in the Gist. Pat On Mar 4, 2009, at 4:43 AM, Rob Holland wrote: > My application (the one on which the wiki example is based) still runs > just fine on 0.9.1, so I don't think it's related to the version > change. > > I think the hacks Pat used are solely to do with getting selenium > mode happy. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From apremdas at gmail.com Wed Mar 4 09:22:51 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Wed, 4 Mar 2009 14:22:51 +0000 Subject: [rspec-users] Sinitra 0.9.1 Webrat 0.4.2 Cuc problem In-Reply-To: <6ea3a1b80903040143v47d4f4fco562baff873b728b4@mail.gmail.com> References: <88fd8ddc0903032039t4dad780ay628ca56bc57953c4@mail.gmail.com> <97ae2db00903032154i1b27180cp544563f1eff4c3@mail.gmail.com> <6ea3a1b80903040143v47d4f4fco562baff873b728b4@mail.gmail.com> Message-ID: <88fd8ddc0903040622g6f68c4deu7400cdbabdd7989c@mail.gmail.com> The app runs fine, its the cucumber tests that don't. If you can point me to your app I'll give it go here. I'm using classic style (just started with Sinatra) 2009/3/4 Rob Holland > My application (the one on which the wiki example is based) still runs > just fine on 0.9.1, so I don't think it's related to the version > change. > > I think the hacks Pat used are solely to do with getting selenium mode > happy. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apremdas at gmail.com Wed Mar 4 09:25:07 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Wed, 4 Mar 2009 14:25:07 +0000 Subject: [rspec-users] Sinitra and Cucumber In-Reply-To: <6ea3a1b80903040133y127b1688j96a477325dd73e4c@mail.gmail.com> References: <88fd8ddc0902152239v1c96d9a0o4c3b607f9dbaf529@mail.gmail.com> <620c6d021a378669605b46bce1c93dd6@ruby-forum.com> <8d961d900902260450i344cddbey8d0381b104ba1731@mail.gmail.com> <88fd8ddc0903032030n54779266k14492d81399efa27@mail.gmail.com> <6ea3a1b80903040133y127b1688j96a477325dd73e4c@mail.gmail.com> Message-ID: <88fd8ddc0903040625n41563f44m485edd744edcc035@mail.gmail.com> Thanks alot - works a treat :) 2009/3/4 Rob Holland > On Wed, Mar 4, 2009 at 4:30 AM, Andrew Premdas wrote: > > With Cuc and Rails I'd be able to debug step definitions by putting > > 'debugger' in the relevant step definition. With Sinatra configured as > above > > this doesn't work. Any tips on making this work and/or explaining whats > > different/ > > Just use: require 'ruby-debug/debugger' where you'd normally use debugger. > > The difference is sinatra doesn't load ruby-debug itself. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apremdas at gmail.com Wed Mar 4 09:39:10 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Wed, 4 Mar 2009 14:39:10 +0000 Subject: [rspec-users] Sinitra 0.9.1 Webrat 0.4.2 Cuc problem In-Reply-To: <88fd8ddc0903040622g6f68c4deu7400cdbabdd7989c@mail.gmail.com> References: <88fd8ddc0903032039t4dad780ay628ca56bc57953c4@mail.gmail.com> <97ae2db00903032154i1b27180cp544563f1eff4c3@mail.gmail.com> <6ea3a1b80903040143v47d4f4fco562baff873b728b4@mail.gmail.com> <88fd8ddc0903040622g6f68c4deu7400cdbabdd7989c@mail.gmail.com> Message-ID: <88fd8ddc0903040639p6ce8e218h687f7b185a904543@mail.gmail.com> Apologies - false alarm - problem was with my step-definition all best Andrew 2009/3/4 Andrew Premdas > The app runs fine, its the cucumber tests that don't. If you can point me > to your app I'll give it go here. > > I'm using classic style (just started with Sinatra) > > 2009/3/4 Rob Holland > > My application (the one on which the wiki example is based) still runs >> just fine on 0.9.1, so I don't think it's related to the version >> change. >> >> I think the hacks Pat used are solely to do with getting selenium mode >> happy. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at benmabey.com Wed Mar 4 11:27:20 2009 From: ben at benmabey.com (Ben Mabey) Date: Wed, 04 Mar 2009 09:27:20 -0700 Subject: [rspec-users] Writing specs for AMQP clients. In-Reply-To: <57c63afe0903040502u66f98051y55d7cfa8f9169c58@mail.gmail.com> References: <57c63afe0903040502u66f98051y55d7cfa8f9169c58@mail.gmail.com> Message-ID: <49AEABE8.8090602@benmabey.com> David Chelimsky wrote: > On Wed, Mar 4, 2009 at 4:54 AM, Bira wrote: > >> Hello! >> >> I've been lurking in the list a while, and now I would like to ask you >> a somewhat "noobish" question... This is the first time I've run >> across this particular problem, so I'm not sure what to do. I'm sure >> this is so common that's in a textbook somewhere, but what is the best >> way to write specs for code that calls out to an external server? >> >> I've just started working on a project that will use AMQP messaging >> (and the "amqp" gem), and most of the code I've written so far is all >> about talking to a messaging server. The only alternatives I saw for >> writing specs were starting said server, and mocking/stubbing out all >> the code that would talk to it. I went witht he second one, but I feel >> it's a fragile approach that won't actually allow me to find bugs, >> since everything is mocked out. What is the best way to do this? >> > > I'm not familiar w/ amqp in particular, but one "good" approach is to > use mock objects to evolve a protocol for this service in the language > of your app, and then write an adapter for amqp with a few system > level tests in place to verify happy paths. > > This approach does a few good things. > > * Keeps you focused on the business domain while writing the business > objects, because you're not sidetracked by the details of messaging. > * Keeps the suite of specs running fast > * Makes it easy to choose a different messaging API later, because all > of the code that depends directly on that API lives in the adapter. > > HTH, > David > > > Bria, In the past, I have done exactly as David has suggested. I have my cucumber features use the actual messaging system to verify that everything is hooked up and is working correctly. I then use a combination of null and fake adapters in my specs to keep them fast and focused on testing the object's responsibility. Doing this required that an adapter layer be introduced. The nice thing about this, as David also points out, is that you can then easily swap out another messaging system by simply writing a new adapter. I have actually open soured my efforts (and my coworker's, Chris Wyckoff) so you can use, or at least get ideas from, the library here: https://github.com/bmabey/rosetta_queue/tree You can use currently use the library with messaging systems that speak AMQP or stomp. Additionally, I have blogged about how we used Cucumber and this library to integrate our distributed systems: http://www.benmabey.com/2009/02/17/using-cucumber-to-integrate-distributed-systems-and-test-messaging/ HTH, Ben From nick at ekenosen.net Wed Mar 4 12:04:54 2009 From: nick at ekenosen.net (nicholas a. evans) Date: Wed, 4 Mar 2009 12:04:54 -0500 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <824F1590-C31C-44D9-B283-C7C0550F0D84@mattwynne.net> <6ea3a1b80902240130u3d8bcb8dyf46a2945165a776c@mail.gmail.com> <8d961d900902240510s46f945f9ofb08a003395a139d@mail.gmail.com> Message-ID: <276ff9870903040904v71f15635rb3f07c1c2508d871@mail.gmail.com> On Wed, Mar 4, 2009 at 6:25 AM, Dan North wrote: > Marking a feature as done can be as simple as moving it between two > directories (called in-progress and done), renaming the feature (from > openid_login.in-progress to openid_login.feature) or having an :in_progress > tag on a feature until it's done. I started out with using an in-process directory, but now I prefer to use a pending step: Given ... And ... And the rest of this scenario is pending: see ticket number #1234, in progress (2009.03.04) When I ... And ... Then ... That way, the build won't break even if some of the steps have already been implemented (e.g. for other scenarios), and I can organize my scenarios according to their final destination (dir and feature file), without needing to worry as much about current status. But I do need to make sure I insert the appropriate "pending" steps prior to "svn commit" / "bzr push", -- Nick From matt at mattwynne.net Wed Mar 4 12:09:39 2009 From: matt at mattwynne.net (Matt Wynne) Date: Wed, 4 Mar 2009 17:09:39 +0000 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <824F1590-C31C-44D9-B283-C7C0550F0D84@mattwynne.net> <6ea3a1b80902240130u3d8bcb8dyf46a2945165a776c@mail.gmail.com> <8d961d900902240510s46f945f9ofb08a003395a139d@mail.gmail.com> Message-ID: On 4 Mar 2009, at 11:25, Dan North wrote: > 2009/2/24 aslak hellesoy > On Tue, Feb 24, 2009 at 10:30 AM, Rob Holland > wrote: > > On Tue, Feb 24, 2009 at 9:17 AM, Matt Wynne > wrote: > > > >> You can even use git commit --amend to commit on red (e.g at the > end of the > >> day) and then change that commit later. > > > > While I think commit --amend is very useful, I'm not sure why you'd > > bother to commit at the end of the day, knowing full well you were > > going to amend it first thing tomorrow morning. > > > > Because the longer you wait, the more your code will diverge from your > teammates'. If you don't commit often you rob them of the opportunity > to reduce merge hell. > > This is the money line for me. > > There's a lovely CI pattern I've seen in the centralised SCM world > (with Java, but that's less important) that I'm surprised hasn't > been mentioned. Before I describe it I'd like to take this back to > first principles. > > The point of continuous integration is to keep each individual > integration small and avoid less frequent big integrations, because > that's where the pain happens. Syncing up once per story or feature, > which could easily be several days work, strikes me as a retrograde > step. The fact that DSCMs like git or hg allow you to do this > doesn't make it a good thing. There are many fantastic reasons to > use DSCM - modelling IBM Rational ClearCase "best practice" usage > patterns shouldn't be one of them. > > Anyhoo, it seems to me the problem we are discussing is the coupling > between checking in an unfinished scenario and failing the build. > The solution I've seen - scaling to projects with tens of developers > and thousands of scenarios - is to separate in-progress features > from finished ones, and build everything. > > If an in-progress scenario fails then the build carries on. If a > completed scenario fails it causes the build to fail. There is a > nice corollary to this whereby you fail the build if an in-progress > scenario accidentally passes. This is because you usually want a > human to find out why. In cuke-land you would do this at a feature > level rather than a scenario level since the convention is to have > one feature (with multiple scenarios) per file. > > Marking a feature as done can be as simple as moving it between two > directories (called in-progress and done), renaming the feature > (from openid_login.in-progress to openid_login.feature) or having > an :in_progress tag on a feature until it's done. > > In Java-land I prefer the first model because I can point the same > junit task at either the in-progress or done directories and just > change the failOnError flag. Thanks for your thoughts, Dan. Cucumber 0.2 tags are ideal for this sort of filtering. I'm going to look at adding a 'two tier' feature run to our build. Matt Wynne http://blog.mattwynne.net http://www.songkick.com From lists at ruby-forum.com Wed Mar 4 12:16:29 2009 From: lists at ruby-forum.com (James Byrne) Date: Wed, 4 Mar 2009 18:16:29 +0100 Subject: [rspec-users] OT: AR Default Values Message-ID: <6ec7f496f43a7c6085465ef3c738d329@ruby-forum.com> This is sort of off topic but it arose from a cucumber test failure and I am unsure how to address the underlying issue. I spent yesterday tracking down an obscure error that was exposed by a new cucumber test. It turned out to be an improper default value assignment made in a controller which in turn proved dependent upon recent changes (Rails 2.2) made in how AR handles timezones. It also turned out that the same error was made in another controller handling that same model. This led me to consider that the place to handle AR default values really should be somewhere else and the logical places are either in the model or in the DBMS schema. The problem with the latter is that Rails migrations provide no accommodation for dynamic defaults like the current time, other than by recourse to explicit SQL. In any case, a DBMS provided default value is not going to be available to a view until after the new row is INSERTed and subsequently SELECTEed, which is too late to be of any use in the presentation of a "new"/"create" resource pair. Thus, I considered it best to handle this requirement in the model. There is a vast amount of information on this subject but it appears, to me, inconsistent and the issue unresolved. The obvious answer is to override the initializer method. However, there are several warnings that basically say that for AR this is NOT A GOOD IDEA! There are a few references that indicate AR may not actually call #new in every case. There is also the matter of interpretation of what new actually means to an ORM. A new model instance is not always the same thing as a new DBMS "row". There are references to using the :after_initialize callback. However, after_initialize is called on every row instantiation whereas a default value only applies on a new DBMS instance. This is an old topic for the rails core team: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/b509a2fe2b62ac5 So, after confusing myself thoroughly, I have to ask: How do people here handle dynamic default values? Do leave these instructions in the controllers or is there an accepted technique for moving this code into the model? If there is then what is it? I ran across this in my research: http://m.onkey.org/2007/7/24/how-to-set-default-values-in-your-model But this is not what one would describe as self documenting code. -- Posted via http://www.ruby-forum.com/. From hayafirst at gmail.com Wed Mar 4 12:31:28 2009 From: hayafirst at gmail.com (Yi) Date: Wed, 4 Mar 2009 11:31:28 -0600 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <824F1590-C31C-44D9-B283-C7C0550F0D84@mattwynne.net> <6ea3a1b80902240130u3d8bcb8dyf46a2945165a776c@mail.gmail.com> <8d961d900902240510s46f945f9ofb08a003395a139d@mail.gmail.com> Message-ID: Great writing. Thanks On Wed, Mar 4, 2009 at 5:25 AM, Dan North wrote: > 2009/2/24 aslak hellesoy > >> On Tue, Feb 24, 2009 at 10:30 AM, Rob Holland >> wrote: >> > On Tue, Feb 24, 2009 at 9:17 AM, Matt Wynne wrote: >> > >> >> You can even use git commit --amend to commit on red (e.g at the end of >> the >> >> day) and then change that commit later. >> > >> > While I think commit --amend is very useful, I'm not sure why you'd >> > bother to commit at the end of the day, knowing full well you were >> > going to amend it first thing tomorrow morning. >> > >> >> Because the longer you wait, the more your code will diverge from your >> teammates'. If you don't commit often you rob them of the opportunity >> to reduce merge hell. > > > This is the money line for me. > > There's a lovely CI pattern I've seen in the centralised SCM world (with > Java, but that's less important) that I'm surprised hasn't been mentioned. > Before I describe it I'd like to take this back to first principles. > > The point of *continuous* integration is to keep each individual > integration small and avoid less frequent *big* integrations, because > that's where the pain happens. Syncing up once per story or feature, which > could easily be several days work, strikes me as a retrograde step. The fact > that DSCMs like git or hg allow you to do this doesn't make it a good thing. > There are many fantastic reasons to use DSCM - modelling IBM Rational > ClearCase "best practice" usage patterns shouldn't be one of them. > > Anyhoo, it seems to me the problem we are discussing is the coupling > between checking in an unfinished scenario and failing the build. The > solution I've seen - scaling to projects with tens of developers and > thousands of scenarios - is to separate in-progress features from finished > ones, and build everything. > > If an in-progress scenario fails then the build carries on. If a completed > scenario fails it causes the build to fail. There is a nice corollary to > this whereby you fail the build if an in-progress scenario accidentally * > passes*. This is because you usually want a human to find out why. In > cuke-land you would do this at a feature level rather than a scenario level > since the convention is to have one feature (with multiple scenarios) per > file. > > Marking a feature as done can be as simple as moving it between two > directories (called in-progress and done), renaming the feature (from > openid_login.in-progress to openid_login.feature) or having an > :in_progress tag on a feature until it's done. > > In Java-land I prefer the first model because I can point the same junit > task at either the in-progress or done directories and just change the > failOnError flag. > > In any case, I would strongly encourage changing the build so you can > integrate continuously - i.e. git push as frequently as you normally would - > knowing the build will remain clean as long as you mark your unfinished work > as in-progress. Lightweight, cheap branches are great for local spikes, > exploration of unfamiliar code and any number of other incidental > activities, but I'm deeply sceptical that they should form part of your core > workflow. > > No doubt once this becomes the norm and Rational are laughing up their > sleeves I'll live to regret saying that :) > > > Aslak > > > Cheers, > Dan > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From u.alberton at gmail.com Wed Mar 4 12:37:16 2009 From: u.alberton at gmail.com (Bira) Date: Wed, 4 Mar 2009 14:37:16 -0300 Subject: [rspec-users] Writing specs for AMQP clients. In-Reply-To: <49AEABE8.8090602@benmabey.com> References: <57c63afe0903040502u66f98051y55d7cfa8f9169c58@mail.gmail.com> <49AEABE8.8090602@benmabey.com> Message-ID: David and Ben, Thank you very much for your advice :). -- Bira http://compexplicita.wordpress.com http://compexplicita.tumblr.com From lists at ruby-forum.com Wed Mar 4 12:46:23 2009 From: lists at ruby-forum.com (Sebastian W.) Date: Wed, 4 Mar 2009 18:46:23 +0100 Subject: [rspec-users] Testing my scripts? In-Reply-To: <57c63afe0903040508v111afd16g8762f8415316d835@mail.gmail.com> References: <5e257dbc314d72c9770f6aea3e14170d@ruby-forum.com> <57c63afe0903040508v111afd16g8762f8415316d835@mail.gmail.com> Message-ID: <09fb36729014dc7fb191fb6e4b39b449@ruby-forum.com> Hi David, I think I see what you're saying, but I admit I'm still a bit confused. Maybe I'm missing something here, but I can't think of how I would drive the scripts (even through Cucumber) without actually invoking them, thus kicking off processes that I don't want. Real code to illustrate my thought process: #test.rb class Test def test true end end #test_spec.rb describe Test it "should test" Test.new.test.should be(true) end end #my_script_using_test.rb require 'test' Test.new.test Even if I invoke my "script" through Cucumber, it's still going to fire, no? I think perhaps I am just missing the point altogether. :) Thank you, Sebastian -- Posted via http://www.ruby-forum.com/. From scott at railsnewbie.com Wed Mar 4 14:13:41 2009 From: scott at railsnewbie.com (Scott Taylor) Date: Wed, 4 Mar 2009 14:13:41 -0500 Subject: [rspec-users] OT: AR Default Values In-Reply-To: <6ec7f496f43a7c6085465ef3c738d329@ruby-forum.com> References: <6ec7f496f43a7c6085465ef3c738d329@ruby-forum.com> Message-ID: <32093C1D-CCFE-4F2B-B6D3-0869069FCFFD@railsnewbie.com> On Mar 4, 2009, at 12:16 PM, James Byrne wrote: > This is sort of off topic but it arose from a cucumber test failure > and > I am unsure how to address the underlying issue. > > I spent yesterday tracking down an obscure error that was exposed by a > new cucumber test. It turned out to be an improper default value > assignment made in a controller which in turn proved dependent upon > recent changes (Rails 2.2) made in how AR handles timezones. It also > turned out that the same error was made in another controller handling > that same model. > > This led me to consider that the place to handle AR default values > really should be somewhere else and the logical places are either in > the > model or in the DBMS schema. The problem with the latter is that > Rails > migrations provide no accommodation for dynamic defaults like the > current time, other than by recourse to explicit SQL. In any case, a > DBMS provided default value is not going to be available to a view > until > after the new row is INSERTed and subsequently SELECTEed, which is too > late to be of any use in the presentation of a "new"/"create" resource > pair. > > Thus, I considered it best to handle this requirement in the model. > There is a vast amount of information on this subject but it > appears, to > me, inconsistent and the issue unresolved. The obvious answer is to > override the initializer method. However, there are several warnings > that basically say that for AR this is NOT A GOOD IDEA! There are a > few > references that indicate AR may not actually call #new in every case. > There is also the matter of interpretation of what new actually > means to > an ORM. A new model instance is not always the same thing as a new > DBMS > "row". > > There are references to using the :after_initialize callback. > However, > after_initialize is called on every row instantiation whereas a > default > value only applies on a new DBMS instance. This is an old topic for > the > rails core team: > > http://groups.google.com/group/rubyonrails-core/browse_thread/thread/b509a2fe2b62ac5 > > So, after confusing myself thoroughly, I have to ask: How do people > here > handle dynamic default values? Do leave these instructions in the > controllers or is there an accepted technique for moving this code > into > the model? If there is then what is it? I ran across this in my > research: > > http://m.onkey.org/2007/7/24/how-to-set-default-values-in-your-model > > But this is not what one would describe as self documenting code. You could try this plugin: http://github.com/aussiegeek/active_record_defaults/tree/master Scott > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Wed Mar 4 14:58:50 2009 From: lists at ruby-forum.com (James Byrne) Date: Wed, 4 Mar 2009 20:58:50 +0100 Subject: [rspec-users] OT: AR Default Values In-Reply-To: <32093C1D-CCFE-4F2B-B6D3-0869069FCFFD@railsnewbie.com> References: <6ec7f496f43a7c6085465ef3c738d329@ruby-forum.com> <32093C1D-CCFE-4F2B-B6D3-0869069FCFFD@railsnewbie.com> Message-ID: <36c7a89533c59fc78edb2fd5f07d43fc@ruby-forum.com> Scott Taylor wrote: > You could try this plugin: > > http://github.com/aussiegeek/active_record_defaults/tree/master > > Scott Thanks, I will try this out. -- Posted via http://www.ruby-forum.com/. From apsmith at aps.org Wed Mar 4 14:57:19 2009 From: apsmith at aps.org (Arthur Smith) Date: Wed, 04 Mar 2009 14:57:19 -0500 Subject: [rspec-users] ArgumentError mystery with jruby/rspec-1.1.11 In-Reply-To: <4DD7A591-4B03-4407-911F-512D5FCB1293@aps.org> References: <4DD7A591-4B03-4407-911F-512D5FCB1293@aps.org> Message-ID: <49AEDD1F.6020600@aps.org> We've seen this behavior again, this time with rspec-1.1.12 and jruby 1.2.0RC1; the common factors seem to be: (1) jruby (2) rspec 1.1.11 or 1.1.12 (3) naming a java class with the string 'context' or 'Context' in its name. In this case the bit of ruby causing trouble was: SecurityContextHolder = Java::org.acegisecurity.context.SecurityContextHolder And running 'jruby script/spec -b ...' gave: ArgumentError in 'ManuscriptPublishedController check_unauthorized should respond with unauthorized for create if user does not have privilege' ArgumentError [...]/jruby-1.2.0RC1/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/example/example_group_factory.rb:54:in `create_example_group' [...]/jruby-1.2.0RC1/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/dsl/main.rb:25:in `describe' [...] Replacing the above SecurityContextHolder definition with an import: import 'org.acegisecurity.context.SecurityContextHolder' fixed the errors. Any explanations out there? Arthur Smith Lenny Marks wrote: > I just got bitten by a strange issue with rspec-1.1.11 and jruby > 1.1.3-1.1.6RC1. I'd love to know what the problem was if anyone has > any ideas. It's almost as if, rspec didn't like something about this > particular class since substituting others worked fine. It does work > with Rspec edge so I guess its not too important. Hopefully if anyone > else runs into this they'll hit upon this. > > -lenny > > # reproduce.rb > > require './spring.jar' > > describe "test with spring" do > > it "should not raise ArgumentError" do > > Java::org.springframework.context.support.ClassPathXmlApplicationContext > # line 7 > end > > end > > > jruby-1.1.3/bin/jruby -v -S spec -v > jruby 1.1.3 (ruby 1.8.6 patchlevel 114) (2008-12-08 rev 6586) > [x86_64-java] > rspec 1.1.11 > > > > jruby-1.1.3/bin/jruby -S spec -fs -b reproduce.rb > > test with spring > - should not raise ArgumentError (ERROR - 1) > > 1) > ArgumentError in 'test with spring should not raise ArgumentError' > ArgumentError > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/extensions/main.rb:23:in > `describe' > /home/jis/compsvc/lenny/tmp/x/./reproduce.rb:7: > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_methods.rb:81:in > `instance_eval' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_methods.rb:81:in > `eval_block' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_methods.rb:15:in > `execute' > /Users/Shared/eds_test/share/jruby-1.1.3/lib/ruby/1.8/timeout.rb:48:in > `timeout' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_methods.rb:12:in > `execute' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_group_methods.rb:245:in > `execute_examples' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_group_methods.rb:244:in > `each' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_group_methods.rb:244:in > `execute_examples' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/example/example_group_methods.rb:141:in > `run' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/runner/example_group_runner.rb:22:in > `run' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/runner/example_group_runner.rb:21:in > `each' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/runner/example_group_runner.rb:21:in > `run' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/runner/options.rb:115:in > `run_examples' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/lib/spec/runner/command_line.rb:10:in > `run' > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/bin/spec:4: > /Users/Shared/RubyGems/1.8/gems/rspec-1.1.11/bin/spec:19:in `load' > /Users/Shared/eds_test/share/jruby-1.1.3/bin/spec:19: > > > /jruby-1.1.3/bin/jruby -v rspec/bin/spec -v > jruby 1.1.3 (ruby 1.8.6 patchlevel 114) (2008-12-08 rev 6586) > [x86_64-java] > rspec 1.1.11.1 > > > jruby-1.1.3/bin/jruby rspec/bin/spec -fs reproduce.rb > > test with spring > - should not raise ArgumentError > > Finished in 0.329 seconds > > 1 example, 0 failures > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > From pezlists at gmail.com Wed Mar 4 23:38:08 2009 From: pezlists at gmail.com (Perryn Fowler) Date: Thu, 5 Mar 2009 15:38:08 +1100 Subject: [rspec-users] Can I construct the controller myself in a controller spec? Message-ID: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> Hi I am experimenting with Constructor based dependency injection for rails controllers. So I have something like this class LoginSessionsController < ApplicationController def initialize(authenticator = TheRealAuthenticator) @authenticator = authenticator end .... end The plan was to override the authenticator used when testing with something like describe LoginSessionsController.new(MyMockAuthenticator) do ...... end but rspec seems to insist on constructing the controller itself Is there a way to do this I am missing? From dchelimsky at gmail.com Thu Mar 5 01:02:39 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 00:02:39 -0600 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> Message-ID: <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> On Wed, Mar 4, 2009 at 10:38 PM, Perryn Fowler wrote: > Hi > > I am experimenting with Constructor based dependency injection for > rails controllers. > > So I have something like this > > class LoginSessionsController < ApplicationController > > ?def initialize(authenticator = ?TheRealAuthenticator) > ? ?@authenticator = authenticator > ?end > > ?.... > end > > > The plan was to override the authenticator used when testing with something like > > describe LoginSessionsController.new(MyMockAuthenticator) do > ? ...... > end > > but rspec seems to insist on constructing the controller itself No, Rails insists upon constructing the controller itself. rspec-rails just wraps rails' testing framework. I'd much rather be constructing the objects myself. As for DI, there is a wealth of discussion about DI in Ruby in various user lists - general consensus is don't do it. I concur. You don't need it. You might be particularly interested in http://rubyconf2008.confreaks.com/recovering-from-enterprise.html, in which Jamis Buck, who authored a DI library for Ruby named needle, explains why that was unnecessary. But even if you disagree, you're kinda stuck here because Rails wants to construct the controllers for us. HTH, David > > Is there a way to do this I am missing? > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From pat.maddox at gmail.com Thu Mar 5 01:47:00 2009 From: pat.maddox at gmail.com (Pat Maddox) Date: Wed, 4 Mar 2009 22:47:00 -0800 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> Message-ID: <2c7e61990903042247j5bf67c2cra53c2b1f6529adcb@mail.gmail.com> On Wed, Mar 4, 2009 at 8:38 PM, Perryn Fowler wrote: > Hi > > I am experimenting with Constructor based dependency injection for > rails controllers. > > So I have something like this > > class LoginSessionsController < ApplicationController > > ?def initialize(authenticator = ?TheRealAuthenticator) > ? ?@authenticator = authenticator > ?end > > ?.... > end > > > The plan was to override the authenticator used when testing with something like > > describe LoginSessionsController.new(MyMockAuthenticator) do > ? ...... > end > > but rspec seems to insist on constructing the controller itself > > Is there a way to do this I am missing? > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > It'd be badass, but, basically, no. Instantiating a controller in Rails takes a lot of work - request/response objects, routes, and the code that does so is a big mess. You could use factory methods, and then stub that method in your examples: class LoginSessionsController < ApplicationController def authenticator TheRealAuthenticator end end describe LoginSessionsController do before(:each) do controller.stub!(:authenticator).and_return MockAuthenticator end end Pat From matt at mattwynne.net Thu Mar 5 04:31:42 2009 From: matt at mattwynne.net (Matt Wynne) Date: Thu, 5 Mar 2009 09:31:42 +0000 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> Message-ID: <011E39CE-1EF6-4E7E-A215-0995FC1A28A8@mattwynne.net> On 5 Mar 2009, at 06:02, David Chelimsky wrote: > On Wed, Mar 4, 2009 at 10:38 PM, Perryn Fowler > wrote: >> Hi >> >> I am experimenting with Constructor based dependency injection for >> rails controllers. >> >> So I have something like this >> >> class LoginSessionsController < ApplicationController >> >> def initialize(authenticator = TheRealAuthenticator) >> @authenticator = authenticator >> end >> >> .... >> end >> >> >> The plan was to override the authenticator used when testing with >> something like >> >> describe LoginSessionsController.new(MyMockAuthenticator) do >> ...... >> end >> >> but rspec seems to insist on constructing the controller itself > > No, Rails insists upon constructing the controller itself. rspec-rails > just wraps rails' testing framework. I'd much rather be constructing > the objects myself. > > As for DI, there is a wealth of discussion about DI in Ruby in various > user lists - general consensus is don't do it. I concur. You don't > need it. You might be particularly interested in > http://rubyconf2008.confreaks.com/recovering-from-enterprise.html, in > which Jamis Buck, who authored a DI library for Ruby named needle, > explains why that was unnecessary. That sounds a little bit like throwing the baby out with the bathwater though - you still need to be able to do some kind of DI if you're doing TDD, so that you can swap in a fake dependency, no? DI doesn't have to mean you use some fancy framework. As Pat said, this is hard when the object you want to test (in this case, a Rails ActionController) is so damn awkward to instantiate in a test. One approach would be to change the references to @authenticator in your controller to call a local #authenticator method, then override this with a TestController subclass and use that subclass instead in your test. David, how would you suggest the OP injects his MockAuthenticator? stub out Authenticator.new? I guess that's what I mostly do. Matt Wynne http://blog.mattwynne.net http://www.songkick.com From lists at ruby-forum.com Thu Mar 5 09:21:11 2009 From: lists at ruby-forum.com (John Small) Date: Thu, 5 Mar 2009 15:21:11 +0100 Subject: [rspec-users] where does cucumber.yml live? Message-ID: Where do I put cucumber.yml? I can't find anything mentioned in the documentation. Thanks John Small -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Thu Mar 5 09:26:01 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 08:26:01 -0600 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <011E39CE-1EF6-4E7E-A215-0995FC1A28A8@mattwynne.net> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> <011E39CE-1EF6-4E7E-A215-0995FC1A28A8@mattwynne.net> Message-ID: <57c63afe0903050626w1e9c4401k5d004729b7092fec@mail.gmail.com> On Thu, Mar 5, 2009 at 3:31 AM, Matt Wynne wrote: > > On 5 Mar 2009, at 06:02, David Chelimsky wrote: > >> On Wed, Mar 4, 2009 at 10:38 PM, Perryn Fowler wrote: >>> >>> Hi >>> >>> I am experimenting with Constructor based dependency injection for >>> rails controllers. >>> >>> So I have something like this >>> >>> class LoginSessionsController < ApplicationController >>> >>> ?def initialize(authenticator = ?TheRealAuthenticator) >>> ? @authenticator = authenticator >>> ?end >>> >>> ?.... >>> end >>> >>> >>> The plan was to override the authenticator used when testing with >>> something like >>> >>> describe LoginSessionsController.new(MyMockAuthenticator) do >>> ?...... >>> end >>> >>> but rspec seems to insist on constructing the controller itself >> >> No, Rails insists upon constructing the controller itself. rspec-rails >> just wraps rails' testing framework. I'd much rather be constructing >> the objects myself. >> >> As for DI, there is a wealth of discussion about DI in Ruby in various >> user lists - general consensus is don't do it. I concur. You don't >> need it. You might be particularly interested in >> http://rubyconf2008.confreaks.com/recovering-from-enterprise.html, in >> which Jamis Buck, who authored a DI library for Ruby named needle, >> explains why that was unnecessary. > > That sounds a little bit like throwing the baby out with the bathwater > though - you still need to be able to do some kind of DI if you're doing > TDD, so that you can swap in a fake dependency, no? DI doesn't have to mean > you use some fancy framework. Agreed. I think I reacted to the term DI, about which J.B. Rainsberger once commented "Oh, you mean parameters." I totally agree that we need strategies for introducing doubles. > > As Pat said, this is hard when the object you want to test (in this case, a > Rails ActionController) is so damn awkward to instantiate in a test. > > One approach would be to change the references to @authenticator in your > controller to call a local #authenticator method, then override this with a > TestController subclass and use that subclass instead in your test. > > David, how would you suggest the OP injects his MockAuthenticator? stub out > Authenticator.new? I guess that's what I mostly do. That's what I usually do as well. If you think of it, in this case Authenticator is the factory, and you're providing a stub factory with this approach - something that would require more elaborate measures in other languages. Maybe we should make this easier by providing some facility in the mock framework to express the following in one statement: @authenticator = stub('authenticator') Authenticator.stub!(:new).and_return(@authenticator) Sure, you could make that a one liner: Authenticator.stub!(:new).and_return(@authenticator = stub('authenticator') But I mean something like: @authenticator = Authenticator.stub! I don't think *that* is the answer - but something that concise would be nice. Thoughts? David > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Thu Mar 5 09:45:12 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 08:45:12 -0600 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: References: Message-ID: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> On Thu, Mar 5, 2009 at 8:21 AM, John Small wrote: > Where do I put cucumber.yml? I can't find anything mentioned in the > documentation. In the project root (or wherever you're typing commands from). Cheers, David > > Thanks > > John Small > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From ben at benmabey.com Thu Mar 5 10:24:27 2009 From: ben at benmabey.com (Ben Mabey) Date: Thu, 05 Mar 2009 08:24:27 -0700 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <57c63afe0903050626w1e9c4401k5d004729b7092fec@mail.gmail.com> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> <011E39CE-1EF6-4E7E-A215-0995FC1A28A8@mattwynne.net> <57c63afe0903050626w1e9c4401k5d004729b7092fec@mail.gmail.com> Message-ID: <49AFEEAB.5020602@benmabey.com> David Chelimsky wrote: > On Thu, Mar 5, 2009 at 3:31 AM, Matt Wynne wrote: > >> On 5 Mar 2009, at 06:02, David Chelimsky wrote: >> >> >>> On Wed, Mar 4, 2009 at 10:38 PM, Perryn Fowler wrote: >>> >>>> Hi >>>> >>>> I am experimenting with Constructor based dependency injection for >>>> rails controllers. >>>> >>>> So I have something like this >>>> >>>> class LoginSessionsController < ApplicationController >>>> >>>> def initialize(authenticator = TheRealAuthenticator) >>>> @authenticator = authenticator >>>> end >>>> >>>> .... >>>> end >>>> >>>> >>>> The plan was to override the authenticator used when testing with >>>> something like >>>> >>>> describe LoginSessionsController.new(MyMockAuthenticator) do >>>> ...... >>>> end >>>> >>>> but rspec seems to insist on constructing the controller itself >>>> >>> No, Rails insists upon constructing the controller itself. rspec-rails >>> just wraps rails' testing framework. I'd much rather be constructing >>> the objects myself. >>> >>> As for DI, there is a wealth of discussion about DI in Ruby in various >>> user lists - general consensus is don't do it. I concur. You don't >>> need it. You might be particularly interested in >>> http://rubyconf2008.confreaks.com/recovering-from-enterprise.html, in >>> which Jamis Buck, who authored a DI library for Ruby named needle, >>> explains why that was unnecessary. >>> >> That sounds a little bit like throwing the baby out with the bathwater >> though - you still need to be able to do some kind of DI if you're doing >> TDD, so that you can swap in a fake dependency, no? DI doesn't have to mean >> you use some fancy framework. >> > > Agreed. I think I reacted to the term DI, about which J.B. Rainsberger > once commented "Oh, you mean parameters." I totally agree that we need > strategies for introducing doubles. > > >> As Pat said, this is hard when the object you want to test (in this case, a >> Rails ActionController) is so damn awkward to instantiate in a test. >> >> One approach would be to change the references to @authenticator in your >> controller to call a local #authenticator method, then override this with a >> TestController subclass and use that subclass instead in your test. >> >> David, how would you suggest the OP injects his MockAuthenticator? stub out >> Authenticator.new? I guess that's what I mostly do. >> > > That's what I usually do as well. If you think of it, in this case > Authenticator is the factory, and you're providing a stub factory with > this approach - something that would require more elaborate measures > in other languages. > > Maybe we should make this easier by providing some facility in the > mock framework to express the following in one statement: > > @authenticator = stub('authenticator') > Authenticator.stub!(:new).and_return(@authenticator) > > Sure, you could make that a one liner: > > Authenticator.stub!(:new).and_return(@authenticator = stub('authenticator') > > But I mean something like: > > @authenticator = Authenticator.stub! > > I don't think *that* is the answer - but something that concise would be nice. > > Thoughts? > > David > > I like the conciseness, but it isn't very clear what it is doing IMO. Perhaps something a little more intention-revealing like: @authenticator = Authenticator.stub_new! -Ben From lists at ruby-forum.com Thu Mar 5 10:43:35 2009 From: lists at ruby-forum.com (John Small) Date: Thu, 5 Mar 2009 16:43:35 +0100 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> References: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> Message-ID: David Chelimsky wrote: > On Thu, Mar 5, 2009 at 8:21 AM, John Small wrote: >> Where do I put cucumber.yml? I can't find anything mentioned in the >> documentation. > > In the project root (or wherever you're typing commands from). > > Cheers, > David Ok, I tried config and features to no avail, I guess that's the only option left Is this documented anywhere, or are people expected to just know it? Ta John Small -- Posted via http://www.ruby-forum.com/. From aslak.hellesoy at gmail.com Thu Mar 5 11:37:47 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 5 Mar 2009 17:37:47 +0100 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: References: Message-ID: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> On Thu, Mar 5, 2009 at 3:21 PM, John Small wrote: > Where do I put cucumber.yml? I can't find anything mentioned in the > documentation. > Here it is: http://wiki.github.com/aslakhellesoy/cucumber/running-features Aslak > Thanks > > John Small > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Aslak (::) From aslak.hellesoy at gmail.com Thu Mar 5 11:55:28 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 5 Mar 2009 17:55:28 +0100 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: References: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> Message-ID: <8d961d900903050855h28dab74bof0f1d0d0d3cade33@mail.gmail.com> On Thu, Mar 5, 2009 at 4:43 PM, John Small wrote: > David Chelimsky wrote: >> On Thu, Mar 5, 2009 at 8:21 AM, John Small wrote: >>> Where do I put cucumber.yml? I can't find anything mentioned in the >>> documentation. >> >> In the project root (or wherever you're typing commands from). >> >> Cheers, >> David > > Ok, I tried config and features to no avail, I guess that's the only > option left > > Is this documented anywhere, or are people expected to just know it? > You didn't read the mail I sent 20 minutes ago? http://wiki.github.com/aslakhellesoy/cucumber/running-features Aslak > Ta > > John Small > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Aslak (::) From nick at deadorange.com Thu Mar 5 11:58:05 2009 From: nick at deadorange.com (Nick Hoffman) Date: Thu, 5 Mar 2009 11:58:05 -0500 Subject: [rspec-users] OT: AR Default Values In-Reply-To: <36c7a89533c59fc78edb2fd5f07d43fc@ruby-forum.com> References: <6ec7f496f43a7c6085465ef3c738d329@ruby-forum.com> <32093C1D-CCFE-4F2B-B6D3-0869069FCFFD@railsnewbie.com> <36c7a89533c59fc78edb2fd5f07d43fc@ruby-forum.com> Message-ID: <16827fa20903050858u5ddec343l8de2e08a2c210a21@mail.gmail.com> On Wed, Mar 4, 2009 at 2:58 PM, James Byrne wrote: > Scott Taylor wrote: > >> You could try this plugin: >> >> http://github.com/aussiegeek/active_record_defaults/tree/master >> >> Scott > > Thanks, I will try this out. Hi James. Just a quick message to let you know that I've used active_record_defaults in the past, and it's been very helpful. Good luck. -Nick From r_j_h_box-sf at yahoo.com Thu Mar 5 12:12:36 2009 From: r_j_h_box-sf at yahoo.com (r_j_h_box-sf at yahoo.com) Date: Thu, 5 Mar 2009 09:12:36 -0800 (PST) Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: References: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> Message-ID: <32974.97429.qm@web31805.mail.mud.yahoo.com> ----- Original Message ---- > From: John Small [David:] > > In the project root (or wherever you're typing commands from). > Is this documented anywhere, or are people expected to just know it? I added the information to the wiki in one or two places, having been bitten by the same expectation you had, and having read through the code that seeks out that file. I think it should look in places named in the options, plus the config/ directory, personally. The config directory is where I'd want to put it, but not every project in the world is a rails project, so I add a grain of salt to that impulse. Randy From aslak.hellesoy at gmail.com Thu Mar 5 12:17:52 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 5 Mar 2009 18:17:52 +0100 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <32974.97429.qm@web31805.mail.mud.yahoo.com> References: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> <32974.97429.qm@web31805.mail.mud.yahoo.com> Message-ID: <8d961d900903050917o7f4a48bfi3ebdceb78040b344@mail.gmail.com> On Thu, Mar 5, 2009 at 6:12 PM, wrote: > > > > > > ----- Original Message ---- >> From: John Small > [David:] >> > In the project root (or wherever you're typing commands from). > >> Is this documented anywhere, or are people expected to just know it? > > I added the information to the wiki in one or two places, having been bitten by the same expectation you had, and having read through the code that seeks out that file. > > I think it should look in places named in the options, plus the config/ directory, personally. ?The config directory is where I'd want to put it, but not every project in the world is a rails project, so I add a grain of salt to that impulse. > Randy, John: You really don't read my responses, do you? Or is there some gmail lag issue going on here? Aslak > Randy > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Aslak (::) From anja-email1 at web.de Thu Mar 5 11:49:47 2009 From: anja-email1 at web.de (Andrea Jahn) Date: Thu, 05 Mar 2009 17:49:47 +0100 Subject: [rspec-users] errors in controller specs when running by rake Message-ID: <1285036318@web.de> Hi, I'm working on Windows Vista and I've installed the plugins rspec and rspec-rails V1.1.12. If I run the controller specs directly by ruby, they are all ok: ----------------------------------- C:\InstantRails-2.0-win\rails_apps\myapplication>ruby spec/controllers/planning/pl_plann ings/pl_plannings_controller_new_spec.rb ... Finished in 0.587 seconds 3 examples, 0 failures ----------------------------------- C:\InstantRails-2.0-win\rails_apps\myapplication>ruby -I"C:/InstantRails-2.0-win/rails_a pps/myapplication/vendor/plugins/rspec/lib" "C:/InstantRails-2.0-win/rails_apps/myapplication/ve ndor/plugins/rspec/bin/spec" "spec/controllers/planning/pl_plannings/pl_planning s_controller_new_spec.rb" --options "C:/InstantRails-2.0-win/rails_apps/myapplication/sp ec/spec.opts" ... Finished in 0.158 seconds 3 examples, 0 failures ------------------------------------------- But when I run "rake spec", I get a lot of errors (and an exception from rake): (in C:/InstantRails-2.0-win/rails_apps/myapplication) ** Invoke spec (first_time) ** Invoke db:test:prepare (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:test:prepare ** Invoke db:test:load (first_time) ** Invoke db:test:purge (first_time) ** Invoke environment ** Execute db:test:purge ** Execute db:test:load ** Invoke db:schema:load (first_time) ** Invoke environment ** Execute db:schema:load ** Execute spec .............................F..FFF........FFF...............FFF..FFFFF.... 1) 'Planning::PlPlanningsController GET new should render the new template' FAILED expected "new", got "planning/pl_plannings/index" ./spec/controllers/planning/pl_plannings/pl_plannings_controller_new_spec.rb:35: 2) 'Planning::PlPlanningsController GET show should render the show template' FAILED expected "show", got "planning/pl_plannings/index" ./spec/controllers/planning/pl_plannings/pl_plannings_controller_show_spec.rb:47: 3) Spec::Mocks::MockExpectationError in 'Planning::PlPlanningsController GET show should call the find method of the PlPlanning class' expected :find with (nil) but received it with (:all) ./spec/controllers/planning/pl_plannings/pl_plannings_controller_show_spec.rb:41: 4) 'Planning::PlPlanningsController GET show should assign a pl_planning' FAILED expected instance_of?(PlPlanning(id: integer, title: string, created_at: datetime, updated_at: datetime)) to return true, got false ./spec/controllers/planning/pl_plannings/pl_plannings_controller_show_spec.rb:36: 5) 'Planning::PlPlanningsController GET edit should render the edit template' FAILED expected "edit", got "planning/pl_plannings/index" ./spec/controllers/planning/pl_plannings/pl_plannings_controller_edit_spec.rb:47: 6) Spec::Mocks::MockExpectationError in 'Planning::PlPlanningsController GET edit should call the find method of the PlPlanning class' expected :find with (nil) but received it with (:all) ./spec/controllers/planning/pl_plannings/pl_plannings_controller_edit_spec.rb:41: 7) 'Planning::PlPlanningsController GET edit should assign a pl_planning' FAILED expected instance_of?(PlPlanning(id: integer, title: string, created_at: datetime, updated_at: datetime)) to return true, got false ./spec/controllers/planning/pl_plannings/pl_plannings_controller_edit_spec.rb:36: 8) 'Planning::PlPlanningsController GET index_deleted should render the index_deleted template' FAILED expected "index_deleted", got "planning/pl_plannings/index" ./spec/controllers/planning/pl_plannings/pl_plannings_controller_index_deleted_spec.rb:47: 9) Spec::Mocks::MockExpectationError in 'Planning::PlPlanningsController GET index_deleted should call the find method of the PlPlanning::Deleted class' expected :find with (:all, {:order=>"title"}) once, but received it 0 times ./spec/controllers/planning/pl_plannings/pl_plannings_controller_index_deleted_spec.rb:41: 10) 'Planning::PlPlanningsController GET index_deleted should assign deleted_pl_plannings' FAILED expected instance_of?(Array) to return true, got false ./spec/controllers/planning/pl_plannings/pl_plannings_controller_index_deleted_spec.rb:36: 11) ActiveRecord::RecordNotFound in 'Planning::PlPlanningsController PUT undestroy should redirect to the PlPlannings list' Couldn't find PlPlanning without an ID C:/InstantRails-2.0-win/rails_apps/myapplication/app/controllers/planning/pl_plannings_controller.rb:78:in `update' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_update_spec.rb:6:in `do_put' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_undestroy_spec.rb:53: 12) ActiveRecord::RecordNotFound in 'Planning::PlPlanningsController PUT undestroy should undestroy the PlPlanning' Couldn't find PlPlanning without an ID C:/InstantRails-2.0-win/rails_apps/myapplication/app/controllers/planning/pl_plannings_controller.rb:78:in `update' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_update_spec.rb:6:in `do_put' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_undestroy_spec.rb:49: 13) ActiveRecord::RecordNotFound in 'Planning::PlPlanningsController PUT undestroy should call the find method of the PlPlanning::Deleted class' Couldn't find PlPlanning without an ID C:/InstantRails-2.0-win/rails_apps/myapplication/app/controllers/planning/pl_plannings_controller.rb:78:in `update' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_update_spec.rb:6:in `do_put' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_undestroy_spec.rb:44: 14) ActiveRecord::RecordNotFound in 'Planning::PlPlanningsController PUT undestroy should assign a pl_planning' Couldn't find PlPlanning without an ID C:/InstantRails-2.0-win/rails_apps/myapplication/app/controllers/planning/pl_plannings_controller.rb:78:in `update' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_update_spec.rb:6:in `do_put' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_undestroy_spec.rb:37: 15) ActiveRecord::RecordNotFound in 'Planning::PlPlanningsController PUT undestroy should be successfully redirected' Couldn't find PlPlanning without an ID C:/InstantRails-2.0-win/rails_apps/myapplication/app/controllers/planning/pl_plannings_controller.rb:78:in `update' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_update_spec.rb:6:in `do_put' ./spec/controllers/planning/pl_plannings/pl_plannings_controller_undestroy_spec.rb:32: Finished in 1.417 seconds 75 examples, 15 failures rake aborted! Command C:/InstantRails-2.0-win/ruby/bin/ruby -I"C:/InstantRails-2.0-win/rails_apps/myapplication/vendor/plugins/rspec/lib" "C:/InstantRails-2.0-win/rails_apps/myapplication/vendor/plugins/rspec/bin/spec" "spec/controllers/planning/pl_plannings/pl_plannings_controller_create_spec.rb" "spec/controllers/planning/pl_plannings/pl_plannings_controller_edit_spec.rb" "spec/controllers/planning/pl_plannings/pl_plannings_controller_index_deleted_spec.rb" "spec/controllers/planning/pl_plannings/pl_plannings_controller_index_spec.rb" "spec/controllers/planning/pl_plannings/pl_plannings_controller_new_spec.rb" "spec/controllers/planning/pl_plannings/pl_plannings_controller_show_spec.rb" "spec/controllers/planning/pl_plannings/pl_plannings_controller_undestroy_spec.rb" "spec/controllers/planning/pl_plannings/pl_plannings_controller_update_spec.rb" "spec/helpers/pl_plannings_helper_spec.rb" "spec/models/planning/pl_planning_spec.rb" "spec/views/planning/pl_plannings/edit_rhtml_spec.rb" "spec/views/planning/pl_plannings/index_deleted_rhtml_spec.rb" "spec/views/planning/pl_plannings/index_rhtml_spec.rb" "spec/views/planning/pl_plannings/new_rhtml_spec.rb" "spec/views/planning/pl_plannings/show_rhtml_spec.rb" "spec/views/planning/pl_plannings/_form_rhtml_spec.rb" "spec/views/planning/pl_plannings/_table_rhtml_spec.rb" --options "C:/InstantRails-2.0-win/rails_apps/myapplication/spec/spec.opts" failed C:/InstantRails-2.0-win/rails_apps/myapplication/vendor/plugins/rspec/lib/spec/rake/spectask.rb:175:in `define' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1090:in `verbose' C:/InstantRails-2.0-win/rails_apps/myapplication/vendor/plugins/rspec/lib/spec/rake/spectask.rb:151:in `define' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in `invoke_with_call_chain' C:/InstantRails-2.0-win/ruby/lib/ruby/1.8/monitor.rb:242:in `synchronize' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run' C:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31 C:/InstantRails-2.0-win/ruby/bin/rake:19:in `load' C:/InstantRails-2.0-win/ruby/bin/rake:19 ------------------------------------------------------------------------------- Perhaps do I have to make some configurations ? Thanks in advance Andrea DSL zum Nulltarif + 20 Euro Extrapr?mie bei Online-Bestellung ?ber die DSL Freundschaftswerbung! *http://dsl.web.de/?ac=OM.AD.AD008K15279B7069a* [http://dsl.web.de/?ac=OM.AD.AD008K15279B7069a] -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Thu Mar 5 12:27:34 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 11:27:34 -0600 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <8d961d900903050855h28dab74bof0f1d0d0d3cade33@mail.gmail.com> References: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> <8d961d900903050855h28dab74bof0f1d0d0d3cade33@mail.gmail.com> Message-ID: <57c63afe0903050927k39e1caabj887df484e67a72e8@mail.gmail.com> On Thu, Mar 5, 2009 at 10:55 AM, aslak hellesoy wrote: > On Thu, Mar 5, 2009 at 4:43 PM, John Small wrote: >> David Chelimsky wrote: >>> On Thu, Mar 5, 2009 at 8:21 AM, John Small wrote: >>>> Where do I put cucumber.yml? I can't find anything mentioned in the >>>> documentation. >>> >>> In the project root (or wherever you're typing commands from). >>> >>> Cheers, >>> David >> >> Ok, I tried config and features to no avail, I guess that's the only >> option left >> >> Is this documented anywhere, or are people expected to just know it? >> > > You didn't read the mail I sent 20 minutes ago? > > http://wiki.github.com/aslakhellesoy/cucumber/running-features Since ppl are having a hard time finding this, I added http://wiki.github.com/aslakhellesoy/cucumber/cucumberyml, which references http://wiki.github.com/aslakhellesoy/cucumber/running-features. I also changed the header of the relevant section to "Defining ?profiles? in cucumber.yml" Should be easy to find now. Cheers, David > > Aslak > >> Ta >> >> John Small >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > Aslak (::) > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From f.mischa at gmail.com Thu Mar 5 12:29:11 2009 From: f.mischa at gmail.com (Mischa Fierer) Date: Thu, 5 Mar 2009 11:29:11 -0600 Subject: [rspec-users] OT: AR Default Values In-Reply-To: <36c7a89533c59fc78edb2fd5f07d43fc@ruby-forum.com> References: <6ec7f496f43a7c6085465ef3c738d329@ruby-forum.com> <32093C1D-CCFE-4F2B-B6D3-0869069FCFFD@railsnewbie.com> <36c7a89533c59fc78edb2fd5f07d43fc@ruby-forum.com> Message-ID: Not sure if this is what you're looking for, but there is also this: http://github.com/FooBarWidget/default_value_for/tree/master On Wed, Mar 4, 2009 at 1:58 PM, James Byrne wrote: > Scott Taylor wrote: > > > You could try this plugin: > > > > http://github.com/aussiegeek/active_record_defaults/tree/master > > > > Scott > > Thanks, I will try this out. > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Thu Mar 5 12:39:13 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 11:39:13 -0600 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <49AFEEAB.5020602@benmabey.com> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> <011E39CE-1EF6-4E7E-A215-0995FC1A28A8@mattwynne.net> <57c63afe0903050626w1e9c4401k5d004729b7092fec@mail.gmail.com> <49AFEEAB.5020602@benmabey.com> Message-ID: <57c63afe0903050939s4785fb7enab06dc23ec7220cb@mail.gmail.com> On Thu, Mar 5, 2009 at 9:24 AM, Ben Mabey wrote: > David Chelimsky wrote: >> >> On Thu, Mar 5, 2009 at 3:31 AM, Matt Wynne wrote: >> >>> >>> On 5 Mar 2009, at 06:02, David Chelimsky wrote: >>> >>> >>>> >>>> On Wed, Mar 4, 2009 at 10:38 PM, Perryn Fowler >>>> wrote: >>>> >>>>> >>>>> Hi >>>>> >>>>> I am experimenting with Constructor based dependency injection for >>>>> rails controllers. >>>>> >>>>> So I have something like this >>>>> >>>>> class LoginSessionsController < ApplicationController >>>>> >>>>> ?def initialize(authenticator = ?TheRealAuthenticator) >>>>> ?@authenticator = authenticator >>>>> ?end >>>>> >>>>> ?.... >>>>> end >>>>> >>>>> >>>>> The plan was to override the authenticator used when testing with >>>>> something like >>>>> >>>>> describe LoginSessionsController.new(MyMockAuthenticator) do >>>>> ?...... >>>>> end >>>>> >>>>> but rspec seems to insist on constructing the controller itself >>>>> >>>> >>>> No, Rails insists upon constructing the controller itself. rspec-rails >>>> just wraps rails' testing framework. I'd much rather be constructing >>>> the objects myself. >>>> >>>> As for DI, there is a wealth of discussion about DI in Ruby in various >>>> user lists - general consensus is don't do it. I concur. You don't >>>> need it. You might be particularly interested in >>>> http://rubyconf2008.confreaks.com/recovering-from-enterprise.html, in >>>> which Jamis Buck, who authored a DI library for Ruby named needle, >>>> explains why that was unnecessary. >>>> >>> >>> That sounds a little bit like throwing the baby out with the bathwater >>> though - you still need to be able to do some kind of DI if you're doing >>> TDD, so that you can swap in a fake dependency, no? DI doesn't have to >>> mean >>> you use some fancy framework. >>> >> >> Agreed. I think I reacted to the term DI, about which J.B. Rainsberger >> once commented "Oh, you mean parameters." I totally agree that we need >> strategies for introducing doubles. >> >> >>> >>> As Pat said, this is hard when the object you want to test (in this case, >>> a >>> Rails ActionController) is so damn awkward to instantiate in a test. >>> >>> One approach would be to change the references to @authenticator in your >>> controller to call a local #authenticator method, then override this with >>> a >>> TestController subclass and use that subclass instead in your test. >>> >>> David, how would you suggest the OP injects his MockAuthenticator? stub >>> out >>> Authenticator.new? I guess that's what I mostly do. >>> >> >> That's what I usually do as well. If you think of it, in this case >> Authenticator is the factory, and you're providing a stub factory with >> this approach - something that would require more elaborate measures >> in other languages. >> >> Maybe we should make this easier by providing some facility in the >> mock framework to express the following in one statement: >> >> @authenticator = stub('authenticator') >> Authenticator.stub!(:new).and_return(@authenticator) >> >> Sure, you could make that a one liner: >> >> Authenticator.stub!(:new).and_return(@authenticator = >> stub('authenticator') >> >> But I mean something like: >> >> @authenticator = Authenticator.stub! >> >> I don't think *that* is the answer - but something that concise would be >> nice. >> >> Thoughts? >> >> David >> >> > > I like the conciseness, but it isn't very clear what it is doing IMO. > ?Perhaps something a little more intention-revealing like: > > @authenticator = Authenticator.stub_new! That's the right direction. Not in love with that either - especially since it requires adding a new method to Object. How about something like: stub_factory(Authenticator) This would configure Authenticator to return the same test double every time it receives #new. So you could say: stub_factory(Authenticator) @authenticator = Authenticator.new Or, perhaps: @authenticator = stub_factory(Authenticator).new Not there yet (that's a bit confusing), but I think you can see where this is headed. More ideas? David > > -Ben > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From r_j_h_box-sf at yahoo.com Thu Mar 5 13:16:08 2009 From: r_j_h_box-sf at yahoo.com (r_j_h_box-sf at yahoo.com) Date: Thu, 5 Mar 2009 10:16:08 -0800 (PST) Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <8d961d900903050917o7f4a48bfi3ebdceb78040b344@mail.gmail.com> References: <57c63afe0903050645n7d4a580bo2606baef85e6429f@mail.gmail.com> <32974.97429.qm@web31805.mail.mud.yahoo.com> <8d961d900903050917o7f4a48bfi3ebdceb78040b344@mail.gmail.com> Message-ID: <321292.98913.qm@web31802.mail.mud.yahoo.com> Aslak: > some gmail lag issue going on here? Not sure who's causing the lag, but yeah. My hope was to help in a way that I could, freeing the "big guns" to focus on things I'm less suited for at this moment. Randy From BrianPatrickDunn at gmail.com Thu Mar 5 13:32:00 2009 From: BrianPatrickDunn at gmail.com (Higgaion) Date: Thu, 5 Mar 2009 10:32:00 -0800 (PST) Subject: [rspec-users] --options file quirky with --drb Message-ID: <79ed71c5-38d9-45e4-a7c4-470e0bfa5885@q30g2000prq.googlegroups.com> putting --drb in my spec.opts file has some unexpected results. $ spec --drb --colour --format specdoc --loadby mtime --reverse -G spec/spec.opts $ spec spec/models/a_model_spec.rb -O spec/spec.opts $ it just returns right away, with no output. but... $ spec --colour --format specdoc --loadby mtime --reverse -G spec/ spec.opts $ spec spec/models/campaign_spec.rb -O spec/spec.opts : : lots of pretty spec output : : $ interestingly, if i include a spec file in the call that generates the options file, like $ spec spec/models/campaign_spec.rb --drb --colour --format specdoc -- loadby mtime --reverse -G spec/spec.opts then running those options like this works as expected, even with -- drb. $ spec spec/models/a_model_spec.rb -O spec/spec.opts of course, that isn't a very useful way to use rspec, and its incompatible with my rspec holy grail dreams: http://wiki.github.com/dchelimsky/rspec/spec_server-autospec-nearly-pure-bdd-joy it seems that this would be a problem with options file loading, no? anyone else able to reproduce this issue? From dchelimsky at gmail.com Thu Mar 5 14:09:32 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 13:09:32 -0600 Subject: [rspec-users] --options file quirky with --drb In-Reply-To: <79ed71c5-38d9-45e4-a7c4-470e0bfa5885@q30g2000prq.googlegroups.com> References: <79ed71c5-38d9-45e4-a7c4-470e0bfa5885@q30g2000prq.googlegroups.com> Message-ID: <57c63afe0903051109p4fb8e410s48cca3cf313582a@mail.gmail.com> On Thu, Mar 5, 2009 at 12:32 PM, Higgaion wrote: > putting --drb in my spec.opts file has some unexpected results. > > $ spec --drb --colour --format specdoc --loadby mtime --reverse -G > spec/spec.opts > $ spec spec/models/a_model_spec.rb -O spec/spec.opts > $ > > it just returns right away, with no output. What version of rspec are you running? This should be fixed in git. > but... > $ spec --colour --format specdoc --loadby mtime --reverse -G spec/ > spec.opts > $ spec spec/models/campaign_spec.rb -O spec/spec.opts > : > : > lots of pretty spec output > : > : > $ > > interestingly, if i include a spec file in the call that generates the > options file, like > $ spec spec/models/campaign_spec.rb --drb --colour --format specdoc -- > loadby mtime --reverse -G spec/spec.opts > then running those options like this works as expected, even with -- > drb. > $ spec spec/models/a_model_spec.rb -O spec/spec.opts Never heard that before :) - obviously not intended. > > of course, that isn't a very useful way to use rspec, and its > incompatible with my rspec holy grail dreams: > http://wiki.github.com/dchelimsky/rspec/spec_server-autospec-nearly-pure-bdd-joy > > it seems that this would be a problem with options file loading, no? > anyone else able to reproduce this issue? > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From mark at mwilden.com Thu Mar 5 15:38:37 2009 From: mark at mwilden.com (Mark Wilden) Date: Thu, 5 Mar 2009 12:38:37 -0800 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> References: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> Message-ID: <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> That reminds me: Was there a reason for using : to run a feature at a line instead of spec's -l ? ///ark From BrianPatrickDunn at gmail.com Thu Mar 5 16:18:34 2009 From: BrianPatrickDunn at gmail.com (Higgaion) Date: Thu, 5 Mar 2009 13:18:34 -0800 (PST) Subject: [rspec-users] --options file quirky with --drb In-Reply-To: <57c63afe0903051109p4fb8e410s48cca3cf313582a@mail.gmail.com> References: <79ed71c5-38d9-45e4-a7c4-470e0bfa5885@q30g2000prq.googlegroups.com> <57c63afe0903051109p4fb8e410s48cca3cf313582a@mail.gmail.com> Message-ID: <677b3e90-d8f2-4b73-93ff-5fcc08051db0@k19g2000prh.googlegroups.com> On Mar 5, 1:09?pm, David Chelimsky wrote: > On Thu, Mar 5, 2009 at 12:32 PM, Higgaion wrote: > > putting --drb in my spec.opts file has some unexpected results. > > > $ spec --drb --colour --format specdoc --loadby mtime --reverse -G > > spec/spec.opts > > $ spec spec/models/a_model_spec.rb -O spec/spec.opts > > $ > > > it just returns right away, with no output. > > What version of rspec are you running? This should be fixed in git. > rspec 1.1.12. i installed the plugins from git, as per the instructions here: http://wiki.github.com/dchelimsky/rspec/rails and it worked beautifully, as in spec_server and autospec talking together* one issue: now all of my route generation specs that illustrate differentiation on http method are failing. ex: Test::Unit::AssertionFailedError in 'UsersController route generation should route users's 'update' action correctly' The recognized options <{"action"=>"show", "id"=>"1", "controller"=>"users"}> did not match <{"action"=>"update", "id"=>"1", "controller"=>"users"}>, difference: <{"action"=>"update"}> here it thought put was get. i guess that's why its the edge version :) * with one minor change: vendor/plugins/rspec/lib/spec/runner/drb_command_line.rb - DRb.start_service("druby://localhost:0") + DRb.start_service("druby://127.0.0.1:0") i always have to change that because i build ruby from macports. > > > > > > but... > > $ spec --colour --format specdoc --loadby mtime --reverse -G spec/ > > spec.opts > > $ spec spec/models/campaign_spec.rb -O spec/spec.opts > > : > > : > > lots of pretty spec output > > : > > : > > $ > > > interestingly, if i include a spec file in the call that generates the > > options file, like > > $ spec spec/models/campaign_spec.rb --drb --colour --format specdoc -- > > loadby mtime --reverse -G spec/spec.opts > > then running those options like this works as expected, even with -- > > drb. > > $ spec spec/models/a_model_spec.rb -O spec/spec.opts > > Never heard that before :) - obviously not intended. > > > > > of course, that isn't a very useful way to use rspec, and its > > incompatible with my rspec holy grail dreams: > >http://wiki.github.com/dchelimsky/rspec/spec_server-autospec-nearly-p... > > > it seems that this would be a problem with options file loading, no? > > anyone else able to reproduce this issue? > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From ben at benmabey.com Thu Mar 5 16:30:30 2009 From: ben at benmabey.com (Ben Mabey) Date: Thu, 05 Mar 2009 14:30:30 -0700 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> References: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> Message-ID: <49B04476.7030209@benmabey.com> Mark Wilden wrote: > That reminds me: Was there a reason for using : to run a > feature at a line instead of spec's -l ? > > ///ark > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > I think it was to keep in line with how Cucumber outputs the backtrace in the CLI. So you can simply copy and paste the line from the output to run just that one scenario. I actually much prefer the concise notation and I would like to see RSpec adopt it. -Ben From BrianPatrickDunn at gmail.com Thu Mar 5 16:49:58 2009 From: BrianPatrickDunn at gmail.com (Higgaion) Date: Thu, 5 Mar 2009 13:49:58 -0800 (PST) Subject: [rspec-users] --options file quirky with --drb In-Reply-To: <677b3e90-d8f2-4b73-93ff-5fcc08051db0@k19g2000prh.googlegroups.com> References: <79ed71c5-38d9-45e4-a7c4-470e0bfa5885@q30g2000prq.googlegroups.com> <57c63afe0903051109p4fb8e410s48cca3cf313582a@mail.gmail.com> <677b3e90-d8f2-4b73-93ff-5fcc08051db0@k19g2000prh.googlegroups.com> Message-ID: On Mar 5, 3:18?pm, Higgaion wrote: > On Mar 5, 1:09?pm, David Chelimsky wrote: > > > On Thu, Mar 5, 2009 at 12:32 PM, Higgaion wrote: > > > putting --drb in my spec.opts file has some unexpected results. > > > > $ spec --drb --colour --format specdoc --loadby mtime --reverse -G > > > spec/spec.opts > > > $ spec spec/models/a_model_spec.rb -O spec/spec.opts > > > $ > > > > it just returns right away, with no output. > > > What version of rspec are you running? This should be fixed in git. > > rspec 1.1.12. > > i installed the plugins from git, as per the instructions here:http://wiki.github.com/dchelimsky/rspec/rails > and it worked beautifully, as in spec_server and autospec talking > together* > > one issue: now all of my route generation specs that illustrate > differentiation on http method are failing. ex: > > Test::Unit::AssertionFailedError in 'UsersController route generation > should route users's 'update' action correctly' > The recognized options <{"action"=>"show", "id"=>"1", > "controller"=>"users"}> did not match <{"action"=>"update", "id"=>"1", > "controller"=>"users"}>, difference: <{"action"=>"update"}> > > here it thought put was get. > > i guess that's why its the edge version :) > ok, i read some code and i see that rspec is now using assert_recognizes, which expects a :method option. so if i change route_for(:controller => 'users', :action => 'update', :id => '1').should == "/users/1" to route_for(:controller => 'users', :action => 'update', :id => '1').should == { :path => "/users/1", :method => :put } the assertion passes (and is a little more descriptive). > * with one minor change: > > vendor/plugins/rspec/lib/spec/runner/drb_command_line.rb > - ? ? ? ? ?DRb.start_service("druby://localhost:0") > + ? ? ? ? ?DRb.start_service("druby://127.0.0.1:0") > > i always have to change that because i build ruby from macports. > > > > > > > > > > but... > > > $ spec --colour --format specdoc --loadby mtime --reverse -G spec/ > > > spec.opts > > > $ spec spec/models/campaign_spec.rb -O spec/spec.opts > > > : > > > : > > > lots of pretty spec output > > > : > > > : > > > $ > > > > interestingly, if i include a spec file in the call that generates the > > > options file, like > > > $ spec spec/models/campaign_spec.rb --drb --colour --format specdoc -- > > > loadby mtime --reverse -G spec/spec.opts > > > then running those options like this works as expected, even with -- > > > drb. > > > $ spec spec/models/a_model_spec.rb -O spec/spec.opts > > > Never heard that before :) - obviously not intended. > > > > of course, that isn't a very useful way to use rspec, and its > > > incompatible with my rspec holy grail dreams: > > >http://wiki.github.com/dchelimsky/rspec/spec_server-autospec-nearly-p... > > > > it seems that this would be a problem with options file loading, no? > > > anyone else able to reproduce this issue? > > > _______________________________________________ > > > rspec-users mailing list > > > rspec-us... at rubyforge.org > > >http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Thu Mar 5 16:52:59 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 15:52:59 -0600 Subject: [rspec-users] --options file quirky with --drb In-Reply-To: <677b3e90-d8f2-4b73-93ff-5fcc08051db0@k19g2000prh.googlegroups.com> References: <79ed71c5-38d9-45e4-a7c4-470e0bfa5885@q30g2000prq.googlegroups.com> <57c63afe0903051109p4fb8e410s48cca3cf313582a@mail.gmail.com> <677b3e90-d8f2-4b73-93ff-5fcc08051db0@k19g2000prh.googlegroups.com> Message-ID: <57c63afe0903051352g4b12416ayd64504ba342357fa@mail.gmail.com> On Thu, Mar 5, 2009 at 3:18 PM, Higgaion wrote: > On Mar 5, 1:09?pm, David Chelimsky wrote: >> On Thu, Mar 5, 2009 at 12:32 PM, Higgaion wrote: >> > putting --drb in my spec.opts file has some unexpected results. >> >> > $ spec --drb --colour --format specdoc --loadby mtime --reverse -G >> > spec/spec.opts >> > $ spec spec/models/a_model_spec.rb -O spec/spec.opts >> > $ >> >> > it just returns right away, with no output. >> >> What version of rspec are you running? This should be fixed in git. >> > > rspec 1.1.12. > > i installed the plugins from git, as per the instructions here: > http://wiki.github.com/dchelimsky/rspec/rails > and it worked beautifully, as in spec_server and autospec talking > together* Great. > > one issue: now all of my route generation specs that illustrate > differentiation on http method are failing. ex: > > Test::Unit::AssertionFailedError in 'UsersController route generation > should route users's 'update' action correctly' > The recognized options <{"action"=>"show", "id"=>"1", > "controller"=>"users"}> did not match <{"action"=>"update", "id"=>"1", > "controller"=>"users"}>, difference: <{"action"=>"update"}> > > here it thought put was get. > > i guess that's why its the edge version :) This is doc'd here: http://github.com/dchelimsky/rspec-rails/blob/master/Upgrade.markdown > * with one minor change: > > vendor/plugins/rspec/lib/spec/runner/drb_command_line.rb > - ? ? ? ? ?DRb.start_service("druby://localhost:0") > + ? ? ? ? ?DRb.start_service("druby://127.0.0.1:0") > > i always have to change that because i build ruby from macports. Maybe we need to make that configurable. Thanks, David >> > but... >> > $ spec --colour --format specdoc --loadby mtime --reverse -G spec/ >> > spec.opts >> > $ spec spec/models/campaign_spec.rb -O spec/spec.opts >> > : >> > : >> > lots of pretty spec output >> > : >> > : >> > $ >> >> > interestingly, if i include a spec file in the call that generates the >> > options file, like >> > $ spec spec/models/campaign_spec.rb --drb --colour --format specdoc -- >> > loadby mtime --reverse -G spec/spec.opts >> > then running those options like this works as expected, even with -- >> > drb. >> > $ spec spec/models/a_model_spec.rb -O spec/spec.opts >> >> Never heard that before :) - obviously not intended. >> >> >> >> > of course, that isn't a very useful way to use rspec, and its >> > incompatible with my rspec holy grail dreams: >> >http://wiki.github.com/dchelimsky/rspec/spec_server-autospec-nearly-p... >> >> > it seems that this would be a problem with options file loading, no? >> > anyone else able to reproduce this issue? >> > _______________________________________________ >> > rspec-users mailing list >> > rspec-us... at rubyforge.org >> >http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From joe at josephwilk.net Thu Mar 5 17:28:28 2009 From: joe at josephwilk.net (Joseph Wilk) Date: Thu, 05 Mar 2009 22:28:28 +0000 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <49B04476.7030209@benmabey.com> References: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> <49B04476.7030209@benmabey.com> Message-ID: <49B0520C.6070205@josephwilk.net> Ben Mabey wrote: > Mark Wilden wrote: >> That reminds me: Was there a reason for using : to run a >> feature at a line instead of spec's -l ? >> >> ///ark >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > I think it was to keep in line with how Cucumber outputs the backtrace > in the CLI. So you can simply copy and paste the line from the output > to run just that one scenario. > > I actually much prefer the concise notation and I would like to see > RSpec adopt it. > Exactly as Ben said. In addition it was also used as it made it nicer when running multiple lines in the same file file:10:11:14:15 -- Joseph Wilk http://blog.josephwilk.net > -Ben > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Thu Mar 5 17:47:40 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 16:47:40 -0600 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <49B04476.7030209@benmabey.com> References: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> <49B04476.7030209@benmabey.com> Message-ID: <57c63afe0903051447y49c60b98i7b5cd15c0907daad@mail.gmail.com> On Thu, Mar 5, 2009 at 3:30 PM, Ben Mabey wrote: > Mark Wilden wrote: >> >> That reminds me: Was there a reason for using : to run a >> feature at a line instead of spec's -l ? >> >> ///ark >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > I think it was to keep in line with how Cucumber outputs the backtrace in > the CLI. ?So you can simply copy and paste the line from the output to run > just that one scenario. > > I actually much prefer the concise notation and I would like to see RSpec > adopt it. I agree. RSpec will adopt it as soon as it receives your patch :) > > -Ben > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From mark at mwilden.com Thu Mar 5 19:03:35 2009 From: mark at mwilden.com (Mark Wilden) Date: Thu, 5 Mar 2009 16:03:35 -0800 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <57c63afe0903051447y49c60b98i7b5cd15c0907daad@mail.gmail.com> References: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> <49B04476.7030209@benmabey.com> <57c63afe0903051447y49c60b98i7b5cd15c0907daad@mail.gmail.com> Message-ID: <3c30da400903051603q244edb76ub02e98691bf3f5ec@mail.gmail.com> On Thu, Mar 5, 2009 at 2:47 PM, David Chelimsky wrote: >> >> I actually much prefer the concise notation and I would like to see RSpec >> adopt it. > > I agree. RSpec will adopt it as soon as it receives your patch :) That would be great. I've been used to seeing the colon notation for a quarter of a century. :) ///ark From ben at benmabey.com Thu Mar 5 19:30:44 2009 From: ben at benmabey.com (Ben Mabey) Date: Thu, 05 Mar 2009 17:30:44 -0700 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <57c63afe0903051447y49c60b98i7b5cd15c0907daad@mail.gmail.com> References: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> <49B04476.7030209@benmabey.com> <57c63afe0903051447y49c60b98i7b5cd15c0907daad@mail.gmail.com> Message-ID: <49B06EB4.90909@benmabey.com> David Chelimsky wrote: > On Thu, Mar 5, 2009 at 3:30 PM, Ben Mabey wrote: > >> Mark Wilden wrote: >> >>> That reminds me: Was there a reason for using : to run a >>> feature at a line instead of spec's -l ? >>> >>> ///ark >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> >> I think it was to keep in line with how Cucumber outputs the backtrace in >> the CLI. So you can simply copy and paste the line from the output to run >> just that one scenario. >> >> I actually much prefer the concise notation and I would like to see RSpec >> adopt it. >> > > I agree. RSpec will adopt it as soon as it receives your patch :) > I really need to stop suggesting things on this list... :) > >> -Ben >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Thu Mar 5 20:11:42 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Mar 2009 19:11:42 -0600 Subject: [rspec-users] where does cucumber.yml live? In-Reply-To: <49B06EB4.90909@benmabey.com> References: <8d961d900903050837h2941770cp1fe1c871e8a8105e@mail.gmail.com> <3c30da400903051238k3e0d618cm4f39505d38013218@mail.gmail.com> <49B04476.7030209@benmabey.com> <57c63afe0903051447y49c60b98i7b5cd15c0907daad@mail.gmail.com> <49B06EB4.90909@benmabey.com> Message-ID: <57c63afe0903051711s18bc70f5h2b67eb82cdc2f48f@mail.gmail.com> On Thu, Mar 5, 2009 at 6:30 PM, Ben Mabey wrote: > David Chelimsky wrote: >> >> On Thu, Mar 5, 2009 at 3:30 PM, Ben Mabey wrote: >> >>> >>> Mark Wilden wrote: >>> >>>> >>>> That reminds me: Was there a reason for using : to run a >>>> feature at a line instead of spec's -l ? >>>> >>>> ///ark >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>>> >>> >>> I think it was to keep in line with how Cucumber outputs the backtrace in >>> the CLI. ?So you can simply copy and paste the line from the output to >>> run >>> just that one scenario. >>> >>> I actually much prefer the concise notation and I would like to see RSpec >>> adopt it. >>> >> >> I agree. RSpec will adopt it as soon as it receives your patch :) >> > > I really need to stop suggesting things on this list... ?:) :) From lists at ruby-forum.com Fri Mar 6 01:52:11 2009 From: lists at ruby-forum.com (Raills Rocks) Date: Fri, 6 Mar 2009 07:52:11 +0100 Subject: [rspec-users] Story / Redirection to static html within public In-Reply-To: References: Message-ID: <180ac9d2fbff88301ccf62418ac20650@ruby-forum.com> I have a story written using webat. > This story uses the above controller and it expects the redirection. > > This story always fails as within the story it cannot follow the > redirection (Always gives a 500 error). It does not seem to be able to > access any public/ content within the story. >Rails Integration tests talk directly to controllers, since there is >no controller in front of static files there is no way to access them >as far as I've seen. You can redirect the static files by creating an extra file say some home.html or index.html and then specifying the path of your next html file(that you want to forward). From that file onwards the redirection takes place correctly without looking for controller. I remind you home.html file must be rendered through controller action using render :file=>".....path to html folder"/home.html I hope this helps. -- Posted via http://www.ruby-forum.com/. From matt at mattwynne.net Fri Mar 6 03:05:59 2009 From: matt at mattwynne.net (Matt Wynne) Date: Fri, 6 Mar 2009 08:05:59 +0000 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <49AFEEAB.5020602@benmabey.com> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> <011E39CE-1EF6-4E7E-A215-0995FC1A28A8@mattwynne.net> <57c63afe0903050626w1e9c4401k5d004729b7092fec@mail.gmail.com> <49AFEEAB.5020602@benmabey.com> Message-ID: <745A0F9E-D5FA-42C7-A0E0-6E7D9677BD8B@mattwynne.net> On 5 Mar 2009, at 15:24, Ben Mabey wrote: > David Chelimsky wrote: >> On Thu, Mar 5, 2009 at 3:31 AM, Matt Wynne >> wrote: >> Maybe we should make this easier by providing some facility in the >> mock framework to express the following in one statement: >> >> @authenticator = stub('authenticator') >> Authenticator.stub!(:new).and_return(@authenticator) >> >> Sure, you could make that a one liner: >> >> Authenticator.stub!(:new).and_return(@authenticator = >> stub('authenticator') >> >> But I mean something like: >> >> @authenticator = Authenticator.stub! >> >> I don't think *that* is the answer - but something that concise >> would be nice. >> >> Thoughts? >> >> David >> >> > I like the conciseness, but it isn't very clear what it is doing > IMO. Perhaps something a little more intention-revealing like: > > @authenticator = Authenticator.stub_new! I think I must mostly use constructor injection, as I don't really seem to have a pattern for this, but if I did I guess it would be something like this: extend StubbingHelpers describe "blah" before(:each) do @authenticator = mock_new_authenticator( :foo => bar ) which is implemented like def stub_new_authenticator( *args ) result = mock(Authenticator, *args) Authenticator.stub!(:new).and_return(result) result end I guess having something like that would be nice. Matt Wynne http://blog.mattwynne.net http://www.songkick.com From Richard.T.Lloyd at gmail.com Wed Mar 4 16:14:38 2009 From: Richard.T.Lloyd at gmail.com (Rick) Date: Wed, 4 Mar 2009 13:14:38 -0800 (PST) Subject: [rspec-users] rspec 1.1.99.10 rails 2.3 - help needed Message-ID: <4839770d-d479-4ac3-8b9e-2a83355efe29@v5g2000prm.googlegroups.com> I checked first and found no conversation that matched my problem so here it is: I'm trying to get rspec going on ruby 1.9.1 / rails 2.3.0 - here's my current gem list: *** LOCAL GEMS *** actionmailer (2.3.0) actionpack (2.3.0) activerecord (2.3.0) activeresource (2.3.0) activesupport (2.3.0) columnize (0.3.0) cucumber (0.1.16) daemons (1.0.10) diff-lcs (1.1.2) eventmachine (0.12.4) git (1.0.5) hoe (1.9.0) mocha (0.9.5) mysql (2.8.1) pg (0.7.9.2009.02.26) polyglot (0.2.5) rack (0.9.1) rails (2.3.0) rake (0.8.3) rspec (1.1.99.10) rspec-rails (1.1.99.10) rubyforge (1.0.3) rubyist-aasm (2.0.5) sqlite3-ruby (1.2.4) term-ansicolor (1.0.3) thin (1.0.0) treetop (1.2.4) As you can see, I followed David's instructions re rspec and rspec- rails for rails 2.3.0. Just by way of test, I did the following: 1) rails spec230test 2) cd spec230test 3) script/generate rspec 4) script/generate rspec_model User name:string email:string 5) rake db:migrate 6) rake spec:models --trace and here's what I get for results: rake spec:models --trace (in /Users/rick/spec230test) ** Invoke spec:models (first_time) ** Invoke db:test:prepare (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:test:prepare ** Invoke db:test:load (first_time) ** Invoke db:test:purge (first_time) ** Invoke environment ** Execute db:test:purge ** Execute db:test:load ** Invoke db:schema:load (first_time) ** Invoke environment ** Execute db:schema:load ** Execute spec:models /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/test_case.rb:6: warning: already initialized constant Mocha /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:440:in `rescue in load_missing_constant': uninitialized constant Mocha::Standalone (NameError) from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:436:in `load_missing_constant' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:80:in `const_missing_with_dependencies' from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: 30:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: 29:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: 28:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: 27:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/test_case.rb:3:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.0/lib/ action_controller/integration.rb:3:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-rails-1.1.99.10/lib/ spec/rails.rb:11:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /Users/rick/spec230test/spec/spec_helper.rb:6:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /Users/rick/spec230test/spec/models/user_spec.rb:1:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:147:in `load_without_new_constant_marking' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:147:in `load_with_new_constant_marking' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/example_group_runner.rb:15:in `block in load_files' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/example_group_runner.rb:14:in `each' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/example_group_runner.rb:14:in `load_files' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/options.rb:87:in `run_examples' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner.rb:61:in `run' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner.rb:44:in `block in autorun' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require': no such file to load -- test/unit/testcase (MissingSourceFile) from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/test_case.rb:10:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.0/lib/ action_controller/integration.rb:3:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-rails-1.1.99.10/lib/ spec/rails.rb:11:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ active_support/dependencies.rb:158:in `require' from /Users/rick/spec230test/spec/spec_helper.rb:6:in `' from /Users/rick/spec230test/spec/models/user_spec.rb:1:in `require' from /Users/rick/spec230test/spec/models/user_spec.rb:1:in `' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/example_group_runner.rb:15:in `load' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/example_group_runner.rb:15:in `block in load_files' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/example_group_runner.rb:14:in `each' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/example_group_runner.rb:14:in `load_files' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/options.rb:87:in `run_examples' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ runner/command_line.rb:9:in `run' from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/bin/spec: 4:in `
' rake aborted! Command /opt/local/bin/ruby -I"/opt/local/lib/ruby/gems/1.9.1/gems/ rspec-1.1.99.10/lib" "/opt/local/lib/ruby/gems/1.9.1/gems/ rspec-1.1.99.10/bin/spec" "spec/models/user_spec.rb" --options "/Users/ rick/spec230test/spec/spec.opts" failed /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/rake/ spectask.rb:174:in `block (2 levels) in define' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1090:in `verbose' /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/rake/ spectask.rb:150:in `block in define' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:617:in `call' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:617:in `block in execute' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:612:in `each' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:612:in `execute' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:578:in `block in invoke_with_call_chain' /opt/local/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:564:in `invoke' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1997:in `block (2 levels) in top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1997:in `each' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1997:in `block in top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1970:in `block in run' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1967:in `run' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/bin/rake:31:in `' /opt/local/bin/rake:19:in `load' /opt/local/bin/rake:19:in `
' Compilation exited abnormally with code 1 at Wed Mar 4 11:07:37 Just by way of sanity check, in a directory that contained both user_spec.rb and user.rb from above, I ran "spec user_spec.rb" and got the same result. Any thoughts on what I should try next? BTW, the same sequence of steps run in a Ruby1.8.7/Rails2.2.2 environment works fine of course. thanks in advance, Rick From vora.manasi at gmail.com Thu Mar 5 07:49:38 2009 From: vora.manasi at gmail.com (Manasi v) Date: Thu, 5 Mar 2009 04:49:38 -0800 (PST) Subject: [rspec-users] Cucumber + Webrat + Selenium + ActionMailer In-Reply-To: <54bf7268cc8b3140727473d005e4bd29@ruby-forum.com> References: <3aa9e123e627fd97b4d75bd5c2ca0fc4@ruby-forum.com> <499C693D.9090006@benmabey.com> <1fb4df0902181515y6d95221bw87c4706f3987f0ce@mail.gmail.com> <499C9955.8080804@benmabey.com> <1fb4df0902182021m497b243ap95b76303d7842a04@mail.gmail.com> <499CEA87.5000804@benmabey.com> <1fb4df0902182144i4d3f655eh3cf7befa27a905a5@mail.gmail.com> <9fa97fb652c4210d767e16757a4610e5@ruby-forum.com> <54bf7268cc8b3140727473d005e4bd29@ruby-forum.com> Message-ID: <22350981.post@talk.nabble.com> > Yeap everything worked like a charm, once again checking email contents > like there is no tomorrow ;-) > > Rai > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > Hi Rai, Good that you have found a solution.. but I still don't understand why you want to test sending mails from the browser. In my project, we use Cucumber + Webrat for writing functional features. and Cucumber + selenium for acceptance features. Functional tests can enable ruby code and test for the number of mails sent and to whom, etc Acdeptance only tests what the user would see.. Let me know if it makes sense.. and it would be great if you could elaborate on your purpose of testing mails from the browser... Thanks, Manasi -- View this message in context: http://www.nabble.com/Cucumber-%2B-Webrat-%2B-Selenium-%2B-ActionMailer-tp22086863p22350981.html Sent from the rspec-users mailing list archive at Nabble.com. From MAwiniarski at gmail.com Wed Mar 4 04:55:25 2009 From: MAwiniarski at gmail.com (MAwiniarski) Date: Wed, 4 Mar 2009 01:55:25 -0800 (PST) Subject: [rspec-users] be_valid (validates_format_of ..., :on => :create) In-Reply-To: <57c63afe0903020838g4013ac5u91637f525f046158@mail.gmail.com> References: <38f994ca-7da0-43cc-a013-34e51a5cca7e@j8g2000yql.googlegroups.com> <6F193A20-D635-44D0-BB30-11F8341D12AA@gmail.com> <57c63afe0903020750g5936966cg85cf715a5d8c980a@mail.gmail.com> <937E5EFE-C47A-433F-AD35-A76889F35434@gmail.com> <57c63afe0903020838g4013ac5u91637f525f046158@mail.gmail.com> Message-ID: > FWIW, the OP's code says :on => :create. I also happened to seehttp://mawiniarski.wordpress.com/2009/02/28/rspec-validation-on-create/, > which reinforced for me that this is about validating on create, not > general validation. I've figured that out after starting a topic. From MAwiniarski at gmail.com Thu Mar 5 08:40:14 2009 From: MAwiniarski at gmail.com (MAwiniarski) Date: Thu, 5 Mar 2009 05:40:14 -0800 (PST) Subject: [rspec-users] have_tag + quantity - question Message-ID: <44088ce1-2ad9-4fd9-a996-9d9ab6977752@w34g2000yqm.googlegroups.com> Greetings, Is there a way to check quantity of tags? Something like this: response.should have_tag('div').quantity(4) Thanks. From kyleoba at gmail.com Thu Mar 5 17:02:20 2009 From: kyleoba at gmail.com (mudphone) Date: Thu, 5 Mar 2009 14:02:20 -0800 (PST) Subject: [rspec-users] Trouble with (Rails) Nested Model Directories Message-ID: <0285e7e0-a22e-4a42-b328-0c2677c4d8f6@d36g2000prf.googlegroups.com> Hi folks, In order to bring some order to the many model classes that I have under /app/models, I'm created a new directory (for example): /app/models/nestdir I've added the required configuration line in environment.rb: config.load_paths += %W( #{RAILS_ROOT}/app/models/nestdir ) But, when I run my specs, I get an error such as: ... dependencies.rb:428:in `load_missing_constant': Expected RAILS_ROOT/ app/models/nestdir/my_model.rb to define Nestdir::MyModel (LoadError) ... >From my understanding, the models in the dir listed in config.load_paths should be available in the root Rails namespace. Is this not how rspec handles things? Is there a standard way of setting up specs for nested model directories? The models are not nested within a parent module (like Nestdir, which would have matched the directory name). Thanks, Kyle From dchelimsky at gmail.com Fri Mar 6 03:52:53 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Mar 2009 02:52:53 -0600 Subject: [rspec-users] Trouble with (Rails) Nested Model Directories In-Reply-To: <0285e7e0-a22e-4a42-b328-0c2677c4d8f6@d36g2000prf.googlegroups.com> References: <0285e7e0-a22e-4a42-b328-0c2677c4d8f6@d36g2000prf.googlegroups.com> Message-ID: <57c63afe0903060052s25e94de4n4ac768c77518f8e@mail.gmail.com> On Thu, Mar 5, 2009 at 4:02 PM, mudphone wrote: > Hi folks, > > In order to bring some order to the many model classes that I have > under /app/models, I'm created a new directory (for example): > /app/models/nestdir > > I've added the required configuration line in environment.rb: > ?config.load_paths += %W( #{RAILS_ROOT}/app/models/nestdir ) > > But, when I run my specs, I get an error such as: > ... > dependencies.rb:428:in `load_missing_constant': Expected RAILS_ROOT/ > app/models/nestdir/my_model.rb to define Nestdir::MyModel (LoadError) > ... > > >From my understanding, the models in the dir listed in > config.load_paths should be available in the root Rails namespace. ?Is > this not how rspec handles things? > > Is there a standard way of setting up specs for nested model > directories? ?The models are not nested within a parent module (like > Nestdir, which would have matched the directory name). I just created a fresh rails-2.3.0 app w/ the latest rspec (built from git - 1.1.99.11) and not only was able to include a nested model, I was able to run the specs under each of the following conditions: * neither spec nor model are namespaced describe User do end class User < ActiveRecord::Base end * model and spec are both namespaced module Admin describe User do end end module Admin class User < ActiveRecord::Base end end * config is modifed per your example above * config is NOT modifed per your example above What versions of rspec and rails are you using? > > Thanks, > Kyle > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Fri Mar 6 03:55:33 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Mar 2009 02:55:33 -0600 Subject: [rspec-users] have_tag + quantity - question In-Reply-To: <44088ce1-2ad9-4fd9-a996-9d9ab6977752@w34g2000yqm.googlegroups.com> References: <44088ce1-2ad9-4fd9-a996-9d9ab6977752@w34g2000yqm.googlegroups.com> Message-ID: <57c63afe0903060055v260fd1behb8dbf81e84278b19@mail.gmail.com> On Thu, Mar 5, 2009 at 7:40 AM, MAwiniarski wrote: > Greetings, > > Is there a way to check quantity of tags? > > Something like this: > > response.should have_tag('div').quantity(4) response.should have_tag('div', 4) Check the assert_select docs (have_tag wraps it) at http://api.rubyonrails.org/classes/ActionController/Assertions/SelectorAssertions.html#M000547 Cheers, David > > Thanks. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Fri Mar 6 04:52:45 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Mar 2009 03:52:45 -0600 Subject: [rspec-users] rspec 1.1.99.10 rails 2.3 - help needed In-Reply-To: <4839770d-d479-4ac3-8b9e-2a83355efe29@v5g2000prm.googlegroups.com> References: <4839770d-d479-4ac3-8b9e-2a83355efe29@v5g2000prm.googlegroups.com> Message-ID: <57c63afe0903060152v67b90319oeff1d78e83e27536@mail.gmail.com> On Wed, Mar 4, 2009 at 3:14 PM, Rick wrote: > I checked first and found no conversation that matched my problem so > here it is: > > I'm trying to get rspec going on ruby 1.9.1 / rails 2.3.0 - here's my > current gem list: rspec-rails does not yet work with Ruby 1.9.1 - this is one item on a rather long list. As of the latest code in git, there are no errors or failures, but there is simply no feedback whatsoever. Patches welcome! > > *** LOCAL GEMS *** > > actionmailer (2.3.0) > actionpack (2.3.0) > activerecord (2.3.0) > activeresource (2.3.0) > activesupport (2.3.0) > columnize (0.3.0) > cucumber (0.1.16) > daemons (1.0.10) > diff-lcs (1.1.2) > eventmachine (0.12.4) > git (1.0.5) > hoe (1.9.0) > mocha (0.9.5) > mysql (2.8.1) > pg (0.7.9.2009.02.26) > polyglot (0.2.5) > rack (0.9.1) > rails (2.3.0) > rake (0.8.3) > rspec (1.1.99.10) > rspec-rails (1.1.99.10) > rubyforge (1.0.3) > rubyist-aasm (2.0.5) > sqlite3-ruby (1.2.4) > term-ansicolor (1.0.3) > thin (1.0.0) > treetop (1.2.4) > > As you can see, I followed David's instructions re rspec and rspec- > rails for rails 2.3.0. ?Just by way of test, I did the following: > > 1) rails spec230test > 2) cd spec230test > 3) script/generate rspec > 4) script/generate rspec_model User name:string email:string > 5) rake db:migrate > 6) rake spec:models --trace > > and here's what I get for results: > > rake spec:models --trace > (in /Users/rick/spec230test) > ** Invoke spec:models (first_time) > ** Invoke db:test:prepare (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:test:prepare > ** Invoke db:test:load (first_time) > ** Invoke db:test:purge (first_time) > ** Invoke environment > ** Execute db:test:purge > ** Execute db:test:load > ** Invoke db:schema:load (first_time) > ** Invoke environment > ** Execute db:schema:load > ** Execute spec:models > /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/test_case.rb:6: warning: already initialized constant > Mocha > /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:440:in `rescue in > load_missing_constant': uninitialized constant Mocha::Standalone > (NameError) > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:436:in `load_missing_constant' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:80:in `const_missing_with_dependencies' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: > 30:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: > 29:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: > 28:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.5/lib/mocha.rb: > 27:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/test_case.rb:3:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.0/lib/ > action_controller/integration.rb:3:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-rails-1.1.99.10/lib/ > spec/rails.rb:11:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /Users/rick/spec230test/spec/spec_helper.rb:6:in `>' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /Users/rick/spec230test/spec/models/user_spec.rb:1:in ` (required)>' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:147:in > `load_without_new_constant_marking' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:147:in `load_with_new_constant_marking' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/example_group_runner.rb:15:in `block in load_files' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/example_group_runner.rb:14:in `each' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/example_group_runner.rb:14:in `load_files' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/options.rb:87:in `run_examples' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner.rb:61:in `run' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner.rb:44:in `block in autorun' > /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require': no such file to load > -- test/unit/testcase (MissingSourceFile) > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/test_case.rb:10:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.0/lib/ > action_controller/integration.rb:3:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-rails-1.1.99.10/lib/ > spec/rails.rb:11:in `' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.0/lib/ > active_support/dependencies.rb:158:in `require' > ? ? ? ?from /Users/rick/spec230test/spec/spec_helper.rb:6:in `>' > ? ? ? ?from /Users/rick/spec230test/spec/models/user_spec.rb:1:in `require' > ? ? ? ?from /Users/rick/spec230test/spec/models/user_spec.rb:1:in ` (required)>' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/example_group_runner.rb:15:in `load' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/example_group_runner.rb:15:in `block in load_files' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/example_group_runner.rb:14:in `each' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/example_group_runner.rb:14:in `load_files' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/options.rb:87:in `run_examples' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/ > runner/command_line.rb:9:in `run' > ? ? ? ?from /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/bin/spec: > 4:in `
' > rake aborted! > Command /opt/local/bin/ruby -I"/opt/local/lib/ruby/gems/1.9.1/gems/ > rspec-1.1.99.10/lib" ?"/opt/local/lib/ruby/gems/1.9.1/gems/ > rspec-1.1.99.10/bin/spec" "spec/models/user_spec.rb" --options "/Users/ > rick/spec230test/spec/spec.opts" failed > /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/rake/ > spectask.rb:174:in `block (2 levels) in define' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1090:in > `verbose' > /opt/local/lib/ruby/gems/1.9.1/gems/rspec-1.1.99.10/lib/spec/rake/ > spectask.rb:150:in `block in define' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:617:in > `call' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:617:in > `block in execute' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:612:in > `each' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:612:in > `execute' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:578:in > `block in invoke_with_call_chain' > /opt/local/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:571:in > `invoke_with_call_chain' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:564:in > `invoke' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:2019:in > `invoke_task' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1997:in > `block (2 levels) in top_level' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1997:in > `each' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1997:in > `block in top_level' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:2036:in > `standard_exception_handling' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1991:in > `top_level' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1970:in > `block in run' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:2036:in > `standard_exception_handling' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/lib/rake.rb:1967:in > `run' > /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.3/bin/rake:31:in ` (required)>' > /opt/local/bin/rake:19:in `load' > /opt/local/bin/rake:19:in `
' > > Compilation exited abnormally with code 1 at Wed Mar ?4 11:07:37 > > Just by way of sanity check, in a directory that contained both > user_spec.rb and user.rb from above, I ran "spec user_spec.rb" and got > the same result. > > Any thoughts on what I should try next? ?BTW, the same sequence of > steps run in a Ruby1.8.7/Rails2.2.2 environment works fine of course. > > thanks in advance, > Rick > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Fri Mar 6 05:59:15 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Mar 2009 04:59:15 -0600 Subject: [rspec-users] Help make rspec-1.2 a smooth upgrade Message-ID: <57c63afe0903060259g33679ae6odd05ee14e670fe67@mail.gmail.com> Hi all, I'm planning to release rspec-1.2 and rspec-rails-1.2 shortly after rails-2.3 goes final (rails-2.3.1 was just released as RC2). There are a couple of loose ends right now, and I need your help in two important areas. I've curtailed releasing github gems, so please clone, build and install the latest [1] if you wish to help out. == Testing the release As rails' internals have changed and rspec-rails has kept up with those changes, I've also been taking the opportunity to clean up much of rspec-rails' internals (along with those of rspec core). While the public API has remain *mostly* unchanged [2], the changes to the internals present some risk for any extension libraries or any of your own customizations that monkey patch internals. To this end, it would be very helpful if you would run your rails apps with the latest rspec/rspec-rails code, and let me know (via reports to http://rspec.lighthouseapp.com) if you run into any problems. == Ruby 1.9 RSpec core's specs are all running against ruby 1.9 now. Not so much with rspec-rails. With rails-2.3.1 (RC2), rspec/rspec-rails-1.1.99.12 [1] and ruby-1.9.1, there is zero feedback. No failures. No errors. Just nothing. It would be most appreciated by many if the bold among you could help to resolve this issue and get rspec-rails working with ruby-1.9.1. Thanks in advance for your assistance. Cheers, David [1] rspec and rspec-rails > 1.1.99.9 require that you clone the github repo and build/install locally. Instructions: http://wiki.github.com/dchelimsky/rspec/releases-and-gems [2] There is some rspec-rails code that needlessly duplicates functionality already available in rails' testing framework. To reduce the maintenance burden, as changes to rails cause problems with rspec-rails, I've been looking for opportunities to access rails via public APIs rather than internals. In some cases, this resulted in changes to rspec-rails. I've documented what I know in Upgrade.markdown in the root of the rspec-rails source. From lists at ruby-forum.com Fri Mar 6 06:23:19 2009 From: lists at ruby-forum.com (Raimond Garcia) Date: Fri, 6 Mar 2009 12:23:19 +0100 Subject: [rspec-users] Cucumber + Webrat + Selenium + ActionMailer In-Reply-To: <22350981.post@talk.nabble.com> References: <3aa9e123e627fd97b4d75bd5c2ca0fc4@ruby-forum.com> <499C693D.9090006@benmabey.com> <1fb4df0902181515y6d95221bw87c4706f3987f0ce@mail.gmail.com> <499C9955.8080804@benmabey.com> <1fb4df0902182021m497b243ap95b76303d7842a04@mail.gmail.com> <499CEA87.5000804@benmabey.com> <1fb4df0902182144i4d3f655eh3cf7befa27a905a5@mail.gmail.com> <9fa97fb652c4210d767e16757a4610e5@ruby-forum.com> <54bf7268cc8b3140727473d005e4bd29@ruby-forum.com> <22350981.post@talk.nabble.com> Message-ID: Manasi Vora wrote: >> >> > > > Hi Rai, > > Good that you have found a solution.. > > but I still don't understand why you want to test sending mails from the > browser. In my project, we use Cucumber + Webrat for writing functional > features. > and Cucumber + selenium for acceptance features. > > Functional tests can enable ruby code and test for the number of mails > sent > and to whom, etc > Acdeptance only tests what the user would see.. > > Let me know if it makes sense.. and it would be great if you could > elaborate > on your purpose of testing mails from the browser... > > Thanks, > Manasi Hi Manasi, We have a bit of both, sometimes we can test email sending with Cucumber + Webrat, but in this particular case, the feature that sent out emails also used Javascript. We could have split the feature in two, one to test the Javascript with a Selenium feature and one to test the emails with a Webrat feature, but IMHO adding a couple of steps to the selenium feature to check for emails, is a good choice to help to clearly see the whole intent of the feature. Rai -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Mar 6 07:27:42 2009 From: lists at ruby-forum.com (Tom Ten thij) Date: Fri, 6 Mar 2009 13:27:42 +0100 Subject: [rspec-users] Cucumber 0.2 final release date? In-Reply-To: <8d961d900902230636te143bc6o92ca13f709688ee9@mail.gmail.com> References: <7ac2300c0902190749x3d659b40w7cc84e5a6f8aedea@mail.gmail.com> <8d961d900902230636te143bc6o92ca13f709688ee9@mail.gmail.com> Message-ID: <3202c5a31a4c97a8dcc16b22d901ef18@ruby-forum.com> > I'm afraid I can't give a release date. 0.2 is fixed(ish) scope, and > therefore time can't be fixed at the same time. I have a lot of travel > the next month, so it will take a least a month I'm afraid. I know I for one would sure like to see 0.2 come out soon. The scope of the two 0.2 tickets in lighthouse seem a bit big. Are there any tasks that I could assist on? Tom. -- Posted via http://www.ruby-forum.com/. From mark at mwilden.com Fri Mar 6 10:03:03 2009 From: mark at mwilden.com (Mark Wilden) Date: Fri, 6 Mar 2009 07:03:03 -0800 Subject: [rspec-users] have_tag + quantity - question In-Reply-To: <44088ce1-2ad9-4fd9-a996-9d9ab6977752@w34g2000yqm.googlegroups.com> References: <44088ce1-2ad9-4fd9-a996-9d9ab6977752@w34g2000yqm.googlegroups.com> Message-ID: <3c30da400903060703o3911ddb9n95c6f560f594f588@mail.gmail.com> On Thu, Mar 5, 2009 at 5:40 AM, MAwiniarski wrote: > Greetings, > > Is there a way to check quantity of tags? > > Something like this: > > response.should have_tag('div').quantity(4) Another great resource is http://labnotes.org/svn/public/ruby/rails_plugins/assert_select/cheat/assert_select.html ///ark From stevemolitor at gmail.com Fri Mar 6 11:23:52 2009 From: stevemolitor at gmail.com (Steve Molitor) Date: Fri, 6 Mar 2009 10:23:52 -0600 Subject: [rspec-users] Webrat - Fill in text field by id Message-ID: <3e21ad60903060823t901c6f5jad329fd5acc6e278@mail.gmail.com> Is there a way to locate and 'fill in' a text field (or check a check box, select an option, etc.) by id? It seems that the fill_in method takes either the text of the label pointing to the field or the field name. The are cases when writing cucumber steps when using the HTML id of the input element would be easier, especially when a page has multiple forms with the same labels and input names. Thanks, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From zach.dennis at gmail.com Fri Mar 6 11:24:35 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Fri, 6 Mar 2009 11:24:35 -0500 Subject: [rspec-users] Can I construct the controller myself in a controller spec? In-Reply-To: <745A0F9E-D5FA-42C7-A0E0-6E7D9677BD8B@mattwynne.net> References: <1c319b810903042038g19ee5248m4de5e644fce7e9a1@mail.gmail.com> <57c63afe0903042202r4cb79dc1h9697cb67889f216d@mail.gmail.com> <011E39CE-1EF6-4E7E-A215-0995FC1A28A8@mattwynne.net> <57c63afe0903050626w1e9c4401k5d004729b7092fec@mail.gmail.com> <49AFEEAB.5020602@benmabey.com> <745A0F9E-D5FA-42C7-A0E0-6E7D9677BD8B@mattwynne.net> Message-ID: <85d99afe0903060824q2e8d409fh916ae1e6ce6d7471@mail.gmail.com> On Fri, Mar 6, 2009 at 3:05 AM, Matt Wynne wrote: > > On 5 Mar 2009, at 15:24, Ben Mabey wrote: > >> David Chelimsky wrote: >>> >>> On Thu, Mar 5, 2009 at 3:31 AM, Matt Wynne wrote: >>> Maybe we should make this easier by providing some facility in the >>> mock framework to express the following in one statement: >>> >>> @authenticator = stub('authenticator') >>> Authenticator.stub!(:new).and_return(@authenticator) >>> >>> Sure, you could make that a one liner: >>> >>> Authenticator.stub!(:new).and_return(@authenticator = >>> stub('authenticator') >>> >>> But I mean something like: >>> >>> @authenticator = Authenticator.stub! >>> >>> I don't think *that* is the answer - but something that concise would be >>> nice. >>> >>> Thoughts? >>> >>> David >>> >>> >> I like the conciseness, but it isn't very clear what it is doing IMO. >> ?Perhaps something a little more intention-revealing like: >> >> @authenticator = Authenticator.stub_new! > > I think I must mostly use constructor injection, as I don't really seem to > have a pattern for this, but if I did I guess it would be something like > this: > > ? ?extend StubbingHelpers > > ? ?describe "blah" > ? ? ?before(:each) do > ? ? ? ?@authenticator = mock_new_authenticator( :foo => bar ) > > which is implemented like > > ? ?def stub_new_authenticator( *args ) > ? ? ?result = mock(Authenticator, *args) > ? ? ?Authenticator.stub!(:new).and_return(result) > ? ? ?result > ? ?end > > I guess having something like that would be nice. This is how I do it, Zach > > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From hayafirst at gmail.com Fri Mar 6 11:55:36 2009 From: hayafirst at gmail.com (Yi) Date: Fri, 6 Mar 2009 10:55:36 -0600 Subject: [rspec-users] Webrat - Fill in text field by id In-Reply-To: <3e21ad60903060823t901c6f5jad329fd5acc6e278@mail.gmail.com> References: <3e21ad60903060823t901c6f5jad329fd5acc6e278@mail.gmail.com> Message-ID: It does take id. At least in the trunk webrat On Fri, Mar 6, 2009 at 10:23 AM, Steve Molitor wrote: > Is there a way to locate and 'fill in' a text field (or check a check box, > select an option, etc.) by id? It seems that the fill_in method takes > either the text of the label pointing to the field or the field name. The > are cases when writing cucumber steps when using the HTML id of the input > element would be easier, especially when a page has multiple forms with the > same labels and input names. > Thanks, > > Steve > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Fri Mar 6 12:03:48 2009 From: lists at ruby-forum.com (James Byrne) Date: Fri, 6 Mar 2009 18:03:48 +0100 Subject: [rspec-users] Webrat - Fill in text field by id In-Reply-To: <3e21ad60903060823t901c6f5jad329fd5acc6e278@mail.gmail.com> References: <3e21ad60903060823t901c6f5jad329fd5acc6e278@mail.gmail.com> Message-ID: Steve Molitor wrote: > Is there a way to locate and 'fill in' a text field (or check a check > box, > select an option, etc.) by id? It seems that the fill_in method takes > either the text of the label pointing to the field or the field name. > The > are cases when writing cucumber steps when using the HTML id of the > input > element would be easier, especially when a page has multiple forms with > the > same labels and input names. > Thanks, > > Steve Yes, just provide the text of the id selector, do not add anything else. So, for an id="test_this_id" on a button you can write in your test/definition: click_button("test-this_id") -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Mar 6 12:04:23 2009 From: lists at ruby-forum.com (James Byrne) Date: Fri, 6 Mar 2009 18:04:23 +0100 Subject: [rspec-users] Webrat - Fill in text field by id In-Reply-To: References: <3e21ad60903060823t901c6f5jad329fd5acc6e278@mail.gmail.com> Message-ID: James Byrne wrote: S/B > > click_button("test_this_id") -- Posted via http://www.ruby-forum.com/. From stevemolitor at gmail.com Fri Mar 6 14:22:06 2009 From: stevemolitor at gmail.com (Steve Molitor) Date: Fri, 6 Mar 2009 13:22:06 -0600 Subject: [rspec-users] Webrat - Fill in text field by id In-Reply-To: References: <3e21ad60903060823t901c6f5jad329fd5acc6e278@mail.gmail.com> Message-ID: <3e21ad60903061122k1dcf85b4q3feef247a70555a8@mail.gmail.com> Well I'm reading the 0.4.2 webrat rdoc for fill_in, at it says: "field can be either the value of a name attribute (i.e. user[email]) or the text inside a