' >> [...] >> So load is trying to load autotest the directory instead of autotest the >> script. >> Any ideas on how to get it to load the right thing? > >I'm not sure how to fix that problem, but before you go much further >you should know that RSpec does not yet run under 1.9. [...] I just ran across this (rspec 1.1.99.7, zentest 3.11.1, ruby 1.9.1-p0) and thought i'd follow up. It appears this is related to rubygems being loaded automatically in ruby 1.9... Cucumber (and rspec for that matter) contains an 'autotest' directory under /lib and it appears earlier in the load path than the ZenTest directories. As evidence, running the following gets past the error: $ ruby --disable-gems `which autotest` Of course that would then necessitate activating needed gems manually, which seems to be counter-productive if 1.9 is encouraging the opposite approach. It's not clear to me that this is a rspec or zentest bug - it might just as easily be a rubygems or ruby deficiency (couldn't 'load' just ignore directories?). Unfortunately i'm not experienced enough with any of these libraries to know where to take this next. If anyone would point me in a direction, i'd be happy to keep digging. In the meantime, here's a hack to $RUBY_HOME/bin/autotest (the one generated by rubygems): @@ -19 +19,2 @@ -load 'autotest' +zentest_gem_dir = Gem.source_index.find_name('ZenTest', version).first.full_gem_path +load File.join(zentest_gem_dir, 'bin', 'autotest') That is very likely the _wrong_ way to calculate zentest_gem_dir... I googled and poked around but couldn't find any definitive API. Any enlightenment on that would also be appreciated. Cheers, lasitha -- View this message in context: http://www.nabble.com/Ruby-1.9---autospec-loadpath-problem-tp20763177p22102148.html Sent from the rspec-users mailing list archive at Nabble.com. From lists at ruby-forum.com Thu Feb 19 09:54:59 2009 From: lists at ruby-forum.com (Raimond Garcia) Date: Thu, 19 Feb 2009 15:54:59 +0100 Subject: [rspec-users] Cucumber + Webrat + Selenium + ActionMailer In-Reply-To: <9fa97fb652c4210d767e16757a4610e5@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> Message-ID: <54bf7268cc8b3140727473d005e4bd29@ruby-forum.com> >1. >http://seattlerb.rubyforge.org/ar_mailer/classes/ActionMailer/ARMailer.html > P.S. I'll follow up with a confirmation post just to let the people know > how it worked out for us with ARMailer. Yeap everything worked like a charm, once again checking email contents like there is no tomorrow ;-) Rai -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Thu Feb 19 09:55:13 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Feb 2009 08:55:13 -0600 Subject: [rspec-users] validate_presence_of In-Reply-To: <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <01C973AD-FF8D-468A-A494-F10285758C40@goldweb.com.au> <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> Message-ID: <57c63afe0902190655y66b388cbs9e109da6b738defd@mail.gmail.com> On Wed, Feb 18, 2009 at 11:40 PM, Stephen Eley wrote: > If your spec breaks because you changed a method call, you're not > testing behavior any more. You're testing syntax. We've got to stop making laws out of guidelines. This is a very general statement about what is really a very specific situation, and it is not in any way as black and white as this statement sounds. But *somebody* is going to read this, not understand the context, and think it's international law. Code examples are clients of the subject code, just like any other clients that are part of the subject code. You don't expect all of the other objects in your app to work correctly when you change a method name in only one place, do you? You need to change all the clients, including the code examples. In Chicago we don't have any j-walking laws (at least that I know of - I've yet to be arrested for it). The guideline we operate under is that you should wait for the light, but we don't always follow that guideline. When I'm at an intersection and don't have the light, I look both ways, like I learned back in kindergarten, and cross if its safe. If there are no cars coming, I'm very likely to survive the incident. If there are cars coming, I can still navigate my way across the street and, if I do so carefully, correctly, and with precise timing, I might well survive. Guidelines are great tools, but if we followed guidelines like laws we'd never get where we're going. FWIW, David From mr.gaffo at gmail.com Thu Feb 19 10:00:46 2009 From: mr.gaffo at gmail.com (Mike Gaffney) Date: Thu, 19 Feb 2009 09:00:46 -0600 Subject: [rspec-users] validate_presence_of In-Reply-To: <57c63afe0902182158w4a6cd740n9608b28819fdaabc@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <3c30da400902181942u195c2628uc1271630f4c929b3@mail.gmail.com> <1fb4df0902182131r1ec87c23hf503548ac877d595@mail.gmail.com> <57c63afe0902182158w4a6cd740n9608b28819fdaabc@mail.gmail.com> Message-ID: <499D741E.4050908@gmail.com> Dave, you make a good point. In our system, where we are converting a legacy database/application, we typically have no user stories and have the technical (or you could argue user) requirement that the database logic / constraints get converted. This is where we are typically just encoding all of the should_have_many, etcs. They at a first glance do seem like fragile and redundant tests but when you consider that the schema isn't in rails standard format, simple has_manys are not always going to work so we actually need to test our configuration of the associations. -Mike David Chelimsky wrote: > On Wed, Feb 18, 2009 at 11:31 PM, Stephen Eley wrote: > >> On Wed, Feb 18, 2009 at 10:42 PM, Mark Wilden wrote: >> >>> On Wed, Feb 18, 2009 at 4:39 PM, Fernando Perez wrote: >>> >>>> What's the point in testing validates_presence_of for a model? >>>> >>> To make sure you wrote that line of code. >>> >> And the circle spins round and round... >> >> Specs that mirror the code that closely are a bad idea, I think. The >> problem with that example is that the syntax of the code is driving >> the syntax of the spec, even if the spec was written first. You're no >> longer thinking about high-level behavior, you're thinking about the >> presence of a certain line in Rails. >> >> I write those sorts of model specs a little differently. I just poke >> at things and set expectations on whether they break. I'd write this >> example like: >> >> describe User do >> before(:each) do >> @this = User.make_unsaved # I use machinist for my factory methods >> end >> >> it "is valid" do >> @this.should be_valid >> end >> >> it "can save" do >> @this.save.should be_true >> end >> >> it "requires a login" do >> @this.login = nil >> @this.should_not be_valid >> end >> >> it "may have a password reminder" do >> @this.password_reminder = nil >> @this.should be_valid >> end >> >> it "does not allow duplicate logins" do >> @that = User.make(:login => "EvilTwin") >> @this.login = "EvilTwin" >> @this.should_not be_valid >> end >> end >> >> ...And so forth. It's wordier, but very readable, and it doesn't rely >> on the validation being done with a specific Rails method. In fact, >> when I shifted to using Merb and Datamapper, I didn't have to change >> these sorts of tests at all. >> > > That's huge! > > >> Also, while I used to be very anal and write "should >> have(1).error_on(:login)" and such, I eventually realized that there's >> no point. Checking on 'valid?' is entire and sufficient. The first >> example proves that the default factory case is valid, so as long as >> we're only changing one thing at a time, we know that that's the thing >> that breaks validity. (Or, in the case of "may have," *doesn't* break >> validity.) >> > > I think this depends on whether or not error messages are part of the > conversation w/ the customer. If not, that seems fine. > > I find that I'll spec validations directly, but not associations. > There's no need to say that a team has_many players when you have > examples like team.should have(9).players_on_the_field. > > But my validation specs do tend to be closely tied to AR methods like > valid?(), which, as your example suggests, is impeding my ability to > choose a different ORM lib. Time for some re-thinking! > > Cheers, > David > > >> -- >> Have Fun, >> Steve Eley (sfeley at gmail.com) >> ESCAPE POD - The Science Fiction Podcast Magazine >> http://www.escapepod.org >> _______________________________________________ >> 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 > -- -Mike Gaffney (http://rdocul.us) From zach.dennis at gmail.com Thu Feb 19 10:05:42 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 19 Feb 2009 10:05:42 -0500 Subject: [rspec-users] validate_presence_of In-Reply-To: <1fb4df0902182131r1ec87c23hf503548ac877d595@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <3c30da400902181942u195c2628uc1271630f4c929b3@mail.gmail.com> <1fb4df0902182131r1ec87c23hf503548ac877d595@mail.gmail.com> Message-ID: <85d99afe0902190705o4904d696q1ae544c47d425ae0@mail.gmail.com> On Thu, Feb 19, 2009 at 12:31 AM, Stephen Eley wrote: > On Wed, Feb 18, 2009 at 10:42 PM, Mark Wilden wrote: >> On Wed, Feb 18, 2009 at 4:39 PM, Fernando Perez wrote: >>> >>> What's the point in testing validates_presence_of for a model? >> >> To make sure you wrote that line of code. > > And the circle spins round and round... > > Specs that mirror the code that closely are a bad idea, I think. The > problem with that example is that the syntax of the code is driving > the syntax of the spec, even if the spec was written first. You're no > longer thinking about high-level behavior, you're thinking about the > presence of a certain line in Rails. A highly expressive declarative phrase has been pushed down to nothing more than "a certain line". :) While I agree with you in general, I think the wrong approach is to immediately disallow ourselves from using words or phrases that are found in the implementation in the specs. Yes, validates_presence_of can be used in the implementation, but it also serves as great, readable, behaviour expressing documentation. I'm not going to fault anyone or any spec where it is used, since the phrase itself is highly communicative. I'd be more concerned with its implementation rather than the fact that someone found it as a clear way to write attribute requiring examples. > > I write those sorts of model specs a little differently. I just poke > at things and set expectations on whether they break. I'd write this > example like: > > describe User do > before(:each) do > @this = User.make_unsaved # I use machinist for my factory methods > end > > it "is valid" do > @this.should be_valid > end > > it "can save" do > @this.save.should be_true > end > > it "requires a login" do > @this.login = nil > @this.should_not be_valid > end > > it "may have a password reminder" do > @this.password_reminder = nil > @this.should be_valid > end > > it "does not allow duplicate logins" do > @that = User.make(:login => "EvilTwin") > @this.login = "EvilTwin" > @this.should_not be_valid > end > end > > ...And so forth. It's wordier, but very readable, and it doesn't rely > on the validation being done with a specific Rails method. In fact, > when I shifted to using Merb and Datamapper, I didn't have to change > these sorts of tests at all. > > Also, while I used to be very anal and write "should > have(1).error_on(:login)" and such, I eventually realized that there's > no point. Checking on 'valid?' is entire and sufficient. The first > example proves that the default factory case is valid, so as long as > we're only changing one thing at a time, we know that that's the thing > that breaks validity. (Or, in the case of "may have," *doesn't* break > validity.) I like the idea of having "may have" examples for optional attributes. > > -- > Have Fun, > Steve Eley (sfeley at gmail.com) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org > _______________________________________________ > 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 Thu Feb 19 10:41:26 2009 From: hayafirst at gmail.com (Yi Wen) Date: Thu, 19 Feb 2009 09:41:26 -0600 Subject: [rspec-users] validate_presence_of In-Reply-To: <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <01C973AD-FF8D-468A-A494-F10285758C40@goldweb.com.au> <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> Message-ID: Good point, that's actually I am debating with myself everyday and haven't got a clear answer. This is classical "calssic unit tester" vs. mockist war. :) Talking about this case: 1. I haven't checked how should valite_presence_of is implemented, but it could pretty much be checking if the value is left blank. So it is behavior tests 2. I couldn't see any reason why I would want to write my own version of check_to_see_if_this_thingy_is_in_my_whatsis. So this is not a very realistic assumption. 3. By checking if validation fails when a value is left blank, I am actually kind of testing Rails and here's why: what if they introduce a bug in validates_presence_of that makes my test break? What if they have a bug in valid? to make my test break? To strictly just testing *my* own code, the test should be something like Person.should_receive(:validates_presence_of).with(:email) I am not really advocating the view of mockists. Just throw a question here. :) Yi On Wed, Feb 18, 2009 at 11:40 PM, Stephen Eley wrote: > On Wed, Feb 18, 2009 at 11:42 PM, Yi Wen wrote: > > > > Without this syntax sugar, we still have to test validates_presence_of to > > make sure it's there and won't broken, right? > > Wrong. You don't have to test validates_presence_of. What matters, > and therefore what you should test, is whether the model will complain > at you if a particular value is left empty. > > validates_presence_of happens to be the name of the method in > ActiveRecord that does that. But if you decide to write your own > check_to_see_if_this_thingy_is_in_my_whatsis() method that does the > same thing, a good *behavior* spec will not break. Because the > behavior remains the same. > > If your spec breaks because you changed a method call, you're not > testing behavior any more. You're testing syntax. > > > > -- > Have Fun, > Steve Eley (sfeley at gmail.com) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org > _______________________________________________ > 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 aidy.lewis at googlemail.com Thu Feb 19 10:49:25 2009 From: aidy.lewis at googlemail.com (aidy lewis) Date: Thu, 19 Feb 2009 15:49:25 +0000 Subject: [rspec-users] Cucumber 0.2 final release date? Message-ID: <7ac2300c0902190749x3d659b40w7cc84e5a6f8aedea@mail.gmail.com> Hi, I know this seems all take and no give, but do we have an estimated final release date for Cucumber 0.2? Thanks Aidy Celerity, Cucumber and Firewatir: http://skillsmatter.com/event/ruby-on-rails/lrug-march From dchelimsky at gmail.com Thu Feb 19 10:55:07 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Feb 2009 09:55:07 -0600 Subject: [rspec-users] validate_presence_of In-Reply-To: <1fb4df0902190620x57758b14k27fa84fcf5411fd2@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <3c30da400902181942u195c2628uc1271630f4c929b3@mail.gmail.com> <1fb4df0902182131r1ec87c23hf503548ac877d595@mail.gmail.com> <57c63afe0902182158w4a6cd740n9608b28819fdaabc@mail.gmail.com> <1fb4df0902190620x57758b14k27fa84fcf5411fd2@mail.gmail.com> Message-ID: <57c63afe0902190755t2ae78302p813565f9fb97c8eb@mail.gmail.com> On Thu, Feb 19, 2009 at 8:20 AM, Stephen Eley wrote: > On Thu, Feb 19, 2009 at 12:58 AM, David Chelimsky wrote: >> >>> Also, while I used to be very anal and write "should >>> have(1).error_on(:login)" and such, I eventually realized that there's >>> no point. Checking on 'valid?' is entire and sufficient. >> >> I think this depends on whether or not error messages are part of the >> conversation w/ the customer. If not, that seems fine. > > But "should have(1).error_on(:login)" isn't a test on error messages. > It's a test on a key called :login. The conversation with the > customer has no bearing on that; the customer's never asked about the > errors data structure. The code in the examples are for developers. The docstrings are for customers. In this very specific case, the matcher doesn't support the specific error message, but if it did, the example would be: describe User do context "with punctuation in the login" do it "raises an error saying Login can't have punctuation" do user = User.generate(:login => "my.login!name") model.should have(1).error_on(:login).with("can't have punctuation") end end end Even without that ability, this would be fairly expressive to both customer and developer: describe User do context "with punctuation in the login" do it "raises an error saying Login can't have punctuation" do user = User.generate(:login => "my.login!name") model.should have(1).error_on(:login) end end end > I do check for error messages making it to the user, but not in my > model specs. Those get checked in my request specs. (Or my Cucumber > features, whichever I'm doing that day.) So again, it's covered; just > not twice. This is where this all gets tricky. TDD (remember? that's where this all started) says you don't write any subject code without a failing *unit test*. This is not about the end result - it's about a process. What you're talking about here is the end result: post-code testing. If you're true to the process, then you'd have material in both places. The cost of this is something that looks like duplication, but it's not really, because at the high level we're specifying the behaviour of the system, and at the low level we're specifying the behaviour of a single object - fulfilling its role in that system. The cost of *not* doing this is different in rails than it is in home grown systems. In home grown systems, since we are in charge of defining what objects have what responsibilities, the cost of only spec'ing from 10k feet is more time tracking down bugs. In rails, this is somewhat mitigated by the conventions we've established of keeping types of behaviour (like error message generation) in commonly accepted locations. If a merb request spec or cucumber scenario fails on an error message, we can be pretty certain the source is a model object. But even that is subject to the level of complexity of the model. If a view is dealing with a complex object graph, then there are multiple potential sources for the failure, in which case there is some benefit to having things specified at the object level. >> But my validation specs do tend to be closely tied to AR methods like >> valid?(), which, as your example suggests, is impeding my ability to >> choose a different ORM lib. Time for some re-thinking! > > To be fair, the only reason the tests I quoted work when I switched to > Datamapper is because DM coincidentally (or not) uses the same > "valid?" method that AR does. Eventually you do have to hit your API. > I just like to hit it at the highest level that proves the behavior I > care about. Agreed in general. Just keep in mind that behaviour exists at more than one level. At the object level, behaviour == responsibility. If I'm a controller and my responsibility is to take a message from you, re-package it and hand it off to the appropriate model, then *that* is my behaviour. Cheers, David > -- > Have Fun, > Steve Eley (sfeley at gmail.com) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From zach.dennis at gmail.com Thu Feb 19 11:05:54 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 19 Feb 2009 11:05:54 -0500 Subject: [rspec-users] validate_presence_of In-Reply-To: References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <01C973AD-FF8D-468A-A494-F10285758C40@goldweb.com.au> <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> Message-ID: <85d99afe0902190805y3469dabfi2d029ce97f35e379@mail.gmail.com> On Thu, Feb 19, 2009 at 10:41 AM, Yi Wen wrote: > Good point, that's actually I am debating with myself everyday and haven't > got a clear answer. This is classical "calssic unit tester" vs. mockist war. > :) > > Talking about this case: > > 1. I haven't checked how should valite_presence_of is implemented, but it > could pretty much be checking if the value is left blank. So it is behavior > tests > > 2. I couldn't see any reason why I would want to write my own version of > check_to_see_if_this_thingy_is_in_my_whatsis. So this is not a very > realistic assumption. > > 3. By checking if validation fails when a value is left blank, I am actually > kind of testing Rails and here's why: what if they introduce a bug in > validates_presence_of that makes my test break? What if they have a bug in > valid? to make my test break? To strictly just testing *my* own code, the > test should be something like > Person.should_receive(:validates_presence_of).with(:email) > > I am not really advocating the view of mockists. Just throw a question here. This is a good example of strictly testing *your* code. But, to the last statement--it is not a very good example of when to use mock expectations. I don't think it advocates an accurate view of *mockists*. > :) > > Yi > > On Wed, Feb 18, 2009 at 11:40 PM, Stephen Eley wrote: >> >> On Wed, Feb 18, 2009 at 11:42 PM, Yi Wen wrote: >> > >> > Without this syntax sugar, we still have to test validates_presence_of >> > to >> > make sure it's there and won't broken, right? >> >> Wrong. You don't have to test validates_presence_of. What matters, >> and therefore what you should test, is whether the model will complain >> at you if a particular value is left empty. >> >> validates_presence_of happens to be the name of the method in >> ActiveRecord that does that. But if you decide to write your own >> check_to_see_if_this_thingy_is_in_my_whatsis() method that does the >> same thing, a good *behavior* spec will not break. Because the >> behavior remains the same. >> >> If your spec breaks because you changed a method call, you're not >> testing behavior any more. You're testing syntax. >> >> >> >> -- >> Have Fun, >> Steve Eley (sfeley at gmail.com) >> ESCAPE POD - The Science Fiction Podcast Magazine >> http://www.escapepod.org >> _______________________________________________ >> 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 lenny at aps.org Thu Feb 19 11:09:04 2009 From: lenny at aps.org (Lenny Marks) Date: Thu, 19 Feb 2009 08:09:04 -0800 Subject: [rspec-users] [Cucumber] Level of features / Feature dependent steps In-Reply-To: References: <45453541-CD64-44FC-9585-0F857B81A43B@aps.org> <1126d7ae0902180512iac72f61la33abf27113f8244@mail.gmail.com> Message-ID: <723AF188-CA47-4266-8F13-2C514C2B8326@aps.org> Just wanted to thank everyone for their replies. I actually recall that thread now about imperative vs. declarative. I've just re-read Ben's post along with some of the linked content off the post and now and I feel a bit more comfortable with the direction I was going in. I personally tend to favor the declarative style. At least for my current projects, Cucumber/SDD seems most attractive as a tool that encourages us to write user stories so that we code the right stuff and then allows us to turn those stories into executable documentation that also tests the full stack sanity of our app. I can definitely see using more specifics in the steps to lessen the burden of writing so many customized steps, at least when they don't distract much from the goal of the story. Recently I was writing a feature for an application for sending very business logic connected correspondences. If I have a scenario that applies to all correspondences and I see a step such as "Given I am sending a 'CTA'" as opposed "Given I am sending a correspondence", then I think it's kind of distracting. One thing I came across in the http://goruco2008.confreaks.com/01_helmkamp.html screencast was the concept of using verbs in scenario titles(e.g. reject duplicate names). Up until now I think I had been taking my translation of 'scenario' a bit too literal and using the scenario titles only state what makes the scenario different and not what the expected behavior should be(e.g reject duplicates). I'm not sure what I think about it yet, but stating the expected behavior in the scenario title and using the steps to demonstrate it can potentially make things less ambiguous when specifics are plugged in. I guess that just sounds more like a feature(sub-feature) to me, but I the line seems pretty blurry and I think has more to do with feature size. I'm curious how others use scenario titles but that may be worth another thread. Anyway, I think the imperative style lends itself more to developers thinking from the testing perspective(does every field on my registration make it into the system) while the declarative style is better suited as customer facing stories. Very subjective stuff, but for us, I see a lot of value having the executable documentation(accurate and up to date) that gives reasonable assurance on sanity but also documents(without a lot of noise) what's in the app. What a developer/tester needs to click through and what they should expect to see, should that need to be done(after refactoring a bunch of javascript or stylesheets or whatever). -lenny On Feb 18, 2009, at 8:07 AM, Mischa Fierer wrote: > Ben has a good post on the declarative vs imperative styles here: > > http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/ > > I totally agree with Josh, and indeed wrote out my own version of > his login example before realizing I should probably read his post > before replying! > > I agree that each scenario should go into a good amount of detail > about what specifically being tested, rather than letting it be > hidden in a step. If other things have to happen in a scenario that > do not involve what is being specifically tested but must be > included for setup, then if it's DRYer it makes sense to make a more > abstract step. > > This also gives you a speed boost if done correctly, for example a > "given I am logged in as foo" step can just post to /session or w/ > e , rather than going to /login, filling in the form and pressing > the button and waiting. > > I'm not sure if I would go as far into the dsl as you are in the > second example, though, Lenny. Depending on whether or not you were > able to reuse those steps, as you say, you would over the course of > a few months end up with an entire level of scenario dependent steps. > > I might instead start by just using webrat / generic steps as long > as you can, and then taking a look at all your feature files and > deciding what you can dry up / what makes sense to move into a more > client specific dsl. > > Finally, having been doing cucumber for a while now, I've found that > i've been moving more towards the imperative style, simply because > it's faster to work with. > For example, if it were in the early stages of the app, I might even > do something like > > Scenario: I Pay a bill when I have enough $ > Given a checking account > And the checking account has "$50" > And a payee named "Acme" > And an "Acme" bill for "$37" > When I follow "bills to pay" > And I follow "Acme" > And I press "pay bill" > And I press "confirm" > Then I should see "payment success" > When I follow "account summary" > Then I should see "$13 remaining" > And I should see "you paid $37 to Acme" > > This is pretty ugly, but not out of the question imo. While it has > its downsides, one benefit is that it encourages a client to > actually think about how the site should work before you make it. > For example, they actually get to think about things like whether > there is a payment success page or not, rather than deciding that > there shouldn't be one after you've spent lots of time building it. > > wdyt? > > > > > On Wed, Feb 18, 2009 at 7:12 AM, Josh Chisholm > wrote: > I find that the _first_ example of some functionality should be > imperative (say specifically how to achieve something step by step) > and subsequent mentions of the same functionality should be more > declarative (say in abstract terms what to achieve, but spare the step > by step details). For me, this is consistent with discussing features > with customers: it starts out step by step, then in subsequent > conversations (especially after implementation of the imperative > steps) we can discuss the same thing in more abstract terms. > > An obvious example is login > > # login.feature > Scenario: Successful login > Given there is a user 'josh' > And the user 'josh' has the password 'pass' > When I visit the login page > And I enter the username 'josh' > And I enter the password 'pass' > And click 'submit' > Then I should see 'welcome josh' > > # some-other.feature > Scenario: Something that requires login > Given I have logged in successfully > ... > > # login_steps.rb > Given /I have logged in successfully/ do > Given "there is a user 'josh'" > Given "the user 'josh' has the password 'pass'" > When "I enter the username 'josh'" > ... > end > > There is duplication between the first imperative feature and the > login steps, but I think that's a slightly different issue from > "Feature coupled steps". The "Given I have logged in successfully" > step is not coupled to a particular feature, it is an aggregation of > other steps. It is designed to be used in different features. > > Going back to your example, I would use the first style. Later, I > would introduce the aggregate step "Given I have paid a bill with > sufficient funds" as and when I needed to. Like Jonathan said, there > is still the issue of shared state, but arguments can be passed > through the aggregate steps to the imperative steps depending on how > you feel about this. > > Josh > > > > > On Wed, Feb 18, 2009 at 8:45 AM, Matt Wynne > wrote: > > > > On 17 Feb 2009, at 20:27, Lenny Marks wrote: > > > >> Forgive the long post, just looking for input/advice/alternate > opinions.. > >> > >> Like many I think that going through the exercise of framing user > requests > >> in Cucumber terms(Features, Scenarios..) really helps facilitate > necessary > >> conversations and avoid time wasted implementing the wrong > thing(e.g. as a > >> requirement/specification tool). However, I'm a bit confused when > it comes > >> to tying this in with Cucumber. I've come across many > suggestions about > >> audience being king as far as language used in features, but when > writing > >> features as part of a specification for a new feature, I > consistently find > >> myself writing at a higher level than most any examples I've come > across(See > >> example below). > >> > >> In the past we've typically relied on very informal means of > specifying > >> new features(Wiki pages, paper, and verbal communication). No > that's not our > >> problem..;-) TPI, Even with extensive object level specs, the > full details > >> of what an application does and how it is expected to behave from > the > >> outside tends to get lost in the app over time. For example, we > have a few > >> applications that were developed by a consulting company. Even > concentrating > >> only on the UI and the flow of the application, there are many > features that > >> are kind of hidden within the app(ex. assign to drop down that > should keep > >> most recently used names first). Without being extremely familiar > with the > >> app, all you really know(as a developer or tester) is that it > renders > >> successfully, which is an obvious maintenance problem. Even with > newer apps, > >> after a feature is implemented it tends to get lost inside the > application. > >> > >> I was thinking that Cucumber could really work here as a full > life cycle > >> tool because the same artifacts that were initially used to > specify a > >> feature, could be kept and re-used as documentation for users and > testers. > >> Unlike alternatives such as keeping a Wiki page up to date, > having features > >> linked to implemented steps serves as integration tests and also > ensures > >> that the feature as written, is still accurate/up to date. (Even > link > >> Cucumber output to Wiki page) > >> > >> Anyway, reading through Cucumber docs and examples, I almost > always see > >> much more specific examples. > >> > >> e.g. (from RSpec book) > >> Feature: Pay bill on line > >> > >> Scenario: Pay a bill > >> Given a checking account with $50 > >> And a payee named Acme > >> And an Acme bill for $37 > >> When I pay the Acme bill > >> Then I should have $13 remaining in my checking account > >> And the payment of $37 to Acme should be listed in Recent > Payments > >> > >> That makes sense to me from a testing perspective, but it just > doesn't > >> seem right to me from the perspective I speak of above. If I were > flushing > >> out this feature with users, I'd have probably wound up with > something more > >> like: > >> > >> Scenario: Pay a bill with sufficient funds > >> Given I have a bill to pay > >> And I have enough money in my checking account to cover it > >> When I pay the bill > >> Then my checking account should be debited by the amount > payed > >> And the payment should be listed in Recent Payments > >> > >> One problem is that obviously this way involves always writing an > extra > >> level of feature dependent steps. It just seems to me that the > specific > >> version tends to distract from the actual story. I'm sure I'm > looking at > >> this backwards, but does anyone else use Cucumber similarly? > >> > >> Thanks, > >> -lenny > > > > My view is, prefer the latter (abstract) style, use the former > (specific) > > style when you have to for clarity. Each can make sense in the right > > context, but the latter style is definitely much easier to read. > > > > In the end I find you usually need some specific examples to drive > out a > > working system if the feature is at all interesting, but trying to > stick to > > the abstract style as long as possible is a good habit to get into. > > > > There was a discussion some time ago about calling these two styles > > 'declarative' and 'imperative'. I'm afraid I'm still too dumb to > remember > > which one is which, but someone else will surely chip in. > 'Abstract' and > > 'Specific' are feeling better to me as I type this. > > > > Matt Wynne > > http://blog.mattwynne.net > > http://www.songkick.com > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfeley at gmail.com Thu Feb 19 11:40:39 2009 From: sfeley at gmail.com (Stephen Eley) Date: Thu, 19 Feb 2009 11:40:39 -0500 Subject: [rspec-users] validate_presence_of In-Reply-To: <57c63afe0902190655y66b388cbs9e109da6b738defd@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <01C973AD-FF8D-468A-A494-F10285758C40@goldweb.com.au> <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> <57c63afe0902190655y66b388cbs9e109da6b738defd@mail.gmail.com> Message-ID: <1fb4df0902190840t57636b1dnc7bdbaf756bbfe30@mail.gmail.com> On Thu, Feb 19, 2009 at 9:55 AM, David Chelimsky wrote: > On Wed, Feb 18, 2009 at 11:40 PM, Stephen Eley wrote: > > >> If your spec breaks because you changed a method call, you're not >> testing behavior any more. You're testing syntax. > > > We've got to stop making laws out of guidelines. This is a very > general statement about what is really a very specific situation, and > it is not in any way as black and white as this statement sounds. But > *somebody* is going to read this, not understand the context, and > think it's international law. Doesn't it increase the probability that someone will read it and not understand the context when you deliberately take it out of context to make a point? >8-> Anyway, I wasn't declaring any laws. I didn't say "specs must never break when method calls change." That would be an impossible standard, since at some point *everything* comes down to a method call. I actually didn't express any imperatives at all. I will agree that "You're not testing behavior any more" is a bit of an overblown statement, since the line between 'behavior' and 'syntax' is highly subjective. Every test is really a test on both. I was expressing my own opinion on where I feel the line is drawn, but it was mostly in response to "You have to do *this*, right?" There's a lot of testing dogma out there. I'm starting to think everyone who gets vocal on the subject lapses into sounding dogmatic eventually...including, apparently, myself. To the extent that I sounded like I was trying to hand down the One True Way, I apologize and withdraw my fervor. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From dchelimsky at gmail.com Thu Feb 19 11:49:45 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Feb 2009 10:49:45 -0600 Subject: [rspec-users] Ruby 1.9 - autospec loadpath problem In-Reply-To: <22102148.post@talk.nabble.com> References: <57a815bf0811301424k131b4155xafee88459449eb@mail.gmail.com> <57c63afe0812010221x58dd37e3w1a7d741df1256b70@mail.gmail.com> <22102148.post@talk.nabble.com> Message-ID: <57c63afe0902190849m4954d192iac667c318a10038@mail.gmail.com> On Thu, Feb 19, 2009 at 8:52 AM, lasitha wrote: > > On Mon, Dec 01, 2008 at 03:51pm, David Chelimsky > wrote: >>On Sun, Nov 30, 2008 at 4:24 PM, Mikel Lindsaar wrote: >>> [...] >>> mikel at baci.local ~/ruby_programs/mail >>> $ autospec >>> /usr/local/bin/autotest:19:in `load': Is a directory - >>> /usr/local/lib/ruby-trunk/gems/1.9.1/gems/rspec-1.1.11/lib/autotest >>> (Errno::EISDIR) >>> from /usr/local/bin/autotest:19:in `

' >>> [...] >>> So load is trying to load autotest the directory instead of autotest the >>> script. >>> Any ideas on how to get it to load the right thing? >> >>I'm not sure how to fix that problem, but before you go much further >>you should know that RSpec does not yet run under 1.9. [...] > > I just ran across this (rspec 1.1.99.7, zentest 3.11.1, ruby 1.9.1-p0) and > thought i'd follow up. > > It appears this is related to rubygems being loaded automatically in ruby > 1.9... Cucumber (and rspec for that matter) contains an 'autotest' directory > under /lib and it appears earlier in the load path than the ZenTest > directories. > > As evidence, running the following gets past the error: > $ ruby --disable-gems `which autotest` > > Of course that would then necessitate activating needed gems manually, which > seems to be counter-productive if 1.9 is encouraging the opposite approach. > > It's not clear to me that this is a rspec or zentest bug - it might just as > easily be a rubygems or ruby deficiency (couldn't 'load' just ignore > directories?). Sounds like Autotest's discovery process is going to need to be revisited. rspec and rspec-rails each have their own subclasses of Autotest, and the autotest executable decides what specific class to load by combing the load path for "autotest/discover" - so rspec and rspec-rails both need to have autotest directories to make that work. Merb apps do the same. > Unfortunately i'm not experienced enough with any of these libraries to know > where to take this next. > If anyone would point me in a direction, i'd be happy to keep digging. > > In the meantime, here's a hack to $RUBY_HOME/bin/autotest (the one generated > by rubygems): > > @@ -19 +19,2 @@ > -load 'autotest' > +zentest_gem_dir = Gem.source_index.find_name('ZenTest', > version).first.full_gem_path > +load File.join(zentest_gem_dir, 'bin', 'autotest') > > That is very likely the _wrong_ way to calculate zentest_gem_dir... I > googled and poked around but couldn't find any definitive API. Any > enlightenment on that would also be appreciated. For a temp solution this seems reasonable to me. Anybody else have a better idea? > > Cheers, > lasitha > > -- > View this message in context: http://www.nabble.com/Ruby-1.9---autospec-loadpath-problem-tp20763177p22102148.html > Sent from the rspec-users mailing list archive at Nabble.com. From sfeley at gmail.com Thu Feb 19 12:15:35 2009 From: sfeley at gmail.com (Stephen Eley) Date: Thu, 19 Feb 2009 12:15:35 -0500 Subject: [rspec-users] validate_presence_of In-Reply-To: <57c63afe0902190755t2ae78302p813565f9fb97c8eb@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <3c30da400902181942u195c2628uc1271630f4c929b3@mail.gmail.com> <1fb4df0902182131r1ec87c23hf503548ac877d595@mail.gmail.com> <57c63afe0902182158w4a6cd740n9608b28819fdaabc@mail.gmail.com> <1fb4df0902190620x57758b14k27fa84fcf5411fd2@mail.gmail.com> <57c63afe0902190755t2ae78302p813565f9fb97c8eb@mail.gmail.com> Message-ID: <1fb4df0902190915n6d74d9dex8b6672fde28ad426@mail.gmail.com> On Thu, Feb 19, 2009 at 10:55 AM, David Chelimsky wrote: > > This is where this all gets tricky. Yep. >8-> > TDD (remember? that's where this all started) says you don't write any > subject code without a failing *unit test*. This is not about the end > result - it's about a process. What you're talking about here is the > end result: post-code testing. Yes. And I didn't. The test "it 'requires a login'" fails until I write a validation for the login field. I don't write the validation until I have that test. Once that test is written, any way of validating login's presence -- with validates_presence_of in AR, or a :nullable => false on the property in DataMapper, or a callback before saving, or whatever -- will pass the test. I have written the code to pass the test, and I have followed TDD principles. I can now move on to the next problem. But I did not write any code yet setting the message. Because I haven't written any tests for the message. At this point I don't care what the message is, just that I have the right data. I care about the message when I start focusing on presentation. When I write specs for the exchange with the user, I will write a test. I might reopen the model's spec and add it there (maintaining 'unit test' purity), or I might put it in the request spec, but either way a test will break before the code is written. I think that keeps the *spirit* of TDD, whether or not it follows its shelving rules. And yes, I know it all comes down to "it depends." On a larger project that would have a lot of people on it, I'd probably insist on more formalism for the sake of keeping things organized. But if it's a small app with a focus on shipping fast and frequently, having one test that fails is enough. > If you're true to the process, then you'd have material in both > places. The cost of this is something that looks like duplication, but > it's not really, because at the high level we're specifying the > behaviour of the system, and at the low level we're specifying the > behaviour of a single object - fulfilling its role in that system. And again: the extent to which I'd do that is the extent to which I care how the system is organized. Sometimes it really does matter. More often, to me, it doesn't. If an integration spec breaks, there's *usually* no mystery to me because I can just look at the backtrace to see what broke and fix it in a few seconds. Writing low-level specs to help isolate what's obvious and quickly fixed without them doesn't save time. Sometimes it is more complicated and confusing, and if it takes me too long to understand why the high level is broken, I'll sometimes write more unit specs to figure it out. That's not backwards. A test still broke. If I always have at least one test that fails on any incorrect behavior that matters, and I never ship with failing tests, then my testing has satisfactory coverage, whether it's an integration test or a unit test or a highly trained hamster reviewing my log files. Having more tests and finer detail only matters if it saves me time. (Which, sometimes, it does.) That's just my opinion. Not the law. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From sfeley at gmail.com Thu Feb 19 12:30:17 2009 From: sfeley at gmail.com (Stephen Eley) Date: Thu, 19 Feb 2009 12:30:17 -0500 Subject: [rspec-users] validate_presence_of In-Reply-To: <1fb4df0902190915n6d74d9dex8b6672fde28ad426@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <3c30da400902181942u195c2628uc1271630f4c929b3@mail.gmail.com> <1fb4df0902182131r1ec87c23hf503548ac877d595@mail.gmail.com> <57c63afe0902182158w4a6cd740n9608b28819fdaabc@mail.gmail.com> <1fb4df0902190620x57758b14k27fa84fcf5411fd2@mail.gmail.com> <57c63afe0902190755t2ae78302p813565f9fb97c8eb@mail.gmail.com> <1fb4df0902190915n6d74d9dex8b6672fde28ad426@mail.gmail.com> Message-ID: <1fb4df0902190930k1d4a3077jae03311c3fffde7b@mail.gmail.com> On Thu, Feb 19, 2009 at 12:15 PM, Stephen Eley wrote: > > But I did not write any code yet setting the message. Because I > haven't written any tests for the message. At this point I don't care > what the message is, just that I have the right data. I care about > the message when I start focusing on presentation. By the way, this spun off a whole line of thought in my head that maybe the way Rails handles validation messages in general is wrong. It's certainly a violation of separation of concerns: models aren't supposed to care about presentation, and yet we're putting plain English (or other language, or internationalized, or whatever) text in then that isn't relevant to the data, just for the purpose of presenting it to the user. *This* is backwards, and maybe that's why I felt some conflict about where the spec on that message should go. The responsibility of the model is to report a problem, not to declare the exact wording of that report. In an ideal MVC world models wouldn't be filling up hashes with message text at all. They'd return exceptions on save, and the standard create/update boilerplate in the controller would contain a rescue instead of an if-then, and responsibility of turning the properties of that exception into English would happen somewhere at the view level. Am I onto something here? (Heh. Maybe I agree with Pat after all: I just went from a very minor "I can't figure out how to test this" to the arrogance of suggesting that pretty much every Ruby ORM should be rewritten.) >8-> -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org From mark at mwilden.com Thu Feb 19 12:38:09 2009 From: mark at mwilden.com (Mark Wilden) Date: Thu, 19 Feb 2009 09:38:09 -0800 Subject: [rspec-users] validate_presence_of In-Reply-To: <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <01C973AD-FF8D-468A-A494-F10285758C40@goldweb.com.au> <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> Message-ID: <3c30da400902190938s4c792ba7jfc34a30c3627dee1@mail.gmail.com> On Wed, Feb 18, 2009 at 9:40 PM, Stephen Eley wrote: > On Wed, Feb 18, 2009 at 11:42 PM, Yi Wen wrote: > > validates_presence_of happens to be the name of the method in > ActiveRecord that does that. But if you decide to write your own > check_to_see_if_this_thingy_is_in_my_whatsis() method that does the > same thing, a good *behavior* spec will not break. Because the > behavior remains the same. I think you're talking about state-based, blackbox testing, rather than behavior-based whitebox testing. RSpec unit tests are all about speccing that one object calls another object's method at the right time. The idea being that if that behavior occurs, and that the other object's method has been similarly tested, that you're OK. ///ark From dchelimsky at gmail.com Thu Feb 19 13:25:34 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Feb 2009 12:25:34 -0600 Subject: [rspec-users] validate_presence_of In-Reply-To: <3c30da400902190938s4c792ba7jfc34a30c3627dee1@mail.gmail.com> References: <32d6ca509dc412ddc8df57a75ac4b261@ruby-forum.com> <01C973AD-FF8D-468A-A494-F10285758C40@goldweb.com.au> <1fb4df0902182140n452afb9fh82855768acb7aa7@mail.gmail.com> <3c30da400902190938s4c792ba7jfc34a30c3627dee1@mail.gmail.com> Message-ID: <57c63afe0902191025q27d396f7j2463ca1e2073b70c@mail.gmail.com> On Thu, Feb 19, 2009 at 11:38 AM, Mark Wilden wrote: > On Wed, Feb 18, 2009 at 9:40 PM, Stephen Eley wrote: >> On Wed, Feb 18, 2009 at 11:42 PM, Yi Wen wrote: >> >> validates_presence_of happens to be the name of the method in >> ActiveRecord that does that. But if you decide to write your own >> check_to_see_if_this_thingy_is_in_my_whatsis() method that does the >> same thing, a good *behavior* spec will not break. Because the >> behavior remains the same. > > I think you're talking about state-based, blackbox testing, rather > than behavior-based whitebox testing. RSpec unit tests are all about > speccing that one object calls another object's method at the right > time. This is true in cases where the object delegates responsibility and that delegation is significant. If a collaborator is polymorphic, and the correct collaborator is chosen based on conditions external to the subject, then it makes sense to spec interactions. If the collaborator connects to an external resource like a database or a network, then stubbing the collaborator makes good sense. On the contrary, if the collaborator is created internally and is always the same object and does not require any setup outside of the subject, then spec'ing interactions doesn't make sense. Make sense? > The idea being that if that behavior occurs, and that the other > object's method has been similarly tested, that you're OK. With the caveat that somewhere there is some level of integration testing going on. Although it looks like J.B. Rainsberger disagrees: http://agile2009.agilealliance.org/node/708 (you have to have an account to view this - but the title of his proposed talk is "Integration Tests are a Scam"). I don't know enough of the detail of his arguments to argue them here, but it seems like an interesting discussion. FWIW, David > > ///ark > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From tero at tilus.net Thu Feb 19 13:34:41 2009 From: tero at tilus.net (Tero Tilus) Date: Thu, 19 Feb 2009 20:34:41 +0200 Subject: [rspec-users] ActiveRecord::Base.should_receive(:find) fails Message-ID: <20090219183440.GC22708@uivelo.tilus.net> I've got an AR-model with some find-magic I want to test. When I have ActiveRecord::Base.should_receive(:find).with(anything(),assert_options) MyModel.find(:all,find_options) in my example find-method somehow disappears alltogether and I get NoMethodError in 'MyModel find-options are passed on correctly' undefined method `find' for MyModel And docs tell that (at least something really close to that one) should work http://rspec.info/documentation/mocks/partial_mocks.html -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From dchelimsky at gmail.com Thu Feb 19 13:47:18 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Feb 2009 12:47:18 -0600 Subject: [rspec-users] ActiveRecord::Base.should_receive(:find) fails In-Reply-To: <20090219183440.GC22708@uivelo.tilus.net> References: <20090219183440.GC22708@uivelo.tilus.net> Message-ID: <57c63afe0902191047y619152cie8b8394529bc7d98@mail.gmail.com> On Thu, Feb 19, 2009 at 12:34 PM, Tero Tilus wrote: > I've got an AR-model with some find-magic I want to test. When I have > > ActiveRecord::Base.should_receive(:find).with(anything(),assert_options) > MyModel.find(:all,find_options) MyModel != ActiveRecord::Base Try this MyModel.should_receive(:find).with(anything(),assert_options) MyModel.find(:all,find_options) > > in my example find-method somehow disappears alltogether and I get > > NoMethodError in 'MyModel find-options are passed on correctly' > undefined method `find' for MyModel > > And docs tell that (at least something really close to that one) > should work > > http://rspec.info/documentation/mocks/partial_mocks.html > > -- > Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From html-kurs at gmx.de Thu Feb 19 15:54:46 2009 From: html-kurs at gmx.de (Martin) Date: Thu, 19 Feb 2009 21:54:46 +0100 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord Message-ID: <499DC716.3050904@gmx.de> Hi, I'm trying to test my views using rspec. I want to test my edit- and new-view also for the case an error occurs (something like "title can't be blank" and so on). Can someone point me please to an example where I can see how to mock my model and stub all methods needed for the view? Thank you, Martin From jim at saturnflyer.com Thu Feb 19 16:15:04 2009 From: jim at saturnflyer.com (Jim Gay) Date: Thu, 19 Feb 2009 16:15:04 -0500 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <499DC716.3050904@gmx.de> References: <499DC716.3050904@gmx.de> Message-ID: <629813E2-88E1-4777-8BD6-0446E9C10A66@saturnflyer.com> On Feb 19, 2009, at 3:54 PM, Martin wrote: > Hi, > > I'm trying to test my views using rspec. I want to test my edit- and > new-view also for the case an error occurs (something like "title > can't be blank" and so on). > Can someone point me please to an example where I can see how to > mock my model and stub all methods needed for the view? Here's how I addressed it http://pastie.org/394417 > Thank you, > Martin From dchelimsky at gmail.com Thu Feb 19 16:18:27 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Feb 2009 15:18:27 -0600 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <499DC716.3050904@gmx.de> References: <499DC716.3050904@gmx.de> Message-ID: <57c63afe0902191318yfd870c8y2bc63c1c900302c8@mail.gmail.com> On Thu, Feb 19, 2009 at 2:54 PM, Martin wrote: > Hi, > > I'm trying to test my views using rspec. I want to test my edit- and > new-view also for the case an error occurs (something like "title can't be > blank" and so on). > Can someone point me please to an example where I can see how to mock my > model and stub all methods needed for the view? Here's a start: http://rspec.info/rails/writing/views.html Also: rails foo cd foo script/generate rspec script/generate rspec_scaffold thing name:string Now look at spec/views/things/*.html.erb_spec.rb HTH, David > > Thank you, > Martin > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From matt at mattwynne.net Thu Feb 19 16:24:09 2009 From: matt at mattwynne.net (Matt Wynne) Date: Thu, 19 Feb 2009 21:24:09 +0000 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <499DC716.3050904@gmx.de> References: <499DC716.3050904@gmx.de> Message-ID: On 19 Feb 2009, at 20:54, Martin wrote: > Hi, > > I'm trying to test my views using rspec. I want to test my edit- and > new-view also for the case an error occurs (something like "title > can't be blank" and so on). > Can someone point me please to an example where I can see how to > mock my model and stub all methods needed for the view? I guess this isn't exactly what you want to hear, but I would counsel you against mocking your whole model object for a form with lots of fields - those kind of 'broad' mocks can be very brittle to changes in your domain model. Can you try using stub_model instead? This creates an instance of your actual model class, but with a crippled database connection. You can then create an invalid model object and throw it to the view. Something like: assigns[:book] = stub_model(Book, :title => '') If your model is at all interesting, you might want to keep the attributes that make a valid Book somewhere: valid_book = { :title => "Test Book Title", :author => "Test Author" } assigns[:book] = stub_model(Book, valid_book.merge(:title => '')) I generally hide these behind a helper method, like def stub_book(attributes = {}) stub_model Book, { :title => "Test Book Title", :author => "Test Author" }.merge(attributes) end Does that help? Matt Wynne http://blog.mattwynne.net http://www.songkick.com From zuperinfinite at gmail.com Thu Feb 19 16:39:09 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Thu, 19 Feb 2009 22:39:09 +0100 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <499DC716.3050904@gmx.de> References: <499DC716.3050904@gmx.de> Message-ID: On 19 feb 2009, at 21:54, Martin wrote: > Hi, > > I'm trying to test my views using rspec. I want to test my edit- and > new-view also for the case an error occurs (something like "title > can't be blank" and so on). > Can someone point me please to an example where I can see how to > mock my model and stub all methods needed for the view? If you happen to use Cucumber as well, I strongly suggest you check the error messages there. First of all, it's easier since you don't have to go mad stubbing and mucking about (sorry, had to make that joke :P), and error messages more or less belong into integration tests. At least, that's my opinion. cheers, bartz From zach.dennis at gmail.com Thu Feb 19 16:51:58 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 19 Feb 2009 16:51:58 -0500 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <499DC716.3050904@gmx.de> References: <499DC716.3050904@gmx.de> Message-ID: <85d99afe0902191351t4c1eba82u8adf82c1443f2966@mail.gmail.com> On Thu, Feb 19, 2009 at 3:54 PM, Martin wrote: > Hi, > > I'm trying to test my views using rspec. I want to test my edit- and > new-view also for the case an error occurs (something like "title can't be > blank" and so on). > Can someone point me please to an example where I can see how to mock my > model and stub all methods needed for the view? Here's two ways to approach writing examples against ensuring errors show up: http://gist.github.com/67135 Note, that if your model really exists, you can use stub_model instead of mock_model. > > Thank you, > Martin > _______________________________________________ > 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 zach.dennis at gmail.com Thu Feb 19 16:53:21 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 19 Feb 2009 16:53:21 -0500 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: References: <499DC716.3050904@gmx.de> Message-ID: <85d99afe0902191353m31bf8476xcd930f075d4d9099@mail.gmail.com> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne wrote: > > On 19 Feb 2009, at 20:54, Martin wrote: > >> Hi, >> >> I'm trying to test my views using rspec. I want to test my edit- and >> new-view also for the case an error occurs (something like "title can't be >> blank" and so on). >> Can someone point me please to an example where I can see how to mock my >> model and stub all methods needed for the view? > > I guess this isn't exactly what you want to hear, but I would counsel you > against mocking your whole model object for a form with lots of fields - > those kind of 'broad' mocks can be very brittle to changes in your domain > model. > > Can you try using stub_model instead? This creates an instance of your > actual model class, but with a crippled database connection. You can then > create an invalid model object and throw it to the view. Something like: > > assigns[:book] = stub_model(Book, :title => '') > > If your model is at all interesting, you might want to keep the attributes > that make a valid Book somewhere: > > valid_book = { > :title => "Test Book Title", > :author => "Test Author" > } > assigns[:book] = stub_model(Book, valid_book.merge(:title => '')) > > I generally hide these behind a helper method, like > > def stub_book(attributes = {}) > stub_model Book, { > :title => "Test Book Title", > :author => "Test Author" > }.merge(attributes) > end Why hide them behind a helper? Why not just only specify them in examples where they are used? ie: it "should display the book title" do @book.stub!(:title).and_return "The Scarlet Letter" render ... response.should include_text("The Scarlet Letter") end > > Does that help? > > 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 zach.dennis at gmail.com Thu Feb 19 17:11:17 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 19 Feb 2009 17:11:17 -0500 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <85d99afe0902191351t4c1eba82u8adf82c1443f2966@mail.gmail.com> References: <499DC716.3050904@gmx.de> <85d99afe0902191351t4c1eba82u8adf82c1443f2966@mail.gmail.com> Message-ID: <85d99afe0902191411s203a1369gb4d7d0ee8d34aa3e@mail.gmail.com> On Thu, Feb 19, 2009 at 4:51 PM, Zach Dennis wrote: > On Thu, Feb 19, 2009 at 3:54 PM, Martin wrote: >> Hi, >> >> I'm trying to test my views using rspec. I want to test my edit- and >> new-view also for the case an error occurs (something like "title can't be >> blank" and so on). >> Can someone point me please to an example where I can see how to mock my >> model and stub all methods needed for the view? > > Here's two ways to approach writing examples against ensuring errors show up: > > http://gist.github.com/67135 > This gist is to show you how-to verify errors are displayed in a view, not necessarily that you should go stubbing a bunch of superfluous errors that may exist in the model to ensure they all show up. You should only need to know that the errors are being displayed and one dummy error message does that. > Note, that if your model really exists, you can use stub_model instead > of mock_model. > > > > >> >> Thank you, >> Martin >> _______________________________________________ >> 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 > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From lists at ruby-forum.com Fri Feb 20 05:35:07 2009 From: lists at ruby-forum.com (Juanma Cervera) Date: Fri, 20 Feb 2009 11:35:07 +0100 Subject: [rspec-users] [ANN] rspec-1.2 release candidate In-Reply-To: <57c63afe0902190558m14107313j9bfa949c48c1c9f1@mail.gmail.com> References: <57c63afe0902182256h37f6449exc29e03cf1275d804@mail.gmail.com> <31D30E37-CF11-4541-B3E4-20C5068AEFB4@wincent.com> <57c63afe0902190558m14107313j9bfa949c48c1c9f1@mail.gmail.com> Message-ID: <47e4b956d5e2a4ffc7eab7f43602575d@ruby-forum.com> David, I have an error when trying to run autospec. It works when I run 'rake spec' I don know why it is still using the rspec-1.1.12 gem. /usr/lib/ruby/gems/1.8/gems/dchelimsky-rspec-1.1.99.7/lib/spec/autorun.rb:3: undefined method `autorun' for Spec::Runner:Module (NoMethodError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /home/jmcervera/.gem/ruby/1.8/gems/activesupport-2.3.0/lib/active_support/dependencies.rb:158:in `require' from ./spec/models/../spec_helper.rb:5 from ./spec/models/cliente_spec.rb:1:in `require' from ./spec/models/cliente_spec.rb:1 from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:15:in `load' from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:15:in `load_files' from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:14:in `each' from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:14:in `load_files' from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/options.rb:94:in `run_examples' from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/command_line.rb:9:in `run' from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/bin/spec:4 Thanks Juanma -- Posted via http://www.ruby-forum.com/. From chris.webstar at gmail.com Fri Feb 20 07:15:26 2009 From: chris.webstar at gmail.com (Christian Hoeppner) Date: Fri, 20 Feb 2009 12:15:26 +0000 Subject: [rspec-users] Autotest won't pickup any tests Message-ID: <067EF338-8816-417E-963F-4BC157E18EFD@gmail.com> Hey there, I've tried using Nick Sieger's "plugin" to have autotest run my tests for gems and other non-rails stuff. However, it doesn't seem to match any tests for any files. Not being sure what was wrong, I traced the execution of RspecAutotest.run() and saw that tests_for_file() never got called. I also replicated a tests_for_file() call by hand in irb, and it does match the right spec file for any given implementation file. Here's what I use: ZenTest (3.11.1), rspec (1.1.12), ruby, ruby 1.8.1 (2003-12-25) [i686- darwin]. Sieger's file is the latest from svn, dated from 2007. From matt at mattwynne.net Fri Feb 20 09:20:20 2009 From: matt at mattwynne.net (Matt Wynne) Date: Fri, 20 Feb 2009 14:20:20 +0000 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <85d99afe0902191353m31bf8476xcd930f075d4d9099@mail.gmail.com> References: <499DC716.3050904@gmx.de> <85d99afe0902191353m31bf8476xcd930f075d4d9099@mail.gmail.com> Message-ID: <5424C9CE-2689-4139-80ED-DC45DCEA4AB9@mattwynne.net> On 19 Feb 2009, at 21:53, Zach Dennis wrote: > On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne > wrote: >> >> On 19 Feb 2009, at 20:54, Martin wrote: >> >>> Hi, >>> >>> I'm trying to test my views using rspec. I want to test my edit- and >>> new-view also for the case an error occurs (something like "title >>> can't be >>> blank" and so on). >>> Can someone point me please to an example where I can see how to >>> mock my >>> model and stub all methods needed for the view? >> >> I guess this isn't exactly what you want to hear, but I would >> counsel you >> against mocking your whole model object for a form with lots of >> fields - >> those kind of 'broad' mocks can be very brittle to changes in your >> domain >> model. >> >> Can you try using stub_model instead? This creates an instance of >> your >> actual model class, but with a crippled database connection. You >> can then >> create an invalid model object and throw it to the view. Something >> like: >> >> assigns[:book] = stub_model(Book, :title => '') >> >> If your model is at all interesting, you might want to keep the >> attributes >> that make a valid Book somewhere: >> >> valid_book = { >> :title => "Test Book Title", >> :author => "Test Author" >> } >> assigns[:book] = stub_model(Book, valid_book.merge(:title => '')) >> >> I generally hide these behind a helper method, like >> >> def stub_book(attributes = {}) >> stub_model Book, { >> :title => "Test Book Title", >> :author => "Test Author" >> }.merge(attributes) >> end > > Why hide them behind a helper? Why not just only specify them in > examples where they are used? ie: > > it "should display the book title" do > @book.stub!(:title).and_return "The Scarlet Letter" > render ... > response.should include_text("The Scarlet Letter") > end Why hide them in a helper? because I don't want the noise of all the attributes needed to make a valid book in each test. @book = stub_book :title => "The Scarlet Letter" This is basically the same pattern people use things like factory_girl for, just using stub_model. Matt Wynne http://blog.mattwynne.net http://www.songkick.com From zach.dennis at gmail.com Fri Feb 20 09:57:33 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Fri, 20 Feb 2009 09:57:33 -0500 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <5424C9CE-2689-4139-80ED-DC45DCEA4AB9@mattwynne.net> References: <499DC716.3050904@gmx.de> <85d99afe0902191353m31bf8476xcd930f075d4d9099@mail.gmail.com> <5424C9CE-2689-4139-80ED-DC45DCEA4AB9@mattwynne.net> Message-ID: <85d99afe0902200657n6347e2b2k32efe5e6b32c5305@mail.gmail.com> On Fri, Feb 20, 2009 at 9:20 AM, Matt Wynne wrote: > > On 19 Feb 2009, at 21:53, Zach Dennis wrote: > >> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne wrote: >>> >>> On 19 Feb 2009, at 20:54, Martin wrote: >>> >>>> Hi, >>>> >>>> I'm trying to test my views using rspec. I want to test my edit- and >>>> new-view also for the case an error occurs (something like "title can't >>>> be >>>> blank" and so on). >>>> Can someone point me please to an example where I can see how to mock my >>>> model and stub all methods needed for the view? >>> >>> I guess this isn't exactly what you want to hear, but I would counsel you >>> against mocking your whole model object for a form with lots of fields - >>> those kind of 'broad' mocks can be very brittle to changes in your domain >>> model. >>> >>> Can you try using stub_model instead? This creates an instance of your >>> actual model class, but with a crippled database connection. You can then >>> create an invalid model object and throw it to the view. Something like: >>> >>> assigns[:book] = stub_model(Book, :title => '') >>> >>> If your model is at all interesting, you might want to keep the >>> attributes >>> that make a valid Book somewhere: >>> >>> valid_book = { >>> :title => "Test Book Title", >>> :author => "Test Author" >>> } >>> assigns[:book] = stub_model(Book, valid_book.merge(:title => '')) >>> >>> I generally hide these behind a helper method, like >>> >>> def stub_book(attributes = {}) >>> stub_model Book, { >>> :title => "Test Book Title", >>> :author => "Test Author" >>> }.merge(attributes) >>> end >> >> Why hide them behind a helper? Why not just only specify them in >> examples where they are used? ie: >> >> it "should display the book title" do >> @book.stub!(:title).and_return "The Scarlet Letter" >> render ... >> response.should include_text("The Scarlet Letter") >> end > > Why hide them in a helper? because I don't want the noise of all the > attributes needed to make a valid book in each test. > > @book = stub_book :title => "The Scarlet Letter" > > This is basically the same pattern people use things like factory_girl for, > just using stub_model. Ah, I'm with you now. I thought you were eluding to doing the following (but I realize now that wasn't what you were getting at): assigns[:book] = stub_book render .. response.should include_text("The Scarlet Letter") -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From dchelimsky at gmail.com Fri Feb 20 10:56:11 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 20 Feb 2009 09:56:11 -0600 Subject: [rspec-users] Autotest won't pickup any tests In-Reply-To: <067EF338-8816-417E-963F-4BC157E18EFD@gmail.com> References: <067EF338-8816-417E-963F-4BC157E18EFD@gmail.com> Message-ID: <57c63afe0902200756q60c87e11wc8caa27bd8af3291@mail.gmail.com> On Fri, Feb 20, 2009 at 6:15 AM, Christian Hoeppner wrote: > Hey there, > > I've tried using Nick Sieger's "plugin" to have autotest run my tests for > gems and other non-rails stuff. However, it doesn't seem to match any tests > for any files. Not being sure what was wrong, I traced the execution of > RspecAutotest.run() and saw that tests_for_file() never got called. I also > replicated a tests_for_file() call by hand in irb, and it does match the > right spec file for any given implementation file. That lib is way outdated. RSpec now supports autotest directly with the autospec command. > > Here's what I use: > ZenTest (3.11.1), rspec (1.1.12), ruby, ruby 1.8.1 (2003-12-25) > [i686-darwin]. > > Sieger's file is the latest from svn, dated from 2007. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From lists at ruby-forum.com Fri Feb 20 12:09:14 2009 From: lists at ruby-forum.com (James Byrne) Date: Fri, 20 Feb 2009 18:09:14 +0100 Subject: [rspec-users] Cucumber Feature Scenario critique Message-ID: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> When I initially began working with cucumber and developing features and steps from existing code I went through a process (prompted by the members of this group) of developing increasingly abstract (declarative?) wording for the feature scenario steps. Now, I am finally at the stage where I am using features to drive new code. I would appreciate very much some advice on how to word a design desire into a feature scenario. The example I have chosen is that of a client. In our design and requirements discussions we have arrived at the idea of "client" being that of an ephemeral "role" assigned to a durable "entity". A client role is thus conceived as episodic in nature. An entity can be a client for a period of years, then dormant for a period (whether due to change in their business patterns or a departure to a competitive service) and then active again. For tax reasons it is important to know precisely when a client was active and when they were not. For business reasons it is important that dormant accounts be deactivated as soon as this state is detected and confirmed. It is however, vital that all previous history of activity not be disturbed by any changes in status and that all the cumulative history of a single legal entity be kept together. The questions I have relate to how best put this down as a set of features or scenarios within a feature or features. I am toying with the idea of a general, application wide, feature file (app.feature) that contains the barest statement of what each major component or element of the evolving application requires. Then, as the step definitions are expressed, the detailed features are arranged in hierarchy of files according to their anticipated nature (external component, model, controller, view, service or library so far). So to begin with, at the highest level I think something like this might serve: app.feature Feature: A Web Based Business Application for Transportation and Customs In Order To: Conduct Routine Business An: Authorized User Should: Securely Access the Web Application To: Reduce Costs #The work will be done anyway and the price won't change Scenario: The Application Has Authorized Users ... Scenario: The Application Has Entities ... Scenario: The Application Has Clients Given I have a user named "admin" And the user named "admin" authenticates And the user named "admin" is authorized to "add" "clients" When they visit the add new client page And they provide valid client data And they submit the new client Then they should see a new client added message The app.feature file will contain no further specifics respecting clients. To deal with these specifics I will later create a model/clients/client.feature file (or files) that will detail the implementation of that model. The step definitions given above will go into model/clients/step_definitions/client_steps.rb I think this approach will work but I really have no experience with organizing a large scale project around BDD. Any insight and experience that anyone can provide is greatly appreciated. As a supplemental issue: We use a project administration system (Redmine). Have any of you adopted practices with respect to the relationships between issue tickets and feature scenarios that you found useful? -- Posted via http://www.ruby-forum.com/. From pat.maddox at gmail.com Fri Feb 20 12:59:48 2009 From: pat.maddox at gmail.com (Pat Maddox) Date: Fri, 20 Feb 2009 09:59:48 -0800 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <5424C9CE-2689-4139-80ED-DC45DCEA4AB9@mattwynne.net> References: <499DC716.3050904@gmx.de> <85d99afe0902191353m31bf8476xcd930f075d4d9099@mail.gmail.com> <5424C9CE-2689-4139-80ED-DC45DCEA4AB9@mattwynne.net> Message-ID: <2c7e61990902200959s214fd1b9wc82c9f8e048d4f2e@mail.gmail.com> On Fri, Feb 20, 2009 at 6:20 AM, Matt Wynne wrote: > > On 19 Feb 2009, at 21:53, Zach Dennis wrote: > >> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne wrote: >>> >>> On 19 Feb 2009, at 20:54, Martin wrote: >>> >>>> Hi, >>>> >>>> I'm trying to test my views using rspec. I want to test my edit- and >>>> new-view also for the case an error occurs (something like "title can't >>>> be >>>> blank" and so on). >>>> Can someone point me please to an example where I can see how to mock my >>>> model and stub all methods needed for the view? >>> >>> I guess this isn't exactly what you want to hear, but I would counsel you >>> against mocking your whole model object for a form with lots of fields - >>> those kind of 'broad' mocks can be very brittle to changes in your domain >>> model. >>> >>> Can you try using stub_model instead? This creates an instance of your >>> actual model class, but with a crippled database connection. You can then >>> create an invalid model object and throw it to the view. Something like: >>> >>> assigns[:book] = stub_model(Book, :title => '') >>> >>> If your model is at all interesting, you might want to keep the >>> attributes >>> that make a valid Book somewhere: >>> >>> valid_book = { >>> :title => "Test Book Title", >>> :author => "Test Author" >>> } >>> assigns[:book] = stub_model(Book, valid_book.merge(:title => '')) >>> >>> I generally hide these behind a helper method, like >>> >>> def stub_book(attributes = {}) >>> stub_model Book, { >>> :title => "Test Book Title", >>> :author => "Test Author" >>> }.merge(attributes) >>> end >> >> Why hide them behind a helper? Why not just only specify them in >> examples where they are used? ie: >> >> it "should display the book title" do >> @book.stub!(:title).and_return "The Scarlet Letter" >> render ... >> response.should include_text("The Scarlet Letter") >> end > > Why hide them in a helper? because I don't want the noise of all the > attributes needed to make a valid book in each test. Also so that when you change validations, you only have to change one part of test code instead of every test that uses that model. Pat From ben at benmabey.com Fri Feb 20 13:34:40 2009 From: ben at benmabey.com (Ben Mabey) Date: Fri, 20 Feb 2009 11:34:40 -0700 Subject: [rspec-users] [RSpec][OT] have autospec just run changed files Message-ID: <499EF7C0.20301@benmabey.com> Hello all, Is there a way to have autospec and/or RSpactor just run the specs for the files that have changed and not run the entire spec suite afterwards? If you start autospec with -f it will wait for a change but it will then run the entire suite after the individual one passes. The project that I am working on now has a spec suite that is too long for the normal autospec cycle. However, I like having that tight feedback loop for the files I touch. Any ideas? Thanks, Ben From lists at technomage.com Fri Feb 20 13:32:20 2009 From: lists at technomage.com (Michael Latta) Date: Fri, 20 Feb 2009 10:32:20 -0800 Subject: [rspec-users] Cucumber Feature Scenario critique In-Reply-To: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> References: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> Message-ID: <754D5764-3410-4D13-888E-B972DB36F198@technomage.com> I would suggest a different approach to organizing the features. In particular I would recommend the features be used to test implementation invariant aspects of the system. Our features are whole stack sequences that involve views, controllers, and models in almost every case. We test the "system" not the parts. In the ideal case you will specify the system up front so little should change from bug reports unless they are really a change in requirements. Requirements changes have a different workflow than implementation bugs. I would recommend you track that difference in your project management system. Keep an eye on how much changes after implementation to measure how good your requirements capture has been. Michael On Feb 20, 2009, at 9:09 AM, James Byrne wrote: > When I initially began working with cucumber and developing features > and > steps from existing code I went through a process (prompted by the > members of this group) of developing increasingly abstract > (declarative?) wording for the feature scenario steps. Now, I am > finally at the stage where I am using features to drive new code. I > would appreciate very much some advice on how to word a design desire > into a feature scenario. > > The example I have chosen is that of a client. In our design and > requirements discussions we have arrived at the idea of "client" being > that of an ephemeral "role" assigned to a durable "entity". A client > role is thus conceived as episodic in nature. An entity can be a > client > for a period of years, then dormant for a period (whether due to > change > in their business patterns or a departure to a competitive service) > and > then active again. > > For tax reasons it is important to know precisely when a client was > active and when they were not. For business reasons it is important > that dormant accounts be deactivated as soon as this state is detected > and confirmed. It is however, vital that all previous history of > activity not be disturbed by any changes in status and that all the > cumulative history of a single legal entity be kept together. > > The questions I have relate to how best put this down as a set of > features or scenarios within a feature or features. I am toying with > the > idea of a general, application wide, feature file (app.feature) that > contains the barest statement of what each major component or > element of > the evolving application requires. Then, as the step definitions are > expressed, the detailed features are arranged in hierarchy of files > according to their anticipated nature (external component, model, > controller, view, service or library so far). > > So to begin with, at the highest level I think something like this > might > serve: > > app.feature > Feature: A Web Based Business Application for Transportation and > Customs > In Order To: Conduct Routine Business > An: Authorized User > Should: Securely Access the Web Application > To: Reduce Costs #The work will be done anyway and the price won't > change > > Scenario: The Application Has Authorized Users > ... > > Scenario: The Application Has Entities > ... > > Scenario: The Application Has Clients > Given I have a user named "admin" > And the user named "admin" authenticates > And the user named "admin" is authorized to "add" "clients" > When they visit the add new client page > And they provide valid client data > And they submit the new client > Then they should see a new client added message > > The app.feature file will contain no further specifics respecting > clients. To deal with these specifics I will later create a > model/clients/client.feature file (or files) that will detail the > implementation of that model. The step definitions given above will > go > into model/clients/step_definitions/client_steps.rb > > I think this approach will work but I really have no experience with > organizing a large scale project around BDD. Any insight and > experience > that anyone can provide is greatly appreciated. > > As a supplemental issue: We use a project administration system > (Redmine). Have any of you adopted practices with respect to the > relationships between issue tickets and feature scenarios that you > found > useful? > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From ashley.moran at patchspace.co.uk Fri Feb 20 14:20:07 2009 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 20 Feb 2009 19:20:07 +0000 Subject: [rspec-users] [~OT] Celerity LinkedIn group Message-ID: <1C65198C-FF9B-4637-A4DF-B66D1D5932FA@patchspace.co.uk> Hi all Marginally on-topic... as part of my compulsion to create LinkedIn groups, I made a group[1] for Celerity[2] today. Thought I would announce here, as there are quite possibly more Celerity users here than on the official Celerity mailing list! And if you haven't tried Celerity with Cucumber, you should! It rocks =) Ashley [1] http://www.linkedin.com/e/vgh/1814903/eml-grp-sub/ [2] http://celerity.rubyforge.org/ -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ http://twitter.com/ashleymoran From peter.a.jaros at gmail.com Fri Feb 20 14:33:16 2009 From: peter.a.jaros at gmail.com (Peter Jaros) Date: Fri, 20 Feb 2009 14:33:16 -0500 Subject: [rspec-users] [RSpec][OT] have autospec just run changed files In-Reply-To: <499EF7C0.20301@benmabey.com> References: <499EF7C0.20301@benmabey.com> Message-ID: <937d9d810902201133k76ab868x64e6cb36b1723ee@mail.gmail.com> I don't know about RSpactor, but autospec will keep track of failing specs and re-run them along with changed specs and specs for changed files. It won't run the entire suite until everything has passed. You could temporarily add a dummy example somewhere in your suite which always fails. That way autospec will never think it's ready to run the whole suite. Other than that, I can't think of a way to do it short of writing your own autospec style and overriding the #run algorithm. Peeja On Fri, Feb 20, 2009 at 1:34 PM, Ben Mabey wrote: > Hello all, > Is there a way to have autospec and/or RSpactor just run the specs for the > files that have changed and not run the entire spec suite afterwards? If > you start autospec with -f it will wait for a change but it will then run > the entire suite after the individual one passes. The project that I am > working on now has a spec suite that is too long for the normal autospec > cycle. However, I like having that tight feedback loop for the files I > touch. Any ideas? > > Thanks, > Ben > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From zach.dennis at gmail.com Fri Feb 20 14:56:01 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Fri, 20 Feb 2009 14:56:01 -0500 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: <2c7e61990902200959s214fd1b9wc82c9f8e048d4f2e@mail.gmail.com> References: <499DC716.3050904@gmx.de> <85d99afe0902191353m31bf8476xcd930f075d4d9099@mail.gmail.com> <5424C9CE-2689-4139-80ED-DC45DCEA4AB9@mattwynne.net> <2c7e61990902200959s214fd1b9wc82c9f8e048d4f2e@mail.gmail.com> Message-ID: <85d99afe0902201156u451661eblb85415be45dd66bb@mail.gmail.com> On Fri, Feb 20, 2009 at 12:59 PM, Pat Maddox wrote: > On Fri, Feb 20, 2009 at 6:20 AM, Matt Wynne wrote: >> >> On 19 Feb 2009, at 21:53, Zach Dennis wrote: >> >>> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne wrote: >>>> >>>> On 19 Feb 2009, at 20:54, Martin wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm trying to test my views using rspec. I want to test my edit- and >>>>> new-view also for the case an error occurs (something like "title can't >>>>> be >>>>> blank" and so on). >>>>> Can someone point me please to an example where I can see how to mock my >>>>> model and stub all methods needed for the view? >>>> >>>> I guess this isn't exactly what you want to hear, but I would counsel you >>>> against mocking your whole model object for a form with lots of fields - >>>> those kind of 'broad' mocks can be very brittle to changes in your domain >>>> model. >>>> >>>> Can you try using stub_model instead? This creates an instance of your >>>> actual model class, but with a crippled database connection. You can then >>>> create an invalid model object and throw it to the view. Something like: >>>> >>>> assigns[:book] = stub_model(Book, :title => '') >>>> >>>> If your model is at all interesting, you might want to keep the >>>> attributes >>>> that make a valid Book somewhere: >>>> >>>> valid_book = { >>>> :title => "Test Book Title", >>>> :author => "Test Author" >>>> } >>>> assigns[:book] = stub_model(Book, valid_book.merge(:title => '')) >>>> >>>> I generally hide these behind a helper method, like >>>> >>>> def stub_book(attributes = {}) >>>> stub_model Book, { >>>> :title => "Test Book Title", >>>> :author => "Test Author" >>>> }.merge(attributes) >>>> end >>> >>> Why hide them behind a helper? Why not just only specify them in >>> examples where they are used? ie: >>> >>> it "should display the book title" do >>> @book.stub!(:title).and_return "The Scarlet Letter" >>> render ... >>> response.should include_text("The Scarlet Letter") >>> end >> >> Why hide them in a helper? because I don't want the noise of all the >> attributes needed to make a valid book in each test. > > Also so that when you change validations, you only have to change one > part of test code instead of every test that uses that model. > Right, it wasn't what I thought Matt was getting at. I thought he was specifically referring to hiding things pertinent in a view spec behind a helper. But that turned out to not be the case, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From lists at ruby-forum.com Fri Feb 20 15:13:16 2009 From: lists at ruby-forum.com (James Byrne) Date: Fri, 20 Feb 2009 21:13:16 +0100 Subject: [rspec-users] specifying which button webrat should press In-Reply-To: References: <3a2f55b7586243049a0672974fabbaba@ruby-forum.com> <8d961d900811192106g6dc93a0fq5ef890c1ac9d4724@mail.gmail.com> <88fd8ddc0811200544j749b7f8fm957fb374569243c0@mail.gmail.com> Message-ID: Given this:

If I want webrat to select on the ccs id (#submit_commit_client) rather than the value (Create) how do I pass this to click_button? I have tried this: click_button("#submit_commit_client") Which gives this error: Could not find button "#submit_commit_client" (Webrat::NotFoundError) /usr/lib64/ruby/gems/1.8/gems/webrat-0.4.1/lib/webrat/core/locators/locator.rb:14:in `locate!' -- Posted via http://www.ruby-forum.com/. From zach.dennis at gmail.com Fri Feb 20 15:24:34 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Fri, 20 Feb 2009 15:24:34 -0500 Subject: [rspec-users] specifying which button webrat should press In-Reply-To: References: <3a2f55b7586243049a0672974fabbaba@ruby-forum.com> <8d961d900811192106g6dc93a0fq5ef890c1ac9d4724@mail.gmail.com> <88fd8ddc0811200544j749b7f8fm957fb374569243c0@mail.gmail.com>

Message-ID: <85d99afe0902201224h5948738anb13016780d1c71d7@mail.gmail.com> On Fri, Feb 20, 2009 at 3:13 PM, James Byrne wrote: > Given this: > > > > If I want webrat to select on the ccs id (#submit_commit_client) rather > than the value (Create) how do I pass this to click_button? > > I have tried this: > > click_button("#submit_commit_client") > Can you use the following or do you need to use an id for other reason? click_button "Create" > Which gives this error: > > Could not find button "#submit_commit_client" (Webrat::NotFoundError) > > /usr/lib64/ruby/gems/1.8/gems/webrat-0.4.1/lib/webrat/core/locators/locator.rb:14:in > `locate!' > -- > Posted via http://www.ruby-forum.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 sfeley at gmail.com Fri Feb 20 15:33:12 2009 From: sfeley at gmail.com (Stephen Eley) Date: Fri, 20 Feb 2009 15:33:12 -0500 Subject: [rspec-users] [RSpec][OT] have autospec just run changed files In-Reply-To: <937d9d810902201133k76ab868x64e6cb36b1723ee@mail.gmail.com> References: <499EF7C0.20301@benmabey.com> <937d9d810902201133k76ab868x64e6cb36b1723ee@mail.gmail.com> Message-ID: <1fb4df0902201233j2691cc97iba777ecc3ce78906@mail.gmail.com> On Fri, Feb 20, 2009 at 2:33 PM, Peter Jaros wrote: > > Other than that, I can't think of a way to do it short of writing your > own autospec style and overriding the #run algorithm. Which is almost exactly what I was about to suggest. >8-> Only you don't have to override #run, you can just fake it out at the point where it reruns all tests and skip that part. 1.) Make an autotest directory in your project. 2.) Add a file 'discover.rb' and include the following: Autotest.add_discovery { "mabey" } # Or whatever you want to call your specialization 3.) If you're using Rails and RSpec, you then need to add a file 'mabey_rails_rspec.rb'. If only RSpec, just 'mabey_rspec.rb'. If you're using Merb and RSpec, it needs to be 'mabey_merb_rspec.rb'. You get the point. Autotest's class and file discovery is just wonky. In it: class Autotest::MabeyRailsRspec < Autotest::RailsRspec # Or whatever your appropriate chain is def rerun_all_tests reset end end I figured that out from reading the Autotest code a while back and figuring out how to fix problems with Merb, RSpec and Cucumber. My conclusion is that Autotest is *sort of* elegant in its own way, but that way appears to be based on the standards of someone high on a cocktail of LSD and laudanum. It uses convention over configuration...sort of...except that you have to configure the conventions first. And then too much is hardcoded, and its inheritance and class-naming structure means you have to predict every possible combination of frameworks in advance. Someone needs to either hit it with the design pattern stick or write a new one. Maybe I will, the next time I manage to take a couple days off. -- 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 Fri Feb 20 15:46:22 2009 From: lists at ruby-forum.com (James Byrne) Date: Fri, 20 Feb 2009 21:46:22 +0100 Subject: [rspec-users] Cucumber Feature Scenario critique In-Reply-To: <754D5764-3410-4D13-888E-B972DB36F198@technomage.com> References: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> <754D5764-3410-4D13-888E-B972DB36F198@technomage.com> Message-ID: <42495fa2279e8a645b94c98a603ee8f3@ruby-forum.com> Michael Latta wrote: > I would suggest a different approach to organizing the features. ... > Requirements changes have a different workflow than implementation > bugs. I would recommend you track that difference in your project > management system. Keep an eye on how much changes after > implementation to measure how good your requirements capture has been. > > Michael This is probably another case where I simply have not yet established in myself a sensible mental framework for working with BDD. Bear with me as I struggle through this adjustment. My apprehension so far is that features are intended to drive out the design requirements by explicitly stating concrete examples of what the client considers desirable. The idea of a contract between developer and client arises from the mutual agreement on functional expression as given in the feature scenarios. Definition steps, on the other hand, are the purview of the design/development team. They can take any reasonable form so long as they: 1. test the functionality of the implementation in a meaningful way 2. meet the requirements of the scenario Unit tests are the purview of the implementers and are tied to their respective code modules. My concern arises from a desire to establish how I should organize the features in relation to one another. Given my understanding respecting features I proceeded from the belief that one could arbitrarily start anywhere in the system design. Features would allow one to elaborate both up and down in detail as appropriate for the stage of the project and the area of immediate concern. As a practical matter it appears to me that the logical flow is Authentication/Authorization, administrative functions relating to record maintenance, algorithmic user applications, report generation, utilities, and finally loose ends. The application can be sliced so that all or most of these issues are dealt with within one specific aspect before tackling another. We are using Redmine to administer the project so milestones, issue tracking and such are kept in there. However, I have acquired this notion of functional decomposition relating to features. As i see it the basic gross requirements of the system (there will be clients, there will be invoices, etc.) are expressed as scenarios in a feature file somewhere. Then as more detail is driven out more features are inserted into the composition tree as appropriate. Is this completely at odds with what I should be doing? -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Feb 20 15:50:44 2009 From: lists at ruby-forum.com (James Byrne) Date: Fri, 20 Feb 2009 21:50:44 +0100 Subject: [rspec-users] specifying which button webrat should press In-Reply-To: <85d99afe0902201224h5948738anb13016780d1c71d7@mail.gmail.com> References: <3a2f55b7586243049a0672974fabbaba@ruby-forum.com> <8d961d900811192106g6dc93a0fq5ef890c1ac9d4724@mail.gmail.com> <88fd8ddc0811200544j749b7f8fm957fb374569243c0@mail.gmail.com>

<85d99afe0902201224h5948738anb13016780d1c71d7@mail.gmail.com> Message-ID: Zach Dennis wrote: > > Can you use the following or do you need to use an id for other reason? > > click_button "Create" > That is how I am doing the check now. I am simply investigating whether another means is available to me. At the back of my mind is the idea that it is the presence of the function and not the form of the label that is important. By adding an id to the input tag and selecting on that then whatever the button itself is labeled as becomes unimportant. -- Posted via http://www.ruby-forum.com/. From zach.dennis at gmail.com Fri Feb 20 16:03:48 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Fri, 20 Feb 2009 16:03:48 -0500 Subject: [rspec-users] specifying which button webrat should press In-Reply-To: References: <3a2f55b7586243049a0672974fabbaba@ruby-forum.com> <8d961d900811192106g6dc93a0fq5ef890c1ac9d4724@mail.gmail.com> <88fd8ddc0811200544j749b7f8fm957fb374569243c0@mail.gmail.com>

<85d99afe0902201224h5948738anb13016780d1c71d7@mail.gmail.com> Message-ID: <85d99afe0902201303i2cd24303s614d6d830fd28cd6@mail.gmail.com> On Fri, Feb 20, 2009 at 3:50 PM, James Byrne wrote: > Zach Dennis wrote: > >> >> Can you use the following or do you need to use an id for other reason? >> >> click_button "Create" >> > > That is how I am doing the check now. I am simply investigating whether > another means is available to me. You should be able to click the button by id, by not using a CSS selector. ie: click_button "submit_commit_client" > At the back of my mind is the idea > that it is the presence of the function and not the form of the label > that is important. By adding an id to the input tag and selecting on > that then whatever the button itself is labeled as becomes unimportant. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From lists at ruby-forum.com Fri Feb 20 16:28:34 2009 From: lists at ruby-forum.com (James Byrne) Date: Fri, 20 Feb 2009 22:28:34 +0100 Subject: [rspec-users] specifying which button webrat should press In-Reply-To: <85d99afe0902201303i2cd24303s614d6d830fd28cd6@mail.gmail.com> References: <3a2f55b7586243049a0672974fabbaba@ruby-forum.com> <8d961d900811192106g6dc93a0fq5ef890c1ac9d4724@mail.gmail.com> <88fd8ddc0811200544j749b7f8fm957fb374569243c0@mail.gmail.com>

<85d99afe0902201224h5948738anb13016780d1c71d7@mail.gmail.com> <85d99afe0902201303i2cd24303s614d6d830fd28cd6@mail.gmail.com> Message-ID: <6a89561e244e69d663bf7220d5b4a3d1@ruby-forum.com> Zach Dennis wrote: > > You should be able to click the button by id, by not using a CSS > selector. ie: > > click_button "submit_commit_client" > You are right. That works. Thank you. Regards, -- Posted via http://www.ruby-forum.com/. From fkchang2000 at yahoo.com Fri Feb 20 16:41:27 2009 From: fkchang2000 at yahoo.com (Forrest Chang) Date: Fri, 20 Feb 2009 13:41:27 -0800 (PST) Subject: [rspec-users] Using cucumber profiles with rake task References: Message-ID: <249741.2675.qm@web82808.mail.mud.yahoo.com> ----- Original Message ---- > Message: 4 > Date: Tue, 10 Feb 2009 10:43:35 -0500 > From: Zach Dennis > The Cucumber rake task doesn't support profiles very well. There is a > ticket for this: > > http://rspec.lighthouseapp.com/projects/16211/tickets/187-rake-task-support-cucumberyml-profiles > > On the ticket Ben Mabey provided his current solution, which is to > clear out the feature list: > > Cucumber::Rake::Task.new(:selenium) do |t| > ENV['WEBRAT'] = 'selenium' > t.cucumber_opts = "--profile selenium" > t.feature_list = [] > end > I just did this sort of thing, you also need to set t.step_list = [], else the rake task will expand all steps in the features directories as well. Forrest From sfeley at gmail.com Fri Feb 20 23:02:10 2009 From: sfeley at gmail.com (Stephen Eley) Date: Fri, 20 Feb 2009 23:02:10 -0500 Subject: [rspec-users] Cucumber Feature Scenario critique In-Reply-To: <42495fa2279e8a645b94c98a603ee8f3@ruby-forum.com> References: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> <754D5764-3410-4D13-888E-B972DB36F198@technomage.com> <42495fa2279e8a645b94c98a603ee8f3@ruby-forum.com> Message-ID: <1fb4df0902202002p4c4bbd19v1874f753878a0b82@mail.gmail.com> On Fri, Feb 20, 2009 at 3:46 PM, James Byrne wrote: > > As a practical matter it appears to me that the logical flow is > Authentication/Authorization, administrative functions relating to > record maintenance, algorithmic user applications, report generation, > utilities, and finally loose ends. The application can be sliced so > that all or most of these issues are dealt with within one specific > aspect before tackling another. > [ . . . ] > > Is this completely at odds with what I should be doing? Well... In my opinion, yes and no. I personally have my doubts about the 'waterfall' chain of serial projects you're talking about here. "We will do authorization. Then we will do admin screens. Then we will..." For one thing it's not very agile; what you learn when you start getting requirements for reporting will surely change what you thought was 'complete' earlier. And it seems harder to sell and keep the client engaged because the sexy stuff, the business value the client *cares* about, doesn't happen until somewhere in the middle. It's my experience that the most effective projects begin early with things you can *show.* You can't really show off authorization. It's visible, but it doesn't excite people. You need to have some basic stuff in for it before you can open it up to the public, but it's not necessarily Square One, and treating it like it is might overemphasize its importance. (And I say this as someone who recently spent a couple of days designing a hierarchical polymorphic authorization framework from hell [http://tinyurl.com/d6w4t8] so don't think I'm discounting it completely.) So I'd personally worry less about getting all your administrative ducks in a row before you start to do anything interesting, and instead _start_ with whatever drives the most value to your company and then build the support framework around it only when it's needed. You might find when you do that that you need fewer struts and pins and guywires than you thought you did. ...But that has nothing to do with RSpec and very little to do with BDD, except in a very general 'start with the behavior you *care* about the most' sense. Odds aren't high that the thing you care about the most in the application is logging in. So spec that out later and start with something more interesting. You'll hit the ground running. Otherwise, it all looks fine. >8-> -- 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 Fri Feb 20 23:33:06 2009 From: lists at ruby-forum.com (James Byrne) Date: Sat, 21 Feb 2009 05:33:06 +0100 Subject: [rspec-users] Cucumber Feature Scenario critique In-Reply-To: <1fb4df0902202002p4c4bbd19v1874f753878a0b82@mail.gmail.com> References: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> <754D5764-3410-4D13-888E-B972DB36F198@technomage.com> <42495fa2279e8a645b94c98a603ee8f3@ruby-forum.com> <1fb4df0902202002p4c4bbd19v1874f753878a0b82@mail.gmail.com> Message-ID: Stephen Eley wrote: > > Well... In my opinion, yes and no. I personally have my doubts about > the 'waterfall' chain of serial projects you're talking about here. > "We will do authorization. Then we will do admin screens. Then we > will..." Perhaps I expressed myself poorly, or perhaps I am missing something fundamental in your commentary. I did not mean to imply that an authorization system had to be "finished", and then record maintenance system "done", before getting into the interesting bits. I only meant that having tried to start in the middle, with the interesting bits insofar as the client is concerned, I quickly discovered that some minimal provision for authentication and record maintenance seemed a prerequisite to support work on the middle. For some reason I seem to have an aversion to using fixtures for this purpose and prefer some sort of interactive UI, however primitive. For instance this is my authorization implementation: def authorized?(auth_request={}) #myrole = auth_request[:role] #myctlr = auth_request[:controller] #myactn = auth_request[:action] return true if self.administrator return false end I did not spend very much time or effort on this but it seemed best to provide the authorization interface when working on user facing components. The future elaboration of the authorization system will nonetheless still present the same interface to the rest of the system, or so I intend. What I am grasping at understanding is how elaborate the feature files should be and how the interrelationship between features are best managed or expressed. -- Posted via http://www.ruby-forum.com/. From mark at mwilden.com Fri Feb 20 23:32:56 2009 From: mark at mwilden.com (Mark Wilden) Date: Fri, 20 Feb 2009 20:32:56 -0800 Subject: [rspec-users] Cucumber Feature Scenario critique In-Reply-To: <1fb4df0902202002p4c4bbd19v1874f753878a0b82@mail.gmail.com> References: <5f0f67d14c7eee172dc6db9a14be3ded@ruby-forum.com> <754D5764-3410-4D13-888E-B972DB36F198@technomage.com> <42495fa2279e8a645b94c98a603ee8f3@ruby-forum.com> <1fb4df0902202002p4c4bbd19v1874f753878a0b82@mail.gmail.com> Message-ID: <3c30da400902202032h64502609yf60fb9f5daafd5ce@mail.gmail.com> On Fri, Feb 20, 2009 at 8:02 PM, Stephen Eley wrote: > > You can't really show off authorization. It's visible, but it doesn't > excite people. You need to have some basic stuff in for it before you > can open it up to the public, but it's not necessarily Square One, and > treating it like it is might overemphasize its importance. Agreed. I've seen projects that weren't public yet, didn't do anything useful, yet had a full authorization model - which did nothing but annoy new developers. ///ark From ben at benmabey.com Sat Feb 21 01:33:46 2009 From: ben at benmabey.com (Ben Mabey) Date: Fri, 20 Feb 2009 23:33:46 -0700 Subject: [rspec-users] [RSpec][OT] have autospec just run changed files In-Reply-To: <1fb4df0902201233j2691cc97iba777ecc3ce78906@mail.gmail.com> References: <499EF7C0.20301@benmabey.com> <937d9d810902201133k76ab868x64e6cb36b1723ee@mail.gmail.com> <1fb4df0902201233j2691cc97iba777ecc3ce78906@mail.gmail.com> Message-ID: <499FA04A.1020308@benmabey.com> Stephen Eley wrote: > On Fri, Feb 20, 2009 at 2:33 PM, Peter Jaros wrote: > >> Other than that, I can't think of a way to do it short of writing your >> own autospec style and overriding the #run algorithm. >> > > Which is almost exactly what I was about to suggest. >8-> Only you > don't have to override #run, you can just fake it out at the point > where it reruns all tests and skip that part. > > 1.) Make an autotest directory in your project. > 2.) Add a file 'discover.rb' and include the following: > Autotest.add_discovery { "mabey" } # Or whatever you want to call > your specialization > 3.) If you're using Rails and RSpec, you then need to add a file > 'mabey_rails_rspec.rb'. If only RSpec, just 'mabey_rspec.rb'. If > you're using Merb and RSpec, it needs to be 'mabey_merb_rspec.rb'. > You get the point. Autotest's class and file discovery is just wonky. > In it: > > class Autotest::MabeyRailsRspec < Autotest::RailsRspec # Or > whatever your appropriate chain is > def rerun_all_tests > reset > end > end > > I figured that out from reading the Autotest code a while back and > figuring out how to fix problems with Merb, RSpec and Cucumber. My > conclusion is that Autotest is *sort of* elegant in its own way, but > that way appears to be based on the standards of someone high on a > cocktail of LSD and laudanum. It uses convention over > configuration...sort of...except that you have to configure the > conventions first. And then too much is hardcoded, and its > inheritance and class-naming structure means you have to predict every > possible combination of frameworks in advance. > > Someone needs to either hit it with the design pattern stick or write > a new one. Maybe I will, the next time I manage to take a couple days > off. > > > > Thanks a lot! I couldn't get your exact way to work so I ended up monkey patching Autotest with your #rerun_all_tests in my .autotest file. So far it is working great. Thanks again! -Ben From listaccount at e-tobi.net Sat Feb 21 06:31:05 2009 From: listaccount at e-tobi.net (Tobi) Date: Sat, 21 Feb 2009 12:31:05 +0100 Subject: [rspec-users] Mocking base class methods Message-ID: <499FE5F9.3050905@e-tobi.net> Hi! I need to write some wrapper classes, that derive from SWIG generated proxy classes for some C/C++ extensions. The Ruby wrapper classes need to do a lot of 'super' calls to the base classes generated by SWIG. The question is: Is there any way to make RSpec mock a base class and record/verify that certain methods on a base class are called? As long as the methods in the derived class have different names this is no problem, but otherwise it doesn't seem to be possible - at least not with RSpec's mocking/stubbing facilities, does it? I see other ways to do this, like wrapping an instance of the Swig class instead of deriving from it or writing some custom mocking code that fakes the base class e.g. with define_method, but I'm especially asking if this is possible with RSpec. thx, Tobias module Swig class Base def initialize(arg) end def do_something(arg) end end end module Wrapper class Derived << Swig::Base def initialize(arg) super(arg) yield(self) if block_given? end def do_something(arg) do_something(arg) # additional behaviour here end end end describe Wrapper::Derived do it 'should initialize the base class with the same argument' do # No idea, how to mock Base.initialize() here end it 'should do something with the base class when doing something' do # No idea, how to mock Base.do_something() here end end From html-kurs at gmx.de Sat Feb 21 07:04:36 2009 From: html-kurs at gmx.de (Martin) Date: Sat, 21 Feb 2009 13:04:36 +0100 Subject: [rspec-users] Mocking / stubbing errors for ActiveRecord In-Reply-To: References: <499DC716.3050904@gmx.de> Message-ID: <499FEDD4.7030508@gmx.de> Hello alltogether, thanks for your help. A mixture of stub_model and .errors.stub!() helped me to solve my problem. I also stumbled across the right arguments of have_tag. I thought it's similar to assert_select as the docs said. But it isn't. I found http://rubypond.com/articles/2008/03/31/using-rspec-have_tag/ which is a nice introduction to it. Thanks again, Martin From zuperinfinite at gmail.com Sat Feb 21 10:28:07 2009 From: zuperinfinite at gmail.com (Bart Zonneveld) Date: Sat, 21 Feb 2009 16:28:07 +0100 Subject: [rspec-users] [OT] Googled for 'cucumber page caching' Message-ID: ...and found this as 4th result: http://www.cafepress.com/foodparadise/4708787 cheers, bartz From phlip2005 at gmail.com Sat Feb 21 11:44:17 2009 From: phlip2005 at gmail.com (Phlip) Date: Sat, 21 Feb 2009 08:44:17 -0800 Subject: [rspec-users] [OT] Googled for 'cucumber page caching' In-Reply-To: References: Message-ID: Bart Zonneveld wrote: > ...and found this as 4th result: > http://www.cafepress.com/foodparadise/4708787 I have a husband named Dean Wormer at Faber. Still want to show me your cucumber? -- Marion Wormer From zach.dennis at gmail.com Sat Feb 21 14:48:21 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Sat, 21 Feb 2009 14:48:21 -0500 Subject: [rspec-users] Mocking base class methods In-Reply-To: <499FE5F9.3050905@e-tobi.net> References: <499FE5F9.3050905@e-tobi.net> Message-ID: <85d99afe0902211148p585d5e5cx283232b250f2e8b4@mail.gmail.com> On Sat, Feb 21, 2009 at 6:31 AM, Tobi wrote: > Hi! > > I need to write some wrapper classes, that derive from SWIG generated > proxy classes for some C/C++ extensions. > > The Ruby wrapper classes need to do a lot of 'super' calls to the base > classes generated by SWIG. > > The question is: Is there any way to make RSpec mock a base class and > record/verify that certain methods on a base class are called? > > As long as the methods in the derived class have different names this is > no problem, but otherwise it doesn't seem to be possible - at least not > with RSpec's mocking/stubbing facilities, does it? > > I see other ways to do this, like wrapping an instance of the Swig class > instead of deriving from it or writing some custom mocking code that fakes > the base class e.g. with define_method, but I'm especially asking if this > is possible with RSpec. +1 to composition over inheritance here. Mocking at different layers of an inheritance hierarchy sounds like trouble and screams to pull that thing apart. Composition will allow you to separate an inheritance hierarchy (if you do need one) from the swig base classes, and it provides a clean separation between the swig stuff and your application stuff. > > thx, > > Tobias > > module Swig > class Base > def initialize(arg) > end > > def do_something(arg) > end > end > end > > module Wrapper > class Derived << Swig::Base > def initialize(arg) > super(arg) > yield(self) if block_given? > end > > def do_something(arg) > do_something(arg) > # additional behaviour here > end > end > end > > describe Wrapper::Derived do > it 'should initialize the base class with the same argument' do > # No idea, how to mock Base.initialize() here > end > > it 'should do something with the base class when doing something' do > # No idea, how to mock Base.do_something() here > end > end > _______________________________________________ > 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 listaccount at e-tobi.net Sat Feb 21 16:24:06 2009 From: listaccount at e-tobi.net (Tobi) Date: Sat, 21 Feb 2009 22:24:06 +0100 Subject: [rspec-users] Mocking base class methods In-Reply-To: <85d99afe0902211148p585d5e5cx283232b250f2e8b4@mail.gmail.com> References: <499FE5F9.3050905@e-tobi.net> <85d99afe0902211148p585d5e5cx283232b250f2e8b4@mail.gmail.com> Message-ID: <49A070F6.2060107@e-tobi.net> Zach Dennis wrote: > +1 to composition over inheritance here. Mocking at different layers > of an inheritance hierarchy sounds like trouble and screams to pull > that thing apart. Good point! I've already tried the composition approach. It solves the testabilitiy problems, but it doesn't feel right in this case. Inheritance seems to be the more natural approach. The C++ application will call virtual methods on the base class which should be overriden in a derived class. So it seems to make sense to have the same inheritance tree in the Ruby counter parts. If I would use composition, I would at least need to dynamically extend the referenced base class so I can override some of the methods that are the counter parts of the virtual C++ methods. And I would need to expose the referenced class to the C++ code. I've finally found a way to kinda mock the base class in some way: module BaseClassMock attr_accessor :base def self.included(klass) class << klass @@base_class = Object.new def base_class return @@base_class end end end def initialize(*args) @@base_class.new(*args) if @@base_class.respond_to?(:new) @base = Object.new end def method_missing(symbol, *args) @base.send(symbol, *args) end end Any base class (Swig classes in my case) should then be declared for RSpec like: module Swig class Base; include BaseClassMock; end end And in the specs I can then do: Derived.base_class.should_receive(:new).with('something') d = Derived.new('something') or: d = Derived.new d.base.should_receive(:do_something) d.do_something Tobias From mark at mwilden.com Sat Feb 21 20:29:55 2009 From: mark at mwilden.com (Mark Wilden) Date: Sat, 21 Feb 2009 17:29:55 -0800 Subject: [rspec-users] [Cucumber] host! Message-ID: <3c30da400902211729x4f569a68l29bcd6c7d0fbdf2d@mail.gmail.com> I'm trying to set a specific host that all my Cucumber steps should use. Putting 'host! "beta.rupture.local"' in Before in env.rb doesn't produce any errors, but it doesn't seem to be making the next request use that host, either. If I explicitly create a step whose definition includes 'host! "beta.rupture.local"' then the next request does use that host. But I don't want to have to include this step in every feature. ///ark From aslak.hellesoy at gmail.com Sun Feb 22 05:03:34 2009 From: aslak.hellesoy at gmail.com (=?utf-8?Q?Aslak_Helles=C3=B8y?=) Date: Sun, 22 Feb 2009 11:03:34 +0100 Subject: [rspec-users] [Cucumber] host! In-Reply-To: <3c30da400902211729x4f569a68l29bcd6c7d0fbdf2d@mail.gmail.com> References: <3c30da400902211729x4f569a68l29bcd6c7d0fbdf2d@mail.gmail.com> Message-ID: Den 22. feb.. 2009 kl. 02.29 skrev Mark Wilden : > I'm trying to set a specific host that all my Cucumber steps should > use. Putting 'host! "beta.rupture.local"' in Before in env.rb doesn't > produce any errors, but it doesn't seem to be making the next request > use that host, either. > > If I explicitly create a step whose definition includes 'host! > "beta.rupture.local"' then the next request does use that host. But I > don't want to have to include this step in every feature. > Please submit a bug report. Aslak > ///ark > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Sun Feb 22 05:23:57 2009 From: lists at ruby-forum.com (Kaleem Ullah) Date: Sun, 22 Feb 2009 11:23:57 +0100 Subject: [rspec-users] Culerity Error while running feature. Message-ID: Hi All, I need your guide on an issue. My Environment: Window xp , Rails 2.2.2, Rspec-rails 1.1.11, Rspec 1.1.11, Cucmber , Webrat,Culerity I installed the jruby, sets its path in environment. It shows me Version of jruby also. Now the problem is when before installing langalex-culerity(http://github.com/langalex/culerity/tree/master) my cucumber and rspec are working fine. Now i have to test my javascript and ajax and i installed cularity. When i run "rake features". it gives me this error. Scenario: Log in # features/manage_logins.feature:5 C:/Documents and Settings/Administrator/My Documents/NetBeansProjects/1.4/vendor/gems/langalex-culerity-0.1.2/lib/culerity.rb :7:in `popen': Exec format error - jruby C:/Documents and Settings/Administrator/My Documents/NetBeansProjects/1.4/vendor/gem s/langalex-culerity-0.1.2/lib/culerity.rb (Errno::ENOEXEC) from C:/Documents and Settings/Administrator/My Documents/NetBeansProjects/1.4/vendor/gems/langalex-culerity-0.1.2/li b/culerity.rb:7:in `run_server' from ./features/step_definitions/common_celerity.rb:2:in `__cucumber_45721280' from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/../lib/cucumber/core_ext/proc.rb:48:in `__send__' from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/../lib/cucumber/core_ext/proc.rb:48:in `call_in' from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/../lib/cucumber/executor.rb:86:in `execute_scenario' from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/../lib/cucumber/executor.rb:86:in `each' from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/../lib/cucumber/executor.rb:86:in `execute_scenario' from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/../lib/cucumber/executor.rb:75:in `visit_scenario' ... 10 levels... from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/../lib/cucumber/cli.rb:13:in `execute' from c:/ruby/lib/ruby/gems/1.8/gems/cucumber-0.1.16/bin/cucumber:6 from c:/ruby/bin/cucumber:19:in `load' from c:/ruby/bin/cucumber:19 Thanks for your Help. Regards, Kaleem Ullah -- Posted via http://www.ruby-forum.com/. From joahking at gmail.com Sun Feb 22 07:42:35 2009 From: joahking at gmail.com (Joaquin Rivera Padron) Date: Sun, 22 Feb 2009 13:42:35 +0100 Subject: [rspec-users] Culerity Error while running feature. In-Reply-To: References: Message-ID: <8277b7f40902220442w7e94c5d1gab8f085d19728dd5@mail.gmail.com> hey Kaleem, I am myself no expert on w$ but the line throwing the error is def self.run_server IO.popen("jruby #{__FILE__}", 'r+') end are you able to run popen calls in w$ ? try your irb and see, if not maybe there's some w$ expert who can help hope that helps joaquin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Sun Feb 22 10:34:37 2009 From: lists at ruby-forum.com (Jacob Radford) Date: Sun, 22 Feb 2009 16:34:37 +0100 Subject: [rspec-users] =?utf-8?q?=5BCucumber=2C_Webrat=5D_Error_backtraces?= =?utf-8?q?_shown_as_HTML_=09in_co?= In-Reply-To: <2C6FB417-AA52-4A94-8102-B8D611590CA9@mattwynne.net> References: <8d961d900902050300q54a19aefnaca7e763fe12f6af@mail.gmail.com> <2C6FB417-AA52-4A94-8102-B8D611590CA9@mattwynne.net> Message-ID: <4ce11b3f91545ac52bcdc75865442bc1@ruby-forum.com> > Rails' HTML error page. It comes up both in my browser (presumably > save_and_open_page doing its thing) and the same HTML is dumped to the > console. > > Can anyone else confirm that with latest Cucumber and Webrat they > *don't* get this behaviour? I do see this behavior and it is specifically a Webrat issue. I'm linking to the gist which I use to remedy it: http://gist.github.com/68497 Hope that helps. -- Posted via http://www.ruby-forum.com/. From joahking at gmail.com Sun Feb 22 10:37:17 2009 From: joahking at gmail.com (Joaquin Rivera Padron) Date: Sun, 22 Feb 2009 16:37:17 +0100 Subject: [rspec-users] Cucumber now runs Webrat and Celerity together Message-ID: <8277b7f40902220737r801a61bxb15140f2208fe8c1@mail.gmail.com> hey there, I have Cucumber running Webrat and Celerity (using culerity) together, check it out in the sample project: http://github.com/joahking/cukes/tree/masters It's a first try, but it runs. I get them by following a feature directory structure similar to the suggested in http://wiki.github.com/aslakhellesoy/cucumber/setting-up-selenium (also thanks to the hints Ben Mabbey pointed) by defining profiles for webrat and celerity you can run features with any of them: cucumber -p webrat and cucumber -p celerity only I don't seem to get Celerity browser to receive the ajax pushing from rails action (have tried browser.wait, also other recommendations from celerity github wiki, but it wont go), any help would be appreciated. cheers, joaquin -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak.hellesoy at gmail.com Sun Feb 22 10:49:59 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 22 Feb 2009 16:49:59 +0100 Subject: [rspec-users] Culerity Error while running feature. In-Reply-To: <8277b7f40902220442w7e94c5d1gab8f085d19728dd5@mail.gmail.com> References: <8277b7f40902220442w7e94c5d1gab8f085d19728dd5@mail.gmail.com> Message-ID: <8d961d900902220749o6885037kf8b848098f5a50f@mail.gmail.com> On Sun, Feb 22, 2009 at 1:42 PM, Joaquin Rivera Padron wrote: > hey Kaleem, > I am myself no expert on w$ but the line throwing the error is > def self.run_server > IO.popen("jruby #{__FILE__}", 'r+') When forking a new ruby interpreter, always use rbconfig: require 'rbconfig' ruby = File.join(Config::CONFIG['bindir'], Config::CONFIG['ruby_install_name']) IO.popen("#{ruby} #{__FILE__}", 'r+') If you don't, you might end up running a different ruby than the one you want. Aslak > end > are you able to run popen calls in w$ ? try your irb and see, if not maybe > there's some w$ expert who can help > > hope that helps > joaquin > > > > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Aslak (::) From dchelimsky at gmail.com Sun Feb 22 11:10:35 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 22 Feb 2009 10:10:35 -0600 Subject: [rspec-users] [ANN] rspec-1.2 release candidate In-Reply-To: <47e4b956d5e2a4ffc7eab7f43602575d@ruby-forum.com> References: <57c63afe0902182256h37f6449exc29e03cf1275d804@mail.gmail.com> <31D30E37-CF11-4541-B3E4-20C5068AEFB4@wincent.com> <57c63afe0902190558m14107313j9bfa949c48c1c9f1@mail.gmail.com> <47e4b956d5e2a4ffc7eab7f43602575d@ruby-forum.com> Message-ID: <57c63afe0902220810r5874e922s9f87cab3afb40cf4@mail.gmail.com> On Fri, Feb 20, 2009 at 4:35 AM, Juanma Cervera wrote: > David, > > I have an error when trying to run autospec. > It works when I run 'rake spec' > > I don know why it is still using the rspec-1.1.12 gem. > > > /usr/lib/ruby/gems/1.8/gems/dchelimsky-rspec-1.1.99.7/lib/spec/autorun.rb:3: > undefined method `autorun' for Spec::Runner:Module (NoMethodError) > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in > `gem_original_require' > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in > `require' > from > /home/jmcervera/.gem/ruby/1.8/gems/activesupport-2.3.0/lib/active_support/dependencies.rb:158:in > `require' > from ./spec/models/../spec_helper.rb:5 > from ./spec/models/cliente_spec.rb:1:in `require' > from ./spec/models/cliente_spec.rb:1 > from > /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:15:in > `load' > from > /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:15:in > `load_files' > from > /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:14:in > `each' > from > /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/example_group_runner.rb:14:in > `load_files' > from > /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/options.rb:94:in > `run_examples' > from > /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/lib/spec/runner/command_line.rb:9:in > `run' > from /usr/lib/ruby/gems/1.8/gems/rspec-1.1.12/bin/spec:4 Can you please submit a bug report? Thanks, David > > Thanks > Juanma > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Sun Feb 22 11:39:22 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 22 Feb 2009 10:39:22 -0600 Subject: [rspec-users] [RSpec][OT] have autospec just run changed files In-Reply-To: <499FA04A.1020308@benmabey.com> References: <499EF7C0.20301@benmabey.com> <937d9d810902201133k76ab868x64e6cb36b1723ee@mail.gmail.com> <1fb4df0902201233j2691cc97iba777ecc3ce78906@mail.gmail.com> <499FA04A.1020308@benmabey.com> Message-ID: <57c63afe0902220839x1154ba30r37ad7d11254a462@mail.gmail.com> On Sat, Feb 21, 2009 at 12:33 AM, Ben Mabey wrote: > Stephen Eley wrote: >> >> On Fri, Feb 20, 2009 at 2:33 PM, Peter Jaros >> wrote: >> >>> >>> Other than that, I can't think of a way to do it short of writing your >>> own autospec style and overriding the #run algorithm. >>> >> >> Which is almost exactly what I was about to suggest. >8-> Only you >> don't have to override #run, you can just fake it out at the point >> where it reruns all tests and skip that part. >> >> 1.) Make an autotest directory in your project. >> 2.) Add a file 'discover.rb' and include the following: >> Autotest.add_discovery { "mabey" } # Or whatever you want to call >> your specialization >> 3.) If you're using Rails and RSpec, you then need to add a file >> 'mabey_rails_rspec.rb'. If only RSpec, just 'mabey_rspec.rb'. If >> you're using Merb and RSpec, it needs to be 'mabey_merb_rspec.rb'. >> You get the point. Autotest's class and file discovery is just wonky. >> In it: >> >> class Autotest::MabeyRailsRspec < Autotest::RailsRspec # Or >> whatever your appropriate chain is >> def rerun_all_tests >> reset >> end >> end >> >> I figured that out from reading the Autotest code a while back and >> figuring out how to fix problems with Merb, RSpec and Cucumber. My >> conclusion is that Autotest is *sort of* elegant in its own way, but >> that way appears to be based on the standards of someone high on a >> cocktail of LSD and laudanum. It uses convention over >> configuration...sort of...except that you have to configure the >> conventions first. And then too much is hardcoded, and its >> inheritance and class-naming structure means you have to predict every >> possible combination of frameworks in advance. >> >> Someone needs to either hit it with the design pattern stick or write >> a new one. Maybe I will, the next time I manage to take a couple days >> off. >> >> >> >> > > Thanks a lot! > I couldn't get your exact way to work so I ended up monkey patching Autotest > with your #rerun_all_tests in my .autotest file. So far it is working > great. Thanks again! I wonder if this might be a better approach to dealing with Autotest extensions. There seems to be an issue with Autotest extensions and ruby 1.9 (1.9 confusing bin/autotest and an ./autoest directory). We could do the following without putting any burden on Autotest: Move what is now in lib/autotest/rspec.rb (lib/autotest/rails_rspec.rb in rspec-rails) to something like lib/spec/autotest.rb, which you'd have to require in .autotest. Done! Unless I'm missing something. This would put an extra step to using autotest, but it solves the 1.9 problem and it also makes it so we no longer need autospec, which I wouldn't mind getting rid of in the long run. Thoughts? > > -Ben > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From joahking at gmail.com Sun Feb 22 13:24:25 2009 From: joahking at gmail.com (Joaquin Rivera Padron) Date: Sun, 22 Feb 2009 19:24:25 +0100 Subject: [rspec-users] Culerity Error while running feature. In-Reply-To: <8d961d900902220749o6885037kf8b848098f5a50f@mail.gmail.com> References: <8277b7f40902220442w7e94c5d1gab8f085d19728dd5@mail.gmail.com> <8d961d900902220749o6885037kf8b848098f5a50f@mail.gmail.com> Message-ID: <8277b7f40902221024q4adaeb98y775a47b3e12b4d9c@mail.gmail.com> cool, I'll give that a try in short thanks joaquin 2009/2/22, aslak hellesoy : > On Sun, Feb 22, 2009 at 1:42 PM, Joaquin Rivera Padron > wrote: >> hey Kaleem, >> I am myself no expert on w$ but the line throwing the error is >> def self.run_server >> IO.popen("jruby #{__FILE__}", 'r+') > > When forking a new ruby interpreter, always use rbconfig: > > require 'rbconfig' > ruby = File.join(Config::CONFIG['bindir'], > Config::CONFIG['ruby_install_name']) > IO.popen("#{ruby} #{__FILE__}", 'r+') > > If you don't, you might end up running a different ruby than the one you > want. > > Aslak > >> end >> are you able to run popen calls in w$ ? try your irb and see, if not maybe >> there's some w$ expert who can help >> >> hope that helps >> joaquin >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- www.least-significant-bit.com From hayafirst at gmail.com Sun Feb 22 14:47:17 2009 From: hayafirst at gmail.com (Yi Wen) Date: Sun, 22 Feb 2009 13:47:17 -0600 Subject: [rspec-users] [cucumber] Cucumber and CI Message-ID: The rhythm for wrking with cucumber advertised by http://cukes.info/ is to write tests that fails first, then code that fixes it. Now my question is, what is the implication when combine this with Continuous Integration? We all know when we do TDD/BDD in unit level, one test can be fixed fairly quick in a coupe minutes and we can check in and kick off a build. It is a ideal scene for doing CI: frequent checkin and fast feedback on build results. Cucumber, as far as my understanding goes, works on feature level. It could take people days to finish a cucumber feature. In the meantime, the cucumber test remains broken. What do we do then? We cannot check in any code because that'll break the build. So we can only checkin code after several days? It doesn't sound right to me. Any takes on this issue? Thanks in advance. Yi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at mwilden.com Sun Feb 22 15:19:31 2009 From: mark at mwilden.com (Mark Wilden) Date: Sun, 22 Feb 2009 12:19:31 -0800 Subject: [rspec-users] [Cucumber] host! In-Reply-To: References: <3c30da400902211729x4f569a68l29bcd6c7d0fbdf2d@mail.gmail.com> Message-ID: <3c30da400902221219t73daaf8fn3f4d8e9849c30774@mail.gmail.com> On Sun, Feb 22, 2009 at 2:03 AM, Aslak Helles?y wrote: > Den 22. feb.. 2009 kl. 02.29 skrev Mark Wilden : > >> I'm trying to set a specific host that all my Cucumber steps should >> use. Putting 'host! "beta.rupture.local"' in Before in env.rb doesn't >> produce any errors, but it doesn't seem to be making the next request >> use that host, either. >> >> If I explicitly create a step whose definition includes 'host! >> "beta.rupture.local"' then the next request does use that host. But I >> don't want to have to include this step in every feature. >> > Ple Sure. Where? I don't see anything on http://wiki.github.com/aslakhellesoy/cucumber and if Lighthouse has a search function, I couldn't find it. ///ark From v.ondruch at gmail.com Sun Feb 22 15:34:15 2009 From: v.ondruch at gmail.com (vo.x) Date: Sun, 22 Feb 2009 12:34:15 -0800 (PST) Subject: [rspec-users] send_file testing Message-ID: <7ca1493b-5301-44bb-98ce-3441480bba85@f33g2000vbf.googlegroups.com> Hello all, Is there some best practice how to test Rails controller action which is using send_file method? Could you help me please? Vit From zach.dennis at gmail.com Sun Feb 22 16:07:27 2009 From: zach.dennis at gmail.com (Zach Dennis) Date: Sun, 22 Feb 2009 16:07:27 -0500 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: Message-ID: <85d99afe0902221307k3bf9a1bfld00743e37be454db@mail.gmail.com> On Sun, Feb 22, 2009 at 2:47 PM, Yi Wen wrote: > The rhythm for wrking with cucumber advertised by http://cukes.info/ is to > write tests that fails first, then code that fixes it. Now my question is, > what is the implication when combine this with Continuous Integration? > > We all know when we do TDD/BDD in unit level, one test can be fixed fairly > quick in a coupe minutes and we can check in and kick off a build. It is a > ideal scene for doing CI: frequent checkin and fast feedback on build > results. > > Cucumber, as far as my understanding goes, works on feature level. It could > take people days to finish a cucumber feature. In the meantime, the cucumber > test remains broken. What do we do then? We cannot check in any code because > that'll break the build. So we can only checkin code after several days? It > doesn't sound right to me. Any takes on this issue? Thanks in advance. > I use git, create a new branch for a feature, and work in that branch while I'm implementing the feature. As I reach stable points in the feature (even though it may not be done) I will merge into master and push the changes. Usually at this point I've reached the end of a step definition so the next step isn't failing, it's just pending. If unable to reach a stable point to merge back into master one option is to call "pending" inside of the step definition you were last working on, so CI doesn't use that to signify that someone broke the build. This lets you merge back into master and push. Most of the time I work in the feature branch, continually updating and rebasing as others push changes so I'm not out of sync, and then I merge back into master and push when the feature is either stable or done. I'm sure there are lots of ways to go about this though, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From mark at mwilden.com Sun Feb 22 16:09:41 2009 From: mark at mwilden.com (Mark Wilden) Date: Sun, 22 Feb 2009 13:09:41 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: Message-ID: <3c30da400902221309s7a64950en10acba4a3c463581@mail.gmail.com> On Sun, Feb 22, 2009 at 11:47 AM, Yi Wen wrote: > Cucumber, as far as my understanding goes, works on feature level. It could > take people days to finish a cucumber feature. In the meantime, the cucumber > test remains broken. What do we do then? We cannot check in any code because > that'll break the build. So we can only checkin code after several days? It > doesn't sound right to me. Any takes on this issue? Thanks in advance. What I do is write the feature, and check that in. Then I work on each step definition TDD-wise, checking in each as it runs without error and without failing the expectation. So I check in yellow (with pending steps) and when there are no more pending steps, I mark the feature as finished. ///ark From aslak.hellesoy at gmail.com Sun Feb 22 16:13:29 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 22 Feb 2009 22:13:29 +0100 Subject: [rspec-users] [Cucumber] host! In-Reply-To: <3c30da400902221219t73daaf8fn3f4d8e9849c30774@mail.gmail.com> References: <3c30da400902211729x4f569a68l29bcd6c7d0fbdf2d@mail.gmail.com> <3c30da400902221219t73daaf8fn3f4d8e9849c30774@mail.gmail.com> Message-ID: <8d961d900902221313h4e4bf405x7b845afd5b711429@mail.gmail.com> On Sun, Feb 22, 2009 at 9:19 PM, Mark Wilden wrote: > On Sun, Feb 22, 2009 at 2:03 AM, Aslak Helles?y > wrote: >> Den 22. feb.. 2009 kl. 02.29 skrev Mark Wilden : >> >>> I'm trying to set a specific host that all my Cucumber steps should >>> use. Putting 'host! "beta.rupture.local"' in Before in env.rb doesn't >>> produce any errors, but it doesn't seem to be making the next request >>> use that host, either. >>> >>> If I explicitly create a step whose definition includes 'host! >>> "beta.rupture.local"' then the next request does use that host. But I >>> don't want to have to include this step in every feature. >>> >> Ple > > Sure. Where? I don't see anything on > http://wiki.github.com/aslakhellesoy/cucumber and if Lighthouse has a > search function, I couldn't find it. > Both the "Getting in touch" page in the wiki and the top menu on cukes.info has links to Lighthouse. Aslak > ///ark > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Aslak (::) From aslak.hellesoy at gmail.com Sun Feb 22 16:36:56 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 22 Feb 2009 22:36:56 +0100 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: Message-ID: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> On Sun, Feb 22, 2009 at 8:47 PM, Yi Wen wrote: > The rhythm for wrking with cucumber advertised by http://cukes.info/ is to > write tests that fails first, then code that fixes it. Now my question is, > what is the implication when combine this with Continuous Integration? > * Nobody checks in code with failing tests (cucumber features, rspec tests, anything else). * If someone accidentally does, CI will run all tests and tell the team. > We all know when we do TDD/BDD in unit level, one test can be fixed fairly > quick in a coupe minutes and we can check in and kick off a build. It is a > ideal scene for doing CI: frequent checkin and fast feedback on build > results. > > Cucumber, as far as my understanding goes, works on feature level. It could > take people days to finish a cucumber feature. In the meantime, the cucumber > test remains broken. What do we do then? We cannot check in any code because A feature typically consists of several scenarios. You don't have to implement all scenarios before you commit. You don't have to write all scenarios when you start working on a feature. I recommend you never have more than one yellow scenario at a time. The same goes for scenarios, which consist of several steps. I recommend you commit every time you have made a step go from yellow to green (via red). This way, many successive commits will gradually build the whole feature. In my experience, getting a step to go from yellow to green rarely takes more than an hour (usually less). Is there anything preventing you from working this way? Aslak > that'll break the build. So we can only checkin code after several days? It > doesn't sound right to me. Any takes on this issue? Thanks in advance. > > Yi > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Aslak (::) From mark at mwilden.com Sun Feb 22 18:18:48 2009 From: mark at mwilden.com (Mark Wilden) Date: Sun, 22 Feb 2009 15:18:48 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> Message-ID: <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> On Sun, Feb 22, 2009 at 1:36 PM, aslak hellesoy wrote: > You don't have to write all > scenarios when you start working on a feature. I recommend you never > have more than one yellow scenario at a time. Whereas I use scenarios as a "to-do" list. I'll keep adding them as I think of them or as they come up in discussion. ///ark From hayafirst at gmail.com Sun Feb 22 19:09:53 2009 From: hayafirst at gmail.com (Yi Wen) Date: Sun, 22 Feb 2009 18:09:53 -0600 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> Message-ID: Wait for an hour before I can checkin something is still too long for me. I'd like to checkin every couple minutes most of time. But I think to make each step just pending first and then make it green when I finish implementation for the step makes sense. I probably will still use unit tests passing as checkin points. Thanks Yi On Sun, Feb 22, 2009 at 3:36 PM, aslak hellesoy wrote: > On Sun, Feb 22, 2009 at 8:47 PM, Yi Wen wrote: > > The rhythm for wrking with cucumber advertised by http://cukes.info/ is > to > > write tests that fails first, then code that fixes it. Now my question > is, > > what is the implication when combine this with Continuous Integration? > > > > * Nobody checks in code with failing tests (cucumber features, rspec > tests, anything else). > * If someone accidentally does, CI will run all tests and tell the team. > > > We all know when we do TDD/BDD in unit level, one test can be fixed > fairly > > quick in a coupe minutes and we can check in and kick off a build. It is > a > > ideal scene for doing CI: frequent checkin and fast feedback on build > > results. > > > > Cucumber, as far as my understanding goes, works on feature level. It > could > > take people days to finish a cucumber feature. In the meantime, the > cucumber > > test remains broken. What do we do then? We cannot check in any code > because > > A feature typically consists of several scenarios. You don't have to > implement all scenarios before you commit. You don't have to write all > scenarios when you start working on a feature. I recommend you never > have more than one yellow scenario at a time. > > The same goes for scenarios, which consist of several steps. > > I recommend you commit every time you have made a step go from yellow > to green (via red). > This way, many successive commits will gradually build the whole feature. > > In my experience, getting a step to go from yellow to green rarely > takes more than an hour (usually less). > Is there anything preventing you from working this way? > > Aslak > > > that'll break the build. So we can only checkin code after several days? > It > > doesn't sound right to me. Any takes on this issue? Thanks in advance. > > > > Yi > > > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hayafirst at gmail.com Sun Feb 22 19:14:44 2009 From: hayafirst at gmail.com (Yi Wen) Date: Sun, 22 Feb 2009 18:14:44 -0600 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> Message-ID: I totally agree with you on this. I have a feeling a lot of people kind of use cucumber as a sexy way for doing waterfall. On Sun, Feb 22, 2009 at 5:18 PM, Mark Wilden wrote: > On Sun, Feb 22, 2009 at 1:36 PM, aslak hellesoy > wrote: > > You don't have to write all > > scenarios when you start working on a feature. I recommend you never > > have more than one yellow scenario at a time. > > Whereas I use scenarios as a "to-do" list. I'll keep adding them as I > think of them or as they come up in discussion. > > ///ark > _______________________________________________ > 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 Sun Feb 22 19:18:54 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 22 Feb 2009 18:18:54 -0600 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> Message-ID: <57c63afe0902221618t4c326ceakec0504e164b958cd@mail.gmail.com> On Sun, Feb 22, 2009 at 6:14 PM, Yi Wen wrote: > I totally agree with you on this. I have a feeling a lot of people kind of > use cucumber as a sexy way for doing waterfall. That may be so, but one view of agile is that each iteration is a mini-waterfall. BDD suggests that we *should* define all of the scenarios in the iteration planning meeting because we use them as a planning tool (how can we estimate a feature at all before we've talked about the acceptance criteria?). FWIW, David > > On Sun, Feb 22, 2009 at 5:18 PM, Mark Wilden wrote: >> >> On Sun, Feb 22, 2009 at 1:36 PM, aslak hellesoy >> wrote: >> > You don't have to write all >> > scenarios when you start working on a feature. I recommend you never >> > have more than one yellow scenario at a time. >> >> Whereas I use scenarios as a "to-do" list. I'll keep adding them as I >> think of them or as they come up in discussion. >> >> ///ark >> _______________________________________________ >> 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 phlip2005 at gmail.com Sun Feb 22 21:36:55 2009 From: phlip2005 at gmail.com (Phlip) Date: Sun, 22 Feb 2009 18:36:55 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> Message-ID: Yi Wen wrote: > I totally agree with you on this. I have a feeling a lot of people kind > of use cucumber as a sexy way for doing waterfall. "Storytests" are very well represented in the Agile development community in general. Cucumber is a (slam-dunk) reinterpretation of Ward Cunningham's FIT concept. (Naturally, born of Java, FIT had no direct translation to Ruby, and that's probably a good thing!) It's only waterfall if your product-owner writes or commissions _thousands_ of story tests before doing _any_ of them. I heavily suspect that the author of a cucumber "feature" can hardly wait to see it pass, and I suspect they will refrain from diverting energy to writing another one. That is the heart of Agile - the feedback loop. So what's the maximum number of cucumber features that anyone has ever seen on-deck but not yet passing? That's a bad metric, exactly like excess inventory in a warehouse. -- Phlip From hayafirst at gmail.com Sun Feb 22 22:06:39 2009 From: hayafirst at gmail.com (Yi Wen) Date: Sun, 22 Feb 2009 21:06:39 -0600 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> Message-ID: yeah, you guys are probably right on this. I was just over stating. :) Yi On Sun, Feb 22, 2009 at 8:36 PM, Phlip wrote: > Yi Wen wrote: > > I totally agree with you on this. I have a feeling a lot of people kind of >> use cucumber as a sexy way for doing waterfall. >> > > "Storytests" are very well represented in the Agile development community > in general. Cucumber is a (slam-dunk) reinterpretation of Ward Cunningham's > FIT concept. > > (Naturally, born of Java, FIT had no direct translation to Ruby, and that's > probably a good thing!) > > It's only waterfall if your product-owner writes or commissions _thousands_ > of story tests before doing _any_ of them. > > I heavily suspect that the author of a cucumber "feature" can hardly wait > to see it pass, and I suspect they will refrain from diverting energy to > writing another one. That is the heart of Agile - the feedback loop. > > So what's the maximum number of cucumber features that anyone has ever seen > on-deck but not yet passing? That's a bad metric, exactly like excess > inventory in a warehouse. > > -- > Phlip > > > _______________________________________________ > 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 phlip2005 at gmail.com Sun Feb 22 22:53:39 2009 From: phlip2005 at gmail.com (Phlip) Date: Sun, 22 Feb 2009 19:53:39 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> Message-ID: Yi Wen wrote: > yeah, you guys are probably right on this. I was just over stating. :) Ah, but Waterfall is indeed like the Emissaries of the Shadow. If you defeat one of them, in one form, another one will always appear, take shape, and grow... I myself have heard well-meaning product managers say "When we go for the rewrite, we are going to make sure we specify each feature, first, before coding them!" They said that because the last effort - code-and-fix - had grown until it died under the weight of its cruft. They perceived their inability to safely request new features as evidence that they did not specify enough, up-front. These managers knew better than to use classic Waterfall, but they still didn't understand that Big Requirements Up Front is essentially Waterfall's worst aspect. And so they re-invented Waterfall, yet again, in yet another form. So keep flying that flag of vigilance, there! -- Phlip From lists at ruby-forum.com Sun Feb 22 23:22:53 2009 From: lists at ruby-forum.com (Kaleem Ullah) Date: Mon, 23 Feb 2009 05:22:53 +0100 Subject: [rspec-users] Culerity Error while running feature. In-Reply-To: <8277b7f40902221024q4adaeb98y775a47b3e12b4d9c@mail.gmail.com> References: <8277b7f40902220442w7e94c5d1gab8f085d19728dd5@mail.gmail.com> <8d961d900902220749o6885037kf8b848098f5a50f@mail.gmail.com> <8277b7f40902221024q4adaeb98y775a47b3e12b4d9c@mail.gmail.com> Message-ID: <06c5acce4666b553cfcad7da2a490152@ruby-forum.com> Let me try... Thanks for your reply..... -- Posted via http://www.ruby-forum.com/. From aslak.hellesoy at gmail.com Mon Feb 23 02:24:10 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 23 Feb 2009 08:24:10 +0100 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> Message-ID: <8d961d900902222324i5870a9fcvd27e7b4ddae50a6f@mail.gmail.com> On Mon, Feb 23, 2009 at 3:36 AM, Phlip wrote: > Yi Wen wrote: > >> I totally agree with you on this. I have a feeling a lot of people kind of >> use cucumber as a sexy way for doing waterfall. > > "Storytests" are very well represented in the Agile development community in > general. Cucumber is a (slam-dunk) reinterpretation of Ward Cunningham's FIT > concept. > > (Naturally, born of Java, FIT had no direct translation to Ruby, and that's > probably a good thing!) > It actually did. It's just that very few have ever used it: http://fit.rubyforge.org/ > It's only waterfall if your product-owner writes or commissions _thousands_ > of story tests before doing _any_ of them. > > I heavily suspect that the author of a cucumber "feature" can hardly wait to > see it pass, and I suspect they will refrain from diverting energy to > writing another one. That is the heart of Agile - the feedback loop. > Well said. That's the feeling I get when I work with this Cucumber. > So what's the maximum number of cucumber features that anyone has ever seen > on-deck but not yet passing? That's a bad metric, exactly like excess Do you mean "on filesystem"? I have used Cucumber on 5-6 projects now, and I never exceed 1. If there is a bigger backlog "somewhere else" (pile of cards, word documents...) then I keep them there for as long as possible. > inventory in a warehouse. > > -- > Phlip > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From v.ondruch at gmail.com Mon Feb 23 02:43:10 2009 From: v.ondruch at gmail.com (vo.x) Date: Sun, 22 Feb 2009 23:43:10 -0800 (PST) Subject: [rspec-users] send_file testing In-Reply-To: <7ca1493b-5301-44bb-98ce-3441480bba85@f33g2000vbf.googlegroups.com> References: <7ca1493b-5301-44bb-98ce-3441480bba85@f33g2000vbf.googlegroups.com> Message-ID: <30fcc9c6-64a1-47cf-842c-3495418c6f4b@j8g2000yql.googlegroups.com> Just to be clear, this is how the action looks: def download log = ActivityLog.find(params[:id]) if log send_file log.path else flash[:notice] = _("Log file \"#{params[:id]}\" was not found.") redirect_to :action => 'index' end end Vit From pat.maddox at gmail.com Mon Feb 23 04:52:50 2009 From: pat.maddox at gmail.com (Pat Maddox) Date: Mon, 23 Feb 2009 01:52:50 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> Message-ID: <2c7e61990902230152u7c2bd7a1n9b5b69b8faf23140@mail.gmail.com> On Sun, Feb 22, 2009 at 6:36 PM, Phlip wrote: > So what's the maximum number of cucumber features that anyone has ever seen > on-deck but not yet passing? That's a bad metric, exactly like excess > inventory in a warehouse. I don't know that it's bad. At the beginning of an iteration, I have most of the features & scenarios that I'll be working on. So I start off with a big pile of yellows, and as the iteration moves on it gradually turns green. I'd say we average 8-10 pending features at the beginning of each iteration maybe. Pat From chris.webstar at gmail.com Mon Feb 23 05:17:47 2009 From: chris.webstar at gmail.com (Christian Hoeppner) Date: Mon, 23 Feb 2009 10:17:47 +0000 Subject: [rspec-users] Autotest won't pickup any tests In-Reply-To: <57c63afe0902200756q60c87e11wc8caa27bd8af3291@mail.gmail.com> References: <067EF338-8816-417E-963F-4BC157E18EFD@gmail.com> <57c63afe0902200756q60c87e11wc8caa27bd8af3291@mail.gmail.com> Message-ID: <1AC72844-E6A5-482A-9F38-DA94A4771497@gmail.com> *smacks forehead* Who would have known. Ha! I spent the entire weekend "debugging" that lib. Now, how do I create a rake task that runs autospec with a few options? On 20/02/2009, at 15:56, David Chelimsky wrote: > On Fri, Feb 20, 2009 at 6:15 AM, Christian Hoeppner > wrote: >> Hey there, >> >> I've tried using Nick Sieger's "plugin" to have autotest run my >> tests for >> gems and other non-rails stuff. However, it doesn't seem to match >> any tests >> for any files. Not being sure what was wrong, I traced the >> execution of >> RspecAutotest.run() and saw that tests_for_file() never got called. >> I also >> replicated a tests_for_file() call by hand in irb, and it does >> match the >> right spec file for any given implementation file. > > That lib is way outdated. RSpec now supports autotest directly with > the autospec command. > >> >> Here's what I use: >> ZenTest (3.11.1), rspec (1.1.12), ruby, ruby 1.8.1 (2003-12-25) >> [i686-darwin]. >> >> Sieger's file is the latest from svn, dated from 2007. >> _______________________________________________ >> 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 Saludos, Chris Hoeppner S.A.T. Gigabyte Solution S.L. 637 333 204 928 821 633 chris.webstar at gmail.com codigo404.wordpress.com From lists at ruby-forum.com Mon Feb 23 06:12:17 2009 From: lists at ruby-forum.com (Hoor Net) Date: Mon, 23 Feb 2009 12:12:17 +0100 Subject: [rspec-users] [cucumber ]Missing lettersm 'a' mafter rake features Message-ID: I am just starting with any testing really, but I chose this post as a tutorial. http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/comment-page-1/#comment-454 I have WinXP, so I had to install one more gem for the colors. After making my first features/tasklist.feature file which is: Feature: Tasks In order to keep track of tasks People should be able to Create a list of tasks Scenario: List Tasks Given that I have created a task "task 1" When I go to the tasks page Then I should see "task 1" After this I run the: rake features and you won't believe what happened! Take a look at the result: http://gist.github.com/68907 The 'a' letters ARE MISSING!!!! Any ideas? -- Posted via http://www.ruby-forum.com/. From joe at josephwilk.net Mon Feb 23 06:28:36 2009 From: joe at josephwilk.net (Joseph Wilk) Date: Mon, 23 Feb 2009 11:28:36 +0000 Subject: [rspec-users] [cucumber ]Missing lettersm 'a' mafter rake features In-Reply-To: References: Message-ID: <49A28864.7010706@josephwilk.net> Hoor Net wrote: > I am just starting with any testing really, but I chose this post as a > tutorial. > http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/comment-page-1/#comment-454 > > I have WinXP, so I had to install one more gem for the colors. > After making my first features/tasklist.feature file which is: > Feature: Tasks > In order to keep track of tasks > People should be able to > Create a list of tasks > > Scenario: List Tasks > Given that I have created a task "task 1" > When I go to the tasks page > Then I should see "task 1" > > > After this I run the: > rake features > > and you won't believe what happened! > Take a look at the result: > http://gist.github.com/68907 > > The 'a' letters ARE MISSING!!!! > > Any ideas? > Take a look at: http://wiki.github.com/aslakhellesoy/cucumber/troubleshooting -- Joseph Wilk http://blog.josephwilk.net From lists at ruby-forum.com Mon Feb 23 07:01:03 2009 From: lists at ruby-forum.com (Hoor Net) Date: Mon, 23 Feb 2009 13:01:03 +0100 Subject: [rspec-users] [cucumber ]Missing lettersm 'a' mafter rake features In-Reply-To: <49A28864.7010706@josephwilk.net> References: <49A28864.7010706@josephwilk.net> Message-ID: It works! It works! Thanks a LOT!!! Joseph Wilk wrote: > Hoor Net wrote: >> >> Take a look at the result: >> http://gist.github.com/68907 >> >> The 'a' letters ARE MISSING!!!! >> >> Any ideas? >> > Take a look at: > > http://wiki.github.com/aslakhellesoy/cucumber/troubleshooting > > -- > Joseph Wilk > http://blog.josephwilk.net -- Posted via http://www.ruby-forum.com/. From phlip2005 at gmail.com Mon Feb 23 07:38:20 2009 From: phlip2005 at gmail.com (Phlip) Date: Mon, 23 Feb 2009 04:38:20 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: <8d961d900902222324i5870a9fcvd27e7b4ddae50a6f@mail.gmail.com> References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <3c30da400902221518p5605eb50qc28d895b087b7da7@mail.gmail.com> <8d961d900902222324i5870a9fcvd27e7b4ddae50a6f@mail.gmail.com> Message-ID: aslak hellesoy wrote: >> So what's the maximum number of cucumber features that anyone has ever seen >> on-deck but not yet passing? That's a bad metric, exactly like excess >> inventory in a warehouse. > > Do you mean "on filesystem"? I have used Cucumber on 5-6 projects now, > and I never exceed 1. If there is a bigger backlog "somewhere else" > (pile of cards, word documents...) then I keep them there for as long > as possible. Among the Agile consultants, the metric there is: Time between fully specifying a feature and profiting from its use. You use each cards as a tickler for one last conversation with an onsite customer, before cutting the test and code, right? BTW, another CI metric for cucumberists to answer is: After passing a cucumber test, it latches, and gates integration. I think cucumber builds that latch effect in with the 'pending' keyword, right? Pass the cuke, take it out, integrate, and then it runs in your integration batch, right? -- Phlip From dchelimsky at gmail.com Mon Feb 23 08:49:44 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Feb 2009 07:49:44 -0600 Subject: [rspec-users] Autotest won't pickup any tests In-Reply-To: <1AC72844-E6A5-482A-9F38-DA94A4771497@gmail.com> References: <067EF338-8816-417E-963F-4BC157E18EFD@gmail.com> <57c63afe0902200756q60c87e11wc8caa27bd8af3291@mail.gmail.com> <1AC72844-E6A5-482A-9F38-DA94A4771497@gmail.com> Message-ID: <57c63afe0902230549i4eaca8am3a3491946b0e24fc@mail.gmail.com> On Mon, Feb 23, 2009 at 4:17 AM, Christian Hoeppner wrote: > *smacks forehead* Who would have known. Ha! I spent the entire weekend > "debugging" that lib. > > Now, how do I create a rake task that runs autospec with a few options? RSpec options, Autotest options, or both? > > On 20/02/2009, at 15:56, David Chelimsky wrote: > >> On Fri, Feb 20, 2009 at 6:15 AM, Christian Hoeppner >> wrote: >>> >>> Hey there, >>> >>> I've tried using Nick Sieger's "plugin" to have autotest run my tests for >>> gems and other non-rails stuff. However, it doesn't seem to match any >>> tests >>> for any files. Not being sure what was wrong, I traced the execution of >>> RspecAutotest.run() and saw that tests_for_file() never got called. I >>> also >>> replicated a tests_for_file() call by hand in irb, and it does match the >>> right spec file for any given implementation file. >> >> That lib is way outdated. RSpec now supports autotest directly with >> the autospec command. >> >>> >>> Here's what I use: >>> ZenTest (3.11.1), rspec (1.1.12), ruby, ruby 1.8.1 (2003-12-25) >>> [i686-darwin]. >>> >>> Sieger's file is the latest from svn, dated from 2007. >>> _______________________________________________ >>> 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 > > Saludos, > Chris Hoeppner > S.A.T. Gigabyte Solution S.L. > 637 333 204 > 928 821 633 > chris.webstar at gmail.com > codigo404.wordpress.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From aslak.hellesoy at gmail.com Mon Feb 23 09:36:42 2009 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 23 Feb 2009 15:36:42 +0100 Subject: [rspec-users] Cucumber 0.2 final release date? In-Reply-To: <7ac2300c0902190749x3d659b40w7cc84e5a6f8aedea@mail.gmail.com> References: <7ac2300c0902190749x3d659b40w7cc84e5a6f8aedea@mail.gmail.com> Message-ID: <8d961d900902230636te143bc6o92ca13f709688ee9@mail.gmail.com> On Thu, Feb 19, 2009 at 4:49 PM, aidy lewis wrote: > Hi, > > I know this seems all take and no give, but do we have an estimated > final release date for Cucumber 0.2? > 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. Aslak > Thanks > > Aidy > > Celerity, Cucumber and Firewatir: > http://skillsmatter.com/event/ruby-on-rails/lrug-march > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Aslak (::) From apremdas at gmail.com Mon Feb 23 09:56:12 2009 From: apremdas at gmail.com (Andrew Premdas) Date: Mon, 23 Feb 2009 14:56:12 +0000 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> Message-ID: <88fd8ddc0902230656v5691d28fj913909b4c9612ba5@mail.gmail.com> I'd question the wisdom of checking into an integration server every couple of minutes. I'm not sure if you meant that but if you did then I think these sort of checkins have to be in bigger chunks. The reason is that each checkin to an intergration server is asking my colleagues to checkout my code and integrate it into their current work. So everything I check in to the intergration server should be fit for them to use, and ideally it should have been reviewed (self review, or even better a bit of peer review - easy enought if pairing). You just can't do that in 2 minutes. IMO a complete scenario is about the smallest size chunk to integrate with, and a complete feature about the largest Of course if your using Git (or any distributed vcs) you can just branch, commit locally and rebase from the master. If you want to push to get a backup as well, you can always have a backup target in addition to your integration target. If your not using Git (or something similar) locally I'd highly reccomend that. I think its reasonable to make failing steps pending for an integration commit, but its not something I would like to do regularly, much prefer to wait a bit longer before integrating and make them green. I really don't like working with more than 1 failing step, but find that occasionally I end up doing that (normally because a new step prompts a refactoring of and older step and that then breaks as well) HTH Andrew 2009/2/23 Yi Wen > Wait for an hour before I can checkin something is still too long for me. > I'd like to checkin every couple minutes most of time. > > But I think to make each step just pending first and then make it green > when I finish implementation for the step makes sense. I probably will still > use unit tests passing as checkin points. > > Thanks > > Yi > > On Sun, Feb 22, 2009 at 3:36 PM, aslak hellesoy wrote: > >> On Sun, Feb 22, 2009 at 8:47 PM, Yi Wen wrote: >> > The rhythm for wrking with cucumber advertised by http://cukes.info/ is >> to >> > write tests that fails first, then code that fixes it. Now my question >> is, >> > what is the implication when combine this with Continuous Integration? >> > >> >> * Nobody checks in code with failing tests (cucumber features, rspec >> tests, anything else). >> * If someone accidentally does, CI will run all tests and tell the team. >> >> > We all know when we do TDD/BDD in unit level, one test can be fixed >> fairly >> > quick in a coupe minutes and we can check in and kick off a build. It is >> a >> > ideal scene for doing CI: frequent checkin and fast feedback on build >> > results. >> > >> > Cucumber, as far as my understanding goes, works on feature level. It >> could >> > take people days to finish a cucumber feature. In the meantime, the >> cucumber >> > test remains broken. What do we do then? We cannot check in any code >> because >> >> A feature typically consists of several scenarios. You don't have to >> implement all scenarios before you commit. You don't have to write all >> scenarios when you start working on a feature. I recommend you never >> have more than one yellow scenario at a time. >> >> The same goes for scenarios, which consist of several steps. >> >> I recommend you commit every time you have made a step go from yellow >> to green (via red). >> This way, many successive commits will gradually build the whole feature. >> >> In my experience, getting a step to go from yellow to green rarely >> takes more than an hour (usually less). >> Is there anything preventing you from working this way? >> >> Aslak >> >> > that'll break the build. So we can only checkin code after several days? >> It >> > doesn't sound right to me. Any takes on this issue? Thanks in advance. >> > >> > Yi >> > >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > 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 mark at mwilden.com Mon Feb 23 10:22:22 2009 From: mark at mwilden.com (Mark Wilden) Date: Mon, 23 Feb 2009 07:22:22 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: <88fd8ddc0902230656v5691d28fj913909b4c9612ba5@mail.gmail.com> References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <88fd8ddc0902230656v5691d28fj913909b4c9612ba5@mail.gmail.com> Message-ID: <3c30da400902230722ifdd659ewc09e6b84b2e4cd7c@mail.gmail.com> On Mon, Feb 23, 2009 at 6:56 AM, Andrew Premdas wrote: > I'd question the wisdom of checking into an integration server every couple > of minutes. Our mantra is ABC: Always Be Committing. So we commit anytime we feel like it, as long as it doesn't break the build. This makes life a lot easier when there is merging to do. > I'm not sure if you meant that but if you did then I think these > sort of checkins have to be in bigger chunks. The reason is that each > checkin to an intergration server is asking my colleagues to checkout my > code and integrate it into their current work. Just because I push doesn't mean my coworkers have to pull. > IMO a complete > scenario is about the smallest size chunk to integrate with, and a complete > feature about the largest A refactoring, a new method (and its tests), a new test, a fixed typo - these are all appropriate chunks of code to check in. I think this is far superior to making massive checkins at the end of each iteration. We usually fall somewhere in between. ///ark From chris.webstar at gmail.com Mon Feb 23 10:26:53 2009 From: chris.webstar at gmail.com (Christian Hoeppner) Date: Mon, 23 Feb 2009 15:26:53 +0000 Subject: [rspec-users] Autotest won't pickup any tests In-Reply-To: <57c63afe0902230549i4eaca8am3a3491946b0e24fc@mail.gmail.com> References: <067EF338-8816-417E-963F-4BC157E18EFD@gmail.com> <57c63afe0902200756q60c87e11wc8caa27bd8af3291@mail.gmail.com> <1AC72844-E6A5-482A-9F38-DA94A4771497@gmail.com> <57c63afe0902230549i4eaca8am3a3491946b0e24fc@mail.gmail.com> Message-ID: <52C220DB-05F4-4874-A0C5-00889FEE2CDD@gmail.com> I'm not really sure what options autotest has, since the website is on "coming soon", and autotest -h doesn't show any help, so I'm thinking about rspec options, like the rpsec command to use, arguments (--diff unified --color, etc). Is there a place to read up on autotest behavior and options? I couldn't even find a manpage, but maybe I'm not looking hard enough. On 23/02/2009, at 13:49, David Chelimsky wrote: > On Mon, Feb 23, 2009 at 4:17 AM, Christian Hoeppner > wrote: >> *smacks forehead* Who would have known. Ha! I spent the entire >> weekend >> "debugging" that lib. >> >> Now, how do I create a rake task that runs autospec with a few >> options? > > RSpec options, Autotest options, or both? > >> >> On 20/02/2009, at 15:56, David Chelimsky wrote: >> >>> On Fri, Feb 20, 2009 at 6:15 AM, Christian Hoeppner >>> wrote: >>>> >>>> Hey there, >>>> >>>> I've tried using Nick Sieger's "plugin" to have autotest run my >>>> tests for >>>> gems and other non-rails stuff. However, it doesn't seem to match >>>> any >>>> tests >>>> for any files. Not being sure what was wrong, I traced the >>>> execution of >>>> RspecAutotest.run() and saw that tests_for_file() never got >>>> called. I >>>> also >>>> replicated a tests_for_file() call by hand in irb, and it does >>>> match the >>>> right spec file for any given implementation file. >>> >>> That lib is way outdated. RSpec now supports autotest directly with >>> the autospec command. >>> >>>> >>>> Here's what I use: >>>> ZenTest (3.11.1), rspec (1.1.12), ruby, ruby 1.8.1 (2003-12-25) >>>> [i686-darwin]. >>>> >>>> Sieger's file is the latest from svn, dated from 2007. >>>> _______________________________________________ >>>> 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 >> >> Saludos, >> Chris Hoeppner >> S.A.T. Gigabyte Solution S.L. >> 637 333 204 >> 928 821 633 >> chris.webstar at gmail.com >> codigo404.wordpress.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 Saludos, Chris Hoeppner S.A.T. Gigabyte Solution S.L. 637 333 204 928 821 633 chris.webstar at gmail.com codigo404.wordpress.com From phlip2005 at gmail.com Mon Feb 23 10:44:46 2009 From: phlip2005 at gmail.com (Phlip) Date: Mon, 23 Feb 2009 07:44:46 -0800 Subject: [rspec-users] [cucumber] Cucumber and CI In-Reply-To: <3c30da400902230722ifdd659ewc09e6b84b2e4cd7c@mail.gmail.com> References: <8d961d900902221336x7822dc36p43ea7c29bca44430@mail.gmail.com> <88fd8ddc0902230656v5691d28fj913909b4c9612ba5@mail.gmail.com> <3c30da400902230722ifdd659ewc09e6b84b2e4cd7c@mail.gmail.com> Message-ID: Mark Wilden wrote: >> I'd question the wisdom of checking into an integration server every couple >> of minutes. > > Our mantra is ABC: Always Be Committing. So we commit anytime we feel > like it, as long as it doesn't break the build. This makes life a lot > easier when there is merging to do. In a post-Agile world, we often need to remind the juniors about the Best Practices that started the movement. Integrate every time you could use a roll-back. Use incremental testing, and a test server. You can't integrate if your changed tests fail. The first step of integrating pulls And work in one room, so if you know another pair is in the same module, you just holler to them to integrate as soon as possible, each time you do it. -- Phlip From dchelimsky at gmail.com Mon Feb 23 10:56:44 2009 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Feb 2009 09:56:44 -0600 Subject: [rspec-users] Autotest won't pickup any tests In-Reply-To: <52C220DB-05F4-4874-A0C5-00889FEE2CDD@gmail.com> References: <067EF338-8816-417E-963F-4BC157E18EFD@gmail.com> <57c63afe0902200756q60c87e11wc8caa27bd8af3291@mail.gmail.com> <1AC72844-E6A5-482A-9F38-DA94A4771497@gmail.com> <57c63afe0902230549i4eaca8am3a3491946b0e24fc@mail.gmail.com> <52C220DB-05F4-4874-A0C5-00889FEE2CDD@gmail.com> Message-ID: <57c