From mailing_lists at railsnewbie.com Tue May 1 07:24:50 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Tue, 1 May 2007 07:24:50 -0400 Subject: [rspec-devel] Multiple formatters In-Reply-To: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> Message-ID: <6C5E6525-73D4-4C51-A278-B60795754BC1@railsnewbie.com> On Apr 24, 2007, at 4:41 AM, aslak hellesoy wrote: > Hi all, > > RSpec supports multiple formatters, but currently you can only use one > at a time. I really need to use several at the same time. > > I'd like to make RSpec handle several --format options. However, that > would require some rethinking of how/where output is written - it > can't all go to the same stream (file or stdout). > > So I'm thinking of making --format take a composite argument: > > --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc > --format progress > > If nothing comes after the format, output is STDOUT, so this would be > backwards compatible. > > If we do this, we could also get rid of --failures - it would just be > a special formatter. > > WDYT? > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel I've seen that you've already implemented this in trunk. I'm not running the latest version of trunk, but I've noticed that in 0.9RC1, when specifying a failures file and an examples file, that the following behavior is exhibited by rspec: 1. If the file exists, but is empty, rspec will run all specs 2. If the file exists, but contains failing examples, these failing specs will be run 3. If the file does not exists, it creates the file (through -- failures - now --format e:filename), but runs no specs. Would a patch addressing the third case (which would mimic the first case) be a welcome addition to rspec? Scott From aslak.hellesoy at gmail.com Tue May 1 07:43:14 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 1 May 2007 13:43:14 +0200 Subject: [rspec-devel] [ANN] RSpec 0.9.1 released Message-ID: <8d961d900705010443h65eb9389n44905a45cae601b9@mail.gmail.com> The RSpec team is pleased to announce RSpec 0.9.1 (we skipped 0.9.0). RSpec is a framework that provides programmers with a Domain Specific Language to describe the behaviour of Ruby code with readable, executable examples that guide you in the design process and serve well as both documentation as tests. This release includes a complete overhaul of the API, which can be summarised as follows: * "context" is now "describe" (we call the blocks behaviours) * "specify" is now "it" (we call the blocks examples) * "should_something" is now "should something" (magic underscores are gone) In order to ease the transition from older specs, RSpec also includes a translator that will translate your old specs. In addition to these major changes, this release has over 60 applied RFEs and bug fixes, many of them related to Spec::Rails - the Ruby on Rails plugin for RSpec. To install RSpec: gem install rspec (you may have to wait a few hours for the gems to replicate) To translate old specs: spec_translator from_dir to_dir (can be the same dir if you use source control and know how to revert) To see the full list of changes: http://rspec.rubyforge.org/rdoc/files/CHANGES.html The RSpec home page: http://rspec.rubyforge.org/ How to use RSpec with Rails: http://rspec.rubyforge.org/documentation/rails/index.html [Regards, The RSpec team] From aslak.hellesoy at gmail.com Tue May 1 07:45:18 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 1 May 2007 13:45:18 +0200 Subject: [rspec-devel] Multiple formatters In-Reply-To: <6C5E6525-73D4-4C51-A278-B60795754BC1@railsnewbie.com> References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> <6C5E6525-73D4-4C51-A278-B60795754BC1@railsnewbie.com> Message-ID: <8d961d900705010445o192830en8639ebea3029a378@mail.gmail.com> On 5/1/07, Scott Taylor wrote: > > On Apr 24, 2007, at 4:41 AM, aslak hellesoy wrote: > > > Hi all, > > > > RSpec supports multiple formatters, but currently you can only use one > > at a time. I really need to use several at the same time. > > > > I'd like to make RSpec handle several --format options. However, that > > would require some rethinking of how/where output is written - it > > can't all go to the same stream (file or stdout). > > > > So I'm thinking of making --format take a composite argument: > > > > --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc > > --format progress > > > > If nothing comes after the format, output is STDOUT, so this would be > > backwards compatible. > > > > If we do this, we could also get rid of --failures - it would just be > > a special formatter. > > > > WDYT? > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > I've seen that you've already implemented this in trunk. > > I'm not running the latest version of trunk, but I've noticed that in > 0.9RC1, when specifying a failures file and an examples file, that > the following behavior is exhibited by rspec: > > 1. If the file exists, but is empty, rspec will run all specs > 2. If the file exists, but contains failing examples, these failing > specs will be run > 3. If the file does not exists, it creates the file (through -- > failures - now --format e:filename), but runs no specs. > > Would a patch addressing the third case (which would mimic the first > case) be a welcome addition to rspec? > It would, but how do you suggest that RSpec guesses that you meant a file, and not the name of a behaviour or example? Aslak > Scott > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From mailing_lists at railsnewbie.com Tue May 1 08:14:55 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Tue, 1 May 2007 08:14:55 -0400 Subject: [rspec-devel] Multiple formatters In-Reply-To: <8d961d900705010445o192830en8639ebea3029a378@mail.gmail.com> References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> <6C5E6525-73D4-4C51-A278-B60795754BC1@railsnewbie.com> <8d961d900705010445o192830en8639ebea3029a378@mail.gmail.com> Message-ID: On May 1, 2007, at 7:45 AM, aslak hellesoy wrote: > On 5/1/07, Scott Taylor wrote: >> >> On Apr 24, 2007, at 4:41 AM, aslak hellesoy wrote: >> >>> Hi all, >>> >>> RSpec supports multiple formatters, but currently you can only >>> use one >>> at a time. I really need to use several at the same time. >>> >>> I'd like to make RSpec handle several --format options. However, >>> that >>> would require some rethinking of how/where output is written - it >>> can't all go to the same stream (file or stdout). >>> >>> So I'm thinking of making --format take a composite argument: >>> >>> --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc >>> --format progress >>> >>> If nothing comes after the format, output is STDOUT, so this >>> would be >>> backwards compatible. >>> >>> If we do this, we could also get rid of --failures - it would >>> just be >>> a special formatter. >>> >>> WDYT? >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> >> I've seen that you've already implemented this in trunk. >> >> I'm not running the latest version of trunk, but I've noticed that in >> 0.9RC1, when specifying a failures file and an examples file, that >> the following behavior is exhibited by rspec: >> >> 1. If the file exists, but is empty, rspec will run all specs >> 2. If the file exists, but contains failing examples, these failing >> specs will be run >> 3. If the file does not exists, it creates the file (through -- >> failures - now --format e:filename), but runs no specs. >> >> Would a patch addressing the third case (which would mimic the first >> case) be a welcome addition to rspec? >> > > It would, but how do you suggest that RSpec guesses that you meant a > file, and not the name of a behaviour or example? I would assume that this would be the case if: 1. There is a failing examples or failing behavior formatter, with at @where != out 2. and that an "example" has the same name as the formatter's @where 3. (and of course)...that the examples/failures file does not yet exist In this case, the example could just be removed from the list. Obviously this must go on after the ::OptionParser#parse method is called. So tell me if I'm missing something obvious, but it would seem very strange if one chose a failures file with the same name as an example, wouldn't it? It could be done, but who ever dream of doing so? Who would create a file with a name like "should do such and such" as the name of their failures file? On another note, what is the exact difference between using should eql () and should == ? Best, Scott > > Aslak > >> Scott >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Tue May 1 08:30:47 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 1 May 2007 07:30:47 -0500 Subject: [rspec-devel] rspec and autotest Message-ID: <57c63afe0705010530g751d046ct4552202e7a9a9bf@mail.gmail.com> If you want to use rspec-0.9.2 with autotest (ZenTest-3.5.2), you'll want to read this blog: http://blog.davidchelimsky.net/articles/2007/05/01/rspec-0-9-1-and-autotest-zentest-3-5-2 Enjoy! David From mattaimonetti at gmail.com Tue May 1 11:25:23 2007 From: mattaimonetti at gmail.com (Matt Aimonetti) Date: Tue, 1 May 2007 08:25:23 -0700 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> Message-ID: describe "a legacy user" do include LegacyUserHelper before :all do LEGACY.connect migration_for_legacy_users end before do @l_user = LegacyUser.new end teardown :each do delete_user_with_email(valid_legacy_user_attributes[:email]) end Here is a snippet of my code. Before running my examples, I need to connect to my legacy database and migrating the schema. After each example I need to delete the legacy user just created. To get the above code to work, I had to move my delete_user_with_email(valid_legacy_user_attributes[:email]) function to be run before each example instead of after. -Matt On 4/30/07, David Chelimsky wrote: > > On 4/30/07, Matt Aimonetti wrote: > > teardown :each and after :each don't seem to work for me. > > > > I had to move my function from "teardown :each" to "before" since the > > function was deleting the object created by the previous spec and the > > function didn't seem to be called. Maybe I didn't understand properly > how > > teardown and after work. > > Each example (i.e. #it or #specify) gets run in its own object. It has > no access to any state in the other examples. before(:each) is run > before each example, in the same object as the example. after(:each) > is run after each example, in the same object as the example. > > I'm a bit confused by your description of the problem. Can you post > some code so we can talk about a specific example? > > > > > > -Matt > > > > > > On 4/18/07, Matthew Heidemann wrote: > > > I personally like before :each_example. The first time I read it I > said, > > "before :each what?". > > > > > > I think once people run the spec and see 1 example 0 failures, they > know > > that the 'it do' is an example > > > > > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > > I fully agree with Dean and prefer the "before :each", "after :all" > > option, it reads better and is easier to understand for newbies. > > > > > > > > -Matt > > > > > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > > Setup and teardown are more approachable to converts from > Test::Unit, > > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > > > "all_examples" might cause people to ask "what examples?" I'm not > sure > > > > > most people will think of the "it blocks" as examples. Still, you > > > > > could just accept any symbol that begins with "each" and "all", so > > > > > people can invent their own name ;) > > > > > > > > > > dean > > > > > > > > > > > > > > > On 4/11/07, David Chelimsky wrote: > > > > > > We're going to rename context_setup and context_teardown because > > they > > > > > > no longer read well when using "describe/id". There are two > ideas > > > > > > floating around about this. The first: > > > > > > > > > > > > setup :each #default - works like setup does now > > > > > > setup :all #replaces context_setup > > > > > > teardown :each #default - works like teardown does now > > > > > > teardown :all #replaces context teardown > > > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > > > before :each #default - works like setup does now > > > > > > before :all #replaces context_setup > > > > > > after :each #default - works like teardown does now > > > > > > after :all #replaces context teardown > > > > > > > > > > > > In both cases, the default is :each, so you can just say "setup > do" > > or > > > > > > "before do" instead of "setup :each do" or "before :each do". > > > > > > > > > > > > == Examples > > > > > > > > > > > > describe Thing do > > > > > > setup :all { ... } > > > > > > setup :each { ... } > > > > > > it "should do something" { ... } > > > > > > it "should do something else" { ... } > > > > > > teardown :each { ... } > > > > > > teardown :all { ... } > > > > > > end > > > > > > > > > > > > describe Thing do > > > > > > before :all { ... } > > > > > > before :each { ... } > > > > > > it "should do something" { ... } > > > > > > it "should do something else" { ... } > > > > > > after :each { ... } > > > > > > after :all { ... } > > > > > > end > > > > > > > > > > > > describe Thing do > > > > > > before { ... } # works like before :each > > > > > > it "should do something" { ... } > > > > > > it "should do something else" { ... } > > > > > > after { ... } # works like after :each > > > > > > end > > > > > > > > > > > > One other thing that occurs to me is that "before :each" really > > means > > > > > > "before each example" - so perhaps it should be "before > > :each_example" > > > > > > and "before :all_examples" (or :each and :each_example could > both be > > > > > > supported, etc). > > > > > > > > > > > > WDYT? > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > -- > > > > > Dean Wampler > > > > > http://www.objectmentor.com > > > > > http://www.aspectprogramming.com > > > > > http://www.contract4j.org > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070501/6518582e/attachment.html From aslak.hellesoy at gmail.com Tue May 1 12:22:34 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 1 May 2007 18:22:34 +0200 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> Message-ID: <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> It's after(:each) and not teardown(:each) On 5/1/07, Matt Aimonetti wrote: > describe "a legacy user" do > include LegacyUserHelper > > before :all do > LEGACY.connect > migration_for_legacy_users > end > > before do > @l_user = LegacyUser.new > end > > teardown :each do > delete_user_with_email(valid_legacy_user_attributes[:email]) > end > > Here is a snippet of my code. > > Before running my examples, I need to connect to my legacy database and > migrating the schema. After each example I need to delete the legacy user > just created. To get the above code to work, I had to move my > delete_user_with_email(valid_legacy_user_attributes[:email]) function to be > run before each example instead of after. > > -Matt > > On 4/30/07, David Chelimsky wrote: > > > > On 4/30/07, Matt Aimonetti wrote: > > > teardown :each and after :each don't seem to work for me. > > > > > > I had to move my function from "teardown :each" to "before" since the > > > function was deleting the object created by the previous spec and the > > > function didn't seem to be called. Maybe I didn't understand properly > > how > > > teardown and after work. > > > > Each example (i.e. #it or #specify) gets run in its own object. It has > > no access to any state in the other examples. before(:each) is run > > before each example, in the same object as the example. after(:each) > > is run after each example, in the same object as the example. > > > > I'm a bit confused by your description of the problem. Can you post > > some code so we can talk about a specific example? > > > > > > > > > > -Matt > > > > > > > > > On 4/18/07, Matthew Heidemann wrote: > > > > I personally like before :each_example. The first time I read it I > > said, > > > "before :each what?". > > > > > > > > I think once people run the spec and see 1 example 0 failures, they > > know > > > that the 'it do' is an example > > > > > > > > > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > > > I fully agree with Dean and prefer the "before :each", "after :all" > > > option, it reads better and is easier to understand for newbies. > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > > > Setup and teardown are more approachable to converts from > > Test::Unit, > > > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > > > > > "all_examples" might cause people to ask "what examples?" I'm not > > sure > > > > > > most people will think of the "it blocks" as examples. Still, you > > > > > > could just accept any symbol that begins with "each" and "all", so > > > > > > people can invent their own name ;) > > > > > > > > > > > > dean > > > > > > > > > > > > > > > > > > On 4/11/07, David Chelimsky wrote: > > > > > > > We're going to rename context_setup and context_teardown because > > > they > > > > > > > no longer read well when using "describe/id". There are two > > ideas > > > > > > > floating around about this. The first: > > > > > > > > > > > > > > setup :each #default - works like setup does now > > > > > > > setup :all #replaces context_setup > > > > > > > teardown :each #default - works like teardown does now > > > > > > > teardown :all #replaces context teardown > > > > > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > > > > > before :each #default - works like setup does now > > > > > > > before :all #replaces context_setup > > > > > > > after :each #default - works like teardown does now > > > > > > > after :all #replaces context teardown > > > > > > > > > > > > > > In both cases, the default is :each, so you can just say "setup > > do" > > > or > > > > > > > "before do" instead of "setup :each do" or "before :each do". > > > > > > > > > > > > > > == Examples > > > > > > > > > > > > > > describe Thing do > > > > > > > setup :all { ... } > > > > > > > setup :each { ... } > > > > > > > it "should do something" { ... } > > > > > > > it "should do something else" { ... } > > > > > > > teardown :each { ... } > > > > > > > teardown :all { ... } > > > > > > > end > > > > > > > > > > > > > > describe Thing do > > > > > > > before :all { ... } > > > > > > > before :each { ... } > > > > > > > it "should do something" { ... } > > > > > > > it "should do something else" { ... } > > > > > > > after :each { ... } > > > > > > > after :all { ... } > > > > > > > end > > > > > > > > > > > > > > describe Thing do > > > > > > > before { ... } # works like before :each > > > > > > > it "should do something" { ... } > > > > > > > it "should do something else" { ... } > > > > > > > after { ... } # works like after :each > > > > > > > end > > > > > > > > > > > > > > One other thing that occurs to me is that "before :each" really > > > means > > > > > > > "before each example" - so perhaps it should be "before > > > :each_example" > > > > > > > and "before :all_examples" (or :each and :each_example could > > both be > > > > > > > supported, etc). > > > > > > > > > > > > > > WDYT? > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Dean Wampler > > > > > > http://www.objectmentor.com > > > > > > http://www.aspectprogramming.com > > > > > > http://www.contract4j.org > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From mattaimonetti at gmail.com Tue May 1 12:39:02 2007 From: mattaimonetti at gmail.com (Matt Aimonetti) Date: Tue, 1 May 2007 09:39:02 -0700 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> Message-ID: after(:each) doesn't work either. -Matt On 5/1/07, aslak hellesoy wrote: > > It's after(:each) and not teardown(:each) > > On 5/1/07, Matt Aimonetti wrote: > > describe "a legacy user" do > > include LegacyUserHelper > > > > before :all do > > LEGACY.connect > > migration_for_legacy_users > > end > > > > before do > > @l_user = LegacyUser.new > > end > > > > teardown :each do > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > end > > > > Here is a snippet of my code. > > > > Before running my examples, I need to connect to my legacy database and > > migrating the schema. After each example I need to delete the legacy > user > > just created. To get the above code to work, I had to move my > > delete_user_with_email(valid_legacy_user_attributes[:email]) function to > be > > run before each example instead of after. > > > > -Matt > > > > On 4/30/07, David Chelimsky wrote: > > > > > > On 4/30/07, Matt Aimonetti wrote: > > > > teardown :each and after :each don't seem to work for me. > > > > > > > > I had to move my function from "teardown :each" to "before" since > the > > > > function was deleting the object created by the previous spec and > the > > > > function didn't seem to be called. Maybe I didn't understand > properly > > > how > > > > teardown and after work. > > > > > > Each example (i.e. #it or #specify) gets run in its own object. It has > > > no access to any state in the other examples. before(:each) is run > > > before each example, in the same object as the example. after(:each) > > > is run after each example, in the same object as the example. > > > > > > I'm a bit confused by your description of the problem. Can you post > > > some code so we can talk about a specific example? > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > On 4/18/07, Matthew Heidemann wrote: > > > > > I personally like before :each_example. The first time I read it I > > > said, > > > > "before :each what?". > > > > > > > > > > I think once people run the spec and see 1 example 0 failures, > they > > > know > > > > that the 'it do' is an example > > > > > > > > > > > > > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > > > > I fully agree with Dean and prefer the "before :each", "after > :all" > > > > option, it reads better and is easier to understand for newbies. > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > > > > Setup and teardown are more approachable to converts from > > > Test::Unit, > > > > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > > > > > > > "all_examples" might cause people to ask "what examples?" I'm > not > > > sure > > > > > > > most people will think of the "it blocks" as examples. Still, > you > > > > > > > could just accept any symbol that begins with "each" and > "all", so > > > > > > > people can invent their own name ;) > > > > > > > > > > > > > > dean > > > > > > > > > > > > > > > > > > > > > On 4/11/07, David Chelimsky wrote: > > > > > > > > We're going to rename context_setup and context_teardown > because > > > > they > > > > > > > > no longer read well when using "describe/id". There are two > > > ideas > > > > > > > > floating around about this. The first: > > > > > > > > > > > > > > > > setup :each #default - works like setup does now > > > > > > > > setup :all #replaces context_setup > > > > > > > > teardown :each #default - works like teardown does now > > > > > > > > teardown :all #replaces context teardown > > > > > > > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > > > > > > > before :each #default - works like setup does now > > > > > > > > before :all #replaces context_setup > > > > > > > > after :each #default - works like teardown does now > > > > > > > > after :all #replaces context teardown > > > > > > > > > > > > > > > > In both cases, the default is :each, so you can just say > "setup > > > do" > > > > or > > > > > > > > "before do" instead of "setup :each do" or "before :each > do". > > > > > > > > > > > > > > > > == Examples > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > setup :all { ... } > > > > > > > > setup :each { ... } > > > > > > > > it "should do something" { ... } > > > > > > > > it "should do something else" { ... } > > > > > > > > teardown :each { ... } > > > > > > > > teardown :all { ... } > > > > > > > > end > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > before :all { ... } > > > > > > > > before :each { ... } > > > > > > > > it "should do something" { ... } > > > > > > > > it "should do something else" { ... } > > > > > > > > after :each { ... } > > > > > > > > after :all { ... } > > > > > > > > end > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > before { ... } # works like before :each > > > > > > > > it "should do something" { ... } > > > > > > > > it "should do something else" { ... } > > > > > > > > after { ... } # works like after :each > > > > > > > > end > > > > > > > > > > > > > > > > One other thing that occurs to me is that "before :each" > really > > > > means > > > > > > > > "before each example" - so perhaps it should be "before > > > > :each_example" > > > > > > > > and "before :all_examples" (or :each and :each_example could > > > both be > > > > > > > > supported, etc). > > > > > > > > > > > > > > > > WDYT? > > > > > > > > _______________________________________________ > > > > > > > > rspec-devel mailing list > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Dean Wampler > > > > > > > http://www.objectmentor.com > > > > > > > http://www.aspectprogramming.com > > > > > > > http://www.contract4j.org > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070501/7e27c661/attachment.html From aslak.hellesoy at gmail.com Tue May 1 14:15:46 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 1 May 2007 20:15:46 +0200 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> Message-ID: <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> On 5/1/07, Matt Aimonetti wrote: > after(:each) doesn't work either. > Really? A sample spec showing how after(:each) doesn't work would be helpful. Aslak > -Matt > > > On 5/1/07, aslak hellesoy wrote: > > > > It's after(:each) and not teardown(:each) > > > > On 5/1/07, Matt Aimonetti < mattaimonetti at gmail.com> wrote: > > > describe "a legacy user" do > > > include LegacyUserHelper > > > > > > before :all do > > > LEGACY.connect > > > migration_for_legacy_users > > > end > > > > > > before do > > > @l_user = LegacyUser.new > > > end > > > > > > teardown :each do > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > > end > > > > > > Here is a snippet of my code. > > > > > > Before running my examples, I need to connect to my legacy database and > > > migrating the schema. After each example I need to delete the legacy > user > > > just created. To get the above code to work, I had to move my > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > function to be > > > run before each example instead of after. > > > > > > -Matt > > > > > > On 4/30/07, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > > On 4/30/07, Matt Aimonetti wrote: > > > > > teardown :each and after :each don't seem to work for me. > > > > > > > > > > I had to move my function from "teardown :each" to "before" since > the > > > > > function was deleting the object created by the previous spec and > the > > > > > function didn't seem to be called. Maybe I didn't understand > properly > > > > how > > > > > teardown and after work. > > > > > > > > Each example (i.e. #it or #specify) gets run in its own object. It has > > > > no access to any state in the other examples. before(:each) is run > > > > before each example, in the same object as the example. after(:each) > > > > is run after each example, in the same object as the example. > > > > > > > > I'm a bit confused by your description of the problem. Can you post > > > > some code so we can talk about a specific example? > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > On 4/18/07, Matthew Heidemann < matthew.heidemann at gmail.com> wrote: > > > > > > I personally like before :each_example. The first time I read it I > > > > said, > > > > > "before :each what?". > > > > > > > > > > > > I think once people run the spec and see 1 example 0 failures, > they > > > > know > > > > > that the 'it do' is an example > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > > > > > I fully agree with Dean and prefer the "before :each", "after > :all" > > > > > option, it reads better and is easier to understand for newbies. > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > > > > > Setup and teardown are more approachable to converts from > > > > Test::Unit, > > > > > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > > > > > > > > > "all_examples" might cause people to ask "what examples?" I'm > not > > > > sure > > > > > > > > most people will think of the "it blocks" as examples. Still, > you > > > > > > > > could just accept any symbol that begins with "each" and > "all", so > > > > > > > > people can invent their own name ;) > > > > > > > > > > > > > > > > dean > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > > > We're going to rename context_setup and context_teardown > because > > > > > they > > > > > > > > > no longer read well when using "describe/id". There are two > > > > ideas > > > > > > > > > floating around about this. The first: > > > > > > > > > > > > > > > > > > setup :each #default - works like setup does now > > > > > > > > > setup :all #replaces context_setup > > > > > > > > > teardown :each #default - works like teardown does now > > > > > > > > > teardown :all #replaces context teardown > > > > > > > > > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > > > > > > > > > before :each #default - works like setup does now > > > > > > > > > before :all #replaces context_setup > > > > > > > > > after :each #default - works like teardown does now > > > > > > > > > after :all #replaces context teardown > > > > > > > > > > > > > > > > > > In both cases, the default is :each, so you can just say > "setup > > > > do" > > > > > or > > > > > > > > > "before do" instead of "setup :each do" or "before :each > do". > > > > > > > > > > > > > > > > > > == Examples > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > setup :all { ... } > > > > > > > > > setup :each { ... } > > > > > > > > > it "should do something" { ... } > > > > > > > > > it "should do something else" { ... } > > > > > > > > > teardown :each { ... } > > > > > > > > > teardown :all { ... } > > > > > > > > > end > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > before :all { ... } > > > > > > > > > before :each { ... } > > > > > > > > > it "should do something" { ... } > > > > > > > > > it "should do something else" { ... } > > > > > > > > > after :each { ... } > > > > > > > > > after :all { ... } > > > > > > > > > end > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > before { ... } # works like before :each > > > > > > > > > it "should do something" { ... } > > > > > > > > > it "should do something else" { ... } > > > > > > > > > after { ... } # works like after :each > > > > > > > > > end > > > > > > > > > > > > > > > > > > One other thing that occurs to me is that "before :each" > really > > > > > means > > > > > > > > > "before each example" - so perhaps it should be "before > > > > > :each_example" > > > > > > > > > and "before :all_examples" (or :each and :each_example could > > > > both be > > > > > > > > > supported, etc). > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > _______________________________________________ > > > > > > > > > rspec-devel mailing list > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Dean Wampler > > > > > > > > http://www.objectmentor.com > > > > > > > > http://www.aspectprogramming.com > > > > > > > > http://www.contract4j.org > > > > > > > > > _______________________________________________ > > > > > > > > rspec-devel mailing list > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue May 1 14:17:26 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 1 May 2007 20:17:26 +0200 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <6cf2a94f0704111056s591105bfm92e32c5e88fb2dc4@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> Message-ID: <8d961d900705011117i23d9c1d2jcaa5f5a343257c9f@mail.gmail.com> On 5/1/07, aslak hellesoy wrote: > On 5/1/07, Matt Aimonetti wrote: > > after(:each) doesn't work either. > > > > Really? A sample spec showing how after(:each) doesn't work would be helpful. > I mean some code I can run to reproduce what you see. > Aslak > > > -Matt > > > > > > On 5/1/07, aslak hellesoy wrote: > > > > > > It's after(:each) and not teardown(:each) > > > > > > On 5/1/07, Matt Aimonetti < mattaimonetti at gmail.com> wrote: > > > > describe "a legacy user" do > > > > include LegacyUserHelper > > > > > > > > before :all do > > > > LEGACY.connect > > > > migration_for_legacy_users > > > > end > > > > > > > > before do > > > > @l_user = LegacyUser.new > > > > end > > > > > > > > teardown :each do > > > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > > > end > > > > > > > > Here is a snippet of my code. > > > > > > > > Before running my examples, I need to connect to my legacy database and > > > > migrating the schema. After each example I need to delete the legacy > > user > > > > just created. To get the above code to work, I had to move my > > > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > function to be > > > > run before each example instead of after. > > > > > > > > -Matt > > > > > > > > On 4/30/07, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > > > > On 4/30/07, Matt Aimonetti wrote: > > > > > > teardown :each and after :each don't seem to work for me. > > > > > > > > > > > > I had to move my function from "teardown :each" to "before" since > > the > > > > > > function was deleting the object created by the previous spec and > > the > > > > > > function didn't seem to be called. Maybe I didn't understand > > properly > > > > > how > > > > > > teardown and after work. > > > > > > > > > > Each example (i.e. #it or #specify) gets run in its own object. It has > > > > > no access to any state in the other examples. before(:each) is run > > > > > before each example, in the same object as the example. after(:each) > > > > > is run after each example, in the same object as the example. > > > > > > > > > > I'm a bit confused by your description of the problem. Can you post > > > > > some code so we can talk about a specific example? > > > > > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > On 4/18/07, Matthew Heidemann < matthew.heidemann at gmail.com> wrote: > > > > > > > I personally like before :each_example. The first time I read it I > > > > > said, > > > > > > "before :each what?". > > > > > > > > > > > > > > I think once people run the spec and see 1 example 0 failures, > > they > > > > > know > > > > > > that the 'it do' is an example > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > > > > > > I fully agree with Dean and prefer the "before :each", "after > > :all" > > > > > > option, it reads better and is easier to understand for newbies. > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > > > > > > Setup and teardown are more approachable to converts from > > > > > Test::Unit, > > > > > > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > > > > > > > > > > > "all_examples" might cause people to ask "what examples?" I'm > > not > > > > > sure > > > > > > > > > most people will think of the "it blocks" as examples. Still, > > you > > > > > > > > > could just accept any symbol that begins with "each" and > > "all", so > > > > > > > > > people can invent their own name ;) > > > > > > > > > > > > > > > > > > dean > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > > > > We're going to rename context_setup and context_teardown > > because > > > > > > they > > > > > > > > > > no longer read well when using "describe/id". There are two > > > > > ideas > > > > > > > > > > floating around about this. The first: > > > > > > > > > > > > > > > > > > > > setup :each #default - works like setup does now > > > > > > > > > > setup :all #replaces context_setup > > > > > > > > > > teardown :each #default - works like teardown does now > > > > > > > > > > teardown :all #replaces context teardown > > > > > > > > > > > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > > > > > > > > > > > before :each #default - works like setup does now > > > > > > > > > > before :all #replaces context_setup > > > > > > > > > > after :each #default - works like teardown does now > > > > > > > > > > after :all #replaces context teardown > > > > > > > > > > > > > > > > > > > > In both cases, the default is :each, so you can just say > > "setup > > > > > do" > > > > > > or > > > > > > > > > > "before do" instead of "setup :each do" or "before :each > > do". > > > > > > > > > > > > > > > > > > > > == Examples > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > setup :all { ... } > > > > > > > > > > setup :each { ... } > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > teardown :each { ... } > > > > > > > > > > teardown :all { ... } > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > before :all { ... } > > > > > > > > > > before :each { ... } > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > after :each { ... } > > > > > > > > > > after :all { ... } > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > before { ... } # works like before :each > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > after { ... } # works like after :each > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > One other thing that occurs to me is that "before :each" > > really > > > > > > means > > > > > > > > > > "before each example" - so perhaps it should be "before > > > > > > :each_example" > > > > > > > > > > and "before :all_examples" (or :each and :each_example could > > > > > both be > > > > > > > > > > supported, etc). > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > rspec-devel mailing list > > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Dean Wampler > > > > > > > > > http://www.objectmentor.com > > > > > > > > > http://www.aspectprogramming.com > > > > > > > > > http://www.contract4j.org > > > > > > > > > > > _______________________________________________ > > > > > > > > > rspec-devel mailing list > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rspec-devel mailing list > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From mattaimonetti at gmail.com Tue May 1 23:27:07 2007 From: mattaimonetti at gmail.com (Matt Aimonetti) Date: Tue, 1 May 2007 20:27:07 -0700 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <8d961d900705011117i23d9c1d2jcaa5f5a343257c9f@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> <8d961d900705011117i23d9c1d2jcaa5f5a343257c9f@mail.gmail.com> Message-ID: Ok, I created a new project and tried to reproduce my issue and I discovered something else. I can't really reproduce the previously reported problem. I have a new rails project with one User model with validates_uniqueness_of :email Here is my spec file for the model require File.dirname(__FILE__) + '/../spec_helper' def create_test_user User.new(:first_name => 'John', :last_name => 'Doe', :email => ' john at doe.fr').save end describe "A user" do it "should be created if valid" do create_test_user.should be(true) create_test_user.should be(false) end it "should not have the same email than another user" do create_test_user.should be(false) end end The second example fails. I'm a bit surprised that the user created by the first example doesn't exist anymore when the 2nd example tries creating a new user. rspec_on_rails plugin and rspec gem from trunk. (updated today) -Matt On 5/1/07, aslak hellesoy wrote: > > On 5/1/07, aslak hellesoy wrote: > > On 5/1/07, Matt Aimonetti wrote: > > > after(:each) doesn't work either. > > > > > > > Really? A sample spec showing how after(:each) doesn't work would be > helpful. > > > > I mean some code I can run to reproduce what you see. > > > Aslak > > > > > -Matt > > > > > > > > > On 5/1/07, aslak hellesoy wrote: > > > > > > > > It's after(:each) and not teardown(:each) > > > > > > > > On 5/1/07, Matt Aimonetti < mattaimonetti at gmail.com> wrote: > > > > > describe "a legacy user" do > > > > > include LegacyUserHelper > > > > > > > > > > before :all do > > > > > LEGACY.connect > > > > > migration_for_legacy_users > > > > > end > > > > > > > > > > before do > > > > > @l_user = LegacyUser.new > > > > > end > > > > > > > > > > teardown :each do > > > > > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > > > > end > > > > > > > > > > Here is a snippet of my code. > > > > > > > > > > Before running my examples, I need to connect to my legacy > database and > > > > > migrating the schema. After each example I need to delete the > legacy > > > user > > > > > just created. To get the above code to work, I had to move my > > > > > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > > function to be > > > > > run before each example instead of after. > > > > > > > > > > -Matt > > > > > > > > > > On 4/30/07, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > > > > > > On 4/30/07, Matt Aimonetti wrote: > > > > > > > teardown :each and after :each don't seem to work for me. > > > > > > > > > > > > > > I had to move my function from "teardown :each" to "before" > since > > > the > > > > > > > function was deleting the object created by the previous spec > and > > > the > > > > > > > function didn't seem to be called. Maybe I didn't understand > > > properly > > > > > > how > > > > > > > teardown and after work. > > > > > > > > > > > > Each example (i.e. #it or #specify) gets run in its own object. > It has > > > > > > no access to any state in the other examples. before(:each) is > run > > > > > > before each example, in the same object as the example. > after(:each) > > > > > > is run after each example, in the same object as the example. > > > > > > > > > > > > I'm a bit confused by your description of the problem. Can you > post > > > > > > some code so we can talk about a specific example? > > > > > > > > > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > On 4/18/07, Matthew Heidemann < matthew.heidemann at gmail.com> > wrote: > > > > > > > > I personally like before :each_example. The first time I > read it I > > > > > > said, > > > > > > > "before :each what?". > > > > > > > > > > > > > > > > I think once people run the spec and see 1 example 0 > failures, > > > they > > > > > > know > > > > > > > that the 'it do' is an example > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > > > > > > > I fully agree with Dean and prefer the "before :each", > "after > > > :all" > > > > > > > option, it reads better and is easier to understand for > newbies. > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > > > > > > > Setup and teardown are more approachable to converts > from > > > > > > Test::Unit, > > > > > > > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > > > > > > > > > > > > > "all_examples" might cause people to ask "what > examples?" I'm > > > not > > > > > > sure > > > > > > > > > > most people will think of the "it blocks" as examples. > Still, > > > you > > > > > > > > > > could just accept any symbol that begins with "each" and > > > "all", so > > > > > > > > > > people can invent their own name ;) > > > > > > > > > > > > > > > > > > > > dean > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, David Chelimsky < dchelimsky at gmail.com> > wrote: > > > > > > > > > > > We're going to rename context_setup and > context_teardown > > > because > > > > > > > they > > > > > > > > > > > no longer read well when using "describe/id". There > are two > > > > > > ideas > > > > > > > > > > > floating around about this. The first: > > > > > > > > > > > > > > > > > > > > > > setup :each #default - works like setup does > now > > > > > > > > > > > setup :all #replaces context_setup > > > > > > > > > > > teardown :each #default - works like teardown does now > > > > > > > > > > > teardown :all #replaces context teardown > > > > > > > > > > > > > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > > > > > > > > > > > > > before :each #default - works like setup does now > > > > > > > > > > > before :all #replaces context_setup > > > > > > > > > > > after :each #default - works like teardown does > now > > > > > > > > > > > after :all #replaces context teardown > > > > > > > > > > > > > > > > > > > > > > In both cases, the default is :each, so you can just > say > > > "setup > > > > > > do" > > > > > > > or > > > > > > > > > > > "before do" instead of "setup :each do" or "before > :each > > > do". > > > > > > > > > > > > > > > > > > > > > > == Examples > > > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > > setup :all { ... } > > > > > > > > > > > setup :each { ... } > > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > > teardown :each { ... } > > > > > > > > > > > teardown :all { ... } > > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > > before :all { ... } > > > > > > > > > > > before :each { ... } > > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > > after :each { ... } > > > > > > > > > > > after :all { ... } > > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > > before { ... } # works like before :each > > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > > after { ... } # works like after :each > > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > > > One other thing that occurs to me is that "before > :each" > > > really > > > > > > > means > > > > > > > > > > > "before each example" - so perhaps it should be > "before > > > > > > > :each_example" > > > > > > > > > > > and "before :all_examples" (or :each and :each_example > could > > > > > > both be > > > > > > > > > > > supported, etc). > > > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rspec-devel mailing list > > > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Dean Wampler > > > > > > > > > > http://www.objectmentor.com > > > > > > > > > > http://www.aspectprogramming.com > > > > > > > > > > http://www.contract4j.org > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > rspec-devel mailing list > > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rspec-devel mailing list > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rspec-devel mailing list > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070501/b4ee6148/attachment-0001.html From dchelimsky at gmail.com Tue May 1 23:36:44 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 1 May 2007 22:36:44 -0500 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> <8d961d900705011117i23d9c1d2jcaa5f5a343257c9f@mail.gmail.com> Message-ID: <57c63afe0705012036g65a1b855n59f417c1d2dc6c05@mail.gmail.com> On 5/1/07, Matt Aimonetti wrote: > Ok, I created a new project and tried to reproduce my issue and I discovered > something else. I can't really reproduce the previously reported problem. > > I have a new rails project with one User model with validates_uniqueness_of > :email > > Here is my spec file for the model > > require File.dirname(__FILE__) + '/../spec_helper' > def create_test_user > User.new(:first_name => 'John', :last_name => 'Doe', :email => ' > john at doe.fr').save > end > > describe "A user" do > > it "should be created if valid" do > create_test_user.should be(true) > create_test_user.should be(false) > end > > it "should not have the same email than another user" do > create_test_user.should be(false) > end > end > > The second example fails. I'm a bit surprised that the user created by the > first example doesn't exist anymore when the 2nd example tries creating a > new user. Actually, it is a well established guideline in unit testing that every test method (it block in our case) should run in complete isolation from every other test method. In the case of Spec::Rails, the database is rolled back to its previous state between each example - so it is the intended behaviour that your second example should fail. Think of the alternative. If that example passed only because of state set up in the previous example, then you'd not be able to run only that one example, or run them in a different order. This sort of independence is absolutely crucial to the process. > > rspec_on_rails plugin and rspec gem from trunk. (updated today) > > > -Matt > > > On 5/1/07, aslak hellesoy < aslak.hellesoy at gmail.com> wrote: > > On 5/1/07, aslak hellesoy < aslak.hellesoy at gmail.com> wrote: > > > On 5/1/07, Matt Aimonetti wrote: > > > > after(:each) doesn't work either. > > > > > > > > > > Really? A sample spec showing how after(:each) doesn't work would be > helpful. > > > > > > > I mean some code I can run to reproduce what you see. > > > > > Aslak > > > > > > > -Matt > > > > > > > > > > > > On 5/1/07, aslak hellesoy wrote: > > > > > > > > > > It's after(:each) and not teardown(:each) > > > > > > > > > > On 5/1/07, Matt Aimonetti < mattaimonetti at gmail.com> wrote: > > > > > > describe "a legacy user" do > > > > > > include LegacyUserHelper > > > > > > > > > > > > before :all do > > > > > > LEGACY.connect > > > > > > migration_for_legacy_users > > > > > > end > > > > > > > > > > > > before do > > > > > > @l_user = LegacyUser.new > > > > > > end > > > > > > > > > > > > teardown :each do > > > > > > > > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > > > > > end > > > > > > > > > > > > Here is a snippet of my code. > > > > > > > > > > > > Before running my examples, I need to connect to my legacy > database and > > > > > > migrating the schema. After each example I need to delete the > legacy > > > > user > > > > > > just created. To get the above code to work, I had to move my > > > > > > > > > > > delete_user_with_email(valid_legacy_user_attributes[:email]) > > > > function to be > > > > > > run before each example instead of after. > > > > > > > > > > > > -Matt > > > > > > > > > > > > On 4/30/07, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > > > > > > > > On 4/30/07, Matt Aimonetti < mattaimonetti at gmail.com> wrote: > > > > > > > > teardown :each and after :each don't seem to work for me. > > > > > > > > > > > > > > > > I had to move my function from "teardown :each" to "before" > since > > > > the > > > > > > > > function was deleting the object created by the previous spec > and > > > > the > > > > > > > > function didn't seem to be called. Maybe I didn't understand > > > > properly > > > > > > > how > > > > > > > > teardown and after work. > > > > > > > > > > > > > > Each example (i.e. #it or #specify) gets run in its own object. > It has > > > > > > > no access to any state in the other examples. before(:each) is > run > > > > > > > before each example, in the same object as the example. > after(:each) > > > > > > > is run after each example, in the same object as the example. > > > > > > > > > > > > > > I'm a bit confused by your description of the problem. Can you > post > > > > > > > some code so we can talk about a specific example? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > > > On 4/18/07, Matthew Heidemann < matthew.heidemann at gmail.com> > wrote: > > > > > > > > > I personally like before :each_example. The first time I > read it I > > > > > > > said, > > > > > > > > "before :each what?". > > > > > > > > > > > > > > > > > > I think once people run the spec and see 1 example 0 > failures, > > > > they > > > > > > > know > > > > > > > > that the 'it do' is an example > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Matt Aimonetti < matt at aimonetti.net> wrote: > > > > > > > > > > I fully agree with Dean and prefer the "before :each", > "after > > > > :all" > > > > > > > > option, it reads better and is easier to understand for > newbies. > > > > > > > > > > > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, Dean Wampler wrote: > > > > > > > > > > > Setup and teardown are more approachable to converts > from > > > > > > > Test::Unit, > > > > > > > > > > > but "before :all" and "after :each" read better, IMHO. > > > > > > > > > > > > > > > > > > > > > > "all_examples" might cause people to ask "what > examples?" I'm > > > > not > > > > > > > sure > > > > > > > > > > > most people will think of the "it blocks" as examples. > Still, > > > > you > > > > > > > > > > > could just accept any symbol that begins with "each" and > > > > "all", so > > > > > > > > > > > people can invent their own name ;) > > > > > > > > > > > > > > > > > > > > > > dean > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/11/07, David Chelimsky < dchelimsky at gmail.com > > wrote: > > > > > > > > > > > > We're going to rename context_setup and > context_teardown > > > > because > > > > > > > > they > > > > > > > > > > > > no longer read well when using "describe/id". There > are two > > > > > > > ideas > > > > > > > > > > > > floating around about this. The first: > > > > > > > > > > > > > > > > > > > > > > > > setup :each #default - works like setup does > now > > > > > > > > > > > > setup :all #replaces context_setup > > > > > > > > > > > > teardown :each #default - works like teardown does now > > > > > > > > > > > > teardown :all #replaces context teardown > > > > > > > > > > > > > > > > > > > > > > > > The second uses "before" and "after" in the same way: > > > > > > > > > > > > > > > > > > > > > > > > before :each #default - works like setup does now > > > > > > > > > > > > before :all #replaces context_setup > > > > > > > > > > > > after :each #default - works like teardown does > now > > > > > > > > > > > > after :all #replaces context teardown > > > > > > > > > > > > > > > > > > > > > > > > In both cases, the default is :each, so you can just > say > > > > "setup > > > > > > > do" > > > > > > > > or > > > > > > > > > > > > "before do" instead of "setup :each do" or "before > :each > > > > do". > > > > > > > > > > > > > > > > > > > > > > > > == Examples > > > > > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > > > setup :all { ... } > > > > > > > > > > > > setup :each { ... } > > > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > > > teardown :each { ... } > > > > > > > > > > > > teardown :all { ... } > > > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > > > before :all { ... } > > > > > > > > > > > > before :each { ... } > > > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > > > after :each { ... } > > > > > > > > > > > > after :all { ... } > > > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > > > > > describe Thing do > > > > > > > > > > > > before { ... } # works like before :each > > > > > > > > > > > > it "should do something" { ... } > > > > > > > > > > > > it "should do something else" { ... } > > > > > > > > > > > > after { ... } # works like after :each > > > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > > > > > One other thing that occurs to me is that "before > :each" > > > > really > > > > > > > > means > > > > > > > > > > > > "before each example" - so perhaps it should be > "before > > > > > > > > :each_example" > > > > > > > > > > > > and "before :all_examples" (or :each and :each_example > could > > > > > > > both be > > > > > > > > > > > > supported, etc). > > > > > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > rspec-devel mailing list > > > > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Dean Wampler > > > > > > > > > > > http://www.objectmentor.com > > > > > > > > > > > http://www.aspectprogramming.com > > > > > > > > > > > http://www.contract4j.org > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rspec-devel mailing list > > > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > rspec-devel mailing list > > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rspec-devel mailing list > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rspec-devel mailing list > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From michael.s.klishin at gmail.com Wed May 2 00:27:19 2007 From: michael.s.klishin at gmail.com (Michael Klishin) Date: Wed, 2 May 2007 08:27:19 +0400 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <306e36aa0704181620m23edba0bn9ae388ca007402be@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> <8d961d900705011117i23d9c1d2jcaa5f5a343257c9f@mail.gmail.com> Message-ID: <709de1d10705012127r1e36d5dbn93d7e25b9a3178a3@mail.gmail.com> Matt, Second spec is not supposed to pass. You have to put the code creating model in setup (before all in rspec 0.9 terms) cause DB is cleared and refilled before each spec run. So this is expected behavior. On 02/05/07, Matt Aimonetti wrote: > The second example fails. I'm a bit surprised that the user created by the > first example doesn't exist anymore when the 2nd example tries creating a > new user. -- This was freedom. Losing all hope was freedom. Chasing the beauty in programming: www.ruby-lang.org | www.rubyonrails.org From noreply at rubyforge.org Wed May 2 04:21:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 04:21:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10516 ] should_include should be able to accept multiple items Message-ID: <20070502082128.D796F5240AF2@rubyforge.org> Feature Requests item #10516, was opened at 2007-05-02 11:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Sharon Rosner (ciconia) Assigned to: Nobody (None) Summary: should_include should be able to accept multiple items Initial Comment: example: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should_include(:read, :write, :execute) end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 From noreply at rubyforge.org Wed May 2 04:38:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 04:38:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10516 ] should_include should be able to accept multiple items Message-ID: <20070502083851.1BF595240942@rubyforge.org> Feature Requests item #10516, was opened at 2007-05-02 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Sharon Rosner (ciconia) Assigned to: Nobody (None) Summary: should_include should be able to accept multiple items Initial Comment: example: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should_include(:read, :write, :execute) end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 04:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 From noreply at rubyforge.org Wed May 2 07:48:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 07:48:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10516 ] should_include should be able to accept multiple items Message-ID: <20070502114845.9EFDC5240990@rubyforge.org> Feature Requests item #10516, was opened at 2007-05-02 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: Sharon Rosner (ciconia) Assigned to: Nobody (None) Summary: should_include should be able to accept multiple items Initial Comment: example: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should_include(:read, :write, :execute) end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 07:48 Message: Sorry, I was a little quick on the trigger here. We should be able to implement the include matcher with varargs as you ask - good idea!. No need to provide the version info I asked about :-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 04:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 From aslak.hellesoy at gmail.com Wed May 2 10:34:08 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 2 May 2007 16:34:08 +0200 Subject: [rspec-devel] Multiple formatters In-Reply-To: References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> <6C5E6525-73D4-4C51-A278-B60795754BC1@railsnewbie.com> <8d961d900705010445o192830en8639ebea3029a378@mail.gmail.com> Message-ID: <8d961d900705020734h2312202dq99ce05bd36f15ff6@mail.gmail.com> > On another note, what is the exact difference between using should eql > () and should == > ? > should eql uses Object#eql? and should == uses Object#== See the ruby doc for the difference: http://www.ruby-doc.org/core/classes/Object.html#M000341 Aslak > Best, > > Scott From mattaimonetti at gmail.com Wed May 2 14:36:12 2007 From: mattaimonetti at gmail.com (Matt Aimonetti) Date: Wed, 2 May 2007 11:36:12 -0700 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: <709de1d10705012127r1e36d5dbn93d7e25b9a3178a3@mail.gmail.com> References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> <8d961d900705011117i23d9c1d2jcaa5f5a343257c9f@mail.gmail.com> <709de1d10705012127r1e36d5dbn93d7e25b9a3178a3@mail.gmail.com> Message-ID: Thanks for the clarification. For some reason, in my project the DB is not cleared and that's why I had to use an after(:each) call. It might be because my example calls a module which creates a new user instead of creating the user directly. Nevermind, I just tried in a new project and it works well. I don't know what's wrong. Anyway, is it normal that the following code passes: def create_test_user User.new(:first_name => 'John', :last_name => 'Doe', :email => ' john at doe.fr').save end describe "A user" do after :each do create_test_user end it "should be created if valid" do create_test_user.should be(true) create_test_user.should be(false) end it "should not have the same email than another user" do create_test_user.should be(true) end end (Obviously if I replace after by before, then the example fail) -Matt On 5/1/07, Michael Klishin wrote: > > Matt, > > Second spec is not supposed to pass. You have to put the code creating > model in setup (before all in rspec 0.9 terms) cause DB is cleared > and refilled before each spec run. So this is expected behavior. > > On 02/05/07, Matt Aimonetti wrote: > > > The second example fails. I'm a bit surprised that the user created by > the > > first example doesn't exist anymore when the 2nd example tries creating > a > > new user. > > -- > This was freedom. Losing all hope was freedom. > > Chasing the beauty in programming: > www.ruby-lang.org | www.rubyonrails.org > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070502/3b6f1b62/attachment-0001.html From dchelimsky at gmail.com Wed May 2 14:49:18 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 2 May 2007 13:49:18 -0500 Subject: [rspec-devel] names for setup and teardown methods In-Reply-To: References: <57c63afe0704110549x2c2a42f6l641e0c59e9de0afb@mail.gmail.com> <57c63afe0704301726n65e7ea4bvbd993c2e1cce723c@mail.gmail.com> <8d961d900705010922u105fe984i5a462c36cb6236b9@mail.gmail.com> <8d961d900705011115s7bcd474boa2b5dc4385143b86@mail.gmail.com> <8d961d900705011117i23d9c1d2jcaa5f5a343257c9f@mail.gmail.com> <709de1d10705012127r1e36d5dbn93d7e25b9a3178a3@mail.gmail.com> Message-ID: <57c63afe0705021149m9e50fd3u75e474c0aed8f085@mail.gmail.com> On 5/2/07, Matt Aimonetti wrote: > Thanks for the clarification. For some reason, in my project the DB is not > cleared and that's why I had to use an after(:each) call. It might be > because my example calls a module which creates a new user instead of > creating the user directly. Nevermind, I just tried in a new project and it > works well. I don't know what's wrong. > > Anyway, is it normal that the following code passes: Yes. It tries to recreate the test user after each example, but that all gets wiped out before the next one, so both examples should pass. David > > def create_test_user > User.new(:first_name => 'John', :last_name => 'Doe', :email => > 'john at doe.fr ').save > end > > describe "A user" do > > after :each do > create_test_user > end > > it "should be created if valid" do > create_test_user.should be(true) > create_test_user.should be(false) > end > > it "should not have the same email than another user" do > create_test_user.should be(true) > end > end > > > (Obviously if I replace after by before, then the example fail) > > -Matt > > > > > On 5/1/07, Michael Klishin wrote: > > Matt, > > > > Second spec is not supposed to pass. You have to put the code creating > > model in setup (before all in rspec 0.9 terms) cause DB is cleared > > and refilled before each spec run. So this is expected behavior. > > > > On 02/05/07, Matt Aimonetti wrote: > > > > > The second example fails. I'm a bit surprised that the user created by > the > > > first example doesn't exist anymore when the 2nd example tries creating > a > > > new user. > > > > -- > > This was freedom. Losing all hope was freedom. > > > > Chasing the beauty in programming: > > www.ruby-lang.org | www.rubyonrails.org > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed May 2 16:46:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 16:46:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10529 ] have_tag does not work while assert_select does Message-ID: <20070502204645.1B8255240AFC@rubyforge.org> Bugs item #10529, was opened at 2007-05-02 20:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Roelofs (jameskilton) Assigned to: Nobody (None) Summary: have_tag does not work while assert_select does Initial Comment: I cannot get the development environment setup and thus I cannot run the attached patch against SVN trunk, so if this doesn't die for anyone then I'll check my environment, but this is the exact code that is causing problems in my rails app. Basically, I pass in the exact same options to have_tag as I do to assert_select. assert_select passes perfectly while have_tag fails. My environment: Ruby version 1.8.6 (i386-mswin32) RubyGems version 0.9.2 Rails version 1.2.0 Active Record version 1.14.4 Action Pack version 1.12.5 Action Web Service version 1.1.6 Action Mailer version 1.2.5 Active Support version 1.3.1 Edge Rails revision 6494 Application root C:/Development/AdminPortal Environment development Database adapter mysql ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 From noreply at rubyforge.org Wed May 2 19:49:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 19:49:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10460 ] Make it easier to create default BehaviourRunner Message-ID: <20070502234922.B29715240AF3@rubyforge.org> Feature Requests item #10460, was opened at 2007-04-30 00:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Make it easier to create default BehaviourRunner Initial Comment: Right now, it is difficult to create a default BehaviourRunner in code. The easiest way to do so is to call create_behaviour_runner and pass in simulated command line args. It would be nice if one would instantiate a BehaviourRunner in a "default" state and work from there. So far I created a Spec::Runner::Options class to replace the OpenStruct implementation. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-02 16:49 Message: I implemented David's suggested refactoring. I also created Options#create_behaviour_runner. I'm marking this story is finished because the BehaviourRunner creation is now decoupled from the parser. Of course further refactoring are in order, but that is an ongoing process. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 04:33 Message: I like the idea of localizing the default settings like this, though it makes me think that Options should contain most of the decision making as well, passing command line args to methods on Options. That should make things more clear since right now we have the parsing and decision making all intermingled. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-30 01:40 Message: I already checked in the Options class. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-04-30 00:57 Message: Did you mean to attach the code? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-04-30 00:27 Message: I'm thinking that the Spec::Runner::Options object can be instantiated with default values. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10460&group_id=797 From noreply at rubyforge.org Wed May 2 19:52:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 19:52:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070502235242.66C0E5240AF3@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From mailing_lists at railsnewbie.com Wed May 2 20:08:58 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Wed, 2 May 2007 20:08:58 -0400 Subject: [rspec-devel] Multiple formatters In-Reply-To: References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> <6C5E6525-73D4-4C51-A278-B60795754BC1@railsnewbie.com> <8d961d900705010445o192830en8639ebea3029a378@mail.gmail.com> Message-ID: <5E66E80E-B687-4D6A-A25E-687887B588CF@railsnewbie.com> On May 1, 2007, at 8:14 AM, Scott Taylor wrote: > > On May 1, 2007, at 7:45 AM, aslak hellesoy wrote: > >> On 5/1/07, Scott Taylor wrote: >>> >>> On Apr 24, 2007, at 4:41 AM, aslak hellesoy wrote: >>> >>>> Hi all, >>>> >>>> RSpec supports multiple formatters, but currently you can only >>>> use one >>>> at a time. I really need to use several at the same time. >>>> >>>> I'd like to make RSpec handle several --format options. However, >>>> that >>>> would require some rethinking of how/where output is written - it >>>> can't all go to the same stream (file or stdout). >>>> >>>> So I'm thinking of making --format take a composite argument: >>>> >>>> --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc >>>> --format progress >>>> >>>> If nothing comes after the format, output is STDOUT, so this >>>> would be >>>> backwards compatible. >>>> >>>> If we do this, we could also get rid of --failures - it would >>>> just be >>>> a special formatter. >>>> >>>> WDYT? >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >>> >>> I've seen that you've already implemented this in trunk. >>> >>> I'm not running the latest version of trunk, but I've noticed >>> that in >>> 0.9RC1, when specifying a failures file and an examples file, that >>> the following behavior is exhibited by rspec: >>> >>> 1. If the file exists, but is empty, rspec will run all specs >>> 2. If the file exists, but contains failing examples, these failing >>> specs will be run >>> 3. If the file does not exists, it creates the file (through -- >>> failures - now --format e:filename), but runs no specs. >>> >>> Would a patch addressing the third case (which would mimic the first >>> case) be a welcome addition to rspec? >>> >> >> It would, but how do you suggest that RSpec guesses that you meant a >> file, and not the name of a behaviour or example? > > I would assume that this would be the case if: > > 1. There is a failing examples or failing behavior formatter, with at > @where != out > 2. and that an "example" has the same name as the formatter's @where > 3. (and of course)...that the examples/failures file does not yet > exist > > In this case, the example could just be removed from the list. > Obviously this must go on after the ::OptionParser#parse method is > called. > > So tell me if I'm missing something obvious, but it would seem very > strange if one chose a failures file with the same name as an > example, wouldn't it? It could be done, but who ever dream of doing > so? Who would create a file with a name like "should do such and > such" as the name of their failures file? Do you think it would be acceptable to remove the appropriate example when the File is empty? Scott From aslak.hellesoy at gmail.com Wed May 2 20:22:44 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 3 May 2007 02:22:44 +0200 Subject: [rspec-devel] Multiple formatters In-Reply-To: <5E66E80E-B687-4D6A-A25E-687887B588CF@railsnewbie.com> References: <8d961d900704240141v5c318aaet449db2ab1f83ac7a@mail.gmail.com> <6C5E6525-73D4-4C51-A278-B60795754BC1@railsnewbie.com> <8d961d900705010445o192830en8639ebea3029a378@mail.gmail.com> <5E66E80E-B687-4D6A-A25E-687887B588CF@railsnewbie.com> Message-ID: <8d961d900705021722m1bb15cb7jf5b41f386ebbcc41@mail.gmail.com> On 5/3/07, Scott Taylor wrote: > > On May 1, 2007, at 8:14 AM, Scott Taylor wrote: > > > > > On May 1, 2007, at 7:45 AM, aslak hellesoy wrote: > > > >> On 5/1/07, Scott Taylor wrote: > >>> > >>> On Apr 24, 2007, at 4:41 AM, aslak hellesoy wrote: > >>> > >>>> Hi all, > >>>> > >>>> RSpec supports multiple formatters, but currently you can only > >>>> use one > >>>> at a time. I really need to use several at the same time. > >>>> > >>>> I'd like to make RSpec handle several --format options. However, > >>>> that > >>>> would require some rethinking of how/where output is written - it > >>>> can't all go to the same stream (file or stdout). > >>>> > >>>> So I'm thinking of making --format take a composite argument: > >>>> > >>>> --format html:/path/to/index.html --format rdoc:/path/to/index.rdoc > >>>> --format progress > >>>> > >>>> If nothing comes after the format, output is STDOUT, so this > >>>> would be > >>>> backwards compatible. > >>>> > >>>> If we do this, we could also get rid of --failures - it would > >>>> just be > >>>> a special formatter. > >>>> > >>>> WDYT? > >>>> _______________________________________________ > >>>> rspec-devel mailing list > >>>> rspec-devel at rubyforge.org > >>>> http://rubyforge.org/mailman/listinfo/rspec-devel > >>> > >>> > >>> I've seen that you've already implemented this in trunk. > >>> > >>> I'm not running the latest version of trunk, but I've noticed > >>> that in > >>> 0.9RC1, when specifying a failures file and an examples file, that > >>> the following behavior is exhibited by rspec: > >>> > >>> 1. If the file exists, but is empty, rspec will run all specs > >>> 2. If the file exists, but contains failing examples, these failing > >>> specs will be run > >>> 3. If the file does not exists, it creates the file (through -- > >>> failures - now --format e:filename), but runs no specs. > >>> > >>> Would a patch addressing the third case (which would mimic the first > >>> case) be a welcome addition to rspec? > >>> > >> > >> It would, but how do you suggest that RSpec guesses that you meant a > >> file, and not the name of a behaviour or example? > > > > I would assume that this would be the case if: > > > > 1. There is a failing examples or failing behavior formatter, with at > > @where != out > > 2. and that an "example" has the same name as the formatter's @where > > 3. (and of course)...that the examples/failures file does not yet > > exist > > > > In this case, the example could just be removed from the list. > > Obviously this must go on after the ::OptionParser#parse method is > > called. > > > > So tell me if I'm missing something obvious, but it would seem very > > strange if one chose a failures file with the same name as an > > example, wouldn't it? It could be done, but who ever dream of doing > > so? Who would create a file with a name like "should do such and > > such" as the name of their failures file? > I don't think anyone would create a file named "should this and that", but currently the --example option is used both for files and behaviour names. RSpec will read the file if it exists, otherwise it will assume it's a behaviour name. > > Do you think it would be acceptable to remove the appropriate example > when the File is empty? > When the file is empty, all specs will run. It will behave as if you didn't specify --example at all. But maybe I'm misunderstanding what you mean by remove. How would you like RSpec to figure out by itself that --example foo_bar refers to a file when foo_bar doesn't exist? Would it make sense to add logic so that it will only be assumed to be a file (existant or not) if it ends with .txt? Aslak > Scott > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed May 2 20:56:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 20:56:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10529 ] have_tag does not work while assert_select does Message-ID: <20070503005628.D699C5240B22@rubyforge.org> Bugs item #10529, was opened at 2007-05-02 16:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Roelofs (jameskilton) Assigned to: Nobody (None) Summary: have_tag does not work while assert_select does Initial Comment: I cannot get the development environment setup and thus I cannot run the attached patch against SVN trunk, so if this doesn't die for anyone then I'll check my environment, but this is the exact code that is causing problems in my rails app. Basically, I pass in the exact same options to have_tag as I do to assert_select. assert_select passes perfectly while have_tag fails. My environment: Ruby version 1.8.6 (i386-mswin32) RubyGems version 0.9.2 Rails version 1.2.0 Active Record version 1.14.4 Action Pack version 1.12.5 Action Web Service version 1.1.6 Action Mailer version 1.2.5 Active Support version 1.3.1 Edge Rails revision 6494 Application root C:/Development/AdminPortal Environment development Database adapter mysql ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 20:56 Message: I applied and committed the patch (r1892) with one minor modification: describe "have_tag", :behaviour_type => :controller do (This is needed in the plugin's specs because it cannot be inferred from its location) It passes fine for me for Railses (edge r, 1.1.6, 1.2.1, 1.2.2, 1.2.3) and Ruby 1.8.4 (about time I upgrade my Ruby, but I'm lazy) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 From noreply at rubyforge.org Wed May 2 21:16:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 21:16:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10529 ] have_tag does not work while assert_select does Message-ID: <20070503011609.86E215240B22@rubyforge.org> Bugs item #10529, was opened at 2007-05-02 20:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Roelofs (jameskilton) Assigned to: Nobody (None) Summary: have_tag does not work while assert_select does Initial Comment: I cannot get the development environment setup and thus I cannot run the attached patch against SVN trunk, so if this doesn't die for anyone then I'll check my environment, but this is the exact code that is causing problems in my rails app. Basically, I pass in the exact same options to have_tag as I do to assert_select. assert_select passes perfectly while have_tag fails. My environment: Ruby version 1.8.6 (i386-mswin32) RubyGems version 0.9.2 Rails version 1.2.0 Active Record version 1.14.4 Action Pack version 1.12.5 Action Web Service version 1.1.6 Action Mailer version 1.2.5 Active Support version 1.3.1 Edge Rails revision 6494 Application root C:/Development/AdminPortal Environment development Database adapter mysql ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 01:16 Message: Everything's passing against ruby 1.8.5 and 1.8.6 as well. Aslak and I are both running on Macs, so perhaps this is a win-ruby problem. Is there anybody else who is having this problem on windows? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-03 00:56 Message: I applied and committed the patch (r1892) with one minor modification: describe "have_tag", :behaviour_type => :controller do (This is needed in the plugin's specs because it cannot be inferred from its location) It passes fine for me for Railses (edge r, 1.1.6, 1.2.1, 1.2.2, 1.2.3) and Ruby 1.8.4 (about time I upgrade my Ruby, but I'm lazy) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 From noreply at rubyforge.org Wed May 2 22:30:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 22:30:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type constraint for mocks Message-ID: <20070503023026.DA2695240B63@rubyforge.org> Feature Requests item #10539, was opened at 2007-05-02 19:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add class_type constraint for mocks Initial Comment: I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type. Maybe we can add a class_type method to be used in addition to the duck_type method. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 From noreply at rubyforge.org Wed May 2 23:15:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 23:15:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to extract specify/it into includable module Message-ID: <20070503031546.500135240B6E@rubyforge.org> Feature Requests item #9472, was opened at 2007-03-22 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9472&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: Bob Cotton (bcotton) >Assigned to: David Chelimsky (dchelimsky) Summary: Provide way to extract specify/it into includable module Initial Comment: Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html provide the ability to extract specify/it into a module that may be included into a context/describe For example: describe AllEditions, :shared => true do it "should" do end end describe LargeEdition do include AllEditions it "should also" do end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 03:15 Message: This is fixed by [#9605] Patch for ER 9472, shared behaviour, which was committed to trunk in rev 1820 and released with RSpec-0.9.1. ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-04-06 18:31 Message: > Date: 2007-04-03 06:36 > Sender: David Chelimsky > So the concern that we've had about this sort of sharing is that > it wouldn't lead to cleaner specs, but would, in fact, end up > making things more complex. Let's take the stack example. > > describe "All Stacks", :shared => true do > it "should return the top item when you send it #top" > do > > OK - right away we've got a problem. Somehow, this example needs > to reference a Stack instance and say something about it: > > describe "All Stacks", :shared => true do > it "should return the top item when you send it #top" > do > @stack.top.should == ??????? Sharing of instance variables, especially instance variables that are the target of the spec was exactly what I need from spec sharing. > What's it going to equal? Where's it going to come from? Perhaps > this: > > describe "All Stacks", :shared => true do > it "should return the top item when you send it #top" > do > @stack.top.should == @last_added > end > end > > describe "An non-empty, non-full Stack" do > it_should_behave_as "All Stacks" > > def setup > @stack = Stack.new > @stack.push "1" > @stack.push @last_added = "2" > end > end > > Now this would pass, but there's this unfortunate binding between > the shared behavoiur and its user. As things grow more complex, > these will end up in different files (or one really big file) > and you'll have to go chasing around to understand what any one > thing is doing. I agree that the possibility for this complexity exists, but it's really no worse than included modules with helper methods that are referencing instance vars created in setup or ruby modules that depend on instance vars or methods present on the including class. > So then my question is what other use cases are there for :shared > => true? Most of our use for rspec is for acceptance/function testing. We have several editions of our product. We need a way to parameterize the creation of each edition, then run some specs over each of them. My first thought was to extend 'describe' to accept a list of modules, then create a new Behavior for each one: describe "All Editions", LargeEditionFactory, SmallEditionFactory do end This would create a Beahviour for each module, include the module on the Behavior, then add it to the list. All of the included modules would respond to the same methods, specifically a method to create the correct edition. Then you suggested shared behaviours. Which does the same thing, except the non-shared behavior would be responsible for the creation of the edition. But the shared behaviors would still have to have knowledge of the instance of the edition from the non-shared behaviour. That's our use case. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-03 12:36 Message: So the concern that we've had about this sort of sharing is that it wouldn't lead to cleaner specs, but would, in fact, end up making things more complex. Let's take the stack example. describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do OK - right away we've got a problem. Somehow, this example needs to reference a Stack instance and say something about it: describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do @stack.top.should == ??????? What's it going to equal? Where's it going to come from? Perhaps this: describe "All Stacks", :shared => true do it "should return the top item when you send it #top" do @stack.top.should == @last_added end end describe "An non-empty, non-full Stack" do it_should_behave_as "All Stacks" def setup @stack = Stack.new @stack.push "1" @stack.push @last_added = "2" end end Now this would pass, but there's this unfortunate binding between the shared behavoiur and its user. As things grow more complex, these will end up in different files (or one really big file) and you'll have to go chasing around to understand what any one thing is doing. Now there is a case in which I see a real use for this that would minimize this binding and provide some benefit - and that is defining a duck type - sort of like a java interface without the interface class. So you could do this: describe "Enumerable", :shared => true do it "should respond to #each" do enumerable.should respond_to(:each) end end describe "A Stack" do it_should_behave_as "Enumerable" def setup @stack = Stack.new end def enumerable @stack end end So now we've defined an interface from the examples instead of from a class from which Stack must derive. This is what duck typing is all about! But we still have an odd binding here - the "A Stack" behaviour has to implement #enumerable. That makes me uncomfortable. So I was batting this around w/ Dan North and he suggested something that would end up looking like this: act_as_enumerable = act_as %w { each } describe Stack do it "should act as enumerable" do Stack.new.should act_as_enumerable end end Actually - his suggestion was quack_like :) quack_like_enumerable = quack_like %w { each } describe Stack do it "should quack like enumerable" do Stack.new.should quack_like_enumerable end end One way or another, I think that we'll want to add something like that because it is a very simple way to solve the behaves_as problem. So then my question is what other use cases are there for :shared => true? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-27 01:24 Message: I need to think about how to word some things. Why don't you go ahead and give it your best shot and I'll tweak what I think needs tweaking. OK? Thanks Bob - a lot of people have been waiting for a feature like this. Cheers, David ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-27 01:01 Message: Thoughs on the wording for including shared behavior, before I write the doc and submit the patch? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-25 13:36 Message: Yes, I'll be doing the work on 0.9. No BDD pie necessary, not being that familar with the code base, just wanted to make sure I wasn't missing anything. Before I can define behavior, I want to make sure I've got all the right classes. Don't worry, there will be specs! Thanks for the followup ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-24 23:33 Message: Following up - I guess there's nothing wrong w/ talking about design a LITTLE first. How about a collection on Spec::Runner with methods to interact with it right on the module. Something like: Spec::Runner.add_shared_behaviour(behaviour) Spec::Runner.find_shared_behaviour(:name) This way you don't have to expose anything and those methods can handle the management of the collection. Thoughts? Feel free to throw a BDD pie in my face instead of answering. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-24 23:24 Message: Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do. As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-24 22:29 Message: I'm about to start implementing this. A couple of questions: 1. I suppose the only way to locate a shared 'describe' would be through its description 2. I'll need to add an attr_reader for :examples to Spec::DSL::Behavior::ModuleMethods so I can grab all shared Examples and add them to the current Behavior just before running. 3. I'll need to add either an attr_reader for :behaviors or a find method to Spec::Runner::BehaviorRunner so I can lookup behaviors by descritpion. Thoughts? ---------------------------------------------------------------------- Comment By: Bob Cotton (bcotton) Date: 2007-03-22 18:45 Message: Very nice. it_should_behave_as Brainstorming with a co-worker: behaving_as behaves_like sharing acts_like an_example_of shares_behavior_with shares_behavior_of same_as same_behavior_as just_like equivalent_to it_doppelgangers ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-22 16:23 Message: I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time. We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this: describe "AllEditions", :shared => true do it "should do something" do end end describe LargeEdition do it_should_behave_as "AllEditions" it "should also do something else" do end end That reads kinda nice, ay? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9472&group_id=797 From noreply at rubyforge.org Wed May 2 23:16:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 23:16:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type constraint for mocks Message-ID: <20070503031643.850215240B36@rubyforge.org> Feature Requests item #10539, was opened at 2007-05-03 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add class_type constraint for mocks Initial Comment: I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type. Maybe we can add a class_type method to be used in addition to the duck_type method. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 03:16 Message: Would this do what you are looking for? http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 From noreply at rubyforge.org Wed May 2 23:39:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 23:39:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8969 ] Evaluate "context_setup" blocks as soon as they are encountered (better compatibility with "dynamic" specs) Message-ID: <20070503033922.EC20F5240BC9@rubyforge.org> Feature Requests item #8969, was opened at 2007-03-01 11:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8969&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Lee Noori (leenoori) Assigned to: Nobody (None) >Summary: Evaluate "context_setup" blocks as soon as they are encountered (better compatibility with "dynamic" specs) Initial Comment: I'm posting this feature request as a follow-up to this mailing test post: http://rubyforge.org/pipermail/rspec-users/2007-February/000854.html The basic problem is that "context_setup" blocks may be run too late when setting up "dynamic" specs. The following example illustrates the problem if you have a "context_setup" block inside a context containing a dynamic specify block. Intuition might lead one to believe that it would be executed *before* the specs because it's labelled as a "setup" block and also because it appears physically before the "specify" block; however this is not the case: context "The month march" do context_setup do @start = 1 @max = 10 end (@start.. at max).each do |n| specify "The root of #{n} square should be #{n}" do Math.sqrt(n*n).should == n end end end Here the "context_setup" block hasn't actually been evaluated by the time Ruby sees (and starts executing) the (@start.. at max).each block, so it doesn't work as intended. The workaround is to forget using "context_setup" and do the setup in the same scope as the following "specify" block: context "The month march" do @start = 1 @max = 10 (@start.. at max).each do |n| specify "The root of #{n} square should be #{n}" do Math.sqrt(n*n).should == n end end end I suspect a robust fix would involve evaluating context_setup blocks as soon as they are encountered rather than deferring them until later. At a minimum, the definition of the context_setup method (in lib/spec/runner/context_eval.rb) would need to be changed. Looks like the rest of the work would probably have to take place in lib/spec/runner/context.rb. I am not yet very familiar with the RSpec codebase but if one of the devs can provide some guidance I can have a shot at whipping together a patch. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 03:39 Message: You can do what you are looking for like this: describe "The month march" do @start = 1 @max = 10 (@start.. at max).each do |n| specify "The root of #{n} square should be #{n}" do Math.sqrt(n*n).should == n end end end No need to set the vars within before(:all) (formerly context_setup). Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-01 13:26 Message: Hi Lee, Thanks for posting this here rather than just on the mailing list. I have some thoughts about why I'd prefer not to do this right now, but this is the right place for any debate and to ensure that if/when the time is right we have the history. In my view, what you're calling a workaround is actually the right way to go here. I see @start and @max as "spec generation" code, something akin to a pre-processor macro, which I would actually prefer to avoid mixing into the scope in which the spec gets executed. On the other hand, the context_setup is intended to set up state that is expensive to set up, and therefore better off set up only once. Things like loading large data sets or starting browsers, in the case of 'spec/ui'. To me, these are two separate concerns, which are causing confusion because they appear to be intermingled, but are never-the-less orthogonal. The other reason is a bit more pragmatic. There have been numerous requests over time for some means of nesting contexts and/or specifications. To that end, I am exploring some alternative approaches to the inner workings of the runner, so I am hesitant to impose any new requirements on the runner right now. Seeing as you are able to use the workaround, I'm going to defer this for now. But please feel free to keep the discussion going here while your thoughts are fresh. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8969&group_id=797 From noreply at rubyforge.org Wed May 2 23:51:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 May 2007 23:51:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type constraint for mocks Message-ID: <20070503035158.9FCF95240B84@rubyforge.org> Feature Requests item #10539, was opened at 2007-05-02 19:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add class_type constraint for mocks Initial Comment: I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type. Maybe we can add a class_type method to be used in addition to the duck_type method. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-02 20:51 Message: Sorry, here is an example. it "sets Expectations differ when differ_class is set" do @options.differ_class = Spec::Expectations::Differs::Default Spec::Expectations.should_receive(:differ=).with(:anything).and_return do |arg| arg.class.should == Spec::Expectations::Differs::Default end @options.create_behaviour_runner end It would be nice to say: Spec::Expectations.should_receive(:differ=).with(class_type(Spec::Expectations::Differs::Default)) Saying duck_type would be ambigious in this situation. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-02 20:16 Message: Would this do what you are looking for? http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 From noreply at rubyforge.org Thu May 3 00:04:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 00:04:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10542 ] reverse predicate matcher syntax Message-ID: <20070503040424.269D75240B84@rubyforge.org> Feature Requests item #10542, was opened at 2007-05-03 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10542&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: reverse predicate matcher syntax Initial Comment: The predicate_matcher feature released in 0.9.1 was implemented thusly: predicate_matchers[:method_on_object] = :method_in_example For example: predicate_matchers[:can_swim?] = :swim Fish.should swim A couple of people have noted that this seems backwards, or odd, so this request is to reverse the key/value: predicate_matchers[:swim] = :can_swim? Fish.should swim ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10542&group_id=797 From noreply at rubyforge.org Thu May 3 00:11:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 00:11:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10542 ] reverse predicate matcher syntax Message-ID: <20070503041100.3E6265240B84@rubyforge.org> Feature Requests item #10542, was opened at 2007-05-03 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10542&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: reverse predicate matcher syntax Initial Comment: The predicate_matcher feature released in 0.9.1 was implemented thusly: predicate_matchers[:method_on_object] = :method_in_example For example: predicate_matchers[:can_swim?] = :swim Fish.should swim A couple of people have noted that this seems backwards, or odd, so this request is to reverse the key/value: predicate_matchers[:swim] = :can_swim? Fish.should swim ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 04:11 Message: Fixed in trunk 1898 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10542&group_id=797 From dchelimsky at gmail.com Thu May 3 00:17:36 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 2 May 2007 23:17:36 -0500 Subject: [rspec-devel] predicate matchers Message-ID: <57c63afe0705022117n1e53f10cyd78695d89072733e@mail.gmail.com> Hey all, If any of you are using the new predicate_matchers feature, I just committed a change to it in trunk. See http://rubyforge.org/tracker/index.php?func=detail&aid=10542&group_id=797&atid=3152 for more details, but the high level is that instead of this: predicate_matchers[:method_on_object] = :method_in_spec It now (as of rev 1898 - soon to be released in 0.9.2) does this: predicate_matchers[:method_in_spec] = :method_on_object I (and I'm apparently not alone) think this reads better. Here's an example: predicate_matchers[:eat] = :eats? sheep.should eat('grass') # passes if sheep.eats?('grass') Apologies for those of you who jumped on this feature. Hopefully it hasn't proven itself that useful yet ;) Cheers, David From noreply at rubyforge.org Thu May 3 00:23:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 00:23:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type constraint for mocks Message-ID: <20070503042333.CFCA05240B84@rubyforge.org> Feature Requests item #10539, was opened at 2007-05-03 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add class_type constraint for mocks Initial Comment: I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type. Maybe we can add a class_type method to be used in addition to the duck_type method. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 04:23 Message: You can kinda fake this now - it's sneaky, but.... describe "sneaky use of predicate matchers as mock argument matcher" do predicate_matchers[:a] = :is_a? it "should make Brian happy" do m = mock("thing") m.should_receive(:message).with(a(String)) m.message("this is a string") end end WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-03 03:51 Message: Sorry, here is an example. it "sets Expectations differ when differ_class is set" do @options.differ_class = Spec::Expectations::Differs::Default Spec::Expectations.should_receive(:differ=).with(:anything).and_return do |arg| arg.class.should == Spec::Expectations::Differs::Default end @options.create_behaviour_runner end It would be nice to say: Spec::Expectations.should_receive(:differ=).with(class_type(Spec::Expectations::Differs::Default)) Saying duck_type would be ambigious in this situation. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 03:16 Message: Would this do what you are looking for? http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 From noreply at rubyforge.org Thu May 3 03:19:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 03:19:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070503071908.AFF2D5240B86@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Thu May 3 03:24:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 03:24:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10465 ] Pre_commit method comments Message-ID: <20070503072422.70CE45240BA6@rubyforge.org> Patches item #10465, was opened at 2007-04-30 12:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 Category: build Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit method comments Initial Comment: As the first step to refactor the pre_commit code I reviewed it and added comments to reveal its (perceived) intention and tricky places of implementation. I didn't make any changes to the code but I did write some FIXMEs to wherever I noticed dead code or bugs. I plan to remove most of the comments after the specs and the code itself reveal intention better. BTW. Should we have a build category or something similar in the RubyForge tracker? This doesn't fall under any of the existing categories. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-03 07:24 Message: Shouldn't we also have a documentation category? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 13:35 Message: Added build category and set this accordingly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 From aslak.hellesoy at gmail.com Thu May 3 04:11:28 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 3 May 2007 10:11:28 +0200 Subject: [rspec-devel] [ANN] RSpec 0.9.2 Message-ID: <8d961d900705030111q60a9f50cu4918f31502a45a54@mail.gmail.com> Behind every great release is a maintenance release. Go get it while it's hot. We've also reworked the website a little - trying to scare off fewer people. Aslak From noreply at rubyforge.org Thu May 3 07:19:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 07:19:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10465 ] Pre_commit method comments Message-ID: <20070503111954.DF86A5240A8C@rubyforge.org> Patches item #10465, was opened at 2007-04-30 12:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 Category: build Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit method comments Initial Comment: As the first step to refactor the pre_commit code I reviewed it and added comments to reveal its (perceived) intention and tricky places of implementation. I didn't make any changes to the code but I did write some FIXMEs to wherever I noticed dead code or bugs. I plan to remove most of the comments after the specs and the code itself reveal intention better. BTW. Should we have a build category or something similar in the RubyForge tracker? This doesn't fall under any of the existing categories. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 11:19 Message: I added a documentation category but failed to set it to public when I did and there is rubyforge bug that won't allow a private tracker to become public. I've got an open RFE w/ the rubyforge project on this. Though inline comments in the code that are in place as part of a refactoring should not go in a documentation tracker. That would be specifically for website and rdoc. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-03 07:24 Message: Shouldn't we also have a documentation category? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 13:35 Message: Added build category and set this accordingly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 From noreply at rubyforge.org Thu May 3 07:57:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 07:57:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10552 ] Doc bug with shared behaviors Message-ID: <20070503115710.8C7F75240A8C@rubyforge.org> Bugs item #10552, was opened at 2007-05-03 05:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10552&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bob Cotton (bcotton) Assigned to: Nobody (None) Summary: Doc bug with shared behaviors Initial Comment: The docs for shared behaviors reference the wrong method for including shared behaviors: behaves_as it should be it_should_behave_like Attached patch fixes it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10552&group_id=797 From noreply at rubyforge.org Thu May 3 08:06:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 08:06:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10552 ] Doc bug with shared behaviors Message-ID: <20070503120658.353B25240B23@rubyforge.org> Bugs item #10552, was opened at 2007-05-03 11:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10552&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Bob Cotton (bcotton) >Assigned to: David Chelimsky (dchelimsky) Summary: Doc bug with shared behaviors Initial Comment: The docs for shared behaviors reference the wrong method for including shared behaviors: behaves_as it should be it_should_behave_like Attached patch fixes it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 12:06 Message: Applied to trunk 1903. Also uploaded to http://rspec.rubyforge.org/documentation/index.html. Thanks Bob. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10552&group_id=797 From noreply at rubyforge.org Thu May 3 08:45:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 08:45:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10553 ] 'rake spec' task modifies spec files Message-ID: <20070503124557.700F15240B7F@rubyforge.org> Bugs item #10553, was opened at 2007-05-03 08:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: 'rake spec' task modifies spec files Initial Comment: Hello, It appears as though, when I run 'rake spec' on a rails project with specs, all of the spec files are modified. Though there is no content changed in these files, the modification date is changed. In itself this is but an annoyance, but when working with sufficiently sophisticated editing software, it detects that a file has been modified since being opened. Thus, I am getting error messages constantly. I assume that there is just a bit of code that now opens the files with write access, even though it is just reading them. I am on the HEAD of svn trunk, by the way. Thanks. -Chris ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 From noreply at rubyforge.org Thu May 3 09:00:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 09:00:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10553 ] 'rake spec' task modifies spec files Message-ID: <20070503130050.BD9CF5240AB4@rubyforge.org> Bugs item #10553, was opened at 2007-05-03 12:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: 'rake spec' task modifies spec files Initial Comment: Hello, It appears as though, when I run 'rake spec' on a rails project with specs, all of the spec files are modified. Though there is no content changed in these files, the modification date is changed. In itself this is but an annoyance, but when working with sufficiently sophisticated editing software, it detects that a file has been modified since being opened. Thus, I am getting error messages constantly. I assume that there is just a bit of code that now opens the files with write access, even though it is just reading them. I am on the HEAD of svn trunk, by the way. Thanks. -Chris ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 13:00 Message: What a puzzle. I've looked through the code (I'm at rev 1903) and I don't see where this could be happening. There are a number of File.opens that read, but the few that use 'w' actually need it to do their work, and they only operate on a few files (that are used by rspec - not files you write as an rspec user). I also looked for FileUtils.touch, of which there are a couple of cases in RSpec's own specs, but not in the code you are running. Other suggestions as to where to look? Also, I just opened up a spec file in vim, ran the specs with rcov enabled, edited the file and saved it w/ no trouble. So I can't reproduce this myself. Can you give us a step by step means to reproduce the bug? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 From noreply at rubyforge.org Thu May 3 09:02:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 09:02:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10553 ] 'rake spec' task modifies spec files Message-ID: <20070503130214.9D3B45240AB4@rubyforge.org> Bugs item #10553, was opened at 2007-05-03 12:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: 'rake spec' task modifies spec files Initial Comment: Hello, It appears as though, when I run 'rake spec' on a rails project with specs, all of the spec files are modified. Though there is no content changed in these files, the modification date is changed. In itself this is but an annoyance, but when working with sufficiently sophisticated editing software, it detects that a file has been modified since being opened. Thus, I am getting error messages constantly. I assume that there is just a bit of code that now opens the files with write access, even though it is just reading them. I am on the HEAD of svn trunk, by the way. Thanks. -Chris ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 13:02 Message: Also - the usual info (OS, ruby version, specific revision number of rspec as HEAD changes from minute to minute, rails/non-rails, rails version if rails, etc) would be helpful. Thanks ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 13:00 Message: What a puzzle. I've looked through the code (I'm at rev 1903) and I don't see where this could be happening. There are a number of File.opens that read, but the few that use 'w' actually need it to do their work, and they only operate on a few files (that are used by rspec - not files you write as an rspec user). I also looked for FileUtils.touch, of which there are a couple of cases in RSpec's own specs, but not in the code you are running. Other suggestions as to where to look? Also, I just opened up a spec file in vim, ran the specs with rcov enabled, edited the file and saved it w/ no trouble. So I can't reproduce this myself. Can you give us a step by step means to reproduce the bug? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 From t.lucas at toolmantim.com Thu May 3 08:40:28 2007 From: t.lucas at toolmantim.com (Tim Lucas) Date: Thu, 3 May 2007 22:40:28 +1000 Subject: [rspec-devel] [rspec-users] [ANN] RSpec 0.9.2 In-Reply-To: <8d961d900705030111q60a9f50cu4918f31502a45a54@mail.gmail.com> References: <8d961d900705030111q60a9f50cu4918f31502a45a54@mail.gmail.com> Message-ID: <3A02F965-59C6-4A53-98AA-2CD6D0655656@toolmantim.com> On 03/05/2007, at 6:11 PM, aslak hellesoy wrote: > We've also reworked the website a little - trying to scare off > fewer people. Great work on the website. Can I give a spec for a small suggestion: TheRSpecWebsite - should take into account most visitors will be rails developers - should take into account many visitors will be using textmate - should have install & getting started instructions on the homepage that take the above into account - should at least provide links to those instructions if the homepage becomes cluttered -- tim From noreply at rubyforge.org Thu May 3 09:48:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 09:48:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10553 ] 'rake spec' task modifies spec files Message-ID: <20070503134827.0E42B5240AE9@rubyforge.org> Bugs item #10553, was opened at 2007-05-03 08:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 Category: rails plugin Group: None Status: Open >Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: 'rake spec' task modifies spec files Initial Comment: Hello, It appears as though, when I run 'rake spec' on a rails project with specs, all of the spec files are modified. Though there is no content changed in these files, the modification date is changed. In itself this is but an annoyance, but when working with sufficiently sophisticated editing software, it detects that a file has been modified since being opened. Thus, I am getting error messages constantly. I assume that there is just a bit of code that now opens the files with write access, even though it is just reading them. I am on the HEAD of svn trunk, by the way. Thanks. -Chris ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-05-03 09:48 Message: Well, I just removed the HEAD externals and got the 0.9.2 release, and things seem to be working just as they should. I will remove this ticket since you guys can't reproduce the bug on HEAD. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 09:02 Message: Also - the usual info (OS, ruby version, specific revision number of rspec as HEAD changes from minute to minute, rails/non-rails, rails version if rails, etc) would be helpful. Thanks ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 09:00 Message: What a puzzle. I've looked through the code (I'm at rev 1903) and I don't see where this could be happening. There are a number of File.opens that read, but the few that use 'w' actually need it to do their work, and they only operate on a few files (that are used by rspec - not files you write as an rspec user). I also looked for FileUtils.touch, of which there are a couple of cases in RSpec's own specs, but not in the code you are running. Other suggestions as to where to look? Also, I just opened up a spec file in vim, ran the specs with rcov enabled, edited the file and saved it w/ no trouble. So I can't reproduce this myself. Can you give us a step by step means to reproduce the bug? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 From noreply at rubyforge.org Thu May 3 09:48:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 09:48:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10553 ] 'rake spec' task modifies spec files Message-ID: <20070503134843.DD2895240A8C@rubyforge.org> Bugs item #10553, was opened at 2007-05-03 08:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: 'rake spec' task modifies spec files Initial Comment: Hello, It appears as though, when I run 'rake spec' on a rails project with specs, all of the spec files are modified. Though there is no content changed in these files, the modification date is changed. In itself this is but an annoyance, but when working with sufficiently sophisticated editing software, it detects that a file has been modified since being opened. Thus, I am getting error messages constantly. I assume that there is just a bit of code that now opens the files with write access, even though it is just reading them. I am on the HEAD of svn trunk, by the way. Thanks. -Chris ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-05-03 09:48 Message: Well, I just removed the HEAD externals and got the 0.9.2 release, and things seem to be working just as they should. I will remove this ticket since you guys can't reproduce the bug on HEAD. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 09:02 Message: Also - the usual info (OS, ruby version, specific revision number of rspec as HEAD changes from minute to minute, rails/non-rails, rails version if rails, etc) would be helpful. Thanks ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 09:00 Message: What a puzzle. I've looked through the code (I'm at rev 1903) and I don't see where this could be happening. There are a number of File.opens that read, but the few that use 'w' actually need it to do their work, and they only operate on a few files (that are used by rspec - not files you write as an rspec user). I also looked for FileUtils.touch, of which there are a couple of cases in RSpec's own specs, but not in the code you are running. Other suggestions as to where to look? Also, I just opened up a spec file in vim, ran the specs with rcov enabled, edited the file and saved it w/ no trouble. So I can't reproduce this myself. Can you give us a step by step means to reproduce the bug? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10553&group_id=797 From noreply at rubyforge.org Thu May 3 09:57:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 09:57:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10529 ] have_tag does not work while assert_select does Message-ID: <20070503135701.3A2955240AE9@rubyforge.org> Bugs item #10529, was opened at 2007-05-02 20:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Roelofs (jameskilton) Assigned to: Nobody (None) Summary: have_tag does not work while assert_select does Initial Comment: I cannot get the development environment setup and thus I cannot run the attached patch against SVN trunk, so if this doesn't die for anyone then I'll check my environment, but this is the exact code that is causing problems in my rails app. Basically, I pass in the exact same options to have_tag as I do to assert_select. assert_select passes perfectly while have_tag fails. My environment: Ruby version 1.8.6 (i386-mswin32) RubyGems version 0.9.2 Rails version 1.2.0 Active Record version 1.14.4 Action Pack version 1.12.5 Action Web Service version 1.1.6 Action Mailer version 1.2.5 Active Support version 1.3.1 Edge Rails revision 6494 Application root C:/Development/AdminPortal Environment development Database adapter mysql ---------------------------------------------------------------------- >Comment By: Jason Roelofs (jameskilton) Date: 2007-05-03 13:57 Message: So it looks like this is in fact a windows problem. I just ran the tests in two different Rails environments (1.2.3 and Edge 6494) on Linux and they both pass. I'll start delving deeper into what could be the problem when I have time. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 01:16 Message: Everything's passing against ruby 1.8.5 and 1.8.6 as well. Aslak and I are both running on Macs, so perhaps this is a win-ruby problem. Is there anybody else who is having this problem on windows? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-03 00:56 Message: I applied and committed the patch (r1892) with one minor modification: describe "have_tag", :behaviour_type => :controller do (This is needed in the plugin's specs because it cannot be inferred from its location) It passes fine for me for Railses (edge r, 1.1.6, 1.2.1, 1.2.2, 1.2.3) and Ruby 1.8.4 (about time I upgrade my Ruby, but I'm lazy) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 From noreply at rubyforge.org Thu May 3 11:17:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 11:17:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10529 ] have_tag does not work while assert_select does Message-ID: <20070503151744.E08BA5240BB2@rubyforge.org> Bugs item #10529, was opened at 2007-05-02 16:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Roelofs (jameskilton) Assigned to: Nobody (None) Summary: have_tag does not work while assert_select does Initial Comment: I cannot get the development environment setup and thus I cannot run the attached patch against SVN trunk, so if this doesn't die for anyone then I'll check my environment, but this is the exact code that is causing problems in my rails app. Basically, I pass in the exact same options to have_tag as I do to assert_select. assert_select passes perfectly while have_tag fails. My environment: Ruby version 1.8.6 (i386-mswin32) RubyGems version 0.9.2 Rails version 1.2.0 Active Record version 1.14.4 Action Pack version 1.12.5 Action Web Service version 1.1.6 Action Mailer version 1.2.5 Active Support version 1.3.1 Edge Rails revision 6494 Application root C:/Development/AdminPortal Environment development Database adapter mysql ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-03 11:17 Message: Running the spec with --backtrace and posting the backtrace here might help ---------------------------------------------------------------------- Comment By: Jason Roelofs (jameskilton) Date: 2007-05-03 09:57 Message: So it looks like this is in fact a windows problem. I just ran the tests in two different Rails environments (1.2.3 and Edge 6494) on Linux and they both pass. I'll start delving deeper into what could be the problem when I have time. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-02 21:16 Message: Everything's passing against ruby 1.8.5 and 1.8.6 as well. Aslak and I are both running on Macs, so perhaps this is a win-ruby problem. Is there anybody else who is having this problem on windows? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 20:56 Message: I applied and committed the patch (r1892) with one minor modification: describe "have_tag", :behaviour_type => :controller do (This is needed in the plugin's specs because it cannot be inferred from its location) It passes fine for me for Railses (edge r, 1.1.6, 1.2.1, 1.2.2, 1.2.3) and Ruby 1.8.4 (about time I upgrade my Ruby, but I'm lazy) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 From noreply at rubyforge.org Thu May 3 14:57:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 14:57:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type constraint for mocks Message-ID: <20070503185724.9E5AD5240B94@rubyforge.org> Feature Requests item #10539, was opened at 2007-05-02 19:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add class_type constraint for mocks Initial Comment: I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type. Maybe we can add a class_type method to be used in addition to the duck_type method. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-03 11:57 Message: That works. So predicate_matchers is a spec/mock only thing right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-02 21:23 Message: You can kinda fake this now - it's sneaky, but.... describe "sneaky use of predicate matchers as mock argument matcher" do predicate_matchers[:a] = :is_a? it "should make Brian happy" do m = mock("thing") m.should_receive(:message).with(a(String)) m.message("this is a string") end end WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-02 20:51 Message: Sorry, here is an example. it "sets Expectations differ when differ_class is set" do @options.differ_class = Spec::Expectations::Differs::Default Spec::Expectations.should_receive(:differ=).with(:anything).and_return do |arg| arg.class.should == Spec::Expectations::Differs::Default end @options.create_behaviour_runner end It would be nice to say: Spec::Expectations.should_receive(:differ=).with(class_type(Spec::Expectations::Differs::Default)) Saying duck_type would be ambigious in this situation. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-02 20:16 Message: Would this do what you are looking for? http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 From noreply at rubyforge.org Thu May 3 15:00:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 15:00:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type constraint for mocks Message-ID: <20070503190046.DE4655240B94@rubyforge.org> Feature Requests item #10539, was opened at 2007-05-03 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add class_type constraint for mocks Initial Comment: I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type. Maybe we can add a class_type method to be used in addition to the duck_type method. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 19:00 Message: No. It's for matching expressions. The mock thing is the sneaky part :) It's intent is more for expectations like: File.should exist(path) ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-03 18:57 Message: That works. So predicate_matchers is a spec/mock only thing right? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 04:23 Message: You can kinda fake this now - it's sneaky, but.... describe "sneaky use of predicate matchers as mock argument matcher" do predicate_matchers[:a] = :is_a? it "should make Brian happy" do m = mock("thing") m.should_receive(:message).with(a(String)) m.message("this is a string") end end WDYT? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-03 03:51 Message: Sorry, here is an example. it "sets Expectations differ when differ_class is set" do @options.differ_class = Spec::Expectations::Differs::Default Spec::Expectations.should_receive(:differ=).with(:anything).and_return do |arg| arg.class.should == Spec::Expectations::Differs::Default end @options.create_behaviour_runner end It would be nice to say: Spec::Expectations.should_receive(:differ=).with(class_type(Spec::Expectations::Differs::Default)) Saying duck_type would be ambigious in this situation. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 03:16 Message: Would this do what you are looking for? http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797 From brian.takita at gmail.com Thu May 3 15:43:36 2007 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 3 May 2007 12:43:36 -0700 Subject: [rspec-devel] [ANN] RSpec 0.9.2 In-Reply-To: <8d961d900705030111q60a9f50cu4918f31502a45a54@mail.gmail.com> References: <8d961d900705030111q60a9f50cu4918f31502a45a54@mail.gmail.com> Message-ID: <1d7ddd110705031243r763c6d6dnb014b40a8e75ddcb@mail.gmail.com> Mmmm. Breadcrumbs! On 5/3/07, aslak hellesoy wrote: > > Behind every great release is a maintenance release. > Go get it while it's hot. > > We've also reworked the website a little - trying to scare off fewer > people. > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070503/0499cf43/attachment.html From noreply at rubyforge.org Thu May 3 18:44:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 18:44:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10566 ] prepend_before and prepend_after callbacks Message-ID: <20070503224458.5089B5240B5F@rubyforge.org> Feature Requests item #10566, was opened at 2007-05-03 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: prepend_before and prepend_after callbacks Initial Comment: Currently before and after callbacks append to the collection. These methods will allow one to prepend to the callback collection. I remember it being mentioned by David, Aslak, and Dave but I didn't see a feature request. Delete this if it is a dupe. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 From noreply at rubyforge.org Thu May 3 19:13:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 19:13:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10566 ] prepend_before and prepend_after callbacks Message-ID: <20070503231319.2FD3F5240B68@rubyforge.org> Feature Requests item #10566, was opened at 2007-05-03 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: prepend_before and prepend_after callbacks Initial Comment: Currently before and after callbacks append to the collection. These methods will allow one to prepend to the callback collection. I remember it being mentioned by David, Aslak, and Dave but I didn't see a feature request. Delete this if it is a dupe. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 From noreply at rubyforge.org Thu May 3 19:21:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 19:21:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10566 ] prepend_before and prepend_after callbacks Message-ID: <20070503232123.B5E035240B9B@rubyforge.org> Feature Requests item #10566, was opened at 2007-05-03 22:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 Category: None Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: prepend_before and prepend_after callbacks Initial Comment: Currently before and after callbacks append to the collection. These methods will allow one to prepend to the callback collection. I remember it being mentioned by David, Aslak, and Dave but I didn't see a feature request. Delete this if it is a dupe. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 23:21 Message: Why did you close this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 From noreply at rubyforge.org Thu May 3 19:50:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 19:50:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10566 ] prepend_before and prepend_after callbacks Message-ID: <20070503235036.9CEA65240BC8@rubyforge.org> Feature Requests item #10566, was opened at 2007-05-03 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 Category: None Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: prepend_before and prepend_after callbacks Initial Comment: Currently before and after callbacks append to the collection. These methods will allow one to prepend to the callback collection. I remember it being mentioned by David, Aslak, and Dave but I didn't see a feature request. Delete this if it is a dupe. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-03 16:50 Message: I already committed the changes. Should we reopen it? One thing that has not been done is to put the superclass setup and teardown methods into a callback. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 16:21 Message: Why did you close this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 From noreply at rubyforge.org Thu May 3 20:09:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 20:09:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10566 ] prepend_before and prepend_after callbacks Message-ID: <20070504000941.3DCBB5240BC8@rubyforge.org> Feature Requests item #10566, was opened at 2007-05-03 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 Category: None Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: prepend_before and prepend_after callbacks Initial Comment: Currently before and after callbacks append to the collection. These methods will allow one to prepend to the callback collection. I remember it being mentioned by David, Aslak, and Dave but I didn't see a feature request. Delete this if it is a dupe. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-03 17:09 Message: Checked in Rev 1905 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-03 16:50 Message: I already committed the changes. Should we reopen it? One thing that has not been done is to put the superclass setup and teardown methods into a callback. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 16:21 Message: Why did you close this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10566&group_id=797 From noreply at rubyforge.org Thu May 3 20:11:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 20:11:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10567 ] Call setup and teardown using before and after callbacks Message-ID: <20070504001135.36F195240BD5@rubyforge.org> Feature Requests item #10567, was opened at 2007-05-03 17:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10567&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Call setup and teardown using before and after callbacks Initial Comment: Remove superclass setup and superclass teardown. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10567&group_id=797 From michael.s.klishin at gmail.com Thu May 3 23:47:37 2007 From: michael.s.klishin at gmail.com (Michael Klishin) Date: Fri, 4 May 2007 07:47:37 +0400 Subject: [rspec-devel] EvalModule meaning and naming concerns Message-ID: <709de1d10705032047i74e007d7xf0e643e60b528d91@mail.gmail.com> Hi, I''m digging through RSpec source code and stumbled upon EvalModule class in Spec::DSL::Behaviour module. First question is what is semantics of this class? I see the way it is used in Behaviour module but doubt I get it right. Second question is why it is called module? We know that Ruby modules cannot be instantiated so it is a bit confusing. Maybe EvalContext is a better fit? Thanks in advance. MK. -- This was freedom. Losing all hope was freedom. Chasing the beauty in programming: www.ruby-lang.org | www.rubyonrails.org From michael.s.klishin at gmail.com Thu May 3 23:49:01 2007 From: michael.s.klishin at gmail.com (Michael Klishin) Date: Fri, 4 May 2007 07:49:01 +0400 Subject: [rspec-devel] EvalModule meaning and naming concerns In-Reply-To: <709de1d10705032047i74e007d7xf0e643e60b528d91@mail.gmail.com> References: <709de1d10705032047i74e007d7xf0e643e60b528d91@mail.gmail.com> Message-ID: <709de1d10705032049lfa68384ib767c3e622594b41@mail.gmail.com> Oops, it is Spec::DSL module you can find this class in, not Spec::DSL::Behaviour :) On 04/05/07, Michael Klishin wrote: > Hi, > > I''m digging through RSpec source code and stumbled upon EvalModule > class in Spec::DSL::Behaviour module. -- This was freedom. Losing all hope was freedom. Chasing the beauty in programming: www.ruby-lang.org | www.rubyonrails.org From noreply at rubyforge.org Fri May 4 01:25:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 01:25:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10567 ] Call setup and teardown using before and after callbacks Message-ID: <20070504052551.AE1975240C07@rubyforge.org> Feature Requests item #10567, was opened at 2007-05-03 17:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10567&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Call setup and teardown using before and after callbacks Initial Comment: Remove superclass setup and superclass teardown. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-03 22:25 Message: Applied with rev 1908. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10567&group_id=797 From noreply at rubyforge.org Fri May 4 02:36:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 02:36:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20070504063609.BAA405240BF8@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-29 22:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 20:58 Message: handle_underscores_for_rspec! doesn't reinstate the should methods - it reinstates the underscore sugar that gets invoked on method_missing. Right now, that is only still in existence to support should_be_predicate, but that is on its way out soon. I added the following to puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect ActiveRecord::Associations::HasManyAssociation.send :include, Spec::Mocks::MockMethods puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect Here's what it output: [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] Note that Spec::Mock::MockMethods appears before and after. So there's something happening at runtime. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-30 20:28 Message: "add_underscores_for_rspec!" gets called on the association base class after that code is parsed, though, and overrides it. That shouldn't be the problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 19:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 16:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 From noreply at rubyforge.org Fri May 4 07:56:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 07:56:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10567 ] Call setup and teardown using before and after callbacks Message-ID: <20070504115605.E0A5B5240A79@rubyforge.org> Feature Requests item #10567, was opened at 2007-05-04 00:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10567&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Call setup and teardown using before and after callbacks Initial Comment: Remove superclass setup and superclass teardown. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-04 11:56 Message: NICE WORK! ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-04 05:25 Message: Applied with rev 1908. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10567&group_id=797 From noreply at rubyforge.org Fri May 4 07:57:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 07:57:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20070504115747.8D2675240A79@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-30 05:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-04 11:57 Message: Please do NOT close tickets without an explanation. Who closed this and why? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 03:58 Message: handle_underscores_for_rspec! doesn't reinstate the should methods - it reinstates the underscore sugar that gets invoked on method_missing. Right now, that is only still in existence to support should_be_predicate, but that is on its way out soon. I added the following to puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect ActiveRecord::Associations::HasManyAssociation.send :include, Spec::Mocks::MockMethods puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect Here's what it output: [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] Note that Spec::Mock::MockMethods appears before and after. So there's something happening at runtime. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-12-01 03:28 Message: "add_underscores_for_rspec!" gets called on the association base class after that code is parsed, though, and overrides it. That shouldn't be the problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 02:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 23:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 From noreply at rubyforge.org Fri May 4 08:08:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 08:08:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20070504120831.E24F55240B67@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-29 22:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2007-05-04 06:08 Message: Sorry, I closed it, because it's old and invalid (imo) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-04 05:57 Message: Please do NOT close tickets without an explanation. Who closed this and why? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 20:58 Message: handle_underscores_for_rspec! doesn't reinstate the should methods - it reinstates the underscore sugar that gets invoked on method_missing. Right now, that is only still in existence to support should_be_predicate, but that is on its way out soon. I added the following to puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect ActiveRecord::Associations::HasManyAssociation.send :include, Spec::Mocks::MockMethods puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect Here's what it output: [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] Note that Spec::Mock::MockMethods appears before and after. So there's something happening at runtime. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-30 20:28 Message: "add_underscores_for_rspec!" gets called on the association base class after that code is parsed, though, and overrides it. That shouldn't be the problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 19:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 16:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 From noreply at rubyforge.org Fri May 4 08:23:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 08:23:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20070504122332.03D105240AA3@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-30 05:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 Category: rails plugin Group: None Status: Closed Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-04 12:23 Message: Thanks! ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2007-05-04 12:08 Message: Sorry, I closed it, because it's old and invalid (imo) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-04 11:57 Message: Please do NOT close tickets without an explanation. Who closed this and why? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 03:58 Message: handle_underscores_for_rspec! doesn't reinstate the should methods - it reinstates the underscore sugar that gets invoked on method_missing. Right now, that is only still in existence to support should_be_predicate, but that is on its way out soon. I added the following to puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect ActiveRecord::Associations::HasManyAssociation.send :include, Spec::Mocks::MockMethods puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect Here's what it output: [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] Note that Spec::Mock::MockMethods appears before and after. So there's something happening at runtime. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-12-01 03:28 Message: "add_underscores_for_rspec!" gets called on the association base class after that code is parsed, though, and overrides it. That shouldn't be the problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 02:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 23:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 From dchelimsky at gmail.com Fri May 4 08:47:15 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 4 May 2007 07:47:15 -0500 Subject: [rspec-devel] EvalModule meaning and naming concerns In-Reply-To: <709de1d10705032047i74e007d7xf0e643e60b528d91@mail.gmail.com> References: <709de1d10705032047i74e007d7xf0e643e60b528d91@mail.gmail.com> Message-ID: <57c63afe0705040547x76bf9e96xad3715759e665daa@mail.gmail.com> On 5/3/07, Michael Klishin wrote: > Hi, > > I''m digging through RSpec source code and stumbled upon EvalModule > class in Spec::DSL::Behaviour module. > > First question is what is semantics of this class? I see the way it is > used in Behaviour module but doubt I get it right. FWIW, this is the most confusing part of RSpec's internals for me too. The examples each get run in a separate instance of some class. By default, this is an instance of Object, but you can use the #inherit method to make it an instance of any other class you like. That's what allows us to get all the rails fixture set up, etc, for free. Whatever type it is, EvalModule gets mixed in to that instance. > > Second question is why it is called module? We know that Ruby modules > cannot be instantiated so it is a bit confusing. EvalModule extends Module. For Module, Ruby gives us a nice keyword: module SomeModule def some_method; end end class SomeClass include SomeModule end Alternatively, you could say: class SomeClass end mod = Module.new do def some_method; end end SomeClass.send :include, mod The result is the same. Since we want to use a subclass of Module and not Module itself, we use the latter form (as Ruby does not provide us with an evalModule keyword - although we could write one!) > Maybe EvalContext is > a better fit? We used to call Behaviours Contexts, so EvalContext had a conflicting meaning with that. I guess we could change it now, but I'm not certain that it would make things more clear. Cheers, David > > Thanks in advance. MK. > -- > This was freedom. Losing all hope was freedom. > > Chasing the beauty in programming: > www.ruby-lang.org | www.rubyonrails.org > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Fri May 4 11:25:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 11:25:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070504152506.639C15240C3B@rubyforge.org> Patches item #10574, was opened at 2007-05-04 18:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From noreply at rubyforge.org Fri May 4 11:27:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 11:27:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070504152730.02F825240BF8@rubyforge.org> Patches item #10574, was opened at 2007-05-04 18:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From noreply at rubyforge.org Fri May 4 11:37:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 11:37:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070504153731.C6B755240BCB@rubyforge.org> Patches item #10574, was opened at 2007-05-04 11:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 11:37 Message: Just a quick heads up before I look at this. I just removed the call to config.breakpoint_server, so that shouldn't be an issue any more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From john.x.andrews at jpmchase.com Fri May 4 10:52:07 2007 From: john.x.andrews at jpmchase.com (john.x.andrews at jpmchase.com) Date: Fri, 4 May 2007 10:52:07 -0400 Subject: [rspec-devel] rspec 0.9.2 broken for Rails users with Oracle. Message-ID: I forgot to mention that this change is in the kernel.rb file: rspec-0.9.2/lib/spec/runner/extensions/kernel.rb 2) change from: def describe(*args, &block) raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) end to: def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else super *args end end ----------------------------------------- This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070504/667bd289/attachment-0001.html From john.x.andrews at jpmchase.com Fri May 4 10:27:35 2007 From: john.x.andrews at jpmchase.com (john.x.andrews at jpmchase.com) Date: Fri, 4 May 2007 10:27:35 -0400 Subject: [rspec-devel] rspec 0.9.2 broken for Rails users with Oracle. Message-ID: Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord breaks due to the following: oracle_adapter.rb:316 (owner, table_name) = @connection.describe(table_name) @connection is an instance of OCI8AutoRecover which itself delegates the describe method to OCI8. class OCI8AutoRecover < DelegateClass(OCI8) #... # no def describe method here end DelegateClass internally uses method_missing to call the delegate class' describe class OCI8 #:nodoc: def describe(name) #... end #... end The problem is that rspec defines Kernel#describe, so method_missing never catches the call to delegate and it fails from rspec because there is obviously no block given. My work around modifies 2 files. I'm sorry, I don't have diffs from the trunk, but I can get them if you need them. (the firewall at work blocks svn traffic!) The following diffs are from 1) my svn repos, and 2) 0.9.2 rspec gem. 1) Index: vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb =================================================================== --- vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb (revision 1506) +++ vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb (working copy) @@ -1,8 +1,10 @@ module Kernel alias_method :original_describe, :describe def describe(*args, &block) - args << {} unless Hash === args.last - args.last[:spec_path] = caller(0)[1] + if block_given? + args << {} unless Hash === args.last + args.last[:spec_path] = caller(0)[1] + end original_describe(*args, &block) end end 2) (sorry again, not a real diff) change from: def describe(*args, &block) raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) end to: def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else super *args end end I don't know that this is necessarily the best way to fix the problem. I only know that my specs pass now. Please let me know if you see a better way to fix the issue. I am able to test against a fairly extensive set of specs on Oracle. Regards, John Andrews ----------------------------------------- This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070504/de984f99/attachment-0001.html From noreply at rubyforge.org Fri May 4 11:57:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 11:57:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10577 ] Rails with Oracle breaks 0.9.2 Message-ID: <20070504155740.287F45240C22@rubyforge.org> Bugs item #10577, was opened at 2007-05-04 11:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: John Andrews (jandrews) Assigned to: Nobody (None) Summary: Rails with Oracle breaks 0.9.2 Initial Comment: Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord breaks due to the following: oracle_adapter.rb:316 (owner, table_name) = @connection.describe(table_name) @connection is an instance of OCI8AutoRecover which itself delegates the describe method to OCI8. class OCI8AutoRecover < DelegateClass(OCI8) #... # no def describe method end DelegateClass internally uses method_missing to call the delegate class' describe class OCI8 #:nodoc: def describe(name) #... end #... end The problem is that rspec defines Kernel#describe, so method_missing never catches the call to delegate and it fails from rspec because there is obviously no block given. My work-around modifies 2 files. I will just include the methods I changed because I don't have diffs from trunk. from file: rspec_on_rails/lib/spec/rails/extensions/kernel.rb def describe(*args, &block) # assuming that if a block is not given that it is not a call # for rspec if block_given? args << {} unless Hash === args.last args.last[:spec_path] = caller(0)[1] end original_describe(*args, &block) end from file: rspec-0.9.2/lib/spec/runner/extensions/kernel.rb def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else # not the describe that we are looking for # it's probably a call from the oracle adapter super *args end end I don't know if this is the best way to fix the issue, but it works for me and all my specs pass again. if you need more info or someone to test a fix for Oracle I am able to help. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 From aslak.hellesoy at gmail.com Fri May 4 12:07:00 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 4 May 2007 18:07:00 +0200 Subject: [rspec-devel] rspec 0.9.2 broken for Rails users with Oracle. In-Reply-To: References: Message-ID: <8d961d900705040907w41615216sdf78b2fa2fd20982@mail.gmail.com> I suppose we can apply that patch, but out of curiosity, why do you specify the spec *inside* the class? RSpec has a better way to do it: describe MyClass do end or even: describe MyClass, " under some specific circumstances" do # no space needed in the string if you're on trunk end Aslak On 5/4/07, john.x.andrews at jpmchase.com wrote: > > Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord > breaks due to the following: > > oracle_adapter.rb:316 > (owner, table_name) = @connection.describe(table_name) > > @connection is an instance of OCI8AutoRecover which itself delegates the > describe method to OCI8. > > class OCI8AutoRecover < DelegateClass(OCI8) > #... > # no def describe method here > end > > DelegateClass internally uses method_missing to call the delegate class' > describe > > class OCI8 #:nodoc: > def describe(name) > #... > end > #... > end > > The problem is that rspec defines Kernel#describe, so method_missing never > catches the call to delegate and it fails from rspec because there is > obviously no block given. > > My work around modifies 2 files. I'm sorry, I don't have diffs from the > trunk, but I can get them if you need them. (the firewall at work blocks svn > traffic!) The following diffs are from 1) my svn repos, and 2) 0.9.2 rspec > gem. > 1) > Index: > vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb > =================================================================== > --- > vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb > (revision 1506) > +++ > vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb > (working copy) > @@ -1,8 +1,10 @@ > module Kernel > alias_method :original_describe, :describe > def describe(*args, &block) > - args << {} unless Hash === args.last > - args.last[:spec_path] = caller(0)[1] > + if block_given? > + args << {} unless Hash === args.last > + args.last[:spec_path] = caller(0)[1] > + end > original_describe(*args, &block) > end > end > > 2) (sorry again, not a real diff) > change from: > def describe(*args, &block) > raise ArgumentError if args.empty? > register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) > end > to: > def describe(*args, &block) > if block_given? > raise ArgumentError if args.empty? > register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) > else > super *args > end > end > > I don't know that this is necessarily the best way to fix the problem. I > only know that my specs pass now. Please let me know if you see a better way > to fix the issue. I am able to test against a fairly extensive set of specs > on Oracle. > > Regards, > John Andrews > > > > ________________________________ > > > > > This communication is for informational purposes only. It is not intended > as an offer or solicitation for the purchase or sale of any financial > instrument or as an official confirmation of any transaction. All market > prices, data and other information are not warranted as to completeness or > accuracy and are subject to change without notice. Any comments or > statements made herein do not necessarily reflect those of JPMorgan Chase & > Co., its subsidiaries and affiliates. This transmission may contain > information that is privileged, confidential, legally privileged, and/or > exempt from disclosure under applicable law. If you are not the intended > recipient, you are hereby notified that any disclosure, copying, > distribution, or use of the information contained herein (including any > reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any > attachments are believed to be free of any virus or other defect that might > affect any computer system into which it is received and opened, it is the > responsibility of the recipient to ensure that it is virus free and no > responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and > affiliates, as applicable, for any loss or damage arising in any way from > its use. If you received this transmission in error, please immediately > contact the sender and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. Please refer to > http://www.jpmorgan.com/pages/disclosures for disclosures > relating to UK legal entities. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Fri May 4 12:08:10 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 4 May 2007 18:08:10 +0200 Subject: [rspec-devel] rspec 0.9.2 broken for Rails users with Oracle. In-Reply-To: References: Message-ID: <8d961d900705040908tebeee87kda282bfa99b982ec@mail.gmail.com> On 5/4/07, john.x.andrews at jpmchase.com wrote: > > Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord > breaks due to the following: > > oracle_adapter.rb:316 > (owner, table_name) = @connection.describe(table_name) > > @connection is an instance of OCI8AutoRecover which itself delegates the > describe method to OCI8. > > class OCI8AutoRecover < DelegateClass(OCI8) > #... > # no def describe method here > end > > DelegateClass internally uses method_missing to call the delegate class' > describe > > class OCI8 #:nodoc: > def describe(name) > #... > end > #... > end > > The problem is that rspec defines Kernel#describe, so method_missing never > catches the call to delegate and it fails from rspec because there is > obviously no block given. > > My work around modifies 2 files. I'm sorry, I don't have diffs from the > trunk, but I can get them if you need them. (the firewall at work blocks svn > traffic!) The following diffs are from 1) my svn repos, and 2) 0.9.2 rspec > gem. > 1) > Index: > vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb > =================================================================== > --- > vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb > (revision 1506) > +++ > vendor/plugins/rspec_on_rails/lib/spec/rails/extensions/kernel.rb > (working copy) > @@ -1,8 +1,10 @@ > module Kernel > alias_method :original_describe, :describe > def describe(*args, &block) > - args << {} unless Hash === args.last > - args.last[:spec_path] = caller(0)[1] > + if block_given? > + args << {} unless Hash === args.last > + args.last[:spec_path] = caller(0)[1] > + end > original_describe(*args, &block) > end > end > > 2) (sorry again, not a real diff) > change from: > def describe(*args, &block) > raise ArgumentError if args.empty? > register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) > end > to: > def describe(*args, &block) > if block_given? > raise ArgumentError if args.empty? > register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) > else > super *args > end > end > > I don't know that this is necessarily the best way to fix the problem. I > only know that my specs pass now. Please let me know if you see a better way > to fix the issue. I am able to test against a fairly extensive set of specs > on Oracle. > Could you please create an issue for this at RubyForge? It helps us not forget... Aslak > Regards, > John Andrews > > > > ________________________________ > > > > > This communication is for informational purposes only. It is not intended > as an offer or solicitation for the purchase or sale of any financial > instrument or as an official confirmation of any transaction. All market > prices, data and other information are not warranted as to completeness or > accuracy and are subject to change without notice. Any comments or > statements made herein do not necessarily reflect those of JPMorgan Chase & > Co., its subsidiaries and affiliates. This transmission may contain > information that is privileged, confidential, legally privileged, and/or > exempt from disclosure under applicable law. If you are not the intended > recipient, you are hereby notified that any disclosure, copying, > distribution, or use of the information contained herein (including any > reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any > attachments are believed to be free of any virus or other defect that might > affect any computer system into which it is received and opened, it is the > responsibility of the recipient to ensure that it is virus free and no > responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and > affiliates, as applicable, for any loss or damage arising in any way from > its use. If you received this transmission in error, please immediately > contact the sender and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. Please refer to > http://www.jpmorgan.com/pages/disclosures for disclosures > relating to UK legal entities. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Fri May 4 19:34:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 19:34:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070504233450.E5E925240AAE@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Nobody (None) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Fri May 4 19:45:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 19:45:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070504234559.12D045240AE2@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 19:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Fri May 4 20:40:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 20:40:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070505004018.75C425240AE2@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 19:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 20:40 Message: This is a little trickier to solve than I had first thought. Just so I understand you correctly: You want the automatic description to be set even when your matcher's #matches? method raises an exception? Such behaviour is actually in violation of the general contract for matchers (which I admit is not clearly documented). #matches? is not allowed to raise exceptions - it must always return true or false. In addition to this it is recommended that #matches? creates an instance reference to the +actual+ argument so that it can be used later in the #description method (if appliccable). This is what happens in most of RSpec's built-in matchers. RSpec can only assume that if #matches? raised an exception, then calling #description would most likely return gibberish (we must assume that @actual was never set), and it doesn't even try to call it. This happens in handler.rb. This is why you don't get a generated description for your examples without names. The solution should be simple - just add a rescue in your #matches? method and have it return false when something goes wrong. Maybe David has something to add. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Fri May 4 22:37:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 May 2007 22:37:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070505023745.375765240AE4@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2007-05-04 23:37 Message: Thank you Aslak for the explanation. Actually I'm not trying to raise an exception from my matcher, but trying to track errors on them during creation. A lot of things about matchers are missing in docs, but tried to mimic existing ones (and the examples too). Anyway, the case I'm dealing with is this: I'm trying to validate attributes and the "validations" (validates_presence_of, validates_uniqueness_of, etc.) Also associations through these matchers. module ModelSpecHelper class Present def initialize(attr) @attr = attr end def matches?(model) @model = model model.send("#{@attr.to_s}=".to_sym, nil) model.valid? return !model.errors.on("#{@attr.to_s}".to_sym).nil? end def failure_message; "expected #{@model.inspect} to have present #{@attr.inspect}"; end def description; "not be valid without #{@attr}"; end end # Here start the accessor for examples: # it { model.should have_present(:attr) } => should not be valid without :attr def have_present(attr) Present.new(attr) end end describe "An Asset" do before(:each) do @asset = Asset.new end [:title, :content_type, :basename].each do |attr| it { @asset.should have_present(attr) } end it { @asset.should have_one(:attachment) } it { @asset.should have_present(:something) } end has_one :attachment nor something attribute are present in the model. in the has_one association, the displayed message is this: 'An Asset should has_one attachment' FAILED expected Asset to has_one :attachment But, in the have_present(:something): NoMethodError in 'An Asset NAME NOT GENERATED' undefined method `pepe=' for # ./spec/my_helpers.rb:9:in `send' ./spec/my_helpers.rb:9:in `matches?' ./spec/models/asset_spec.rb:20: Is easy to track down the error, but is not visually appealing if I made a typo or something. If i put everything into a begin ... rescue could workaround this, now I know. Wanted to know if I'm doing something wrong (like breaking rspec, I'm used to crash things) ;-) made some corrections: def matches?(model) @model = model if model.respond_to?("#{@attr.to_s}=".to_sym) model.send("#{@attr.to_s}=".to_sym, nil) model.valid? !model.errors.on("#{@attr.to_s}".to_sym).nil? end end and that avoids the exception. Thanks again for your time Luis ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 21:40 Message: This is a little trickier to solve than I had first thought. Just so I understand you correctly: You want the automatic description to be set even when your matcher's #matches? method raises an exception? Such behaviour is actually in violation of the general contract for matchers (which I admit is not clearly documented). #matches? is not allowed to raise exceptions - it must always return true or false. In addition to this it is recommended that #matches? creates an instance reference to the +actual+ argument so that it can be used later in the #description method (if appliccable). This is what happens in most of RSpec's built-in matchers. RSpec can only assume that if #matches? raised an exception, then calling #description would most likely return gibberish (we must assume that @actual was never set), and it doesn't even try to call it. This happens in handler.rb. This is why you don't get a generated description for your examples without names. The solution should be simple - just add a rescue in your #matches? method and have it return false when something goes wrong. Maybe David has something to add. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From dchelimsky at gmail.com Fri May 4 23:25:12 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 4 May 2007 22:25:12 -0500 Subject: [rspec-devel] have_one and have_present Message-ID: <57c63afe0705042025x7ba302d0icb6243730e3c7732@mail.gmail.com> >Comment By: Luis Lavena (luislavena) > Date: 2007-05-04 23:37 > describe "An Asset" do > before(:each) do > @asset = Asset.new > end > > it { @asset.should have_one(:attachment) } > it { @asset.should have_present(:something) } > end Food for thought on these. I like have_one a lot. It speaks to me as a Rails developer and I think it speaks to a customer as well. On the flip side, 'have_present' doesn't really tell me what is interesting about having it present, or why it should be present. I think 'require_attribute' would be nice ('require' would be even better, but obviously that is a keyword). Or 'validate_presence_of': an { @asset.should validate_presence_of(:something) } That's a little more Rails-developer-friendly than customer-friendly, but it still 'speaks' better than 'have_present' for me. FYI - Jay Fields has a Validatable framework that includes some test/unit assertions that look like this: Foo.must_validate do presence_of :name format_of(:name).with(/^[A-Z]/) numericality_of(:age).only_integer(true) end Because Spec::Rails behaviours inherit from Test::Unit::TestCase, you can install the validations gem (gem install validatable) and use these as/is with RSpec. Or, if you want it to feel more spec'ish, you could monkey patch an alias: Foo.should_validate do presence_of :name format_of(:name).with(/^[A-Z]/) numericality_of(:age).only_integer(true) end Whether you choose to use his framework or write your own, I think there is something to be learned from its expressiveness. Cheers, David From dchelimsky at gmail.com Fri May 4 23:29:57 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 4 May 2007 22:29:57 -0500 Subject: [rspec-devel] have_one and have_present In-Reply-To: <57c63afe0705042025x7ba302d0icb6243730e3c7732@mail.gmail.com> References: <57c63afe0705042025x7ba302d0icb6243730e3c7732@mail.gmail.com> Message-ID: <57c63afe0705042029l59a825c4u8de36e87f2d3c84e@mail.gmail.com> On 5/4/07, David Chelimsky wrote: > >Comment By: Luis Lavena (luislavena) > > Date: 2007-05-04 23:37 > > > describe "An Asset" do > > before(:each) do > > @asset = Asset.new > > end > > > > it { @asset.should have_one(:attachment) } > > it { @asset.should have_present(:something) } > > end > > Food for thought on these. I like have_one a lot. It speaks to me as a > Rails developer and I think it speaks to a customer as well. > > On the flip side, 'have_present' doesn't really tell me what is > interesting about having it present, or why it should be present. I > think 'require_attribute' would be nice ('require' would be even > better, but obviously that is a keyword). Or 'validate_presence_of': > > an { @asset.should validate_presence_of(:something) } > > That's a little more Rails-developer-friendly than customer-friendly, > but it still 'speaks' better than 'have_present' for me. > > FYI - Jay Fields has a Validatable framework that includes some > test/unit assertions that look like this: > > Foo.must_validate do > presence_of :name > format_of(:name).with(/^[A-Z]/) > numericality_of(:age).only_integer(true) > end > > Because Spec::Rails behaviours inherit from Test::Unit::TestCase, you > can install the validations gem (gem install validatable) and use > these as/is with RSpec. Or, if you want it to feel more spec'ish, you > could monkey patch an alias: > > Foo.should_validate do > presence_of :name > format_of(:name).with(/^[A-Z]/) > numericality_of(:age).only_integer(true) > end D'oh!! Foo.should validate do ... > Whether you choose to use his framework or write your own, I think > there is something to be learned from its expressiveness. > > Cheers, > David > From dchelimsky at gmail.com Fri May 4 23:38:35 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 4 May 2007 22:38:35 -0500 Subject: [rspec-devel] [rspec-users] have_one and have_present In-Reply-To: <71166b3b0705042034k5a8a328ah90816257bb08d962@mail.gmail.com> References: <57c63afe0705042025x7ba302d0icb6243730e3c7732@mail.gmail.com> <71166b3b0705042034k5a8a328ah90816257bb08d962@mail.gmail.com> Message-ID: <57c63afe0705042038h41f65cbbi11c60e5daac595db@mail.gmail.com> On 5/4/07, Luis Lavena wrote: > On 5/5/07, David Chelimsky wrote: > > >Comment By: Luis Lavena (luislavena) > > > Date: 2007-05-04 23:37 > > > > > describe "An Asset" do > > > before(:each) do > > > @asset = Asset.new > > > end > > > > > > it { @asset.should have_one(:attachment) } > > > it { @asset.should have_present(:something) } > > > end > > > > Food for thought on these. I like have_one a lot. It speaks to me as a > > Rails developer and I think it speaks to a customer as well. > > > > On the flip side, 'have_present' doesn't really tell me what is > > interesting about having it present, or why it should be present. I > > think 'require_attribute' would be nice ('require' would be even > > better, but obviously that is a keyword). Or 'validate_presence_of': > > > > an { @asset.should validate_presence_of(:something) } > > > > That's a little more Rails-developer-friendly than customer-friendly, > > but it still 'speaks' better than 'have_present' for me. > > > > yeah, have_present was due "require" been reserved word :-P > > validate_presence_of was another option, but that will force me to use > validate_uniqueness_of, etc... > > A lot of typing just for one liner of example :-P FWIW, you only have to type these things once each time you type them. You're going to read them hundreds of times. It's worth the extra typing in my view! If the examples are documentation, they should tell you, with as little mental mapping as possible, what it is that's being described. Using 'validate_presence_of' tells me EXACTLY what the code should look like. That's worth a lot to me. Cheers, David > > > FYI - Jay Fields has a Validatable framework that includes some > > test/unit assertions that look like this: > > > > Foo.must_validate do > > presence_of :name > > format_of(:name).with(/^[A-Z]/) > > numericality_of(:age).only_integer(true) > > end > > > > Because Spec::Rails behaviours inherit from Test::Unit::TestCase, you > > can install the validations gem (gem install validatable) and use > > these as/is with RSpec. Or, if you want it to feel more spec'ish, you > > could monkey patch an alias: > > > > I wasn't aware of it, thanks for the tip. > > > Foo.should_validate do > > presence_of :name > > format_of(:name).with(/^[A-Z]/) > > numericality_of(:age).only_integer(true) > > end > > > > Whether you choose to use his framework or write your own, I think > > there is something to be learned from its expressiveness. > > > > Of course, I often try to keep small the set of plugins/gems I use > during development, which require I do gem install there to get the > functionality. > > Piston the gem just for testing is also questionable, but doable. > > > Cheers, > > David > > Again, thank for your your feedback, > > Regards, > > -- > Luis Lavena > Multimedia systems > - > Leaders are made, they are not born. They are made by hard effort, > which is the price which all of us must pay to achieve any goal that > is worthwhile. > Vince Lombardi > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From noreply at rubyforge.org Sat May 5 19:56:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 5 May 2007 19:56:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10577 ] Rails with Oracle breaks 0.9.2 Message-ID: <20070505235620.2E51B5240A77@rubyforge.org> Bugs item #10577, was opened at 2007-05-04 15:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: John Andrews (jandrews) Assigned to: Nobody (None) Summary: Rails with Oracle breaks 0.9.2 Initial Comment: Upgrading to rspec 0.9.2 from 0.8.2 using Oracle database with ActiveRecord breaks due to the following: oracle_adapter.rb:316 (owner, table_name) = @connection.describe(table_name) @connection is an instance of OCI8AutoRecover which itself delegates the describe method to OCI8. class OCI8AutoRecover < DelegateClass(OCI8) #... # no def describe method end DelegateClass internally uses method_missing to call the delegate class' describe class OCI8 #:nodoc: def describe(name) #... end #... end The problem is that rspec defines Kernel#describe, so method_missing never catches the call to delegate and it fails from rspec because there is obviously no block given. My work-around modifies 2 files. I will just include the methods I changed because I don't have diffs from trunk. from file: rspec_on_rails/lib/spec/rails/extensions/kernel.rb def describe(*args, &block) # assuming that if a block is not given that it is not a call # for rspec if block_given? args << {} unless Hash === args.last args.last[:spec_path] = caller(0)[1] end original_describe(*args, &block) end from file: rspec-0.9.2/lib/spec/runner/extensions/kernel.rb def describe(*args, &block) if block_given? raise ArgumentError if args.empty? register_behaviour(Spec::DSL::BehaviourFactory.create(*args, &block)) else # not the describe that we are looking for # it's probably a call from the oracle adapter super *args end end I don't know if this is the best way to fix the issue, but it works for me and all my specs pass again. if you need more info or someone to test a fix for Oracle I am able to help. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-05 23:56 Message: I'm uncomfortable with this solution. It's a band-aid for this particular example, but someone else might come along and do something similar - using method_missing to delegate to another object WITH a block expected in that object's #describe method. Does anyone have any other suggestions? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10577&group_id=797 From brian.takita at gmail.com Sat May 5 21:03:53 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 5 May 2007 18:03:53 -0700 Subject: [rspec-devel] [ANN] RSpec 0.9.1 released In-Reply-To: References: <8d961d900705010443h65eb9389n44905a45cae601b9@mail.gmail.com> <1d7ddd110705020004t7230bf4chbf16312b2adc90c4@mail.gmail.com> <7a93bd340705021457l32f815c4k6ad0c76657d80050@mail.gmail.com> <1d7ddd110705021908l43b2197fq61036edd1df964b8@mail.gmail.com> <5683b1290705041902n6e9e4117yce4a3c38821cfe0e@mail.gmail.com> <1d7ddd110705050124o3399c8ect5615946ff95ae0a3@mail.gmail.com> Message-ID: <1d7ddd110705051803v6c4ba54ep3bfc19ebd29d0245@mail.gmail.com> On 5/5/07, Chad Woolley wrote: > > On 5/5/07, Brian Takita wrote: > > On 5/4/07, Ian McFarland wrote: > > > Also, with the new syntax, how do we describe more about our context, > > things like: > > > > > > spec "partially initialized User object" do > > > should "fail validation" do > > > #things > > > end > > > end > > > > Thats interesting. I'm not sure if "should" has been brought up. It has > a > > nice orthoginal quality to it. > > I don't think it would work. The current keywords, specify or it, > leave the choice of the "specification" verb up to the user. It could > be "shall", "should", "may", or "can". > > In fact, these terms have specific meaning in formal specifications > such as IEEE (section 13.1): > > http://standards.ieee.org/guides/style/section5.html > > That's one reason I don't really get the guy's link you sent that was > the supposed justification for the wording change: > > http://www.testing.com/cgi-bin/blog/2006/04/12#spec-vs-example > > I've read that three times, but I still don't get it. Maybe because > I'm not a math geek, and in fact was never that good at math at all. > > However, I do understand english pretty well, and I think that if I > write a spec that says "should", that doesn't have to represent the > entire specification for my app. It represents one facet of it. > Again, the IEEE standards language supports this: > > "The word should is used to indicate that among several possibilities > one is recommended as particularly suitable, without mentioning or > excluding others" > > It doesn't say "the word 'should' is used to represent a mathematical > equation that leaves absolutely no ambiguity." > > And that's coming from Engineers, who ARE math geeks... I think the following quote is the gist of the terminology change: > Still, it creeps me out when people refer to tests (aka examples) > as specifications. There's an important distinction: > > A specification *describes* a correct program, while a test *provokes* a > correct program. > > That's why example are used instead of specifications. So maybe the question now is why is example better than test? Also, why is 'describe' replacing 'context'? The quote implies we don't want to describe software, but provoke the correct software. > > Also, is the old syntax supported still? Or is migrating to the new > > version a matter of reopening every spec file we've ever written? > > > > The old syntax is still supported. There has not been talk of > deprecating it > > either, and I'll fight it if there is :) > > > > I actually think that's worse in the long run. They should decide on > one and switch to it exclusively. Having two supported styles will > just confuse newbies (and oldies), and result in specs (err, examples) > that use an ugly and inconsistent mix of both styles, as well as > arguments over which is better (like this one, for example!) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070505/5ed0a769/attachment.html From noreply at rubyforge.org Sun May 6 04:53:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 04:53:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070506085317.CD2F452409D5@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2007-05-06 05:53 Message: Ok, more information about the bug. rake spec:doc some results: A User (in general) - NAME NOT GENERATED - NAME NOT GENERATED - NAME NOT GENERATED for these examples: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end even if description of have_many and have_one is set. (spec -f s spec/models/user_spec.rb don't show this glitch). Thanks Luis ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-04 23:37 Message: Thank you Aslak for the explanation. Actually I'm not trying to raise an exception from my matcher, but trying to track errors on them during creation. A lot of things about matchers are missing in docs, but tried to mimic existing ones (and the examples too). Anyway, the case I'm dealing with is this: I'm trying to validate attributes and the "validations" (validates_presence_of, validates_uniqueness_of, etc.) Also associations through these matchers. module ModelSpecHelper class Present def initialize(attr) @attr = attr end def matches?(model) @model = model model.send("#{@attr.to_s}=".to_sym, nil) model.valid? return !model.errors.on("#{@attr.to_s}".to_sym).nil? end def failure_message; "expected #{@model.inspect} to have present #{@attr.inspect}"; end def description; "not be valid without #{@attr}"; end end # Here start the accessor for examples: # it { model.should have_present(:attr) } => should not be valid without :attr def have_present(attr) Present.new(attr) end end describe "An Asset" do before(:each) do @asset = Asset.new end [:title, :content_type, :basename].each do |attr| it { @asset.should have_present(attr) } end it { @asset.should have_one(:attachment) } it { @asset.should have_present(:something) } end has_one :attachment nor something attribute are present in the model. in the has_one association, the displayed message is this: 'An Asset should has_one attachment' FAILED expected Asset to has_one :attachment But, in the have_present(:something): NoMethodError in 'An Asset NAME NOT GENERATED' undefined method `pepe=' for # ./spec/my_helpers.rb:9:in `send' ./spec/my_helpers.rb:9:in `matches?' ./spec/models/asset_spec.rb:20: Is easy to track down the error, but is not visually appealing if I made a typo or something. If i put everything into a begin ... rescue could workaround this, now I know. Wanted to know if I'm doing something wrong (like breaking rspec, I'm used to crash things) ;-) made some corrections: def matches?(model) @model = model if model.respond_to?("#{@attr.to_s}=".to_sym) model.send("#{@attr.to_s}=".to_sym, nil) model.valid? !model.errors.on("#{@attr.to_s}".to_sym).nil? end end and that avoids the exception. Thanks again for your time Luis ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 21:40 Message: This is a little trickier to solve than I had first thought. Just so I understand you correctly: You want the automatic description to be set even when your matcher's #matches? method raises an exception? Such behaviour is actually in violation of the general contract for matchers (which I admit is not clearly documented). #matches? is not allowed to raise exceptions - it must always return true or false. In addition to this it is recommended that #matches? creates an instance reference to the +actual+ argument so that it can be used later in the #description method (if appliccable). This is what happens in most of RSpec's built-in matchers. RSpec can only assume that if #matches? raised an exception, then calling #description would most likely return gibberish (we must assume that @actual was never set), and it doesn't even try to call it. This happens in handler.rb. This is why you don't get a generated description for your examples without names. The solution should be simple - just add a rescue in your #matches? method and have it return false when something goes wrong. Maybe David has something to add. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Sun May 6 06:05:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 06:05:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070506100539.158325240A1D@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 19:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:05 Message: This is expected (but undocumented) too. Generated example names are based on the last executed should/should_not statement of the example block. rake spec:doc runs RSpec with --dry-run, which means that there is nothing to generate the example names from. We have several options: 1) Document this behaviour * In --help * In the spec:doc desc * In a FAQ 2) Output this instead: NAME NOT GENERATED (Because this was a --dry-run) 3) Exit with an exception saying: All examples must have explicit names when using --dry-run Which one do you prefer? Do you have other suggestions? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-06 04:53 Message: Ok, more information about the bug. rake spec:doc some results: A User (in general) - NAME NOT GENERATED - NAME NOT GENERATED - NAME NOT GENERATED for these examples: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end even if description of have_many and have_one is set. (spec -f s spec/models/user_spec.rb don't show this glitch). Thanks Luis ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-04 22:37 Message: Thank you Aslak for the explanation. Actually I'm not trying to raise an exception from my matcher, but trying to track errors on them during creation. A lot of things about matchers are missing in docs, but tried to mimic existing ones (and the examples too). Anyway, the case I'm dealing with is this: I'm trying to validate attributes and the "validations" (validates_presence_of, validates_uniqueness_of, etc.) Also associations through these matchers. module ModelSpecHelper class Present def initialize(attr) @attr = attr end def matches?(model) @model = model model.send("#{@attr.to_s}=".to_sym, nil) model.valid? return !model.errors.on("#{@attr.to_s}".to_sym).nil? end def failure_message; "expected #{@model.inspect} to have present #{@attr.inspect}"; end def description; "not be valid without #{@attr}"; end end # Here start the accessor for examples: # it { model.should have_present(:attr) } => should not be valid without :attr def have_present(attr) Present.new(attr) end end describe "An Asset" do before(:each) do @asset = Asset.new end [:title, :content_type, :basename].each do |attr| it { @asset.should have_present(attr) } end it { @asset.should have_one(:attachment) } it { @asset.should have_present(:something) } end has_one :attachment nor something attribute are present in the model. in the has_one association, the displayed message is this: 'An Asset should has_one attachment' FAILED expected Asset to has_one :attachment But, in the have_present(:something): NoMethodError in 'An Asset NAME NOT GENERATED' undefined method `pepe=' for # ./spec/my_helpers.rb:9:in `send' ./spec/my_helpers.rb:9:in `matches?' ./spec/models/asset_spec.rb:20: Is easy to track down the error, but is not visually appealing if I made a typo or something. If i put everything into a begin ... rescue could workaround this, now I know. Wanted to know if I'm doing something wrong (like breaking rspec, I'm used to crash things) ;-) made some corrections: def matches?(model) @model = model if model.respond_to?("#{@attr.to_s}=".to_sym) model.send("#{@attr.to_s}=".to_sym, nil) model.valid? !model.errors.on("#{@attr.to_s}".to_sym).nil? end end and that avoids the exception. Thanks again for your time Luis ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 20:40 Message: This is a little trickier to solve than I had first thought. Just so I understand you correctly: You want the automatic description to be set even when your matcher's #matches? method raises an exception? Such behaviour is actually in violation of the general contract for matchers (which I admit is not clearly documented). #matches? is not allowed to raise exceptions - it must always return true or false. In addition to this it is recommended that #matches? creates an instance reference to the +actual+ argument so that it can be used later in the #description method (if appliccable). This is what happens in most of RSpec's built-in matchers. RSpec can only assume that if #matches? raised an exception, then calling #description would most likely return gibberish (we must assume that @actual was never set), and it doesn't even try to call it. This happens in handler.rb. This is why you don't get a generated description for your examples without names. The solution should be simple - just add a rescue in your #matches? method and have it return false when something goes wrong. Maybe David has something to add. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Sun May 6 06:10:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 06:10:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070506101044.39EF35240A1C@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Sun May 6 06:13:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 06:13:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070506101331.C93C75240A1C@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2007-05-06 07:13 Message: I see, Document it is a must, but better in-line (or in this situation, in-run) information is good to. 1 & 2, but 2 could be: NAME NOT GENERATED (Because this was a --dry-run or failed matcher) Since a error in the matchers (a thrown exception due bad coding) could generate the same glitch. Guess that will close this ticket ;-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 07:05 Message: This is expected (but undocumented) too. Generated example names are based on the last executed should/should_not statement of the example block. rake spec:doc runs RSpec with --dry-run, which means that there is nothing to generate the example names from. We have several options: 1) Document this behaviour * In --help * In the spec:doc desc * In a FAQ 2) Output this instead: NAME NOT GENERATED (Because this was a --dry-run) 3) Exit with an exception saying: All examples must have explicit names when using --dry-run Which one do you prefer? Do you have other suggestions? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-06 05:53 Message: Ok, more information about the bug. rake spec:doc some results: A User (in general) - NAME NOT GENERATED - NAME NOT GENERATED - NAME NOT GENERATED for these examples: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end even if description of have_many and have_one is set. (spec -f s spec/models/user_spec.rb don't show this glitch). Thanks Luis ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-04 23:37 Message: Thank you Aslak for the explanation. Actually I'm not trying to raise an exception from my matcher, but trying to track errors on them during creation. A lot of things about matchers are missing in docs, but tried to mimic existing ones (and the examples too). Anyway, the case I'm dealing with is this: I'm trying to validate attributes and the "validations" (validates_presence_of, validates_uniqueness_of, etc.) Also associations through these matchers. module ModelSpecHelper class Present def initialize(attr) @attr = attr end def matches?(model) @model = model model.send("#{@attr.to_s}=".to_sym, nil) model.valid? return !model.errors.on("#{@attr.to_s}".to_sym).nil? end def failure_message; "expected #{@model.inspect} to have present #{@attr.inspect}"; end def description; "not be valid without #{@attr}"; end end # Here start the accessor for examples: # it { model.should have_present(:attr) } => should not be valid without :attr def have_present(attr) Present.new(attr) end end describe "An Asset" do before(:each) do @asset = Asset.new end [:title, :content_type, :basename].each do |attr| it { @asset.should have_present(attr) } end it { @asset.should have_one(:attachment) } it { @asset.should have_present(:something) } end has_one :attachment nor something attribute are present in the model. in the has_one association, the displayed message is this: 'An Asset should has_one attachment' FAILED expected Asset to has_one :attachment But, in the have_present(:something): NoMethodError in 'An Asset NAME NOT GENERATED' undefined method `pepe=' for # ./spec/my_helpers.rb:9:in `send' ./spec/my_helpers.rb:9:in `matches?' ./spec/models/asset_spec.rb:20: Is easy to track down the error, but is not visually appealing if I made a typo or something. If i put everything into a begin ... rescue could workaround this, now I know. Wanted to know if I'm doing something wrong (like breaking rspec, I'm used to crash things) ;-) made some corrections: def matches?(model) @model = model if model.respond_to?("#{@attr.to_s}=".to_sym) model.send("#{@attr.to_s}=".to_sym, nil) model.valid? !model.errors.on("#{@attr.to_s}".to_sym).nil? end end and that avoids the exception. Thanks again for your time Luis ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 21:40 Message: This is a little trickier to solve than I had first thought. Just so I understand you correctly: You want the automatic description to be set even when your matcher's #matches? method raises an exception? Such behaviour is actually in violation of the general contract for matchers (which I admit is not clearly documented). #matches? is not allowed to raise exceptions - it must always return true or false. In addition to this it is recommended that #matches? creates an instance reference to the +actual+ argument so that it can be used later in the #description method (if appliccable). This is what happens in most of RSpec's built-in matchers. RSpec can only assume that if #matches? raised an exception, then calling #description would most likely return gibberish (we must assume that @actual was never set), and it doesn't even try to call it. This happens in handler.rb. This is why you don't get a generated description for your examples without names. The solution should be simple - just add a rescue in your #matches? method and have it return false when something goes wrong. Maybe David has something to add. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Sun May 6 06:14:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 06:14:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070506101416.0521B5240A1D@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2007-05-06 07:14 Message: Hit submit too quick.. Thanks Aslak for your support. Good weekend Luis ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-06 07:13 Message: I see, Document it is a must, but better in-line (or in this situation, in-run) information is good to. 1 & 2, but 2 could be: NAME NOT GENERATED (Because this was a --dry-run or failed matcher) Since a error in the matchers (a thrown exception due bad coding) could generate the same glitch. Guess that will close this ticket ;-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 07:05 Message: This is expected (but undocumented) too. Generated example names are based on the last executed should/should_not statement of the example block. rake spec:doc runs RSpec with --dry-run, which means that there is nothing to generate the example names from. We have several options: 1) Document this behaviour * In --help * In the spec:doc desc * In a FAQ 2) Output this instead: NAME NOT GENERATED (Because this was a --dry-run) 3) Exit with an exception saying: All examples must have explicit names when using --dry-run Which one do you prefer? Do you have other suggestions? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-06 05:53 Message: Ok, more information about the bug. rake spec:doc some results: A User (in general) - NAME NOT GENERATED - NAME NOT GENERATED - NAME NOT GENERATED for these examples: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end even if description of have_many and have_one is set. (spec -f s spec/models/user_spec.rb don't show this glitch). Thanks Luis ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-04 23:37 Message: Thank you Aslak for the explanation. Actually I'm not trying to raise an exception from my matcher, but trying to track errors on them during creation. A lot of things about matchers are missing in docs, but tried to mimic existing ones (and the examples too). Anyway, the case I'm dealing with is this: I'm trying to validate attributes and the "validations" (validates_presence_of, validates_uniqueness_of, etc.) Also associations through these matchers. module ModelSpecHelper class Present def initialize(attr) @attr = attr end def matches?(model) @model = model model.send("#{@attr.to_s}=".to_sym, nil) model.valid? return !model.errors.on("#{@attr.to_s}".to_sym).nil? end def failure_message; "expected #{@model.inspect} to have present #{@attr.inspect}"; end def description; "not be valid without #{@attr}"; end end # Here start the accessor for examples: # it { model.should have_present(:attr) } => should not be valid without :attr def have_present(attr) Present.new(attr) end end describe "An Asset" do before(:each) do @asset = Asset.new end [:title, :content_type, :basename].each do |attr| it { @asset.should have_present(attr) } end it { @asset.should have_one(:attachment) } it { @asset.should have_present(:something) } end has_one :attachment nor something attribute are present in the model. in the has_one association, the displayed message is this: 'An Asset should has_one attachment' FAILED expected Asset to has_one :attachment But, in the have_present(:something): NoMethodError in 'An Asset NAME NOT GENERATED' undefined method `pepe=' for # ./spec/my_helpers.rb:9:in `send' ./spec/my_helpers.rb:9:in `matches?' ./spec/models/asset_spec.rb:20: Is easy to track down the error, but is not visually appealing if I made a typo or something. If i put everything into a begin ... rescue could workaround this, now I know. Wanted to know if I'm doing something wrong (like breaking rspec, I'm used to crash things) ;-) made some corrections: def matches?(model) @model = model if model.respond_to?("#{@attr.to_s}=".to_sym) model.send("#{@attr.to_s}=".to_sym, nil) model.valid? !model.errors.on("#{@attr.to_s}".to_sym).nil? end end and that avoids the exception. Thanks again for your time Luis ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 21:40 Message: This is a little trickier to solve than I had first thought. Just so I understand you correctly: You want the automatic description to be set even when your matcher's #matches? method raises an exception? Such behaviour is actually in violation of the general contract for matchers (which I admit is not clearly documented). #matches? is not allowed to raise exceptions - it must always return true or false. In addition to this it is recommended that #matches? creates an instance reference to the +actual+ argument so that it can be used later in the #description method (if appliccable). This is what happens in most of RSpec's built-in matchers. RSpec can only assume that if #matches? raised an exception, then calling #description would most likely return gibberish (we must assume that @actual was never set), and it doesn't even try to call it. This happens in handler.rb. This is why you don't get a generated description for your examples without names. The solution should be simple - just add a rescue in your #matches? method and have it return false when something goes wrong. Maybe David has something to add. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Sun May 6 06:24:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 06:24:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070506102418.B4CF95240A1D@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Sun May 6 07:12:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 07:12:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070506111253.6FAB85240A1D@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 23:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 11:12 Message: Here's the regexp used to determine the path: /spec(\/|\)+(view|helper|controller|model)s/ The (\/|\) is there to support /unix/style and \windows\style paths. This used be to expressed in 4 separate regexps and this release merged them into one. The specs that describe windows style paths still pass, but I'm running them on *nix. Could there be a difference in the way windows is handling regexps? Also, please try this one windows as well: script/spec spec/controllers/session_controller_spec.rb and let us know if you get the same result. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 10:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 10:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Sun May 6 07:44:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 07:44:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070506114451.67B005240A1D@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 07:44 Message: There shouldn't be any need to support Windows style paths with \. Ruby will always report forward slashes for paths, even on Windows. I don't think Regexp support is different on Windows either, that would never slip through the Ruby community. However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 07:12 Message: Here's the regexp used to determine the path: /spec(\/|\)+(view|helper|controller|model)s/ The (\/|\) is there to support /unix/style and \windows\style paths. This used be to expressed in 4 separate regexps and this release merged them into one. The specs that describe windows style paths still pass, but I'm running them on *nix. Could there be a difference in the way windows is handling regexps? Also, please try this one windows as well: script/spec spec/controllers/session_controller_spec.rb and let us know if you get the same result. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Sun May 6 07:52:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 07:52:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070506115255.923C6524095A@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 23:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 11:52 Message: "However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X." Now THAT would make sense. Larry, would you kindly apply the patch below, run `script/spec spec/controllers/session_controller_spec.rb` and show us the output? Thanks Index: rspec_on_rails/lib/spec/dsl/behaviour_factory.rb =================================================================== --- rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (revision 1893) +++ rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (working copy) @@ -31,6 +31,7 @@ # describe "name", :behaviour_type => :view ... def create(*args, &block) opts = Hash === args.last ? args.last : {} + puts opts[:spec_path] if opts[:shared] key = :default elsif opts[:behaviour_type] ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 11:44 Message: There shouldn't be any need to support Windows style paths with \. Ruby will always report forward slashes for paths, even on Windows. I don't think Regexp support is different on Windows either, that would never slip through the Ruby community. However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 11:12 Message: Here's the regexp used to determine the path: /spec(\/|\)+(view|helper|controller|model)s/ The (\/|\) is there to support /unix/style and \windows\style paths. This used be to expressed in 4 separate regexps and this release merged them into one. The specs that describe windows style paths still pass, but I'm running them on *nix. Could there be a difference in the way windows is handling regexps? Also, please try this one windows as well: script/spec spec/controllers/session_controller_spec.rb and let us know if you get the same result. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 10:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 10:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Sun May 6 08:36:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 08:36:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10594 ] Failing Custom Matcher show NAME NOT GENERATED description Message-ID: <20070506123642.1F103524095A@rubyforge.org> Bugs item #10594, was opened at 2007-05-04 19:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Failing Custom Matcher show NAME NOT GENERATED description Initial Comment: By request of aslak hellesoy: Also, auto-generated names for the examples is very helpful, I'm trying to take advantage of it. Since I often prior code/define all the "examples", I have created a few matchers to fulfill associations and validations of attributes. Example: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end That creates the following descriptions: A User (in general) - should has_many contest_public_votes - should has_many design_industry_user_interests - should has_one user_extension A new User - should not be valid without first_name - should not be valid without last_name - should not be valid without login - should not be valid without email - should not be valid without password - should not be valid without password_confirmation - should not be valid without city - should not be valid without postal_code - should not be valid without country - should not be valid with duplicate login - should not be valid with duplicate email Anyway, the problem started with latest release, which if someone my matcher shows a problem, NAME NOT GENERATED was put in the description instead of my fancy, nicely done name ;-) Attached I have included a faulty matcher that shows the issue. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 08:36 Message: Fixed in r1913 RSpec will report one of the following: * NO NAME (Because of --dry-run) * NO NAME (Because there were no expectations) * NO NAME (Because of Error raised in matcher) ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-06 06:14 Message: Hit submit too quick.. Thanks Aslak for your support. Good weekend Luis ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-06 06:13 Message: I see, Document it is a must, but better in-line (or in this situation, in-run) information is good to. 1 & 2, but 2 could be: NAME NOT GENERATED (Because this was a --dry-run or failed matcher) Since a error in the matchers (a thrown exception due bad coding) could generate the same glitch. Guess that will close this ticket ;-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:05 Message: This is expected (but undocumented) too. Generated example names are based on the last executed should/should_not statement of the example block. rake spec:doc runs RSpec with --dry-run, which means that there is nothing to generate the example names from. We have several options: 1) Document this behaviour * In --help * In the spec:doc desc * In a FAQ 2) Output this instead: NAME NOT GENERATED (Because this was a --dry-run) 3) Exit with an exception saying: All examples must have explicit names when using --dry-run Which one do you prefer? Do you have other suggestions? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-06 04:53 Message: Ok, more information about the bug. rake spec:doc some results: A User (in general) - NAME NOT GENERATED - NAME NOT GENERATED - NAME NOT GENERATED for these examples: describe "A User (in general)" do before(:each) do @user = User.new end it { @user.should have_many(:contest_public_votes) } it { @user.should have_many(:design_industry_user_interests) } it { @user.should have_one(:user_extension) } end even if description of have_many and have_one is set. (spec -f s spec/models/user_spec.rb don't show this glitch). Thanks Luis ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2007-05-04 22:37 Message: Thank you Aslak for the explanation. Actually I'm not trying to raise an exception from my matcher, but trying to track errors on them during creation. A lot of things about matchers are missing in docs, but tried to mimic existing ones (and the examples too). Anyway, the case I'm dealing with is this: I'm trying to validate attributes and the "validations" (validates_presence_of, validates_uniqueness_of, etc.) Also associations through these matchers. module ModelSpecHelper class Present def initialize(attr) @attr = attr end def matches?(model) @model = model model.send("#{@attr.to_s}=".to_sym, nil) model.valid? return !model.errors.on("#{@attr.to_s}".to_sym).nil? end def failure_message; "expected #{@model.inspect} to have present #{@attr.inspect}"; end def description; "not be valid without #{@attr}"; end end # Here start the accessor for examples: # it { model.should have_present(:attr) } => should not be valid without :attr def have_present(attr) Present.new(attr) end end describe "An Asset" do before(:each) do @asset = Asset.new end [:title, :content_type, :basename].each do |attr| it { @asset.should have_present(attr) } end it { @asset.should have_one(:attachment) } it { @asset.should have_present(:something) } end has_one :attachment nor something attribute are present in the model. in the has_one association, the displayed message is this: 'An Asset should has_one attachment' FAILED expected Asset to has_one :attachment But, in the have_present(:something): NoMethodError in 'An Asset NAME NOT GENERATED' undefined method `pepe=' for # ./spec/my_helpers.rb:9:in `send' ./spec/my_helpers.rb:9:in `matches?' ./spec/models/asset_spec.rb:20: Is easy to track down the error, but is not visually appealing if I made a typo or something. If i put everything into a begin ... rescue could workaround this, now I know. Wanted to know if I'm doing something wrong (like breaking rspec, I'm used to crash things) ;-) made some corrections: def matches?(model) @model = model if model.respond_to?("#{@attr.to_s}=".to_sym) model.send("#{@attr.to_s}=".to_sym, nil) model.valid? !model.errors.on("#{@attr.to_s}".to_sym).nil? end end and that avoids the exception. Thanks again for your time Luis ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 20:40 Message: This is a little trickier to solve than I had first thought. Just so I understand you correctly: You want the automatic description to be set even when your matcher's #matches? method raises an exception? Such behaviour is actually in violation of the general contract for matchers (which I admit is not clearly documented). #matches? is not allowed to raise exceptions - it must always return true or false. In addition to this it is recommended that #matches? creates an instance reference to the +actual+ argument so that it can be used later in the #description method (if appliccable). This is what happens in most of RSpec's built-in matchers. RSpec can only assume that if #matches? raised an exception, then calling #description would most likely return gibberish (we must assume that @actual was never set), and it doesn't even try to call it. This happens in handler.rb. This is why you don't get a generated description for your examples without names. The solution should be simple - just add a rescue in your #matches? method and have it return false when something goes wrong. Maybe David has something to add. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10594&group_id=797 From noreply at rubyforge.org Sun May 6 09:48:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 09:48:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Documentation-8572 ] Old Google result Message-ID: <20070506134829.545B85240A1D@rubyforge.org> Documentation item #8572, was opened at 2007-02-11 11:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=8572&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Old Google result Initial Comment: Thanks for the heads up Richard We need to make sure that before a new website is uploaded - the old one is entirely deleted. Google will automatically remove hits for dead pages. On 2/11/07, Richard Musiol wrote: > Hi, > > > > I just want to mention that when using Google to search for "RSpec" the second result is > > http://rspec.rubyforge.org/tools/rails.html > > This page seems to be outdated, so maybe a redirection would be nice to avoid confusion. > > > > Thx and Bye > > Richard > ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 09:48 Message: Resolving this issue depends on this: http://rubyforge.org/tracker/index.php?func=detail&aid=10630&group_id=5&atid=102 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9738&aid=8572&group_id=797 From aslak.hellesoy at gmail.com Sun May 6 10:20:19 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 6 May 2007 16:20:19 +0200 Subject: [rspec-devel] [ANN] RSpec 0.9.3 Message-ID: <8d961d900705060720n683988bcwd761d29d82a5ef95@mail.gmail.com> Nothing big this time, but it's released From t.lucas at toolmantim.com Sun May 6 10:31:35 2007 From: t.lucas at toolmantim.com (Tim Lucas) Date: Mon, 7 May 2007 00:31:35 +1000 Subject: [rspec-devel] redirect_to matcher bug Message-ID: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> There's a bug in the redirect_to matcher in that it doesn't use @request.host but instead hard codes "test.host". I'm trying to trying to run the redirect_to_spec but it doesn't look like it can be run by itself. $ spec rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- ./rspec_on_rails/spec/ rails/matchers/../../../../../../spec/spec_helper (LoadError) ... I'm guessing nobody's attempted to run these specs on their own? How am I meant to add to and run the spec? The patch for the bugfix and spec is here: http://pastie.caboo.se/59357 -- tim From aslak.hellesoy at gmail.com Sun May 6 10:46:24 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 6 May 2007 16:46:24 +0200 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> Message-ID: <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> On 5/6/07, Tim Lucas wrote: > There's a bug in the redirect_to matcher in that it doesn't use > @request.host but instead hard codes "test.host". I'm trying to > trying to run the redirect_to_spec but it doesn't look like it can be > run by itself. > > $ spec rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb > /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- ./rspec_on_rails/spec/ > rails/matchers/../../../../../../spec/spec_helper (LoadError) > ... > > I'm guessing nobody's attempted to run these specs on their own? How > am I meant to add to and run the spec? > > The patch for the bugfix and spec is here: http://pastie.caboo.se/59357 > Thanks for the patch. Please make an issue at Rubyforge so we only have one place to go for patches. Cheers, Aslak > -- tim > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From t.lucas at toolmantim.com Sun May 6 10:57:40 2007 From: t.lucas at toolmantim.com (Tim Lucas) Date: Mon, 7 May 2007 00:57:40 +1000 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> Message-ID: <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> On 07/05/2007, at 12:46 AM, aslak hellesoy wrote: > On 5/6/07, Tim Lucas wrote: >> There's a bug in the redirect_to matcher in that it doesn't use >> @request.host but instead hard codes "test.host". I'm trying to >> trying to run the redirect_to_spec but it doesn't look like it can be >> run by itself. >> >> $ spec rspec_on_rails/spec/rails/matchers/redirect_to_spec.rb >> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in >> `gem_original_require': no such file to load -- ./rspec_on_rails/ >> spec/ >> rails/matchers/../../../../../../spec/spec_helper (LoadError) >> ... >> >> I'm guessing nobody's attempted to run these specs on their own? How >> am I meant to add to and run the spec? I'm guessing the answer to my question is: no and no. Use "rake pre_commit", read README for more info :) >> The patch for the bugfix and spec is here: http://pastie.caboo.se/ >> 59357 >> > > Thanks for the patch. Please make an issue at Rubyforge so we only > have one place to go for patches. will do. -- tim From noreply at rubyforge.org Sun May 6 11:21:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 11:21:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10631 ] redirect_to matcher doesn't respect request.host Message-ID: <20070506152125.9160F5240A42@rubyforge.org> Patches item #10631, was opened at 2007-05-07 01:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10631&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tim Lucas (toolmantim) Assigned to: Nobody (None) Summary: redirect_to matcher doesn't respect request.host Initial Comment: The redirect_to matcher has "test.host" hard-coded everywhere, when it should be using @request.host. This problem shows up in controller tests where you set a custom request.host. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10631&group_id=797 From t.lucas at toolmantim.com Sun May 6 11:22:44 2007 From: t.lucas at toolmantim.com (Tim Lucas) Date: Mon, 7 May 2007 01:22:44 +1000 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> Message-ID: On 07/05/2007, at 12:57 AM, Tim Lucas wrote: > On 07/05/2007, at 12:46 AM, aslak hellesoy wrote: > >> On 5/6/07, Tim Lucas wrote: >>> I'm guessing nobody's attempted to run these specs on their own? How >>> am I meant to add to and run the spec? > > I'm guessing the answer to my question is: no and no. Use "rake > pre_commit", read README for more info :) Sweet testing system you've created, but may I suggest a TESTING file explaining somewhere that you have to create a database.yml in the example_rails_app which points to a mysql DB named rspec_dev and rspec_test. I figured out by finding the mysql_setup.sql files in the example app's db directory. And after the hour long effort to test this patch, it all passes :) http://rubyforge.org/tracker/index.php? func=detail&aid=10631&group_id=797&atid=3151 and btw, looks like the new resftul route format on edge is creating some failing tests. -- tim From dchelimsky at gmail.com Sun May 6 11:48:22 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 6 May 2007 10:48:22 -0500 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> Message-ID: <57c63afe0705060848v7efc1de0g60b69c55d19413a8@mail.gmail.com> On 5/6/07, Tim Lucas wrote: > On 07/05/2007, at 12:57 AM, Tim Lucas wrote: > > > On 07/05/2007, at 12:46 AM, aslak hellesoy wrote: > > > >> On 5/6/07, Tim Lucas wrote: > >>> I'm guessing nobody's attempted to run these specs on their own? How > >>> am I meant to add to and run the spec? > > > > I'm guessing the answer to my question is: no and no. Use "rake > > pre_commit", read README for more info :) > > Sweet testing system you've created, but may I suggest a TESTING file > explaining somewhere that you have to create a database.yml in the > example_rails_app which points to a mysql DB named rspec_dev and > rspec_test. I figured out by finding the mysql_setup.sql files in the > example app's db directory. > > And after the hour long effort to test this patch, it all passes :) Sorry you missed it, but in README it says developers should look at rspec/README. In rspec/README it explains all this. > > http://rubyforge.org/tracker/index.php? > func=detail&aid=10631&group_id=797&atid=3151 > > and btw, looks like the new resftul route format on edge is creating > some failing tests. > > -- tim > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun May 6 11:51:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 11:51:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10631 ] redirect_to matcher doesn't respect request.host Message-ID: <20070506155155.5143D5240A36@rubyforge.org> Patches item #10631, was opened at 2007-05-06 15:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10631&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Tim Lucas (toolmantim) >Assigned to: David Chelimsky (dchelimsky) Summary: redirect_to matcher doesn't respect request.host Initial Comment: The redirect_to matcher has "test.host" hard-coded everywhere, when it should be using @request.host. This problem shows up in controller tests where you set a custom request.host. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 15:51 Message: Applied to trunk rev 1920. Nice patch. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10631&group_id=797 From noreply at rubyforge.org Sun May 6 12:21:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 12:21:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506162110.DAD5C5240A21@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Sun May 6 12:31:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 12:31:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506163103.57F7E5240A21@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From t.lucas at toolmantim.com Sun May 6 12:31:20 2007 From: t.lucas at toolmantim.com (Tim Lucas) Date: Mon, 7 May 2007 02:31:20 +1000 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: <57c63afe0705060848v7efc1de0g60b69c55d19413a8@mail.gmail.com> References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> <57c63afe0705060848v7efc1de0g60b69c55d19413a8@mail.gmail.com> Message-ID: On 07/05/2007, at 1:48 AM, David Chelimsky wrote: >> Sweet testing system you've created, but may I suggest a TESTING file >> explaining somewhere that you have to create a database.yml in the >> example_rails_app which points to a mysql DB named rspec_dev and >> rspec_test. I figured out by finding the mysql_setup.sql files in the >> example app's db directory. >> >> And after the hour long effort to test this patch, it all passes :) > > Sorry you missed it, but in README it says developers should look at > rspec/README. In rspec/README it explains all this. doh! Thanks David. I just kept hitting pre_commit and fixing gem dependencies. What's the purpose of trunk/README? Is there any need for it? If so, it could probably just contain "See rspec/README" as everything it half-states is explained (in not too many words) in spec/README. -- tim From dchelimsky at gmail.com Sun May 6 13:00:45 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 6 May 2007 12:00:45 -0500 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> <57c63afe0705060848v7efc1de0g60b69c55d19413a8@mail.gmail.com> Message-ID: <57c63afe0705061000y42751b23h91c26dc01f15ca07@mail.gmail.com> On 5/6/07, Tim Lucas wrote: > On 07/05/2007, at 1:48 AM, David Chelimsky wrote: > > >> Sweet testing system you've created, but may I suggest a TESTING file > >> explaining somewhere that you have to create a database.yml in the > >> example_rails_app which points to a mysql DB named rspec_dev and > >> rspec_test. I figured out by finding the mysql_setup.sql files in the > >> example app's db directory. > >> > >> And after the hour long effort to test this patch, it all passes :) > > > > Sorry you missed it, but in README it says developers should look at > > rspec/README. In rspec/README it explains all this. > > doh! Thanks David. I just kept hitting pre_commit and fixing gem > dependencies. > > What's the purpose of trunk/README? Is there any need for it? If so, > it could probably just contain "See rspec/README" as everything it > half-states is explained (in not too many words) in spec/README. Good idea. Done (rev 1921). Cheers, David > > -- tim > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun May 6 13:04:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 13:04:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506170439.B55F45240A21@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Sun May 6 13:20:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 13:20:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10636 ] Added spec for OptionParser in Runner Message-ID: <20070506172016.8DB2C5240A1C@rubyforge.org> Patches item #10636, was opened at 2007-05-06 17:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10636&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Added spec for OptionParser in Runner Initial Comment: This is just an added spec for the option parser. It clears up one bit of behavior. When --examples is given an empty file, no examples are specified. I added an empty file to check this. If you prefer this spec to be in a different context (in which the empty file is created on setup and destroyed on teardown,) just let me know. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10636&group_id=797 From noreply at rubyforge.org Sun May 6 13:20:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 13:20:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10516 ] should_include should be able to accept multiple items Message-ID: <20070506172038.360595240A21@rubyforge.org> Feature Requests item #10516, was opened at 2007-05-02 08:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: Sharon Rosner (ciconia) >Assigned to: David Chelimsky (dchelimsky) Summary: should_include should be able to accept multiple items Initial Comment: example: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should_include(:read, :write, :execute) end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:20 Message: In rspec 0.9, this expectation reads: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should include(:read, :write, :execute) end I've applied this change to trunk (rev 1922) and it will be released with 0.9.4. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 11:48 Message: Sorry, I was a little quick on the trigger here. We should be able to implement the include matcher with varargs as you ask - good idea!. No need to provide the version info I asked about :-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 08:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 From noreply at rubyforge.org Sun May 6 13:22:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 13:22:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10516 ] should_include should be able to accept multiple items Message-ID: <20070506172223.9FAAF5240A21@rubyforge.org> Feature Requests item #10516, was opened at 2007-05-02 08:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 Category: expectation module Group: None >Status: Open Priority: 3 Submitted By: Sharon Rosner (ciconia) Assigned to: David Chelimsky (dchelimsky) Summary: should_include should be able to accept multiple items Initial Comment: example: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should_include(:read, :write, :execute) end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:22 Message: D'oh! I changed the wrong thing and set it so you can include multiple modules in one command. Working on the actual feature requested here now.... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:20 Message: In rspec 0.9, this expectation reads: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should include(:read, :write, :execute) end I've applied this change to trunk (rev 1922) and it will be released with 0.9.4. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 11:48 Message: Sorry, I was a little quick on the trigger here. We should be able to implement the include matcher with varargs as you ask - good idea!. No need to provide the version info I asked about :-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 08:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 From noreply at rubyforge.org Sun May 6 13:44:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 13:44:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10516 ] should_include should be able to accept multiple items Message-ID: <20070506174400.B588D5240998@rubyforge.org> Feature Requests item #10516, was opened at 2007-05-02 08:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: Sharon Rosner (ciconia) Assigned to: David Chelimsky (dchelimsky) Summary: should_include should be able to accept multiple items Initial Comment: example: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should_include(:read, :write, :execute) end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:44 Message: OK - done correctly this time in rev 1924. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:22 Message: D'oh! I changed the wrong thing and set it so you can include multiple modules in one command. Working on the actual feature requested here now.... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:20 Message: In rspec 0.9, this expectation reads: specify "permissions should reflect those granted" do @user.grant(@root, true, true, true) @user.permissions(@root).should include(:read, :write, :execute) end I've applied this change to trunk (rev 1922) and it will be released with 0.9.4. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 11:48 Message: Sorry, I was a little quick on the trigger here. We should be able to implement the include matcher with varargs as you ask - good idea!. No need to provide the version info I asked about :-) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-02 08:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10516&group_id=797 From dchelimsky at gmail.com Sun May 6 13:53:58 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 6 May 2007 12:53:58 -0500 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> Message-ID: <57c63afe0705061053x6ef2dcc6t3db432f279cafc98@mail.gmail.com> On 5/6/07, Tim Lucas wrote: > and btw, looks like the new resftul route format on edge is creating > some failing tests. This is because Spec::Rails uses rails templates to generate app components (i.e. models, views, controllers, helpers) and the files rspec's generator is referencing have moved. Will fix - thanks for alerting. Cheers, David From dchelimsky at gmail.com Sun May 6 14:01:47 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 6 May 2007 13:01:47 -0500 Subject: [rspec-devel] redirect_to matcher bug In-Reply-To: <57c63afe0705061053x6ef2dcc6t3db432f279cafc98@mail.gmail.com> References: <61939D5E-A4BC-4576-A219-0FDCD0400FC2@toolmantim.com> <8d961d900705060746u6330d67en6068f9fd93de2ed3@mail.gmail.com> <9D332832-004B-4EE5-B074-38572D18EF42@toolmantim.com> <57c63afe0705061053x6ef2dcc6t3db432f279cafc98@mail.gmail.com> Message-ID: <57c63afe0705061101n65455a09lf58de87b2d08cd30@mail.gmail.com> On 5/6/07, David Chelimsky wrote: > On 5/6/07, Tim Lucas wrote: > > and btw, looks like the new resftul route format on edge is creating > > some failing tests. > > This is because Spec::Rails uses rails templates to generate app > components (i.e. models, views, controllers, helpers) and the files > rspec's generator is referencing have moved. Will fix - thanks for > alerting. Fixed - passing against edge rails rev 6690 > > Cheers, > David > From noreply at rubyforge.org Sun May 6 15:02:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 15:02:21 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506190221.730935240A1C@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:02 Message: Well, in this case, you would use the e switch when you want to read the examples from a file generated from a failing example or failing behavior formatter. Aslak and I had a discussion about this on the mailing list a few days ago. Should I refer you to the thread? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Sun May 6 15:09:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 15:09:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506190935.1CE7C5240A21@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 19:09 Message: I saw that thread, but it seemed unresolved, as does this thread. I'm probably just missing something obvious, but I simply don't understand the problem you are trying to solve. Can you please give a very clear example, with the spec names and file names you are worried about conflicting? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:02 Message: Well, in this case, you would use the e switch when you want to read the examples from a file generated from a failing example or failing behavior formatter. Aslak and I had a discussion about this on the mailing list a few days ago. Should I refer you to the thread? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From chad at pivotalsf.com Sun May 6 14:36:50 2007 From: chad at pivotalsf.com (Chad Woolley) Date: Sun, 6 May 2007 11:36:50 -0700 Subject: [rspec-devel] [ANN] RSpec 0.9.1 released In-Reply-To: <1d7ddd110705051803v6c4ba54ep3bfc19ebd29d0245@mail.gmail.com> References: <8d961d900705010443h65eb9389n44905a45cae601b9@mail.gmail.com> <1d7ddd110705020004t7230bf4chbf16312b2adc90c4@mail.gmail.com> <7a93bd340705021457l32f815c4k6ad0c76657d80050@mail.gmail.com> <1d7ddd110705021908l43b2197fq61036edd1df964b8@mail.gmail.com> <5683b1290705041902n6e9e4117yce4a3c38821cfe0e@mail.gmail.com> <1d7ddd110705050124o3399c8ect5615946ff95ae0a3@mail.gmail.com> <1d7ddd110705051803v6c4ba54ep3bfc19ebd29d0245@mail.gmail.com> Message-ID: On 5/5/07, Brian Takita wrote: > I think the following quote is the gist of the terminology change: > > > > > > Still, it creeps me out when people refer to tests (aka examples) as > specifications. There's an important distinction: > > A specification describes a correct program, while a test provokes a > correct program. http://en.wikipedia.org/wiki/Whatever_%28slang%29#Cultural_impact > That's why example are used instead of specifications. So maybe the > question now is why is example better than test? > Also, why is 'describe' replacing 'context'? The quote implies we don't want > to describe software, but provoke the correct software. I dunno. I still don't get it. The more I think about it, the more I just want to go back to "test". From noreply at rubyforge.org Sun May 6 15:26:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 15:26:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506192636.7426B5240A36@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:26 Message: Oh - Ok. I thought it was obvious. I'll try my best, but if it's still not obvious, hopefully Aslak can help me out. If I ran a spec command like the following: spec some_spec.rb --examples failures.txt --failures failures.txt What is my intention here? It is to run the examples given in failures.txt, outputing any of the failing examples back to failures.txt. Now if the examples file (failures.txt) is blank, then it will run all of the specs. I would get some output like this: .............................................................................. Finished in 3.595967 seconds 78 examples, 0 failures Now if the examples file does not exist, what should happen? Should it run none of the specs, or should it run all of them, as if the examples file was empty? It has always seemed like it should work like the latter case. If the failures/examples file does not exist, it should create it, then run all of the specs, and dump any failing ones to the failures file. As of now, it creates the file, but will not run *any* of the specs: Finished in 4.9e-05 seconds 0 examples, 0 failures Right now there are two ways to get around this: 1. Create the failures file before running the command 2. Run the spec commmand twice. The first time the failures file will be created. The second time it will run all specs, dumping the failing ones to the failures file. So this patch addresses that issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 19:09 Message: I saw that thread, but it seemed unresolved, as does this thread. I'm probably just missing something obvious, but I simply don't understand the problem you are trying to solve. Can you please give a very clear example, with the spec names and file names you are worried about conflicting? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:02 Message: Well, in this case, you would use the e switch when you want to read the examples from a file generated from a failing example or failing behavior formatter. Aslak and I had a discussion about this on the mailing list a few days ago. Should I refer you to the thread? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Sun May 6 15:31:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 15:31:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506193113.35D245240A1C@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:31 Message: As for conflicting files/spec names: Given the spec command: spec some_spec.rb --examples failures.txt --failures failures.txt where failures.txt does not exist. What specs are going to be run? RSpec can't find the failures file (since it does not yet exist), and so it assumes that failures.txt is the name of a failing example. The failures file then gets created, and it looks to run an example named "failures.txt." Obviously this does not exist, and so no specs will run. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:26 Message: Oh - Ok. I thought it was obvious. I'll try my best, but if it's still not obvious, hopefully Aslak can help me out. If I ran a spec command like the following: spec some_spec.rb --examples failures.txt --failures failures.txt What is my intention here? It is to run the examples given in failures.txt, outputing any of the failing examples back to failures.txt. Now if the examples file (failures.txt) is blank, then it will run all of the specs. I would get some output like this: .............................................................................. Finished in 3.595967 seconds 78 examples, 0 failures Now if the examples file does not exist, what should happen? Should it run none of the specs, or should it run all of them, as if the examples file was empty? It has always seemed like it should work like the latter case. If the failures/examples file does not exist, it should create it, then run all of the specs, and dump any failing ones to the failures file. As of now, it creates the file, but will not run *any* of the specs: Finished in 4.9e-05 seconds 0 examples, 0 failures Right now there are two ways to get around this: 1. Create the failures file before running the command 2. Run the spec commmand twice. The first time the failures file will be created. The second time it will run all specs, dumping the failing ones to the failures file. So this patch addresses that issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 19:09 Message: I saw that thread, but it seemed unresolved, as does this thread. I'm probably just missing something obvious, but I simply don't understand the problem you are trying to solve. Can you please give a very clear example, with the spec names and file names you are worried about conflicting? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:02 Message: Well, in this case, you would use the e switch when you want to read the examples from a file generated from a failing example or failing behavior formatter. Aslak and I had a discussion about this on the mailing list a few days ago. Should I refer you to the thread? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Sun May 6 16:13:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 16:13:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070506201311.BB56C5240A1C@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: Larry Kluger (larrykluger) Date: 2007-05-06 16:13 Message: Hi David, I've deleted the rspec gem and plugin. I then installed ver 0.9.3 as plugins per the installation instructions. I added the puts as requested the result was nil, see trace. Aslak, where do I put the lines describe MyController, :behaviour_type => :controller do end ? I tried describe "SessionController", :behaviour_type => :controller do end just after the require statement in my session_controller_spec.rb but received the same problem. Thank you for your help and time on this puzzler. Larry C:\instant_rails_1.7\InstantRails\rails_apps\am2>ruby script/spec spec/controllers/session_controller_spec.rb nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `create' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 C:\instant_rails_1.7\InstantRails\rails_apps\am2> ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 07:52 Message: "However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X." Now THAT would make sense. Larry, would you kindly apply the patch below, run `script/spec spec/controllers/session_controller_spec.rb` and show us the output? Thanks Index: rspec_on_rails/lib/spec/dsl/behaviour_factory.rb =================================================================== --- rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (revision 1893) +++ rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (working copy) @@ -31,6 +31,7 @@ # describe "name", :behaviour_type => :view ... def create(*args, &block) opts = Hash === args.last ? args.last : {} + puts opts[:spec_path] if opts[:shared] key = :default elsif opts[:behaviour_type] ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 07:44 Message: There shouldn't be any need to support Windows style paths with \. Ruby will always report forward slashes for paths, even on Windows. I don't think Regexp support is different on Windows either, that would never slip through the Ruby community. However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 07:12 Message: Here's the regexp used to determine the path: /spec(\/|\)+(view|helper|controller|model)s/ The (\/|\) is there to support /unix/style and \windows\style paths. This used be to expressed in 4 separate regexps and this release merged them into one. The specs that describe windows style paths still pass, but I'm running them on *nix. Could there be a difference in the way windows is handling regexps? Also, please try this one windows as well: script/spec spec/controllers/session_controller_spec.rb and let us know if you get the same result. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Sun May 6 16:22:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 16:22:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070506202232.985B35240A1C@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: Larry Kluger (larrykluger) Date: 2007-05-06 16:22 Message: Hi, I changed behaviour_factory.rb to be: def create(*args, &block) opts = Hash === args.last ? args.last : {} require 'pp' puts pp(args) if opts[:shared] .... Here is the output: ["/session/new GET"] nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb :95:in `method_missing': undefined method `controller_name' for # ( NoMethodError) .... Larry ---------------------------------------------------------------------- Comment By: Larry Kluger (larrykluger) Date: 2007-05-06 16:13 Message: Hi David, I've deleted the rspec gem and plugin. I then installed ver 0.9.3 as plugins per the installation instructions. I added the puts as requested the result was nil, see trace. Aslak, where do I put the lines describe MyController, :behaviour_type => :controller do end ? I tried describe "SessionController", :behaviour_type => :controller do end just after the require statement in my session_controller_spec.rb but received the same problem. Thank you for your help and time on this puzzler. Larry C:\instant_rails_1.7\InstantRails\rails_apps\am2>ruby script/spec spec/controllers/session_controller_spec.rb nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `create' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 C:\instant_rails_1.7\InstantRails\rails_apps\am2> ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 07:52 Message: "However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X." Now THAT would make sense. Larry, would you kindly apply the patch below, run `script/spec spec/controllers/session_controller_spec.rb` and show us the output? Thanks Index: rspec_on_rails/lib/spec/dsl/behaviour_factory.rb =================================================================== --- rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (revision 1893) +++ rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (working copy) @@ -31,6 +31,7 @@ # describe "name", :behaviour_type => :view ... def create(*args, &block) opts = Hash === args.last ? args.last : {} + puts opts[:spec_path] if opts[:shared] key = :default elsif opts[:behaviour_type] ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 07:44 Message: There shouldn't be any need to support Windows style paths with \. Ruby will always report forward slashes for paths, even on Windows. I don't think Regexp support is different on Windows either, that would never slip through the Ruby community. However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 07:12 Message: Here's the regexp used to determine the path: /spec(\/|\)+(view|helper|controller|model)s/ The (\/|\) is there to support /unix/style and \windows\style paths. This used be to expressed in 4 separate regexps and this release merged them into one. The specs that describe windows style paths still pass, but I'm running them on *nix. Could there be a difference in the way windows is handling regexps? Also, please try this one windows as well: script/spec spec/controllers/session_controller_spec.rb and let us know if you get the same result. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Sun May 6 19:51:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 19:51:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070506235129.784BA5240955@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 23:51 Message: OK. I get it now. Thank you for explaining this again and clearing it up. You mentioned that you were still working on the code - can I delete the patch that's attached to this RFE so I don't look at this in a few days and think it's the one I should use? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:31 Message: As for conflicting files/spec names: Given the spec command: spec some_spec.rb --examples failures.txt --failures failures.txt where failures.txt does not exist. What specs are going to be run? RSpec can't find the failures file (since it does not yet exist), and so it assumes that failures.txt is the name of a failing example. The failures file then gets created, and it looks to run an example named "failures.txt." Obviously this does not exist, and so no specs will run. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:26 Message: Oh - Ok. I thought it was obvious. I'll try my best, but if it's still not obvious, hopefully Aslak can help me out. If I ran a spec command like the following: spec some_spec.rb --examples failures.txt --failures failures.txt What is my intention here? It is to run the examples given in failures.txt, outputing any of the failing examples back to failures.txt. Now if the examples file (failures.txt) is blank, then it will run all of the specs. I would get some output like this: .............................................................................. Finished in 3.595967 seconds 78 examples, 0 failures Now if the examples file does not exist, what should happen? Should it run none of the specs, or should it run all of them, as if the examples file was empty? It has always seemed like it should work like the latter case. If the failures/examples file does not exist, it should create it, then run all of the specs, and dump any failing ones to the failures file. As of now, it creates the file, but will not run *any* of the specs: Finished in 4.9e-05 seconds 0 examples, 0 failures Right now there are two ways to get around this: 1. Create the failures file before running the command 2. Run the spec commmand twice. The first time the failures file will be created. The second time it will run all specs, dumping the failing ones to the failures file. So this patch addresses that issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 19:09 Message: I saw that thread, but it seemed unresolved, as does this thread. I'm probably just missing something obvious, but I simply don't understand the problem you are trying to solve. Can you please give a very clear example, with the spec names and file names you are worried about conflicting? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:02 Message: Well, in this case, you would use the e switch when you want to read the examples from a file generated from a failing example or failing behavior formatter. Aslak and I had a discussion about this on the mailing list a few days ago. Should I refer you to the thread? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Sun May 6 20:02:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 20:02:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070507000206.8A1175240955@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-07 00:02 Message: Sure. Actually, I think it would be better to close/reject the ticket (since the title is misleading). I'll open another ticket with an appropriate title, and refer to this one. Also - do you think that you could apply patch #10636? It is nothing more than added spec to the options parser. This patch will rely on that one (since they both use an empty file). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 23:51 Message: OK. I get it now. Thank you for explaining this again and clearing it up. You mentioned that you were still working on the code - can I delete the patch that's attached to this RFE so I don't look at this in a few days and think it's the one I should use? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:31 Message: As for conflicting files/spec names: Given the spec command: spec some_spec.rb --examples failures.txt --failures failures.txt where failures.txt does not exist. What specs are going to be run? RSpec can't find the failures file (since it does not yet exist), and so it assumes that failures.txt is the name of a failing example. The failures file then gets created, and it looks to run an example named "failures.txt." Obviously this does not exist, and so no specs will run. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:26 Message: Oh - Ok. I thought it was obvious. I'll try my best, but if it's still not obvious, hopefully Aslak can help me out. If I ran a spec command like the following: spec some_spec.rb --examples failures.txt --failures failures.txt What is my intention here? It is to run the examples given in failures.txt, outputing any of the failing examples back to failures.txt. Now if the examples file (failures.txt) is blank, then it will run all of the specs. I would get some output like this: .............................................................................. Finished in 3.595967 seconds 78 examples, 0 failures Now if the examples file does not exist, what should happen? Should it run none of the specs, or should it run all of them, as if the examples file was empty? It has always seemed like it should work like the latter case. If the failures/examples file does not exist, it should create it, then run all of the specs, and dump any failing ones to the failures file. As of now, it creates the file, but will not run *any* of the specs: Finished in 4.9e-05 seconds 0 examples, 0 failures Right now there are two ways to get around this: 1. Create the failures file before running the command 2. Run the spec commmand twice. The first time the failures file will be created. The second time it will run all specs, dumping the failing ones to the failures file. So this patch addresses that issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 19:09 Message: I saw that thread, but it seemed unresolved, as does this thread. I'm probably just missing something obvious, but I simply don't understand the problem you are trying to solve. Can you please give a very clear example, with the spec names and file names you are worried about conflicting? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:02 Message: Well, in this case, you would use the e switch when you want to read the examples from a file generated from a failing example or failing behavior formatter. Aslak and I had a discussion about this on the mailing list a few days ago. Should I refer you to the thread? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From nick at pivotalsf.com Sun May 6 15:36:39 2007 From: nick at pivotalsf.com (Nick Kallen) Date: Sun, 6 May 2007 12:36:39 -0700 Subject: [rspec-devel] [ANN] RSpec 0.9.1 released In-Reply-To: References: <8d961d900705010443h65eb9389n44905a45cae601b9@mail.gmail.com> <7a93bd340705021457l32f815c4k6ad0c76657d80050@mail.gmail.com> <1d7ddd110705021908l43b2197fq61036edd1df964b8@mail.gmail.com> <5683b1290705041902n6e9e4117yce4a3c38821cfe0e@mail.gmail.com> <1d7ddd110705050124o3399c8ect5615946ff95ae0a3@mail.gmail.com> <1d7ddd110705051803v6c4ba54ep3bfc19ebd29d0245@mail.gmail.com> Message-ID: <82c457760705061236q3b73b04ex488a0ea27c33a0aa@mail.gmail.com> Not to get into a semantic argument but... I've long complained that Rspec's are not specs but examples. A specification is a formal, complete description of all possible behaviors of a program. A spec of fib, for example is like Forall n > 1, fib(n) == f(n-1) + fib(n-2) Or for a sort algorithm, Forall array s.t., array.length > 0, For all j. s.t. 0 < j < array.length, let array' = array.sort in array'[j] < array'[j+1] The unfortunate thing about specifications is that they are usually non-executable. However, you can prove the a program corresponds to a specification using formal methods (i.e., proofs). The idea that specifications "provoke" a program is a misleading way of putting it. On 5/6/07, Chad Woolley wrote: > > On 5/5/07, Brian Takita wrote: > > I think the following quote is the gist of the terminology change: > > > > > > > > > Still, it creeps me out when people refer to tests (aka examples) as > > specifications. There's an important distinction: > > > A specification describes a correct program, while a test provokes a > > correct program. > > http://en.wikipedia.org/wiki/Whatever_%28slang%29#Cultural_impact > > > That's why example are used instead of specifications. So maybe the > > question now is why is example better than test? > > Also, why is 'describe' replacing 'context'? The quote implies we don't > want > > to describe software, but provoke the correct software. > > I dunno. I still don't get it. The more I think about it, the more I > just want to go back to "test". > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070506/39923ecd/attachment.html From noreply at rubyforge.org Sun May 6 20:11:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 20:11:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10636 ] Added spec for OptionParser in Runner Message-ID: <20070507001105.07DFE5240955@rubyforge.org> Patches item #10636, was opened at 2007-05-06 17:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10636&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) >Assigned to: David Chelimsky (dchelimsky) Summary: Added spec for OptionParser in Runner Initial Comment: This is just an added spec for the option parser. It clears up one bit of behavior. When --examples is given an empty file, no examples are specified. I added an empty file to check this. If you prefer this spec to be in a different context (in which the empty file is created on setup and destroyed on teardown,) just let me know. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-07 00:11 Message: Applied to trunk rev 1926 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10636&group_id=797 From noreply at rubyforge.org Sun May 6 20:12:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 6 May 2007 20:12:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10545 ] Removal of --options when appropriate Message-ID: <20070507001201.8643452409B4@rubyforge.org> Patches item #10545, was opened at 2007-05-03 07:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) >Assigned to: David Chelimsky (dchelimsky) Summary: Removal of --options when appropriate Initial Comment: Consider a spec command like the following: spec some_spec --options filename.txt --format failing_examples:filename.txt What happens when the file filename.txt does not exist? The file gets created, and no specs are run. This patch addresses this problem by removing the appropriate option. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-07 00:12 Message: OK - I applied 10636. I'll close this one and await your new RFE. Thanks for playing. Cheers, David ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-07 00:02 Message: Sure. Actually, I think it would be better to close/reject the ticket (since the title is misleading). I'll open another ticket with an appropriate title, and refer to this one. Also - do you think that you could apply patch #10636? It is nothing more than added spec to the options parser. This patch will rely on that one (since they both use an empty file). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 23:51 Message: OK. I get it now. Thank you for explaining this again and clearing it up. You mentioned that you were still working on the code - can I delete the patch that's attached to this RFE so I don't look at this in a few days and think it's the one I should use? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:31 Message: As for conflicting files/spec names: Given the spec command: spec some_spec.rb --examples failures.txt --failures failures.txt where failures.txt does not exist. What specs are going to be run? RSpec can't find the failures file (since it does not yet exist), and so it assumes that failures.txt is the name of a failing example. The failures file then gets created, and it looks to run an example named "failures.txt." Obviously this does not exist, and so no specs will run. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:26 Message: Oh - Ok. I thought it was obvious. I'll try my best, but if it's still not obvious, hopefully Aslak can help me out. If I ran a spec command like the following: spec some_spec.rb --examples failures.txt --failures failures.txt What is my intention here? It is to run the examples given in failures.txt, outputing any of the failing examples back to failures.txt. Now if the examples file (failures.txt) is blank, then it will run all of the specs. I would get some output like this: .............................................................................. Finished in 3.595967 seconds 78 examples, 0 failures Now if the examples file does not exist, what should happen? Should it run none of the specs, or should it run all of them, as if the examples file was empty? It has always seemed like it should work like the latter case. If the failures/examples file does not exist, it should create it, then run all of the specs, and dump any failing ones to the failures file. As of now, it creates the file, but will not run *any* of the specs: Finished in 4.9e-05 seconds 0 examples, 0 failures Right now there are two ways to get around this: 1. Create the failures file before running the command 2. Run the spec commmand twice. The first time the failures file will be created. The second time it will run all specs, dumping the failing ones to the failures file. So this patch addresses that issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 19:09 Message: I saw that thread, but it seemed unresolved, as does this thread. I'm probably just missing something obvious, but I simply don't understand the problem you are trying to solve. Can you please give a very clear example, with the spec names and file names you are worried about conflicting? ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 19:02 Message: Well, in this case, you would use the e switch when you want to read the examples from a file generated from a failing example or failing behavior formatter. Aslak and I had a discussion about this on the mailing list a few days ago. Should I refer you to the thread? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 17:04 Message: So you're worried about people accidentally using the -e switch with an example that has the same name as a file? Same question applies. What is the likelihood that that would happen? I'm not completely opposed to it, but the case seems unlikely to me. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-06 16:31 Message: Sorry. I messed up the post royally. It should be --examples instead of --options. I'm still working on some of the code, so feel free to reject this one, and i'll open another ticket when I'm ready. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 16:21 Message: It makes no sense that anybody would intentionally use the same filename for these two orthogonal concepts. Even if they do by accident, quietly processing only one file would make it even more difficult to understand what went wrong. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10545&group_id=797 From noreply at rubyforge.org Mon May 7 01:13:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 01:13:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10645 ] removal of --examples when appropriate Message-ID: <20070507051317.0BE855240A66@rubyforge.org> Patches item #10645, was opened at 2007-05-07 05:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: removal of --examples when appropriate Initial Comment: See ticket: #10545 "Removal of --options when appropriate" http://rubyforge.org/tracker/index.php?func=detail&aid=10545&group_id=797&atid=3151 David/Aslak: I added a an attribute reader for @where in the base text formatter, and called the method output. Feel free to change this as you wish. It is only referenced in the Options class, under the method I've added: remove_extraneous_examples! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 From dchelimsky at gmail.com Mon May 7 07:43:49 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 7 May 2007 06:43:49 -0500 Subject: [rspec-devel] mock frameworks Message-ID: <57c63afe0705070443p12046c05off053706e844c129@mail.gmail.com> Just curious - now that rspec (as of 0.9) let's you choose your mock framework, how many of you are actually using (or planning to use) mocha or flexmock? Anybody planning to use any other mock framework besides rspec, mocha or flexmock? Thanks, David From noreply at rubyforge.org Mon May 7 19:01:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 19:01:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10669 ] Kernel#describe override does not cover Kernel#context Message-ID: <20070507230139.86AD15240AB6@rubyforge.org> Bugs item #10669, was opened at 2007-05-07 16:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10669&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Kernel#describe override does not cover Kernel#context Initial Comment: This makes Rails specs not work because the spec_path option is not used. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10669&group_id=797 From noreply at rubyforge.org Mon May 7 19:06:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 19:06:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10670 ] IVarProxy#delete raises exception when instance variable does not exist Message-ID: <20070507230614.A64365240AB6@rubyforge.org> Bugs item #10670, was opened at 2007-05-07 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: IVarProxy#delete raises exception when instance variable does not exist Initial Comment: This causes issues with Markaby. It should just return nil. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 From noreply at rubyforge.org Mon May 7 19:20:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 19:20:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10672 ] Setting Spec::Runner.configure fixture_path doesn't seem to work Message-ID: <20070507232006.492355240B40@rubyforge.org> Bugs item #10672, was opened at 2007-05-07 16:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10672&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Setting Spec::Runner.configure fixture_path doesn't seem to work Initial Comment: Spec::Runner.configure do |config| config.use_transactional_fixtures = true config.use_instantiated_fixtures = false config.fixture_path = RAILS_ROOT + '/test/fixtures' # config.global_fixtures = :table_a, :table_b end module Spec module Rails module Runner class EvalContext < Test::Unit::TestCase # When the next line is uncommented, the specs work # self.fixture_path = RAILS_ROOT + '/test/fixtures' extend DisabledSpecs include CommunityPatentSpecHelper include RjsSpecHelper end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10672&group_id=797 From noreply at rubyforge.org Mon May 7 19:23:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 19:23:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10673 ] should > and should >= broken Message-ID: <20070507232305.866C55240B45@rubyforge.org> Bugs item #10673, was opened at 2007-05-07 16:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: should > and should >= broken Initial Comment: should == still works ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 From noreply at rubyforge.org Mon May 7 19:27:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 19:27:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10673 ] should > and should > = broken Message-ID: <20070507232718.075F85240B28@rubyforge.org> Bugs item #10673, was opened at 2007-05-07 16:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) >Summary: should > and should >= broken Initial Comment: should == still works ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-07 16:27 Message: should < and should <= doesn't work either. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 From noreply at rubyforge.org Mon May 7 21:17:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 21:17:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10673 ] should > and should > = broken Message-ID: <20070508011706.A162B5240B6F@rubyforge.org> Bugs item #10673, was opened at 2007-05-07 23:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: should > and should >= broken Initial Comment: should == still works ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-08 01:17 Message: This is really a doc issue. Here is what is supported: should == should_not == should be > should be >= should be <= should be < I'll make sure the docs are clear. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-07 23:27 Message: should < and should <= doesn't work either. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 From noreply at rubyforge.org Mon May 7 22:13:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 22:13:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10669 ] Kernel#describe override does not cover Kernel#context Message-ID: <20070508021347.EEA865240BB3@rubyforge.org> Bugs item #10669, was opened at 2007-05-07 23:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10669&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: Kernel#describe override does not cover Kernel#context Initial Comment: This makes Rails specs not work because the spec_path option is not used. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10669&group_id=797 From noreply at rubyforge.org Mon May 7 23:06:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 23:06:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10669 ] Kernel#describe override does not cover Kernel#context Message-ID: <20070508030651.576635240B99@rubyforge.org> Bugs item #10669, was opened at 2007-05-07 23:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10669&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: David Chelimsky (dchelimsky) Summary: Kernel#describe override does not cover Kernel#context Initial Comment: This makes Rails specs not work because the spec_path option is not used. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-08 03:06 Message: Fixed in rev 1930. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10669&group_id=797 From noreply at rubyforge.org Mon May 7 23:35:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 23:35:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10670 ] IVarProxy#delete raises exception when instance variable does not exist Message-ID: <20070508033548.6E6DB5240C2F@rubyforge.org> Bugs item #10670, was opened at 2007-05-07 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: Brian Takita (btakita) Summary: IVarProxy#delete raises exception when instance variable does not exist Initial Comment: This causes issues with Markaby. It should just return nil. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 From noreply at rubyforge.org Mon May 7 23:39:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 23:39:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10672 ] Setting Spec::Runner.configure fixture_path doesn't seem to work Message-ID: <20070508033959.74BC05240C2F@rubyforge.org> Bugs item #10672, was opened at 2007-05-07 23:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10672&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Setting Spec::Runner.configure fixture_path doesn't seem to work Initial Comment: Spec::Runner.configure do |config| config.use_transactional_fixtures = true config.use_instantiated_fixtures = false config.fixture_path = RAILS_ROOT + '/test/fixtures' # config.global_fixtures = :table_a, :table_b end module Spec module Rails module Runner class EvalContext < Test::Unit::TestCase # When the next line is uncommented, the specs work # self.fixture_path = RAILS_ROOT + '/test/fixtures' extend DisabledSpecs include CommunityPatentSpecHelper include RjsSpecHelper end end end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-08 03:39 Message: I think this is an update problem. There is no longer a Spec::Rails::Runner::EvalContext being used (so I'm not sure what's going on with your example). I just created a brand new rails 1.2.3 app w/ rspec rev 1930, created an rspec_resource, migrated, watched the specs pass, moved fixtures to /test/fixtures, watched the specs fail, changed the fixture path accordingly, watched the specs pass. One problem I see is that you're extending w/ DisabledSpecs. Right now there is no support for extend in config (i.e. config.extend DisabledSpecs), but I think you can this: module DisabledSpecs def included(mod) mod extend(self) end .. end Or something similar. Please report back after playing w/ this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10672&group_id=797 From noreply at rubyforge.org Mon May 7 23:56:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 23:56:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10670 ] IVarProxy#delete raises exception when instance variable does not exist Message-ID: <20070508035646.9ACB85240C2F@rubyforge.org> Bugs item #10670, was opened at 2007-05-07 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: IVarProxy#delete raises exception when instance variable does not exist Initial Comment: This causes issues with Markaby. It should just return nil. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-07 20:56 Message: Fixed in rev. 1931 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 From noreply at rubyforge.org Mon May 7 23:58:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 May 2007 23:58:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10670 ] IVarProxy#delete raises exception when instance variable does not exist Message-ID: <20070508035841.3FC565240C2F@rubyforge.org> Bugs item #10670, was opened at 2007-05-07 16:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 Category: None Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: IVarProxy#delete raises exception when instance variable does not exist Initial Comment: This causes issues with Markaby. It should just return nil. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-07 20:56 Message: Fixed in rev. 1931 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10670&group_id=797 From noreply at rubyforge.org Tue May 8 00:03:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 00:03:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10681 ] Documentation for should have_rjs Message-ID: <20070508040326.B19EE5240C2F@rubyforge.org> Feature Requests item #10681, was opened at 2007-05-07 21:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10681&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Documentation for should have_rjs Initial Comment: I could not figure out how to use it and got unexplainable exceptions. A simple example would be great. I will post the exception later. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10681&group_id=797 From noreply at rubyforge.org Tue May 8 00:55:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 00:55:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10681 ] Documentation for should have_rjs Message-ID: <20070508045549.732655240C37@rubyforge.org> Feature Requests item #10681, was opened at 2007-05-08 04:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10681&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Documentation for should have_rjs Initial Comment: I could not figure out how to use it and got unexplainable exceptions. A simple example would be great. I will post the exception later. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-08 04:55 Message: have_rjs wraps assert_select_rjs. We should improve our docs if you're having trouble understanding, but in the mean time you can take a look at http://api.rubyonrails.com/classes/ActionController/Assertions/SelectorAssertions.html#M000209 and you might find your answer there. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10681&group_id=797 From noreply at rubyforge.org Tue May 8 02:30:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 02:30:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10673 ] should > and should > = broken Message-ID: <20070508063009.C79285240C46@rubyforge.org> Bugs item #10673, was opened at 2007-05-07 19:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: should > and should >= broken Initial Comment: should == still works ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-08 02:30 Message: I got bitten by the same thing the other day. It was very unintuitive to me to have to put the be in front. Is it possible to lose the "be" for these? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-07 21:17 Message: This is really a doc issue. Here is what is supported: should == should_not == should be > should be >= should be <= should be < I'll make sure the docs are clear. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-07 19:27 Message: should < and should <= doesn't work either. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 From noreply at rubyforge.org Tue May 8 02:34:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 02:34:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6510 ] Named routes in controller specs Message-ID: <20070508063410.A5E185240C46@rubyforge.org> Feature Requests item #6510, was opened at 2006-11-06 03:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: Named routes in controller specs Initial Comment: [from RFE 5719 - Jonathan del Strother] Being able to use named routes would be extremely useful - eg "get accounts_url" or "delete account_url(@account)" (though it's perhaps worth noting that this doesn't even work in Rails' functional tests - you have to use integration tests if you want this to work) (this is a dup of 6501, but I was unable to move it from tracker to tracker, so I deleted that one and added this one) ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-08 06:34 Message: Doesn't this work now? ---------------------------------------------------------------------- Comment By: David Goodlad (dgoodlad) Date: 2007-03-01 20:20 Message: I've just run into this issue, although it's because I'm trying to spec out my named routes. It seems that ActionController::Base's normal behavior of using the current url's options and merging them with whatever is generated in url_for doesn't work, since AC::Base needs to have @url set to do that. I worked around the problem in this case by doing a simple 'get' on one of my actions in setup first, but this is an ugly solution. We should have a way of specifying that the controller's "current url" is already set to something... ---------------------------------------------------------------------- Comment By: Rodrigo Kochenburger (divoxx) Date: 2007-03-01 16:15 Message: I think this must be fixed. Mostly because having some redirect_to some_url in the controller will also break the spec. So it's not really a spec needs, but controller execution need. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797 From noreply at rubyforge.org Tue May 8 14:46:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 14:46:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10695 ] Add fixtures method in shared specs Message-ID: <20070508184649.C94965240A9A@rubyforge.org> Feature Requests item #10695, was opened at 2007-05-08 11:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10695&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Add fixtures method in shared specs Initial Comment: Something like this: describe "comment/_new_comment", :shared => true, :behaviour_type => "view" do fixtures :patent_applications end describe "comment/_new_comment", "logged in" do it_should_behave_like "comment/_new_comment" end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10695&group_id=797 From noreply at rubyforge.org Tue May 8 14:53:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 14:53:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10696 ] before(:all) and after(:all) should be instance_evaled in the EvalModule object Message-ID: <20070508185316.18F2A5240A9A@rubyforge.org> Feature Requests item #10696, was opened at 2007-05-08 11:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10696&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: before(:all) and after(:all) should be instance_evaled in the EvalModule object Initial Comment: This would allow methods such as 'fixtures' to be called in before(:all) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10696&group_id=797 From noreply at rubyforge.org Tue May 8 15:00:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 15:00:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10697 ] Consider renaming 'describe' method to 'behaviour' Message-ID: <20070508190009.009F75240AE3@rubyforge.org> Feature Requests item #10697, was opened at 2007-05-08 12:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Consider renaming 'describe' method to 'behaviour' Initial Comment: It would be conducive to conversations if I didn't need to do a mental mapping from describe to behaviour. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 From noreply at rubyforge.org Tue May 8 15:48:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 15:48:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6510 ] Named routes in controller specs Message-ID: <20070508194857.C931E5240A88@rubyforge.org> Feature Requests item #6510, was opened at 2006-11-06 03:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: Named routes in controller specs Initial Comment: [from RFE 5719 - Jonathan del Strother] Being able to use named routes would be extremely useful - eg "get accounts_url" or "delete account_url(@account)" (though it's perhaps worth noting that this doesn't even work in Rails' functional tests - you have to use integration tests if you want this to work) (this is a dup of 6501, but I was unable to move it from tracker to tracker, so I deleted that one and added this one) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-08 19:48 Message: Yes, it does. Closing this. Cheers, David ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-08 06:34 Message: Doesn't this work now? ---------------------------------------------------------------------- Comment By: David Goodlad (dgoodlad) Date: 2007-03-01 20:20 Message: I've just run into this issue, although it's because I'm trying to spec out my named routes. It seems that ActionController::Base's normal behavior of using the current url's options and merging them with whatever is generated in url_for doesn't work, since AC::Base needs to have @url set to do that. I worked around the problem in this case by doing a simple 'get' on one of my actions in setup first, but this is an ugly solution. We should have a way of specifying that the controller's "current url" is already set to something... ---------------------------------------------------------------------- Comment By: Rodrigo Kochenburger (divoxx) Date: 2007-03-01 16:15 Message: I think this must be fixed. Mostly because having some redirect_to some_url in the controller will also break the spec. So it's not really a spec needs, but controller execution need. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797 From noreply at rubyforge.org Tue May 8 15:52:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 15:52:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10698 ] Running with --drb executes specs twice (fix included) Message-ID: <20070508195204.E81645240A88@rubyforge.org> Patches item #10698, was opened at 2007-05-08 12:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ruy Asan (rubyruy) Assigned to: Nobody (None) Summary: Running with --drb executes specs twice (fix included) Initial Comment: Finally tracked this down to the fact that the $behavior_runner doesn't return nil as it should when running with --drb. This ends up causing each spec to be ran once with drb and then once more without (which makes everything slow and annoying). This in turn happens because of a missing return statement in options_parser.rb at least from what I can tell. Spec included and passes (fails without the patch) - not sure I used the correct style but hey, it works. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 From noreply at rubyforge.org Tue May 8 16:00:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 May 2007 16:00:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10699 ] Shared Behaviour error message should include the Behaviour that is using it Message-ID: <20070508200035.2B1C35240A9A@rubyforge.org> Feature Requests item #10699, was opened at 2007-05-08 13:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10699&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Shared Behaviour error message should include the Behaviour that is using it Initial Comment: describe "shared" do it "fails" do fail end end describe "consumer" do it_should_behave_like "shared" end Here is the error message: 'shared fails' FAILED Is would be useful if it where something like: 'consumer - shared fails' FAILED ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10699&group_id=797 From noreply at rubyforge.org Wed May 9 03:38:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 03:38:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10697 ] Consider renaming 'describe' method to 'behaviour' Message-ID: <20070509073829.30A7C5240C46@rubyforge.org> Feature Requests item #10697, was opened at 2007-05-08 12:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Consider renaming 'describe' method to 'behaviour' Initial Comment: It would be conducive to conversations if I didn't need to do a mental mapping from describe to behaviour. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-09 00:38 Message: I do have to say that the new syntax encourages me to mention Behaviour more than the old syntax. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 From noreply at rubyforge.org Wed May 9 04:13:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 04:13:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10697 ] Consider renaming 'describe' method to 'behaviour' Message-ID: <20070509081318.DA3C85240C41@rubyforge.org> Feature Requests item #10697, was opened at 2007-05-08 19:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Consider renaming 'describe' method to 'behaviour' Initial Comment: It would be conducive to conversations if I didn't need to do a mental mapping from describe to behaviour. ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-05-09 08:13 Message: Brian, I think 3rd alias for one method will be too confusing for newcomers. Especially for those who start from 0.9.x but still see 0.8.x tutorials. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-09 07:38 Message: I do have to say that the new syntax encourages me to mention Behaviour more than the old syntax. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 From noreply at rubyforge.org Wed May 9 05:34:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 05:34:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10697 ] Consider renaming 'describe' method to 'behaviour' Message-ID: <20070509093455.25518524098A@rubyforge.org> Feature Requests item #10697, was opened at 2007-05-08 15:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Consider renaming 'describe' method to 'behaviour' Initial Comment: It would be conducive to conversations if I didn't need to do a mental mapping from describe to behaviour. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-09 05:34 Message: Consider: "describe big stone, it should be heavy" versus "behaviour big stone, it should be heavy" Specs should provide users with a language that almost forces them to write examples of behaviour of some known state. I'm concerned that "behaviour" will give too much room for bad styles and it doesn't read so well either. ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-05-09 04:13 Message: Brian, I think 3rd alias for one method will be too confusing for newcomers. Especially for those who start from 0.9.x but still see 0.8.x tutorials. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-09 03:38 Message: I do have to say that the new syntax encourages me to mention Behaviour more than the old syntax. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 From noreply at rubyforge.org Wed May 9 10:36:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 10:36:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10718 ] Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Message-ID: <20070509143631.9B68D5240AC1@rubyforge.org> Feature Requests item #10718, was opened at 2007-05-09 10:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Initial Comment: It would be great if we could pass arbitrary variables into the shared behavior specs, for things such as differing controller actions. Right now, I'm having to do the following: before(:all) do @action = "foo" end it_should_behave_like "CRUD" Instead, I could imagine something like the following, a la partial locals: it_should_behave_like "CRUD", :locals => { :action => "foo" } ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 From noreply at rubyforge.org Wed May 9 11:10:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 11:10:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10718 ] Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Message-ID: <20070509151032.B01685240A5B@rubyforge.org> Feature Requests item #10718, was opened at 2007-05-09 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Initial Comment: It would be great if we could pass arbitrary variables into the shared behavior specs, for things such as differing controller actions. Right now, I'm having to do the following: before(:all) do @action = "foo" end it_should_behave_like "CRUD" Instead, I could imagine something like the following, a la partial locals: it_should_behave_like "CRUD", :locals => { :action => "foo" } ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 15:10 Message: Interesting idea but there's a disconnect. Locals are actually slung over to another scope (the partial), whereas shared examples are all executed in the same scope as any non-shared examples. It's, conceptually, a different animal, that will surely lead to confusion when you start doing this: describe Thing do before(:each) do @thing = Thing.new(:some_state) end it_should_behave_like "other things", :locals => { :thing => Thing.new(:some_other_state) } it "should do something unique" do @thing.should write_novels end end In this case, both assignments to @thing happen in the same context, so the last one executed wins. I, personally, would rather not have to debug that scenario. Other thoughts? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 From noreply at rubyforge.org Wed May 9 11:19:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 11:19:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10718 ] Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Message-ID: <20070509151943.68EDF52409E6@rubyforge.org> Feature Requests item #10718, was opened at 2007-05-09 10:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Initial Comment: It would be great if we could pass arbitrary variables into the shared behavior specs, for things such as differing controller actions. Right now, I'm having to do the following: before(:all) do @action = "foo" end it_should_behave_like "CRUD" Instead, I could imagine something like the following, a la partial locals: it_should_behave_like "CRUD", :locals => { :action => "foo" } ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-05-09 11:19 Message: how would @thing be assigned in the call to it_should_behave_like in your example? I was imagining that a local 'thing' variable would get assigned, perhaps with block locals. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 11:10 Message: Interesting idea but there's a disconnect. Locals are actually slung over to another scope (the partial), whereas shared examples are all executed in the same scope as any non-shared examples. It's, conceptually, a different animal, that will surely lead to confusion when you start doing this: describe Thing do before(:each) do @thing = Thing.new(:some_state) end it_should_behave_like "other things", :locals => { :thing => Thing.new(:some_other_state) } it "should do something unique" do @thing.should write_novels end end In this case, both assignments to @thing happen in the same context, so the last one executed wins. I, personally, would rather not have to debug that scenario. Other thoughts? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 From noreply at rubyforge.org Wed May 9 12:45:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 12:45:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10697 ] Consider renaming 'describe' method to 'behaviour' Message-ID: <20070509164533.6702B5240AA6@rubyforge.org> Feature Requests item #10697, was opened at 2007-05-08 12:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Consider renaming 'describe' method to 'behaviour' Initial Comment: It would be conducive to conversations if I didn't need to do a mental mapping from describe to behaviour. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-09 09:45 Message: That makes sense. I think it will get easier calling describe blocks behaviour. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-09 02:34 Message: Consider: "describe big stone, it should be heavy" versus "behaviour big stone, it should be heavy" Specs should provide users with a language that almost forces them to write examples of behaviour of some known state. I'm concerned that "behaviour" will give too much room for bad styles and it doesn't read so well either. ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-05-09 01:13 Message: Brian, I think 3rd alias for one method will be too confusing for newcomers. Especially for those who start from 0.9.x but still see 0.8.x tutorials. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-09 00:38 Message: I do have to say that the new syntax encourages me to mention Behaviour more than the old syntax. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10697&group_id=797 From noreply at rubyforge.org Wed May 9 18:38:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 18:38:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10673 ] should > and should > = broken Message-ID: <20070509223843.EFAAD5240AC2@rubyforge.org> Bugs item #10673, was opened at 2007-05-07 23:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: should > and should >= broken Initial Comment: should == still works ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 22:38 Message: Anything's posssible, but it doesn't read as well that way: "5 should greater than 3"???? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-08 06:30 Message: I got bitten by the same thing the other day. It was very unintuitive to me to have to put the be in front. Is it possible to lose the "be" for these? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-08 01:17 Message: This is really a doc issue. Here is what is supported: should == should_not == should be > should be >= should be <= should be < I'll make sure the docs are clear. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-07 23:27 Message: should < and should <= doesn't work either. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 From noreply at rubyforge.org Wed May 9 18:44:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 18:44:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070509224424.E2E725240AC2@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 23:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 22:44 Message: Hi Larry - what I'm looking for is not the args, but the options: puts opts.inspect or puts pp(opts) Thanks ---------------------------------------------------------------------- Comment By: Larry Kluger (larrykluger) Date: 2007-05-06 20:22 Message: Hi, I changed behaviour_factory.rb to be: def create(*args, &block) opts = Hash === args.last ? args.last : {} require 'pp' puts pp(args) if opts[:shared] .... Here is the output: ["/session/new GET"] nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb :95:in `method_missing': undefined method `controller_name' for # ( NoMethodError) .... Larry ---------------------------------------------------------------------- Comment By: Larry Kluger (larrykluger) Date: 2007-05-06 20:13 Message: Hi David, I've deleted the rspec gem and plugin. I then installed ver 0.9.3 as plugins per the installation instructions. I added the puts as requested the result was nil, see trace. Aslak, where do I put the lines describe MyController, :behaviour_type => :controller do end ? I tried describe "SessionController", :behaviour_type => :controller do end just after the require statement in my session_controller_spec.rb but received the same problem. Thank you for your help and time on this puzzler. Larry C:\instant_rails_1.7\InstantRails\rails_apps\am2>ruby script/spec spec/controllers/session_controller_spec.rb nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `create' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 C:\instant_rails_1.7\InstantRails\rails_apps\am2> ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 11:52 Message: "However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X." Now THAT would make sense. Larry, would you kindly apply the patch below, run `script/spec spec/controllers/session_controller_spec.rb` and show us the output? Thanks Index: rspec_on_rails/lib/spec/dsl/behaviour_factory.rb =================================================================== --- rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (revision 1893) +++ rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (working copy) @@ -31,6 +31,7 @@ # describe "name", :behaviour_type => :view ... def create(*args, &block) opts = Hash === args.last ? args.last : {} + puts opts[:spec_path] if opts[:shared] key = :default elsif opts[:behaviour_type] ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 11:44 Message: There shouldn't be any need to support Windows style paths with \. Ruby will always report forward slashes for paths, even on Windows. I don't think Regexp support is different on Windows either, that would never slip through the Ruby community. However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 11:12 Message: Here's the regexp used to determine the path: /spec(\/|\)+(view|helper|controller|model)s/ The (\/|\) is there to support /unix/style and \windows\style paths. This used be to expressed in 4 separate regexps and this release merged them into one. The specs that describe windows style paths still pass, but I'm running them on *nix. Could there be a difference in the way windows is handling regexps? Also, please try this one windows as well: script/spec spec/controllers/session_controller_spec.rb and let us know if you get the same result. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 10:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 10:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From noreply at rubyforge.org Wed May 9 19:56:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 19:56:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10731 ] response.should be_a_success Message-ID: <20070509235640.7179E5240AB9@rubyforge.org> Patches item #10731, was opened at 2007-05-09 23:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: response.should be_a_success Initial Comment: The current rails controller/resource generators output code like the following: response.should be_success I think it reads much better like this: response.should be_a_success This is a tiny little patch that changes those instances in the generators ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 From noreply at rubyforge.org Wed May 9 21:20:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 May 2007 21:20:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10534 ] Windows: undefined method `controller_name' Message-ID: <20070510012003.2F3D75240A79@rubyforge.org> Bugs item #10534, was opened at 2007-05-02 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kluger (larrykluger) Assigned to: Nobody (None) Summary: Windows: undefined method `controller_name' Initial Comment: Running 0.9.1 on windows -- (InstantRails with updated rails and other gems) gives following trace (below). I have updated to all the latest gems and plugins as of today, May 2, 07. The exact same svn tree on Linux works fine for rake spec I think something is not requiring the right modules due to Window's back slashes. Regards, LarryK ~~~~~~~~~~~~~~~ Trace followed by list of installed gems > rake spec C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/dsl/ behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec /dsl/behaviour_factory.rb:43:in `create' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 ... 14 levels... from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:261:in `parse' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/option_parser.rb:28:in `create_behaviour_runner' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib/spec/runn er/command_line.rb:14:in `run' from C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec:3 rake aborted! Command ruby -I"C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/lib" "C:/i nstant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/rspec-0.9.1/bin/spec" "spec/controllers/se ssion_controller_spec.rb" "spec/controllers/users_controller_spec.rb" "spec/controllers/user_assets_ controller_spec.rb" "spec/helpers/user_assets_helper_spec.rb" "spec/helpers/user_assets_url_helpers_ spec.rb" "spec/models/asset_spec.rb" "spec/models/authenticated_base_spec.rb" "spec/models/user_spec .rb" "spec/views/assets/edit_rhtml_spec.rb" "spec/views/assets/index_rhtml_spec.rb" "spec/views/asse ts/new_rhtml_spec.rb" "spec/views/assets/show_rhtml_spec.rb" "spec/views/users/edit_rhtml_spec.rb" " spec/views/users/index_rhtml_spec.rb" "spec/views/users/new_rhtml_spec.rb" "spec/views/users/show_rh tml_spec.rb" --options "C:/instant_rails_1.7/InstantRails/rails_apps/am2/config/../spec/spec.opts" failed C:\instant_rails_1.7\InstantRails\rails_apps\am2>gem list --local *** LOCAL GEMS *** actionmailer (1.3.3) Service layer for easy email delivery and testing. actionpack (1.13.3) Web-flow and rendering framework putting the VC in MVC. actionwebservice (1.2.3) Web service support for Action Pack. activerecord (1.15.3) Implements the ActiveRecord pattern for ORM. activesupport (1.4.2) Support and utility classes used by the Rails framework. capistrano (1.4.1) Capistrano is a framework and utility for executing commands in parallel on multiple remote machines, via SSH. The primary goal is to simplify and automate the deployment of web applications. cgi_multipart_eof_fix (2.1) Fix an exploitable bug in CGI multipart parsing which affects Ruby <= 1.8.5 when multipart boundary attribute contains a non-halting regular expression string. cmdparse (2.0.2) Advanced command line parser supporting commands fxri (0.3.6) Graphical interface to the RI documentation, with search engine. fxruby (1.6.6) FXRuby is the Ruby binding to the FOX GUI toolkit. gem_plugin (0.2.2) A plugin system based only on rubygems that uses dependencies only highline (1.2.7) HighLine is a high-level command-line IO library. hpricot (0.4) a swift, liberal HTML parser with a fantastic library log4r (1.0.5) Log4r is a comprehensive and flexible logging library for Ruby. mongrel (1.0.1) A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps. mongrel_cluster (0.2.1) Mongrel plugin that provides commands and Capistrano tasks for managing multiple Mongrel processes. mysql (2.7.3) A win32-native build of the MySQL API module for Ruby. needle (1.3.0) Needle is a Dependency Injection/Inversion of Control container for Ruby. It supports both type-2 (setter) and type-3 (constructor) injection. It takes advantage of the dynamic nature of Ruby to provide a rich and flexible approach to injecting dependencies. net-sftp (1.1.0) Net::SFTP is a pure-Ruby implementation of the SFTP client protocol. net-ssh (1.0.10) Net::SSH is a pure-Ruby implementation of the SSH2 client protocol. piston (1.3.3) Piston is a utility that enables merge tracking of remote repositories. rails (1.2.3) Web-application framework with template engine, control-flow layer, and ORM. rake (0.7.2) Ruby based make-like utility. rcov (0.8.0.2) Code coverage analysis tool for Ruby rmagick (1.14.1) RMagick is an interface between the Ruby programming language and the ImageMagick and GraphicsMagick image processing libraries. rspec (0.9.1, 0.8.2) RSpec-0.9.1 (r1880) - BDD for Ruby http://rspec.rubyforge.org/ sources (0.0.1) This package provides download sources for remote gem installation win32-clipboard (0.4.1) A package for interacting with the Windows clipboard win32-dir (0.3.1) Extra constants and methods for the Dir class on Windows. win32-eventlog (0.4.3) Interface for the MS Windows Event Log. win32-file (0.5.3) Extra or redefined methods for the File class on Windows. win32-file-stat (1.2.3) A File::Stat class tailored to MS Windows win32-process (0.5.1) Adds fork, wait, wait2, waitpid, waitpid2 and a special kill method win32-sapi (0.1.3) An interface to the MS SAPI (Sound API) library. win32-sound (0.4.0) A package for playing with sound on Windows. win32console (1.0.8) A library giving the Win32 console ANSI escape sequence support. windows-pr (0.6.2) Windows functions and constants predefined via Win32API ---------------------------------------------------------------------- >Comment By: Larry Kluger (larrykluger) Date: 2007-05-09 21:20 Message: Hi David, nil seems a bit boring. Please let me know how I can further help track this down. I'm at your service. Larry Source: def create(*args, &block) opts = Hash === args.last ? args.last : {} require 'pp' puts pp(opts) if opts[:shared] key = :default .... result: C:\instant_rails_1.7\InstantRails\rails_apps\am2>ruby script/spec spec/controllers/session_controlle r_spec.rb /config/../vendor/plugins/acts_as_wizard/lib/wizard_setup_filter.rb:2) {} nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:6 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `class_eval' .... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 18:44 Message: Hi Larry - what I'm looking for is not the args, but the options: puts opts.inspect or puts pp(opts) Thanks ---------------------------------------------------------------------- Comment By: Larry Kluger (larrykluger) Date: 2007-05-06 16:22 Message: Hi, I changed behaviour_factory.rb to be: def create(*args, &block) opts = Hash === args.last ? args.last : {} require 'pp' puts pp(args) if opts[:shared] .... Here is the output: ["/session/new GET"] nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb :95:in `method_missing': undefined method `controller_name' for # ( NoMethodError) .... Larry ---------------------------------------------------------------------- Comment By: Larry Kluger (larrykluger) Date: 2007-05-06 16:13 Message: Hi David, I've deleted the rspec gem and plugin. I then installed ver 0.9.3 as plugins per the installation instructions. I added the puts as requested the result was nil, see trace. Aslak, where do I put the lines describe MyController, :behaviour_type => :controller do end ? I tried describe "SessionController", :behaviour_type => :controller do end just after the require statement in my session_controller_spec.rb but received the same problem. Thank you for your help and time on this puzzler. Larry C:\instant_rails_1.7\InstantRails\rails_apps\am2>ruby script/spec spec/controllers/session_controller_spec.rb nil C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:95:in `method_missing': undefined method `controller_name' for # (NoMethodError) from ./spec/controllers/session_controller_spec.rb:4 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `class_eval' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:47:in `eval_behaviour' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:29:in `initialize' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `new' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec_on_rails/lib/spec/dsl/behaviour_factory.rb:44:in `create' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:4:in `context' from ./spec/controllers/session_controller_spec.rb:3 from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `each' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:22:in `run' from C:/instant_rails_1.7/InstantRails/rails_apps/am2/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from script/spec:4 C:\instant_rails_1.7\InstantRails\rails_apps\am2> ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 07:52 Message: "However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X." Now THAT would make sense. Larry, would you kindly apply the patch below, run `script/spec spec/controllers/session_controller_spec.rb` and show us the output? Thanks Index: rspec_on_rails/lib/spec/dsl/behaviour_factory.rb =================================================================== --- rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (revision 1893) +++ rspec_on_rails/lib/spec/dsl/behaviour_factory.rb (working copy) @@ -31,6 +31,7 @@ # describe "name", :behaviour_type => :view ... def create(*args, &block) opts = Hash === args.last ? args.last : {} + puts opts[:spec_path] if opts[:shared] key = :default elsif opts[:behaviour_type] ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 07:44 Message: There shouldn't be any need to support Windows style paths with \. Ruby will always report forward slashes for paths, even on Windows. I don't think Regexp support is different on Windows either, that would never slip through the Ruby community. However, I think maybe the call to caller might yield slightly different values on Windows and Linux/OS X. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-06 07:12 Message: Here's the regexp used to determine the path: /spec(\/|\)+(view|helper|controller|model)s/ The (\/|\) is there to support /unix/style and \windows\style paths. This used be to expressed in 4 separate regexps and this release merged them into one. The specs that describe windows style paths still pass, but I'm running them on *nix. Could there be a difference in the way windows is handling regexps? Also, please try this one windows as well: script/spec spec/controllers/session_controller_spec.rb and let us know if you get the same result. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:24 Message: I think the source of this bug is in rspec_on_rails/lib/spec/rails/extensions/kernel.rb This is where Spec::Rails tries to guess what kind of spec this is. Perhaps this behaves differently on windows? Could you investigate this please? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-06 06:10 Message: Hint: Spec::Rails mixes in different modules for specs depending on whether it thinks it is a model spec, controller spec, view spec or helper spec. Your error tells me that the controller mixin wasn't included. RSpec decides what to mix in by looking at the folder of your spec. If it's under spec/controllers this should happen automatically (and apparently this is buggy on windows). Just to verify this theory (and work around it until a fix has been committed), you could try to be explicit about it: describe MyController, :behaviour_type => :controller do end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10534&group_id=797 From aslak.hellesoy at gmail.com Thu May 10 06:57:50 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 10 May 2007 12:57:50 +0200 Subject: [rspec-devel] [ANN] RSpec 0.9.4 Message-ID: <8d961d900705100357r5c7c217ay364039a71829e52c@mail.gmail.com> RSpec 0.9.4 has just been released. Gems haven't rsync'ed around the globe yet, so you might have to wait a few hours to install it. The big news this time is Spec::Ui 0.2.0, which has been released along with RSpec core. This RSpec extension gives you custom Watir matchers (custom Selenium-RC matchers are not implemented yet). Moreover, it comes with a custom KICK ASS formatter that, for each failing example, puts a screenshot of your browser - and its HTML source - straight into the report. And it all gets embedded into one single HTML file. Spec::Ui is not documented on the website yet (there are some READMEs and examples in the source though). But here is the gist of it: == Install == gem install rspec -r 0.9.4 gem install spec_ui -r 0.2.0 === Windows users - if you want screenshots === gem install win32screenshot Install RMagick (special install procedure) == Configure == === Rakefile === require 'spec/rake/spectask' desc "Run UI Specs" Spec::Rake::SpecTask.new('spec:ui') do |t| t.spec_files = FileList['spec/**/*.rb'] t.spec_opts = [ '--require', 'spec/spec_helper', '--format', 'Spec::Ui::ScreenshotFormatter:spec_report.html', '--format', 'progress', ] end === spec_helper.rb === # require this file from all your specs under MYAPP/spec/watir or MYAPP/spec/selenium require 'rubygems' require 'spec' require 'spec/ui' require 'spec/ui/watir' class Spec::DSL::Behaviour def before_eval # This gives us Watir matchers. Sorry - Selenium-RC users must use the low level API include Spec::Matchers::Watir end end === before and after blocks === All of your specs need some carefully designed before and after blocks: before(:all) do @browser = Watir::Browser.new #@browser = Selenium::SeleniumDriver.new("localhost", 4444, "*safari", "http://www.google.no", 10000) end after(:each) do # This is needed to make screenshots work Spec::Ui::ScreenshotFormatter.browser = @browser end after(:all) do @browser.kill! rescue nil end From noreply at rubyforge.org Thu May 10 08:05:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 08:05:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10698 ] Running with --drb executes specs twice (fix included) Message-ID: <20070510120557.7A6A0524097E@rubyforge.org> Patches item #10698, was opened at 2007-05-08 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ruy Asan (rubyruy) Assigned to: Nobody (None) Summary: Running with --drb executes specs twice (fix included) Initial Comment: Finally tracked this down to the fact that the $behavior_runner doesn't return nil as it should when running with --drb. This ends up causing each spec to be ran once with drb and then once more without (which makes everything slow and annoying). This in turn happens because of a missing return statement in options_parser.rb at least from what I can tell. Spec included and passes (fails without the patch) - not sure I used the correct style but hey, it works. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 12:05 Message: Aslak/David - Do you think you could look at this patch? Right now I can't use DRB and my rails specs are taking about 20 seconds to run ...TOO Slow! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 From noreply at rubyforge.org Thu May 10 08:10:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 08:10:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10698 ] Running with --drb executes specs twice (fix included) Message-ID: <20070510121049.A1CAD524097E@rubyforge.org> Patches item #10698, was opened at 2007-05-08 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ruy Asan (rubyruy) Assigned to: Nobody (None) Summary: Running with --drb executes specs twice (fix included) Initial Comment: Finally tracked this down to the fact that the $behavior_runner doesn't return nil as it should when running with --drb. This ends up causing each spec to be ran once with drb and then once more without (which makes everything slow and annoying). This in turn happens because of a missing return statement in options_parser.rb at least from what I can tell. Spec included and passes (fails without the patch) - not sure I used the correct style but hey, it works. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-10 12:10 Message: Sure we can look at it, by why would you want to wait for us? Download the patch yourself and try it!!! ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 12:05 Message: Aslak/David - Do you think you could look at this patch? Right now I can't use DRB and my rails specs are taking about 20 seconds to run ...TOO Slow! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 From noreply at rubyforge.org Thu May 10 09:31:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 09:31:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10698 ] Running with --drb executes specs twice (fix included) Message-ID: <20070510133119.3C492524099A@rubyforge.org> Patches item #10698, was opened at 2007-05-08 15:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ruy Asan (rubyruy) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Running with --drb executes specs twice (fix included) Initial Comment: Finally tracked this down to the fact that the $behavior_runner doesn't return nil as it should when running with --drb. This ends up causing each spec to be ran once with drb and then once more without (which makes everything slow and annoying). This in turn happens because of a missing return statement in options_parser.rb at least from what I can tell. Spec included and passes (fails without the patch) - not sure I used the correct style but hey, it works. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 09:31 Message: Applied in r1940 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-10 08:10 Message: Sure we can look at it, by why would you want to wait for us? Download the patch yourself and try it!!! ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 08:05 Message: Aslak/David - Do you think you could look at this patch? Right now I can't use DRB and my rails specs are taking about 20 seconds to run ...TOO Slow! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 From noreply at rubyforge.org Thu May 10 09:32:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 09:32:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10698 ] Running with --drb executes specs twice (fix included) Message-ID: <20070510133247.88D78524099A@rubyforge.org> Patches item #10698, was opened at 2007-05-08 19:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 Category: runner module Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Ruy Asan (rubyruy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Running with --drb executes specs twice (fix included) Initial Comment: Finally tracked this down to the fact that the $behavior_runner doesn't return nil as it should when running with --drb. This ends up causing each spec to be ran once with drb and then once more without (which makes everything slow and annoying). This in turn happens because of a missing return statement in options_parser.rb at least from what I can tell. Spec included and passes (fails without the patch) - not sure I used the correct style but hey, it works. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-10 13:32 Message: Or get Aslak to look at it! ;) Thanks Aslak. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:31 Message: Applied in r1940 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-10 12:10 Message: Sure we can look at it, by why would you want to wait for us? Download the patch yourself and try it!!! ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 12:05 Message: Aslak/David - Do you think you could look at this patch? Right now I can't use DRB and my rails specs are taking about 20 seconds to run ...TOO Slow! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10698&group_id=797 From noreply at rubyforge.org Thu May 10 09:34:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 09:34:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10731 ] response.should be_a_success Message-ID: <20070510133445.AE5CA524099A@rubyforge.org> Patches item #10731, was opened at 2007-05-09 19:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: response.should be_a_success Initial Comment: The current rails controller/resource generators output code like the following: response.should be_success I think it reads much better like this: response.should be_a_success This is a tiny little patch that changes those instances in the generators ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 09:34 Message: I think be_a_success looks more cluttered than be_success ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 From noreply at rubyforge.org Thu May 10 09:35:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 09:35:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070510133541.B3ED5524099A@rubyforge.org> Patches item #10574, was opened at 2007-05-04 11:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 09:35 Message: What's the purpose of this refactoring? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 11:37 Message: Just a quick heads up before I look at this. I just removed the call to config.breakpoint_server, so that shouldn't be an issue any more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From noreply at rubyforge.org Thu May 10 09:41:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 09:41:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10645 ] removal of --examples when appropriate Message-ID: <20070510134127.08BB2524099A@rubyforge.org> Patches item #10645, was opened at 2007-05-07 01:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: removal of --examples when appropriate Initial Comment: See ticket: #10545 "Removal of --options when appropriate" http://rubyforge.org/tracker/index.php?func=detail&aid=10545&group_id=797&atid=3151 David/Aslak: I added a an attribute reader for @where in the base text formatter, and called the method output. Feel free to change this as you wish. It is only referenced in the Options class, under the method I've added: remove_extraneous_examples! ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 09:41 Message: I'm not so keen on applying this. It seems like a complicated solution to a simple problem. An easier solution is this: $ touch previous_failures.txt ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 From noreply at rubyforge.org Thu May 10 11:24:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 11:24:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070510152431.6667F52409BA@rubyforge.org> Patches item #10574, was opened at 2007-05-04 18:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- >Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-10 18:24 Message: The purpose is to add specs to it so that we know that we don't break it when we change it. In the original form, it was too complicated to spec in a reasonable manner. For an example of the type of problems that can go unnoticed without specs, see patch 10315. http://rubyforge.org/tracker/index.php?func=detail&aid=10315&group_id=797&atid=3151 In my opinion, although it is "just" the build code it should not be left unspecced. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 16:35 Message: What's the purpose of this refactoring? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 18:37 Message: Just a quick heads up before I look at this. I just removed the call to config.breakpoint_server, so that shouldn't be an issue any more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From noreply at rubyforge.org Thu May 10 11:58:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 11:58:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-9287 ] Add regular expression support to --spec switch Message-ID: <20070510155826.28C2C52409D6@rubyforge.org> Feature Requests item #9287, was opened at 2007-03-14 15:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9287&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Add regular expression support to --spec switch Initial Comment: Hello, As a means of getting around the situation described here: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9286&group_id=797 I propose adding regular expression support to the --spec switch. I am not big on typing, and being able to do spec --spec ".*unique phrase.*" some_spec.rb instead of spec --spec "Long specification statement with a unique phrase" some_spec.rb would be fantastic. Additionally, you could run all specs related to a loop, by regex'ing out the unique bits of the spec description, a la spec --spec "should have \d+ items" some_spec.rb Thanks. Keep up the good work! ---------------------------------------------------------------------- >Comment By: Chris Hoffman (hoffman_c) Date: 2007-05-10 11:58 Message: Is there any way to have a simple keyword match on these spec names? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9287&group_id=797 From noreply at rubyforge.org Thu May 10 12:26:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 12:26:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10744 ] should raise_error not working in new controller specs Message-ID: <20070510162617.7407652409D6@rubyforge.org> Bugs item #10744, was opened at 2007-05-10 16:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: should raise_error not working in new controller specs Initial Comment: I have the following spec it "Should raise exception when ***" do lambda{post :index, :key => '987'}.should raise_error(Exception) end which fails because of 'The LoginController Should raise exception when packet is not found' FAILED expected Exception but nothing was raised login_controller_spec.rb:42: and in the controller i have an index method which does throw an exception, which I can verify by wrapping it in a begin/rescue block, but the spec still fails. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 From noreply at rubyforge.org Thu May 10 13:48:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 13:48:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10747 ] Helper methods defined in shared specs are not visible when shared spec is used Message-ID: <20070510174856.6A50752409B7@rubyforge.org> Bugs item #10747, was opened at 2007-05-10 10:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10747&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Helper methods defined in shared specs are not visible when shared spec is used Initial Comment: Helper methods that are defined in shared descriptions are not visible to the description's examples when the are instantiated in a non-shared description: a_spec.rb --------- describe "shared", :shared => true do def foobar 37 end it "foobar should be 37" do foobar.should == 37 end end describe "not shared" do it_should_behave_like "shared" end --- % spec -v RSpec-0.9.3 (r1916) - BDD for Ruby http://rspec.rubyforge.org/ /tmp % spec a_spec.rb F 1) NameError in 'not shared foobar should be 37' undefined local variable or method `foobar' for #<#:0x1065188> ./a_spec.rb:7: Finished in 0.364168 seconds 1 example, 1 failure If the definition of foobar is moved into "not shared", it works. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10747&group_id=797 From noreply at rubyforge.org Thu May 10 13:54:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 13:54:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10748 ] Shared descriptions in separate files causes 'already exists' error Message-ID: <20070510175442.4540652409C1@rubyforge.org> Bugs item #10748, was opened at 2007-05-10 10:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10748&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Shared descriptions in separate files causes 'already exists' error Initial Comment: There does not appear to be any protection against multiple inclusions of spec files. This shows up when splitting out a shared description into its own file so that it can be included into multiple spec files. The shared description file is then required into the other files and works as expected when spec is invoked on one such file. If, however, spec is invoked on the directory or on all files in the directory (as the 'rake spec' task in rspec_on_rails does), an error results. To reproduce, define the following files: a_spec.rb --------- describe "shared", :shared => true do it "should do something" do end end b_spec.rb --------- require 'a_spec' describe "not shared" do it_should_behave_like "shared" end Then run spec on *_spec.rb: % spec -v RSpec-0.9.3 (r1916) - BDD for Ruby http://rspec.rubyforge.org/ % spec *_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/dsl/behaviour.rb:9:in `add_shared_behaviour': Shared Behaviour 'shared' already exists (ArgumentError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/extensions/kernel.rb:16:in `register_behaviour' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/extensions/kernel.rb:4:in `describe' from ./a_spec.rb:1 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from ./b_spec.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:22:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/command_line.rb:17:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/bin/spec:3 from /usr/local/bin/spec:18 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10748&group_id=797 From noreply at rubyforge.org Thu May 10 15:49:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 15:49:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10750 ] spec_translator doesn't handle non_parenthesized arguments to expectations. Message-ID: <20070510194929.18CDF52409B7@rubyforge.org> Bugs item #10750, was opened at 2007-05-10 14:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10750&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ed Howland (edhowland) Assigned to: Nobody (None) Summary: spec_translator doesn't handle non_parenthesized arguments to expectations. Initial Comment: An example is .should include 'arg = ?' This get translated to .should include('arg = )?' Here is some before and after specs: context "OldSchool" do class OldSchool attr_accessor collection def initialize @collection = [] end def add_new(item) @collection << item end end specify "should include string with '?'" do school = OldSchool.new school.add_item 'like ?' school.collection.should_include 'like ?' end end The specify clause gets translated to: it "should include string with '?'" do school = OldSchool.new school.add_item 'like ?' school.collection.should include('like)?' end Which ruby won't parse. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10750&group_id=797 From noreply at rubyforge.org Thu May 10 15:52:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 15:52:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10744 ] should raise_error not working in new controller specs Message-ID: <20070510195217.63F9752409B7@rubyforge.org> Bugs item #10744, was opened at 2007-05-10 12:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: should raise_error not working in new controller specs Initial Comment: I have the following spec it "Should raise exception when ***" do lambda{post :index, :key => '987'}.should raise_error(Exception) end which fails because of 'The LoginController Should raise exception when packet is not found' FAILED expected Exception but nothing was raised login_controller_spec.rb:42: and in the controller i have an index method which does throw an exception, which I can verify by wrapping it in a begin/rescue block, but the spec still fails. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 15:52 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 From noreply at rubyforge.org Thu May 10 15:54:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 15:54:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10744 ] should raise_error not working in new controller specs Message-ID: <20070510195425.D3A5052409B7@rubyforge.org> Bugs item #10744, was opened at 2007-05-10 12:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: should raise_error not working in new controller specs Initial Comment: I have the following spec it "Should raise exception when ***" do lambda{post :index, :key => '987'}.should raise_error(Exception) end which fails because of 'The LoginController Should raise exception when packet is not found' FAILED expected Exception but nothing was raised login_controller_spec.rb:42: and in the controller i have an index method which does throw an exception, which I can verify by wrapping it in a begin/rescue block, but the spec still fails. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 15:54 Message: Does your spec fail if you remove the lambda and just do: post :index, :key => '987' How can we reproduce this? Please attach a failing example ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 15:52 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 From noreply at rubyforge.org Thu May 10 16:01:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 16:01:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10645 ] removal of --examples when appropriate Message-ID: <20070510200103.21F0552409B7@rubyforge.org> Patches item #10645, was opened at 2007-05-07 05:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: removal of --examples when appropriate Initial Comment: See ticket: #10545 "Removal of --options when appropriate" http://rubyforge.org/tracker/index.php?func=detail&aid=10545&group_id=797&atid=3151 David/Aslak: I added a an attribute reader for @where in the base text formatter, and called the method output. Feel free to change this as you wish. It is only referenced in the Options class, under the method I've added: remove_extraneous_examples! ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 20:01 Message: I agree, Aslak. Although I don't think touch would be the appropriate thing to use here, because it modifies the mtimes, and that would be a problem for autotest. I'll rework the code. btw: thanks for applying the other patch ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:41 Message: I'm not so keen on applying this. It seems like a complicated solution to a simple problem. An easier solution is this: $ touch previous_failures.txt ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 From noreply at rubyforge.org Thu May 10 16:03:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 16:03:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10731 ] response.should be_a_success Message-ID: <20070510200323.3ACEC52409B7@rubyforge.org> Patches item #10731, was opened at 2007-05-09 23:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: response.should be_a_success Initial Comment: The current rails controller/resource generators output code like the following: response.should be_success I think it reads much better like this: response.should be_a_success This is a tiny little patch that changes those instances in the generators ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 20:03 Message: I think it only looks more cluttered if the it blocks read "it should be successful". If the it blocks read "it should be a success", then I think it gives a uniformity to the spec. WDYT? Reject it if you still think the same. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:34 Message: I think be_a_success looks more cluttered than be_success ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 From noreply at rubyforge.org Thu May 10 17:10:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 17:10:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10753 ] Global before and after Message-ID: <20070510211047.ACB725240A55@rubyforge.org> Feature Requests item #10753, was opened at 2007-05-10 21:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Nobody (None) Summary: Global before and after Initial Comment: Side effects be damned. Unfortunately, we're running test cases in an environment that has a lot of them, so we need to sandbox the environment before every test, and reset it after every test. Shared behavior works, but you need to include them in every single describe. Redundant. I eventually settled on this, hoping it will not break come 1.0: Spec::Runner.configure { |config| config.include Sandbox } class Spec::DSL::Behaviour before(:each) { sandbox } after(:each) { reset } end How about an easier way that will be a formal part of RSpec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 From noreply at rubyforge.org Thu May 10 17:21:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 17:21:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10753 ] Global before and after Message-ID: <20070510212157.D487852409C1@rubyforge.org> Feature Requests item #10753, was opened at 2007-05-10 21:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Nobody (None) Summary: Global before and after Initial Comment: Side effects be damned. Unfortunately, we're running test cases in an environment that has a lot of them, so we need to sandbox the environment before every test, and reset it after every test. Shared behavior works, but you need to include them in every single describe. Redundant. I eventually settled on this, hoping it will not break come 1.0: Spec::Runner.configure { |config| config.include Sandbox } class Spec::DSL::Behaviour before(:each) { sandbox } after(:each) { reset } end How about an easier way that will be a formal part of RSpec? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-10 21:21 Message: How about integrating before/after into the config: Spec::Runner.configure do |config| config.include Sandbox config.before(:each) { sandbox } config.after(:each) { reset } end This is sort of what we were thinking anyhow - does that work for you? Note that config.before would happen BEFORE any before blocks in any given behaviour, whereas config.after would happen AFTER any after blocks in the behaviour. There is a way to override that, but it gets complicated. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 From noreply at rubyforge.org Thu May 10 21:13:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 21:13:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10748 ] Shared descriptions in separate files causes 'already exists' error Message-ID: <20070511011356.D7C3952409C1@rubyforge.org> Bugs item #10748, was opened at 2007-05-10 17:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10748&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Spurrier (gregspurrier) >Assigned to: David Chelimsky (dchelimsky) Summary: Shared descriptions in separate files causes 'already exists' error Initial Comment: There does not appear to be any protection against multiple inclusions of spec files. This shows up when splitting out a shared description into its own file so that it can be included into multiple spec files. The shared description file is then required into the other files and works as expected when spec is invoked on one such file. If, however, spec is invoked on the directory or on all files in the directory (as the 'rake spec' task in rspec_on_rails does), an error results. To reproduce, define the following files: a_spec.rb --------- describe "shared", :shared => true do it "should do something" do end end b_spec.rb --------- require 'a_spec' describe "not shared" do it_should_behave_like "shared" end Then run spec on *_spec.rb: % spec -v RSpec-0.9.3 (r1916) - BDD for Ruby http://rspec.rubyforge.org/ % spec *_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/dsl/behaviour.rb:9:in `add_shared_behaviour': Shared Behaviour 'shared' already exists (ArgumentError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/extensions/kernel.rb:16:in `register_behaviour' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/extensions/kernel.rb:4:in `describe' from ./a_spec.rb:1 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from ./b_spec.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:22:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/command_line.rb:17:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/bin/spec:3 from /usr/local/bin/spec:18 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10748&group_id=797 From noreply at rubyforge.org Thu May 10 21:29:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 21:29:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10748 ] Shared descriptions in separate files causes 'already exists' error Message-ID: <20070511012901.25EAA5240A77@rubyforge.org> Bugs item #10748, was opened at 2007-05-10 17:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10748&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: David Chelimsky (dchelimsky) Summary: Shared descriptions in separate files causes 'already exists' error Initial Comment: There does not appear to be any protection against multiple inclusions of spec files. This shows up when splitting out a shared description into its own file so that it can be included into multiple spec files. The shared description file is then required into the other files and works as expected when spec is invoked on one such file. If, however, spec is invoked on the directory or on all files in the directory (as the 'rake spec' task in rspec_on_rails does), an error results. To reproduce, define the following files: a_spec.rb --------- describe "shared", :shared => true do it "should do something" do end end b_spec.rb --------- require 'a_spec' describe "not shared" do it_should_behave_like "shared" end Then run spec on *_spec.rb: % spec -v RSpec-0.9.3 (r1916) - BDD for Ruby http://rspec.rubyforge.org/ % spec *_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/dsl/behaviour.rb:9:in `add_shared_behaviour': Shared Behaviour 'shared' already exists (ArgumentError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/extensions/kernel.rb:16:in `register_behaviour' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/extensions/kernel.rb:4:in `describe' from ./a_spec.rb:1 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from ./b_spec.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:85:in `load_specs' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:84:in `load_specs' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/behaviour_runner.rb:22:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/runner/command_line.rb:17:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/bin/spec:3 from /usr/local/bin/spec:18 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 01:29 Message: Fixed in rev 1942. You'll still get the error if you try to add two different shared behaviours with the same description twice, but if the same instance is submitted twice (for example, due to reloading the file) it will simply ignore it and move on. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10748&group_id=797 From noreply at rubyforge.org Thu May 10 21:29:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 May 2007 21:29:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10747 ] Helper methods defined in shared specs are not visible when shared spec is used Message-ID: <20070511012917.983175240A77@rubyforge.org> Bugs item #10747, was opened at 2007-05-10 17:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10747&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Spurrier (gregspurrier) >Assigned to: David Chelimsky (dchelimsky) Summary: Helper methods defined in shared specs are not visible when shared spec is used Initial Comment: Helper methods that are defined in shared descriptions are not visible to the description's examples when the are instantiated in a non-shared description: a_spec.rb --------- describe "shared", :shared => true do def foobar 37 end it "foobar should be 37" do foobar.should == 37 end end describe "not shared" do it_should_behave_like "shared" end --- % spec -v RSpec-0.9.3 (r1916) - BDD for Ruby http://rspec.rubyforge.org/ /tmp % spec a_spec.rb F 1) NameError in 'not shared foobar should be 37' undefined local variable or method `foobar' for #<#:0x1065188> ./a_spec.rb:7: Finished in 0.364168 seconds 1 example, 1 failure If the definition of foobar is moved into "not shared", it works. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10747&group_id=797 From mailing_lists at railsnewbie.com Fri May 11 03:41:17 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Fri, 11 May 2007 03:41:17 -0400 Subject: [rspec-devel] Failing specs in trunk Message-ID: Is anyone else seeing failing specs in trunk/rspec ? I'm getting this when running rake spec under the trunk/spec dir 1) RangeError in 'DrbCommandLine with local server should output red colorized text when running with -c option' 0x1560012 is not id value (druby:/localhost:8989) ./script/spec_server:44 ./spec/spec/runner/drb_command_line_spec.rb:68:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:42: 2) RangeError in 'DrbCommandLine with local server should output green colorized text when running with --colour option' 0x155a644 is not id value (druby:/localhost:8989) ./script/spec_server:44 ./spec/spec/runner/drb_command_line_spec.rb:68:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:37: 3) RangeError in 'DrbCommandLine with local server should run against local server' 0x1554c8a is not id value (druby:/localhost:8989) ./script/spec_server:44 ./spec/spec/runner/drb_command_line_spec.rb:68:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:32: 4) RangeError in 'DrbCommandLine without running local server should print error when there is no running local server' 0x154eb1e is not id value (druby:/localhost:8989) ./script/spec_server:44 ./spec/spec/runner/drb_command_line_spec.rb:10: Finished in 20.746856 seconds 762 examples, 4 failures Scott From aslak.hellesoy at gmail.com Fri May 11 03:52:31 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 11 May 2007 09:52:31 +0200 Subject: [rspec-devel] Failing specs in trunk In-Reply-To: References: Message-ID: <8d961d900705110052m1036db5q2bb47fd3d5a32591@mail.gmail.com> On 5/11/07, Scott Taylor wrote: > > Is anyone else seeing failing specs in trunk/rspec ? All of my specs are passing in r1942 Perhaps it's an environment thing? > I'm getting > this when running rake spec under the trunk/spec dir > > > 1) > RangeError in 'DrbCommandLine with local server should output red > colorized text when running with -c option' > 0x1560012 is not id value > (druby:/localhost:8989) ./script/spec_server:44 > ./spec/spec/runner/drb_command_line_spec.rb:68:in `run_spec_via_druby' > ./spec/spec/runner/drb_command_line_spec.rb:42: > > 2) > RangeError in 'DrbCommandLine with local server should output green > colorized text when running with --colour option' > 0x155a644 is not id value > (druby:/localhost:8989) ./script/spec_server:44 > ./spec/spec/runner/drb_command_line_spec.rb:68:in `run_spec_via_druby' > ./spec/spec/runner/drb_command_line_spec.rb:37: > > 3) > RangeError in 'DrbCommandLine with local server should run against > local server' > 0x1554c8a is not id value > (druby:/localhost:8989) ./script/spec_server:44 > ./spec/spec/runner/drb_command_line_spec.rb:68:in `run_spec_via_druby' > ./spec/spec/runner/drb_command_line_spec.rb:32: > > 4) > RangeError in 'DrbCommandLine without running local server should > print error when there is no running local server' > 0x154eb1e is not id value > (druby:/localhost:8989) ./script/spec_server:44 > ./spec/spec/runner/drb_command_line_spec.rb:10: > > Finished in 20.746856 seconds > > 762 examples, 4 failures > > > Scott > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From mailing_lists at railsnewbie.com Fri May 11 03:57:46 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Fri, 11 May 2007 03:57:46 -0400 Subject: [rspec-devel] Failing specs in trunk In-Reply-To: <8d961d900705110052m1036db5q2bb47fd3d5a32591@mail.gmail.com> References: <8d961d900705110052m1036db5q2bb47fd3d5a32591@mail.gmail.com> Message-ID: <00143A2C-5377-4115-8DAA-B6DD076096EB@railsnewbie.com> On May 11, 2007, at 3:52 AM, aslak hellesoy wrote: > On 5/11/07, Scott Taylor wrote: >> >> Is anyone else seeing failing specs in trunk/rspec ? > > All of my specs are passing in r1942 > Perhaps it's an environment thing? Yeah - I had my rails spec_server running in the background. I completely forgot about it. Not the first time this has happened to me. Maybe I should add a note in the docs? Scott From noreply at rubyforge.org Fri May 11 04:26:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 04:26:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10770 ] Allow before and after to be specified in config, finer grained includes Message-ID: <20070511082652.D5A19A970002@rubyforge.org> Feature Requests item #10770, was opened at 2007-05-11 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 Category: runner module Group: None Status: Open Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Allow before and after to be specified in config, finer grained includes Initial Comment: Suggestion: Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end # This will only include the module in Watir specs (to avoid collisions) config.include(Spec::Matchers::Watir, :behaviour_type => 'watir') end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 From noreply at rubyforge.org Fri May 11 07:24:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 07:24:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10770 ] Allow before and after to be specified in config, finer grained includes Message-ID: <20070511112422.395705240977@rubyforge.org> Feature Requests item #10770, was opened at 2007-05-11 08:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 Category: runner module Group: None Status: Open Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Allow before and after to be specified in config, finer grained includes Initial Comment: Suggestion: Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end # This will only include the module in Watir specs (to avoid collisions) config.include(Spec::Matchers::Watir, :behaviour_type => 'watir') end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 11:24 Message: We should do this for fixtures as well. That way you can set up your fixtures for only your model behaviours and use mocks everywhere else. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 From noreply at rubyforge.org Fri May 11 08:28:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 08:28:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10770 ] Allow before and after to be specified in config, finer grained includes Message-ID: <20070511122807.E047C52408DC@rubyforge.org> Feature Requests item #10770, was opened at 2007-05-11 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 Category: runner module Group: None Status: Open Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Allow before and after to be specified in config, finer grained includes Initial Comment: Suggestion: Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end # This will only include the module in Watir specs (to avoid collisions) config.include(Spec::Matchers::Watir, :behaviour_type => 'watir') end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:28 Message: I'm renaming this issue - we'll deal with config.before/config.after in a separate issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 07:24 Message: We should do this for fixtures as well. That way you can set up your fixtures for only your model behaviours and use mocks everywhere else. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 From noreply at rubyforge.org Fri May 11 08:28:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 08:28:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10770 ] Allow before and after to be specified in config, finer grained includes Message-ID: <20070511122854.029C052408DC@rubyforge.org> Feature Requests item #10770, was opened at 2007-05-11 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 Category: runner module Group: None Status: Open Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Allow before and after to be specified in config, finer grained includes Initial Comment: Suggestion: Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end # This will only include the module in Watir specs (to avoid collisions) config.include(Spec::Matchers::Watir, :behaviour_type => 'watir') end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:28 Message: Right - renames don't work in this tacker. Well - this one is now only about finer grained includes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:28 Message: I'm renaming this issue - we'll deal with config.before/config.after in a separate issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 07:24 Message: We should do this for fixtures as well. That way you can set up your fixtures for only your model behaviours and use mocks everywhere else. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 From noreply at rubyforge.org Fri May 11 08:30:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 08:30:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10774 ] Allow before and after to be specified in config II Message-ID: <20070511123033.647CA52408DC@rubyforge.org> Feature Requests item #10774, was opened at 2007-05-11 08:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10774&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Allow before and after to be specified in config II Initial Comment: This issue is about the before/after part only of: http://rubyforge.org/tracker/index.php?func=detail&aid=10770&group_id=797&atid=3152 Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10774&group_id=797 From noreply at rubyforge.org Fri May 11 08:30:42 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 08:30:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10770 ] Allow before and after to be specified in config, finer grained includes Message-ID: <20070511123042.9EC1B52408DC@rubyforge.org> Feature Requests item #10770, was opened at 2007-05-11 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 Category: runner module Group: None Status: Open Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Allow before and after to be specified in config, finer grained includes Initial Comment: Suggestion: Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end # This will only include the module in Watir specs (to avoid collisions) config.include(Spec::Matchers::Watir, :behaviour_type => 'watir') end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:28 Message: Right - renames don't work in this tacker. Well - this one is now only about finer grained includes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:28 Message: I'm renaming this issue - we'll deal with config.before/config.after in a separate issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 07:24 Message: We should do this for fixtures as well. That way you can set up your fixtures for only your model behaviours and use mocks everywhere else. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 From noreply at rubyforge.org Fri May 11 08:30:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 08:30:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10775 ] Allow fixtures to be specified in config with finer granularity Message-ID: <20070511123044.3655A52408DC@rubyforge.org> Feature Requests item #10775, was opened at 2007-05-11 12:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10775&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: Allow fixtures to be specified in config with finer granularity Initial Comment: Similar to http://rubyforge.org/tracker/index.php?func=detail&aid=10770&group_id=797&atid=3152, let's support this: Spec::Runner.configure do |config| config.global_fixtures(:fixture1, :fixture2, :behaviour_type => :model) end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10775&group_id=797 From noreply at rubyforge.org Fri May 11 08:50:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 08:50:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10770 ] Allow before and after to be specified in config, finer grained includes Message-ID: <20070511125002.69F625240977@rubyforge.org> Feature Requests item #10770, was opened at 2007-05-11 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 Category: runner module Group: None >Status: Closed Priority: 4 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Allow before and after to be specified in config, finer grained includes Initial Comment: Suggestion: Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end # This will only include the module in Watir specs (to avoid collisions) config.include(Spec::Matchers::Watir, :behaviour_type => 'watir') end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:50 Message: Fixed in r1944 - in Spec::DSL::Behaviour#include. The last arg can be a Hash. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:28 Message: Right - renames don't work in this tacker. Well - this one is now only about finer grained includes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-11 08:28 Message: I'm renaming this issue - we'll deal with config.before/config.after in a separate issue. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 07:24 Message: We should do this for fixtures as well. That way you can set up your fixtures for only your model behaviours and use mocks everywhere else. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10770&group_id=797 From noreply at rubyforge.org Fri May 11 09:02:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 09:02:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10747 ] Helper methods defined in shared specs are not visible when shared spec is used Message-ID: <20070511130204.056BB52408FF@rubyforge.org> Bugs item #10747, was opened at 2007-05-10 17:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10747&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: David Chelimsky (dchelimsky) Summary: Helper methods defined in shared specs are not visible when shared spec is used Initial Comment: Helper methods that are defined in shared descriptions are not visible to the description's examples when the are instantiated in a non-shared description: a_spec.rb --------- describe "shared", :shared => true do def foobar 37 end it "foobar should be 37" do foobar.should == 37 end end describe "not shared" do it_should_behave_like "shared" end --- % spec -v RSpec-0.9.3 (r1916) - BDD for Ruby http://rspec.rubyforge.org/ /tmp % spec a_spec.rb F 1) NameError in 'not shared foobar should be 37' undefined local variable or method `foobar' for #<#:0x1065188> ./a_spec.rb:7: Finished in 0.364168 seconds 1 example, 1 failure If the definition of foobar is moved into "not shared", it works. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 13:02 Message: Fixed in trunk rev 1946. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10747&group_id=797 From noreply at rubyforge.org Fri May 11 13:17:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 13:17:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511171744.05B2C5240A31@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 10:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 14:13:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 14:13:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511181318.2CF3E5240A76@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 17:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 18:13 Message: Personally I think that makes things more confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 14:38:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 14:38:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511183831.053D15240A76@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 10:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- >Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 11:38 Message: I can certainly see your point for simple examples like the one in the docs: Officer - should be payable - should be bonusable - should be optionable is indeed preferable to: Officer - should behave like All Managers, and: - should behave like All Employees, and : - be bonusable - be payable - be optionable Let me describe the root issue that I'm grappling with and that initially led me to request hierarchical output. Perhaps there's a beter way. How do you deal with subclasses that should share multiple behaviors with their superclass. E.g., suppose you have: class A #... end class B < A # ... end and behaviors like: describe "A when it is sunny", :shared => true do end describe "A when it is cloudy", :shared => true do end For B, you can do: describe "B when it is sunny" do it_should_behave_like "A when it is sunny" end describe "B when it is cloudy" do it_should_behave_like "A when it is cloudy" end and, maybe that's the right way to do it. But, it leads to a lot of repeated typing when A has a lot of shared behaviors or there are a lot of subclasses of A. So, I was thinking about doing something like this for A: describe "A", :shared => true do it_should_behave_like "A when it is sunny" it_should_behave_like "A when is is cloudy" end And for B: describe "B inherited behavior" do it_should_behave_like "A" end The advantage of this approach is that you can continue to add shared behaviors to the "A" description without having to go update the specs of all the subclasses. But, with the current specdoc output, this aggregating of shared behaviors into another shared behavior would be pretty confusing in the output. Maybe there's another way to tackle this. Suggestions? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 11:13 Message: Personally I think that makes things more confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 15:10:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 15:10:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511191054.117F15240A56@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 17:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 19:10 Message: Why would the output be confusing? Everything just gets flattened, so for an A that does 2 things when it rains and 2 other things when it's cloudy, with subclasses B and C, the output would say: B - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy C - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy Looking at either listing, everything seems clear. What am I missing? ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 18:38 Message: I can certainly see your point for simple examples like the one in the docs: Officer - should be payable - should be bonusable - should be optionable is indeed preferable to: Officer - should behave like All Managers, and: - should behave like All Employees, and : - be bonusable - be payable - be optionable Let me describe the root issue that I'm grappling with and that initially led me to request hierarchical output. Perhaps there's a beter way. How do you deal with subclasses that should share multiple behaviors with their superclass. E.g., suppose you have: class A #... end class B < A # ... end and behaviors like: describe "A when it is sunny", :shared => true do end describe "A when it is cloudy", :shared => true do end For B, you can do: describe "B when it is sunny" do it_should_behave_like "A when it is sunny" end describe "B when it is cloudy" do it_should_behave_like "A when it is cloudy" end and, maybe that's the right way to do it. But, it leads to a lot of repeated typing when A has a lot of shared behaviors or there are a lot of subclasses of A. So, I was thinking about doing something like this for A: describe "A", :shared => true do it_should_behave_like "A when it is sunny" it_should_behave_like "A when is is cloudy" end And for B: describe "B inherited behavior" do it_should_behave_like "A" end The advantage of this approach is that you can continue to add shared behaviors to the "A" description without having to go update the specs of all the subclasses. But, with the current specdoc output, this aggregating of shared behaviors into another shared behavior would be pretty confusing in the output. Maybe there's another way to tackle this. Suggestions? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 18:13 Message: Personally I think that makes things more confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 18:18:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 18:18:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511221850.19BFB5240B08@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 10:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- >Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 15:18 Message: The output you describe is great, but it requires you to put "if it's raining" in the description of each example that is part of the "when it's raining" behavior, which seems redundant. Writing the spec the natural way in which the descriptions of the examples are taken to be within the context of the description: describe "A when it's sunny", :shared => true do it "should be open for business" do end it "should be use natural lighting" do end end describe "A when it's cloudy", :shared =>true do it "should be open for business" do end it "should be use electric lighting" do end end describe "A", :shared => true do it_should_behave_like "A when it's sunny" it_should_behave_like "A when it's cloudy" end describe "B's inherited behavior" do it_should_behave_like "A" end gives: B's inherited behavior - should be open for business - should be use natural lighting - should be open for business - should be use electric lighting which is what I was referring to as being confusing. It'd be nice if there was a way for the context of the behavior to carry through to the specdoc output so that the output can be unambiguous, but the specs can still read naturally without having to explicitly include the context in each example. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 12:10 Message: Why would the output be confusing? Everything just gets flattened, so for an A that does 2 things when it rains and 2 other things when it's cloudy, with subclasses B and C, the output would say: B - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy C - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy Looking at either listing, everything seems clear. What am I missing? ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 11:38 Message: I can certainly see your point for simple examples like the one in the docs: Officer - should be payable - should be bonusable - should be optionable is indeed preferable to: Officer - should behave like All Managers, and: - should behave like All Employees, and : - be bonusable - be payable - be optionable Let me describe the root issue that I'm grappling with and that initially led me to request hierarchical output. Perhaps there's a beter way. How do you deal with subclasses that should share multiple behaviors with their superclass. E.g., suppose you have: class A #... end class B < A # ... end and behaviors like: describe "A when it is sunny", :shared => true do end describe "A when it is cloudy", :shared => true do end For B, you can do: describe "B when it is sunny" do it_should_behave_like "A when it is sunny" end describe "B when it is cloudy" do it_should_behave_like "A when it is cloudy" end and, maybe that's the right way to do it. But, it leads to a lot of repeated typing when A has a lot of shared behaviors or there are a lot of subclasses of A. So, I was thinking about doing something like this for A: describe "A", :shared => true do it_should_behave_like "A when it is sunny" it_should_behave_like "A when is is cloudy" end And for B: describe "B inherited behavior" do it_should_behave_like "A" end The advantage of this approach is that you can continue to add shared behaviors to the "A" description without having to go update the specs of all the subclasses. But, with the current specdoc output, this aggregating of shared behaviors into another shared behavior would be pretty confusing in the output. Maybe there's another way to tackle this. Suggestions? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 11:13 Message: Personally I think that makes things more confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 18:24:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 18:24:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects Message-ID: <20070511222416.613C75240AD1@rubyforge.org> Feature Requests item #8654, was opened at 2007-02-14 07:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: Aspects Initial Comment: Specifications become a bit messy in large applications. What if implementing aspects for rspec? context "New Document instance" do setup do @document = Document.new end aspect "versioning" do specify "should have no versions" do @document.should_have(0).versions end end aspect "printing" do aspect "pdf" do ... end end end New Document instance - (versioning) should have no versions - (printing/pdf) ... Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 22:24 Message: "Facet" is brilliant. Thanks. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-03-19 13:40 Message: > Any other suggestions? I want to come up w/ the right name > before we add this. "Facet"? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-19 12:56 Message: Agreed that sub_context is the wrong name, and "aspect" WOULD be a great name if it didn't evoke Aspect Oriented Programming. Any other suggestions? I want to come up w/ the right name before we add this. ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-02-16 12:57 Message: Also, I think that sub_context isn't good name for aspect. In my understanding aspects to be _quite_ orthogonal to context. It's kind of protocol in Smalltalk, or something like that. ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-02-16 12:49 Message: David, basically your idea about nested blocks with arbitrary names is nice, but I foresee one problem. My current implementation supports nested aspects and joins their names like "(versioning/backup)" for nested versioning -> backup aspects. WDYT? I will surely be able to rework any of my proof-of-concept implementation of rspec extensions as a patch with tests once it will be agreed with rspec maintainers. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-14 14:02 Message: Thanks Yurii. This is pretty sweet. Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152. The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for: context "New Document instance" do aspect "(versioning)" do specify "should have no versions" do ... WDYT? Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place. Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8654&group_id=797 From noreply at rubyforge.org Fri May 11 18:31:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 18:31:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10645 ] removal of --examples when appropriate Message-ID: <20070511223114.54A475240AD1@rubyforge.org> Patches item #10645, was opened at 2007-05-07 05:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: removal of --examples when appropriate Initial Comment: See ticket: #10545 "Removal of --options when appropriate" http://rubyforge.org/tracker/index.php?func=detail&aid=10545&group_id=797&atid=3151 David/Aslak: I added a an attribute reader for @where in the base text formatter, and called the method output. Feel free to change this as you wish. It is only referenced in the Options class, under the method I've added: remove_extraneous_examples! ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-11 22:31 Message: Well, now that I look at it, it appears as though it isn't that simple, because if you want the example switch to touch the file, it *needs to know* that it is a file, and not a simple example (this is why there was the complicated logic in my patch). On the other hand, the --formatter switch does touch the file. So the bug looks like it only occurs when you specify --examples before --formatter, because ::OptionParser parses options sequentially, as they are given on the command line. I've opted for a low-tech solution (in this version of the patch), so that --help will specify that --examples should come after the corresponding formatter. Another low-tech solution exists, of course, and that would be to have an --example switch which only processes named examples, and an --example-file switch which would process a formatted file. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 20:01 Message: I agree, Aslak. Although I don't think touch would be the appropriate thing to use here, because it modifies the mtimes, and that would be a problem for autotest. I'll rework the code. btw: thanks for applying the other patch ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:41 Message: I'm not so keen on applying this. It seems like a complicated solution to a simple problem. An easier solution is this: $ touch previous_failures.txt ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 From noreply at rubyforge.org Fri May 11 19:06:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 19:06:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511230648.307635240B0E@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 17:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 23:06 Message: OK, now I understand the problem better. Let me think on it for a bit. ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 22:18 Message: The output you describe is great, but it requires you to put "if it's raining" in the description of each example that is part of the "when it's raining" behavior, which seems redundant. Writing the spec the natural way in which the descriptions of the examples are taken to be within the context of the description: describe "A when it's sunny", :shared => true do it "should be open for business" do end it "should be use natural lighting" do end end describe "A when it's cloudy", :shared =>true do it "should be open for business" do end it "should be use electric lighting" do end end describe "A", :shared => true do it_should_behave_like "A when it's sunny" it_should_behave_like "A when it's cloudy" end describe "B's inherited behavior" do it_should_behave_like "A" end gives: B's inherited behavior - should be open for business - should be use natural lighting - should be open for business - should be use electric lighting which is what I was referring to as being confusing. It'd be nice if there was a way for the context of the behavior to carry through to the specdoc output so that the output can be unambiguous, but the specs can still read naturally without having to explicitly include the context in each example. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 19:10 Message: Why would the output be confusing? Everything just gets flattened, so for an A that does 2 things when it rains and 2 other things when it's cloudy, with subclasses B and C, the output would say: B - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy C - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy Looking at either listing, everything seems clear. What am I missing? ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 18:38 Message: I can certainly see your point for simple examples like the one in the docs: Officer - should be payable - should be bonusable - should be optionable is indeed preferable to: Officer - should behave like All Managers, and: - should behave like All Employees, and : - be bonusable - be payable - be optionable Let me describe the root issue that I'm grappling with and that initially led me to request hierarchical output. Perhaps there's a beter way. How do you deal with subclasses that should share multiple behaviors with their superclass. E.g., suppose you have: class A #... end class B < A # ... end and behaviors like: describe "A when it is sunny", :shared => true do end describe "A when it is cloudy", :shared => true do end For B, you can do: describe "B when it is sunny" do it_should_behave_like "A when it is sunny" end describe "B when it is cloudy" do it_should_behave_like "A when it is cloudy" end and, maybe that's the right way to do it. But, it leads to a lot of repeated typing when A has a lot of shared behaviors or there are a lot of subclasses of A. So, I was thinking about doing something like this for A: describe "A", :shared => true do it_should_behave_like "A when it is sunny" it_should_behave_like "A when is is cloudy" end And for B: describe "B inherited behavior" do it_should_behave_like "A" end The advantage of this approach is that you can continue to add shared behaviors to the "A" description without having to go update the specs of all the subclasses. But, with the current specdoc output, this aggregating of shared behaviors into another shared behavior would be pretty confusing in the output. Maybe there's another way to tackle this. Suggestions? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 18:13 Message: Personally I think that makes things more confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 19:11:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 19:11:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511231159.B3DDD5240B08@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 17:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 23:11 Message: I hadn't really thought of shared behaviours as being about context. I think that the "concrete" behaviours that use them are where context should be expressed. I see the problem, but I feel like this is a misuse of shared behaviors and that there is some other construct that is trying to be emerge here. One thought is an RFE from a while back about "aspects" (or "facets"): http://rubyforge.org/tracker/?group_id=797&atid=3152&func=detail&aid=8654 Take a look at that and let me know what you think about it vis a vis this particular problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 23:06 Message: OK, now I understand the problem better. Let me think on it for a bit. ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 22:18 Message: The output you describe is great, but it requires you to put "if it's raining" in the description of each example that is part of the "when it's raining" behavior, which seems redundant. Writing the spec the natural way in which the descriptions of the examples are taken to be within the context of the description: describe "A when it's sunny", :shared => true do it "should be open for business" do end it "should be use natural lighting" do end end describe "A when it's cloudy", :shared =>true do it "should be open for business" do end it "should be use electric lighting" do end end describe "A", :shared => true do it_should_behave_like "A when it's sunny" it_should_behave_like "A when it's cloudy" end describe "B's inherited behavior" do it_should_behave_like "A" end gives: B's inherited behavior - should be open for business - should be use natural lighting - should be open for business - should be use electric lighting which is what I was referring to as being confusing. It'd be nice if there was a way for the context of the behavior to carry through to the specdoc output so that the output can be unambiguous, but the specs can still read naturally without having to explicitly include the context in each example. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 19:10 Message: Why would the output be confusing? Everything just gets flattened, so for an A that does 2 things when it rains and 2 other things when it's cloudy, with subclasses B and C, the output would say: B - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy C - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy Looking at either listing, everything seems clear. What am I missing? ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 18:38 Message: I can certainly see your point for simple examples like the one in the docs: Officer - should be payable - should be bonusable - should be optionable is indeed preferable to: Officer - should behave like All Managers, and: - should behave like All Employees, and : - be bonusable - be payable - be optionable Let me describe the root issue that I'm grappling with and that initially led me to request hierarchical output. Perhaps there's a beter way. How do you deal with subclasses that should share multiple behaviors with their superclass. E.g., suppose you have: class A #... end class B < A # ... end and behaviors like: describe "A when it is sunny", :shared => true do end describe "A when it is cloudy", :shared => true do end For B, you can do: describe "B when it is sunny" do it_should_behave_like "A when it is sunny" end describe "B when it is cloudy" do it_should_behave_like "A when it is cloudy" end and, maybe that's the right way to do it. But, it leads to a lot of repeated typing when A has a lot of shared behaviors or there are a lot of subclasses of A. So, I was thinking about doing something like this for A: describe "A", :shared => true do it_should_behave_like "A when it is sunny" it_should_behave_like "A when is is cloudy" end And for B: describe "B inherited behavior" do it_should_behave_like "A" end The advantage of this approach is that you can continue to add shared behaviors to the "A" description without having to go update the specs of all the subclasses. But, with the current specdoc output, this aggregating of shared behaviors into another shared behavior would be pretty confusing in the output. Maybe there's another way to tackle this. Suggestions? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 18:13 Message: Personally I think that makes things more confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 19:35:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 19:35:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors Message-ID: <20070511233531.35C8C5240B38@rubyforge.org> Feature Requests item #10781, was opened at 2007-05-11 10:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 Category: reports Group: None Status: Open Priority: 3 Submitted By: Greg Spurrier (gregspurrier) Assigned to: Nobody (None) Summary: Hierarchical specdoc output for shared behaviors Initial Comment: When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.: describe "REST index action", :shared => true do it "should return status code 200" do end end describe "REST show action", :shared => true do it "should return status code 200" do end end describe "FooController" do it_should_behave_like "REST index action" it_should_behave_like "REST show action" end gives the following output with 0.9.4: % spec -fs a_spec.rb FooController - should return status code 200 - should return status code 200 It would be better, IMHO, if it looked like: FooController - should behave like REST index action and: - should return status code 200 - should behave like REST show action and: - should return status code 200 What do you guys think? ---------------------------------------------------------------------- >Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 16:35 Message: Yes, there may indeed be a new construct waiting to emerge add address this elegantly. Essentially, what I'm looking for is a way to group a set of behaviors that pertain to a superclass (or module that is mixed in) and then include them into the specification of derived classes. Sort of a spec hierarchy that runs parallel to the class hierarchy. Looking at the RFE you mentioned, unless I'm missing something, the "aspects" there seem to be more about namespace management than about defining generic aspects that can be included into multiple behaviors. Anyway, I'll continue to ponder it over the weekend as well, and maybe something will come to one of us. :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 16:11 Message: I hadn't really thought of shared behaviours as being about context. I think that the "concrete" behaviours that use them are where context should be expressed. I see the problem, but I feel like this is a misuse of shared behaviors and that there is some other construct that is trying to be emerge here. One thought is an RFE from a while back about "aspects" (or "facets"): http://rubyforge.org/tracker/?group_id=797&atid=3152&func=detail&aid=8654 Take a look at that and let me know what you think about it vis a vis this particular problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 16:06 Message: OK, now I understand the problem better. Let me think on it for a bit. ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 15:18 Message: The output you describe is great, but it requires you to put "if it's raining" in the description of each example that is part of the "when it's raining" behavior, which seems redundant. Writing the spec the natural way in which the descriptions of the examples are taken to be within the context of the description: describe "A when it's sunny", :shared => true do it "should be open for business" do end it "should be use natural lighting" do end end describe "A when it's cloudy", :shared =>true do it "should be open for business" do end it "should be use electric lighting" do end end describe "A", :shared => true do it_should_behave_like "A when it's sunny" it_should_behave_like "A when it's cloudy" end describe "B's inherited behavior" do it_should_behave_like "A" end gives: B's inherited behavior - should be open for business - should be use natural lighting - should be open for business - should be use electric lighting which is what I was referring to as being confusing. It'd be nice if there was a way for the context of the behavior to carry through to the specdoc output so that the output can be unambiguous, but the specs can still read naturally without having to explicitly include the context in each example. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 12:10 Message: Why would the output be confusing? Everything just gets flattened, so for an A that does 2 things when it rains and 2 other things when it's cloudy, with subclasses B and C, the output would say: B - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy C - should do thing 1 if it's raining - should do thing 2 if it's raining - should do thing 3 if it's cloudy - should do thing 4 if it's cloudy Looking at either listing, everything seems clear. What am I missing? ---------------------------------------------------------------------- Comment By: Greg Spurrier (gregspurrier) Date: 2007-05-11 11:38 Message: I can certainly see your point for simple examples like the one in the docs: Officer - should be payable - should be bonusable - should be optionable is indeed preferable to: Officer - should behave like All Managers, and: - should behave like All Employees, and : - be bonusable - be payable - be optionable Let me describe the root issue that I'm grappling with and that initially led me to request hierarchical output. Perhaps there's a beter way. How do you deal with subclasses that should share multiple behaviors with their superclass. E.g., suppose you have: class A #... end class B < A # ... end and behaviors like: describe "A when it is sunny", :shared => true do end describe "A when it is cloudy", :shared => true do end For B, you can do: describe "B when it is sunny" do it_should_behave_like "A when it is sunny" end describe "B when it is cloudy" do it_should_behave_like "A when it is cloudy" end and, maybe that's the right way to do it. But, it leads to a lot of repeated typing when A has a lot of shared behaviors or there are a lot of subclasses of A. So, I was thinking about doing something like this for A: describe "A", :shared => true do it_should_behave_like "A when it is sunny" it_should_behave_like "A when is is cloudy" end And for B: describe "B inherited behavior" do it_should_behave_like "A" end The advantage of this approach is that you can continue to add shared behaviors to the "A" description without having to go update the specs of all the subclasses. But, with the current specdoc output, this aggregating of shared behaviors into another shared behavior would be pretty confusing in the output. Maybe there's another way to tackle this. Suggestions? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-11 11:13 Message: Personally I think that makes things more confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797 From noreply at rubyforge.org Fri May 11 22:11:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 May 2007 22:11:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10672 ] Setting Spec::Runner.configure fixture_path doesn't seem to work Message-ID: <20070512021128.3D3265240C75@rubyforge.org> Bugs item #10672, was opened at 2007-05-07 16:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10672&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Setting Spec::Runner.configure fixture_path doesn't seem to work Initial Comment: Spec::Runner.configure do |config| config.use_transactional_fixtures = true config.use_instantiated_fixtures = false config.fixture_path = RAILS_ROOT + '/test/fixtures' # config.global_fixtures = :table_a, :table_b end module Spec module Rails module Runner class EvalContext < Test::Unit::TestCase # When the next line is uncommented, the specs work # self.fixture_path = RAILS_ROOT + '/test/fixtures' extend DisabledSpecs include CommunityPatentSpecHelper include RjsSpecHelper end end end end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-07 20:39 Message: I think this is an update problem. There is no longer a Spec::Rails::Runner::EvalContext being used (so I'm not sure what's going on with your example). I just created a brand new rails 1.2.3 app w/ rspec rev 1930, created an rspec_resource, migrated, watched the specs pass, moved fixtures to /test/fixtures, watched the specs fail, changed the fixture path accordingly, watched the specs pass. One problem I see is that you're extending w/ DisabledSpecs. Right now there is no support for extend in config (i.e. config.extend DisabledSpecs), but I think you can this: module DisabledSpecs def included(mod) mod extend(self) end .. end Or something similar. Please report back after playing w/ this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10672&group_id=797 From noreply at rubyforge.org Sat May 12 01:31:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 12 May 2007 01:31:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10791 ] A 'switch between source and spec file' command for textmate (with auto-creation!) Message-ID: <20070512053128.0EF9A5240A3E@rubyforge.org> Patches item #10791, was opened at 2007-05-11 22:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10791&group_id=797 Category: None Group: Unstable (example) Status: Open Resolution: None Priority: 3 Submitted By: Ruy Asan (rubyruy) Assigned to: Nobody (None) Summary: A 'switch between source and spec file' command for textmate (with auto-creation!) Initial Comment: There is a great deal of switching back and forth between source and spec files when doing RSpec. The official tmbundle could probably benefit from this. Unforunately, I started writing this for just-my-own-use, so as a result it's not very pretty, needs to be tested, integrated with the various (and annoyingly un-documented) textmate libs and packaged. If a fellow text-mater wants to clean it up and add it to the official bundle, please do :) If not, I'll probably make it into a proper patch when I get some time. Source (and added info) here: http://ruy.ca/posts/6-A-simple-switch-between-source-and-spec-file-command-for-textmate-with-auto-creation- ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10791&group_id=797 From noreply at rubyforge.org Sat May 12 05:50:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 12 May 2007 05:50:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10794 ] Fixtures do not work in Helper Specs Message-ID: <20070512095048.3B26B5240948@rubyforge.org> Bugs item #10794, was opened at 2007-05-12 02:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Fixtures do not work in Helper Specs Initial Comment: It seems that fixture support for Helper examples has been taken out.. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 From noreply at rubyforge.org Sat May 12 07:59:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 12 May 2007 07:59:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10794 ] Fixtures do not work in Helper Specs Message-ID: <20070512115941.E853B5240967@rubyforge.org> Bugs item #10794, was opened at 2007-05-12 09:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Fixtures do not work in Helper Specs Initial Comment: It seems that fixture support for Helper examples has been taken out.. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 11:59 Message: Did they ever work? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 From noreply at rubyforge.org Sat May 12 08:42:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 12 May 2007 08:42:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10744 ] should raise_error not working in new controller specs Message-ID: <20070512124206.598AF5240A26@rubyforge.org> Bugs item #10744, was opened at 2007-05-10 16:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: should raise_error not working in new controller specs Initial Comment: I have the following spec it "Should raise exception when ***" do lambda{post :index, :key => '987'}.should raise_error(Exception) end which fails because of 'The LoginController Should raise exception when packet is not found' FAILED expected Exception but nothing was raised login_controller_spec.rb:42: and in the controller i have an index method which does throw an exception, which I can verify by wrapping it in a begin/rescue block, but the spec still fails. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 12:42 Message: By default, Rails swallows exceptions and returns error codes in headers (see actionpack/lib/action_controller/rescue.rb). Controller specs in 0.8.x and earlier used to override the default behaviour like this: @controller_class.send(:define_method, :rescue_action) { |e| raise e } This would cause errors thrown in actions to be thrown in the specs. Unfortunately, it also overrode custom rescue_actions (see http://rubyforge.org/tracker/?group_id=797&atid=3149&func=detail&aid=9767). I'm closing this as this is now the expected behaviour. I've added the following rdoc for ControllerBehaviour: # == Expecting Errors # # By default, Rails will swallow errors that are raised in controller # actions and return an error code in the header. If you want to # specify that an action should raise an error, you can either # override rescue_action in your controller ... # # before(:each) do # controller.class.send(:define_method, :rescue_action) { |e| raise e } # end # # ... or you can expect error codes in headers ... # # it "should return an error in the header" do # response.should be_error # end # # it "should return a 501" do # response.response_code.should == 501 # end # # it "should return a 501" do # response.code.should == "501" # end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 19:54 Message: Does your spec fail if you remove the lambda and just do: post :index, :key => '987' How can we reproduce this? Please attach a failing example ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 19:52 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 From noreply at rubyforge.org Sat May 12 17:09:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 12 May 2007 17:09:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10805 ] selenium.rb missing from gem? Message-ID: <20070512210925.3865C5240ABF@rubyforge.org> Bugs item #10805, was opened at 2007-05-12 14:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10805&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Dees (undees) Assigned to: Nobody (None) Summary: selenium.rb missing from gem? Initial Comment: After a gem install of RSpec 0.9.4 and Spec::Ui 0.2.0, the line: require 'spec/ui/selenium' fails because selenium.rb is not in my Ruby tree. However, I can see the file in SVN, and when I paste its code into a new selenium.rb on my machine (PowerBook G4 running Tiger), all seems well. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10805&group_id=797 From noreply at rubyforge.org Sun May 13 18:42:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 18:42:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10753 ] Global before and after Message-ID: <20070513224226.B9FC95240B77@rubyforge.org> Feature Requests item #10753, was opened at 2007-05-10 17:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Assaf Arkin (assaf) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Global before and after Initial Comment: Side effects be damned. Unfortunately, we're running test cases in an environment that has a lot of them, so we need to sandbox the environment before every test, and reset it after every test. Shared behavior works, but you need to include them in every single describe. Redundant. I eventually settled on this, hoping it will not break come 1.0: Spec::Runner.configure { |config| config.include Sandbox } class Spec::DSL::Behaviour before(:each) { sandbox } after(:each) { reset } end How about an easier way that will be a formal part of RSpec? ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 18:42 Message: Fixed in r1951 (What David suggested) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-10 17:21 Message: How about integrating before/after into the config: Spec::Runner.configure do |config| config.include Sandbox config.before(:each) { sandbox } config.after(:each) { reset } end This is sort of what we were thinking anyhow - does that work for you? Note that config.before would happen BEFORE any before blocks in any given behaviour, whereas config.after would happen AFTER any after blocks in the behaviour. There is a way to override that, but it gets complicated. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 From noreply at rubyforge.org Sun May 13 18:42:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 18:42:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10774 ] Allow before and after to be specified in config II Message-ID: <20070513224248.A8C2B5240B79@rubyforge.org> Feature Requests item #10774, was opened at 2007-05-11 08:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10774&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Allow before and after to be specified in config II Initial Comment: This issue is about the before/after part only of: http://rubyforge.org/tracker/index.php?func=detail&aid=10770&group_id=797&atid=3152 Spec::Runner.configure do |config| config.before(:all) do # This will run for all Behaviours end config.before(:all, :behaviour_type => 'watir') do # This will only run for Watir behaviours @browser = Watir::Browser.new end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 18:42 Message: Fixed in r1951 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10774&group_id=797 From noreply at rubyforge.org Sun May 13 18:43:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 18:43:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10805 ] selenium.rb missing from gem? Message-ID: <20070513224324.E556C5240B77@rubyforge.org> Bugs item #10805, was opened at 2007-05-12 17:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10805&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Ian Dees (undees) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: selenium.rb missing from gem? Initial Comment: After a gem install of RSpec 0.9.4 and Spec::Ui 0.2.0, the line: require 'spec/ui/selenium' fails because selenium.rb is not in my Ruby tree. However, I can see the file in SVN, and when I paste its code into a new selenium.rb on my machine (PowerBook G4 running Tiger), all seems well. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 18:43 Message: Fixed in r1951 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10805&group_id=797 From noreply at rubyforge.org Sun May 13 18:47:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 18:47:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10753 ] Global before and after Message-ID: <20070513224716.76C1D5240B79@rubyforge.org> Feature Requests item #10753, was opened at 2007-05-10 21:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 Category: runner module Group: None Status: Closed Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Global before and after Initial Comment: Side effects be damned. Unfortunately, we're running test cases in an environment that has a lot of them, so we need to sandbox the environment before every test, and reset it after every test. Shared behavior works, but you need to include them in every single describe. Redundant. I eventually settled on this, hoping it will not break come 1.0: Spec::Runner.configure { |config| config.include Sandbox } class Spec::DSL::Behaviour before(:each) { sandbox } after(:each) { reset } end How about an easier way that will be a formal part of RSpec? ---------------------------------------------------------------------- >Comment By: Assaf Arkin (assaf) Date: 2007-05-13 22:47 Message: Thanks. That's exactly what we need. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 22:42 Message: Fixed in r1951 (What David suggested) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-10 21:21 Message: How about integrating before/after into the config: Spec::Runner.configure do |config| config.include Sandbox config.before(:each) { sandbox } config.after(:each) { reset } end This is sort of what we were thinking anyhow - does that work for you? Note that config.before would happen BEFORE any before blocks in any given behaviour, whereas config.after would happen AFTER any after blocks in the behaviour. There is a way to override that, but it gets complicated. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797 From noreply at rubyforge.org Sun May 13 19:02:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 19:02:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10744 ] should raise_error not working in new controller specs Message-ID: <20070513230227.CDDD05240B79@rubyforge.org> Bugs item #10744, was opened at 2007-05-10 16:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: should raise_error not working in new controller specs Initial Comment: I have the following spec it "Should raise exception when ***" do lambda{post :index, :key => '987'}.should raise_error(Exception) end which fails because of 'The LoginController Should raise exception when packet is not found' FAILED expected Exception but nothing was raised login_controller_spec.rb:42: and in the controller i have an index method which does throw an exception, which I can verify by wrapping it in a begin/rescue block, but the spec still fails. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-13 23:02 Message: FYI - with the addition of Global before and after (http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10753&group_id=797), you can now do this: Spec::Runner.configure do |config| config.before(:each, :behaviour_type => :controller) do controller.class.send(:define_method, :rescue_action) do |e| raise e end end end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 12:42 Message: By default, Rails swallows exceptions and returns error codes in headers (see actionpack/lib/action_controller/rescue.rb). Controller specs in 0.8.x and earlier used to override the default behaviour like this: @controller_class.send(:define_method, :rescue_action) { |e| raise e } This would cause errors thrown in actions to be thrown in the specs. Unfortunately, it also overrode custom rescue_actions (see http://rubyforge.org/tracker/?group_id=797&atid=3149&func=detail&aid=9767). I'm closing this as this is now the expected behaviour. I've added the following rdoc for ControllerBehaviour: # == Expecting Errors # # By default, Rails will swallow errors that are raised in controller # actions and return an error code in the header. If you want to # specify that an action should raise an error, you can either # override rescue_action in your controller ... # # before(:each) do # controller.class.send(:define_method, :rescue_action) { |e| raise e } # end # # ... or you can expect error codes in headers ... # # it "should return an error in the header" do # response.should be_error # end # # it "should return a 501" do # response.response_code.should == 501 # end # # it "should return a 501" do # response.code.should == "501" # end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 19:54 Message: Does your spec fail if you remove the lambda and just do: post :index, :key => '987' How can we reproduce this? Please attach a failing example ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 19:52 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10744&group_id=797 From noreply at rubyforge.org Sun May 13 19:03:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 19:03:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10814 ] Runner loads shared code, test cases require them again Message-ID: <20070513230325.165135240B82@rubyforge.org> Feature Requests item #10814, was opened at 2007-05-13 23:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Nobody (None) Summary: Runner loads shared code, test cases require them again Initial Comment: Our test directory contains one file that provides methods and behaviores shared by all other test files. To run individual files, each one requires that shared file. However, when running spec test, RSpec loads all the files from the test directory (and its sub-directories). So the file gets loaded once (by RSpec) and required once (by the test files), and interpreted twice (by Ruby). Some of the code doesn't like that. The current workaround is to detect the second load and ignore it (e.g. unless defined?(SomeConst)). But given the amount of time it took to find the culprit and work around it, can RSpec require the file instead, or allow a directory of shared behaviors not loaded by default? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 From noreply at rubyforge.org Sun May 13 19:04:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 19:04:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10791 ] A 'switch between source and spec file' command for textmate (with auto-creation!) Message-ID: <20070513230446.885045240B79@rubyforge.org> Patches item #10791, was opened at 2007-05-12 01:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10791&group_id=797 Category: None Group: Unstable (example) Status: Open Resolution: None Priority: 3 Submitted By: Ruy Asan (rubyruy) Assigned to: Nobody (None) Summary: A 'switch between source and spec file' command for textmate (with auto-creation!) Initial Comment: There is a great deal of switching back and forth between source and spec files when doing RSpec. The official tmbundle could probably benefit from this. Unforunately, I started writing this for just-my-own-use, so as a result it's not very pretty, needs to be tested, integrated with the various (and annoyingly un-documented) textmate libs and packaged. If a fellow text-mater wants to clean it up and add it to the official bundle, please do :) If not, I'll probably make it into a proper patch when I get some time. Source (and added info) here: http://ruy.ca/posts/6-A-simple-switch-between-source-and-spec-file-command-for-textmate-with-auto-creation- ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 19:04 Message: Very nice, but I have two problems: 1) When I run the command, TextMate complains: command not found: mate /path/to/some/file 2) There are no specs for this. It won't get in without specs. I recommend adding to the existing specs for RSpec.tmbundle. You can also add some fixtures (Some app/spec file pairs). The specs should be decoupled from TextMate itself. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10791&group_id=797 From noreply at rubyforge.org Sun May 13 20:58:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 May 2007 20:58:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10791 ] A 'switch between source and spec file' command for textmate (with auto-creation!) Message-ID: <20070514005806.56ED35240B43@rubyforge.org> Patches item #10791, was opened at 2007-05-12 05:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10791&group_id=797 Category: None Group: Unstable (example) Status: Open Resolution: None Priority: 3 Submitted By: Ruy Asan (rubyruy) Assigned to: Nobody (None) Summary: A 'switch between source and spec file' command for textmate (with auto-creation!) Initial Comment: There is a great deal of switching back and forth between source and spec files when doing RSpec. The official tmbundle could probably benefit from this. Unforunately, I started writing this for just-my-own-use, so as a result it's not very pretty, needs to be tested, integrated with the various (and annoyingly un-documented) textmate libs and packaged. If a fellow text-mater wants to clean it up and add it to the official bundle, please do :) If not, I'll probably make it into a proper patch when I get some time. Source (and added info) here: http://ruy.ca/posts/6-A-simple-switch-between-source-and-spec-file-command-for-textmate-with-auto-creation- ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-14 00:58 Message: On Point #1, you may need to use the textmate url syntax: tmate://path/to/file that's what the rails tmbundle uses to open files inside the already open project. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 23:04 Message: Very nice, but I have two problems: 1) When I run the command, TextMate complains: command not found: mate /path/to/some/file 2) There are no specs for this. It won't get in without specs. I recommend adding to the existing specs for RSpec.tmbundle. You can also add some fixtures (Some app/spec file pairs). The specs should be decoupled from TextMate itself. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10791&group_id=797 From brian.takita at gmail.com Mon May 14 00:56:18 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 13 May 2007 21:56:18 -0700 Subject: [rspec-devel] mock frameworks In-Reply-To: <57c63afe0705070443p12046c05off053706e844c129@mail.gmail.com> References: <57c63afe0705070443p12046c05off053706e844c129@mail.gmail.com> Message-ID: <1d7ddd110705132156vb51eb70vd1c0f6f657a62057@mail.gmail.com> I'm considering using Mocha + Mocha Shot. http://rubyforge.org/projects/mocha-shot There are some things that are in Rspec's mocking framework that are missing in Mocha though. For example, in spec/mock, #and_return takes a block that gets executed and accepts the arguments passed to the method. Oh well, I guess nothing is "perfect" :) On 5/7/07, David Chelimsky wrote: > > Just curious - now that rspec (as of 0.9) let's you choose your mock > framework, how many of you are actually using (or planning to use) > mocha or flexmock? > > Anybody planning to use any other mock framework besides rspec, mocha > or flexmock? > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070513/063b475a/attachment.html From noreply at rubyforge.org Mon May 14 01:13:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 01:13:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10794 ] Fixtures do not work in Helper Specs Message-ID: <20070514051357.E46185240BBF@rubyforge.org> Bugs item #10794, was opened at 2007-05-12 02:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Fixtures do not work in Helper Specs Initial Comment: It seems that fixture support for Helper examples has been taken out.. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-13 22:13 Message: They where working as of 0.9.3. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 04:59 Message: Did they ever work? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 From noreply at rubyforge.org Mon May 14 01:33:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 01:33:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10673 ] should & gt; and should & gt; = broken Message-ID: <20070514053319.AEE675240BC4@rubyforge.org> Bugs item #10673, was opened at 2007-05-07 16:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) >Summary: should &gt; and should &gt;= broken Initial Comment: should == still works ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-13 22:33 Message: The convention being proposed has two pulls. Pros: Predictability of syntax (be's usage here can be seen as a special case) Compatible with < 0.9.0 specs Brevity (to a lesser extent) Cons: Not grammatically correct There is also the question of should we support both ways. Here lies the standard more than one way to do it vs. minimalist interface arguments. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 15:38 Message: Anything's posssible, but it doesn't read as well that way: "5 should greater than 3"???? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-07 23:30 Message: I got bitten by the same thing the other day. It was very unintuitive to me to have to put the be in front. Is it possible to lose the "be" for these? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-07 18:17 Message: This is really a doc issue. Here is what is supported: should == should_not == should be > should be >= should be <= should be < I'll make sure the docs are clear. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-07 16:27 Message: should < and should <= doesn't work either. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 From noreply at rubyforge.org Mon May 14 02:21:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 02:21:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10794 ] Fixtures do not work in Helper Specs Message-ID: <20070514062153.607CC5240BC5@rubyforge.org> Bugs item #10794, was opened at 2007-05-12 05:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Fixtures do not work in Helper Specs Initial Comment: It seems that fixture support for Helper examples has been taken out.. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-14 02:21 Message: Strange. Time to do some diff debugging? http://www.martinfowler.com/bliki/DiffDebugging.html ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-14 01:13 Message: They where working as of 0.9.3. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 07:59 Message: Did they ever work? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 From noreply at rubyforge.org Mon May 14 02:50:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 02:50:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10819 ] rake pre_commit seems to be broken on Linux Message-ID: <20070514065041.5A6535240BC4@rubyforge.org> Bugs item #10819, was opened at 2007-05-13 23:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: rake pre_commit seems to be broken on Linux Initial Comment: I'll try to fix soon, but don't know if I will get a chance to before Rails conf. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 From noreply at rubyforge.org Mon May 14 02:51:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 02:51:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10819 ] rake pre_commit seems to be broken on Linux Message-ID: <20070514065105.05CC15240BA2@rubyforge.org> Bugs item #10819, was opened at 2007-05-13 23:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: rake pre_commit seems to be broken on Linux Initial Comment: I'll try to fix soon, but don't know if I will get a chance to before Rails conf. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-13 23:51 Message: TMBundle and Drb issues. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 From noreply at rubyforge.org Mon May 14 02:51:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 02:51:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10819 ] rake pre_commit seems to be broken on Linux Message-ID: <20070514065140.09ABE5240BA2@rubyforge.org> Bugs item #10819, was opened at 2007-05-13 23:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: rake pre_commit seems to be broken on Linux Initial Comment: I'll try to fix soon, but don't know if I will get a chance to before Rails conf. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-13 23:51 Message: 1) RuntimeError in 'SpecMate should run all selected files' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 2) RuntimeError in 'SpecMate should run first spec when file and line 8 specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 3) RuntimeError in 'SpecMate should run first spec when file and line 4 specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 4) RuntimeError in 'SpecMate should run whole file when only file specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 5) Timeout::Error in 'DrbCommandLine with local server should output red colorized text when running with -c option' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:41: 6) Timeout::Error in 'DrbCommandLine with local server should output green colorized text when running with --colour option' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:36: 7) Timeout::Error in 'DrbCommandLine with local server should run against local server' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:31: 8) Timeout::Error in 'DrbCommandLine without running local server should print error when there is no running local server' execution expired ./spec/spec/runner/drb_command_line_spec.rb:9: ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-13 23:51 Message: TMBundle and Drb issues. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 From noreply at rubyforge.org Mon May 14 02:52:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 02:52:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10819 ] rake pre_commit seems to be broken on Linux Message-ID: <20070514065206.CED925240BC4@rubyforge.org> Bugs item #10819, was opened at 2007-05-13 23:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: rake pre_commit seems to be broken on Linux Initial Comment: I'll try to fix soon, but don't know if I will get a chance to before Rails conf. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-13 23:52 Message: These specs run fine on their own. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-13 23:51 Message: 1) RuntimeError in 'SpecMate should run all selected files' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 2) RuntimeError in 'SpecMate should run first spec when file and line 8 specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 3) RuntimeError in 'SpecMate should run first spec when file and line 4 specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 4) RuntimeError in 'SpecMate should run whole file when only file specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 5) Timeout::Error in 'DrbCommandLine with local server should output red colorized text when running with -c option' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:41: 6) Timeout::Error in 'DrbCommandLine with local server should output green colorized text when running with --colour option' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:36: 7) Timeout::Error in 'DrbCommandLine with local server should run against local server' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:31: 8) Timeout::Error in 'DrbCommandLine without running local server should print error when there is no running local server' execution expired ./spec/spec/runner/drb_command_line_spec.rb:9: ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-13 23:51 Message: TMBundle and Drb issues. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 From noreply at rubyforge.org Mon May 14 03:06:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 03:06:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10819 ] rake pre_commit seems to be broken on Linux Message-ID: <20070514070645.3BE245240BC4@rubyforge.org> Bugs item #10819, was opened at 2007-05-14 02:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: rake pre_commit seems to be broken on Linux Initial Comment: I'll try to fix soon, but don't know if I will get a chance to before Rails conf. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-14 03:06 Message: The timeout ones can probably be fixed by increasing the timeout value in spec.opts ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-14 02:52 Message: These specs run fine on their own. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-14 02:51 Message: 1) RuntimeError in 'SpecMate should run all selected files' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 2) RuntimeError in 'SpecMate should run first spec when file and line 8 specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 3) RuntimeError in 'SpecMate should run first spec when file and line 4 specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 4) RuntimeError in 'SpecMate should run whole file when only file specified' TM_RSPEC_HOME points to a bad location: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb ../RSpec.tmbundle/Support/spec/../lib/spec_mate.rb:10: ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18:in `load' ../RSpec.tmbundle/Support/spec/spec_mate_spec.rb:18: 5) Timeout::Error in 'DrbCommandLine with local server should output red colorized text when running with -c option' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:41: 6) Timeout::Error in 'DrbCommandLine with local server should output green colorized text when running with --colour option' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:36: 7) Timeout::Error in 'DrbCommandLine with local server should run against local server' execution expired ./spec/spec/runner/drb_command_line_spec.rb:67:in `run_spec_via_druby' ./spec/spec/runner/drb_command_line_spec.rb:31: 8) Timeout::Error in 'DrbCommandLine without running local server should print error when there is no running local server' execution expired ./spec/spec/runner/drb_command_line_spec.rb:9: ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-14 02:51 Message: TMBundle and Drb issues. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10819&group_id=797 From noreply at rubyforge.org Mon May 14 09:07:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 09:07:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10823 ] separate errors and failures in output Message-ID: <20070514130737.4AB3952409BF@rubyforge.org> Feature Requests item #10823, was opened at 2007-05-14 13:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10823&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: separate errors and failures in output Initial Comment: Observe the following output: ========================= $ spec user_spec.rb --format specdoc User - should be in any roles assigned to it (ERROR - 1) - should NOT be in any roles not assigned to it (FAILED - 2) 1) NameError in 'User should be in any roles assigned to it' undefined local variable or method `user' for #<#:0x14ec6a8> ./user_spec.rb:6: 2) 'User should NOT be in any roles not assigned to it' FAILED expected in_role?("unassigned role") to return false, got true ./user_spec.rb:12: Finished in 0.017713 seconds 2 examples, 2 failures ========================= The specdoc output makes a distinction between errors that are raised (ERROR - 1) and logical failures (FAILED - 2), but the last line of the output does not (2 examples, 2 failures). The last line should make the distinction the same way the detailed output does: 2 examples, 1 failure, 1 error ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10823&group_id=797 From noreply at rubyforge.org Mon May 14 10:45:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 10:45:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6397 ] Support headers and session variables in http requests Message-ID: <20070514144538.CCE6A5240B3E@rubyforge.org> Feature Requests item #6397, was opened at 2006-10-30 16:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jeff Dean (jefdean) Assigned to: Nobody (None) Summary: Support headers and session variables in http requests Initial Comment: [the following is a duplicate comment from one I posted on the mailing list because rubyforge logins were down for a while...] I'd love to see better support for specifying headers headers and session variables to the http requests - something like: _verb_(action, parameters=nil, session_vars=nil, headers=nil) This way we could write: get(:index, {:id=>1}, {:user=>@user}, {:accept=>'application/...'}) Or add some syntactic sugar such as: get(:index, {}, {}, {:format=>:js}) to simulate xml/javascript/mobile device formats. I'll start working on this shortly unless anyone else has the time to do it easily and quickly. ---------------------------------------------------------------------- Comment By: Douglas Tan (bianster) Date: 2007-05-14 22:45 Message: Has any progress been made regarding this? I'll like to help with implementing the feature. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-31 08:24 Message: I don't think anyone is working on it. Make sure you submit specs too :-) I haven't looked into the details, but you might actually have to patch zentest, since rspec on rails builds on it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797 From noreply at rubyforge.org Mon May 14 11:16:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 May 2007 11:16:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6397 ] Support headers and session variables in http requests Message-ID: <20070514151615.42DD45240AD7@rubyforge.org> Feature Requests item #6397, was opened at 2006-10-30 03:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jeff Dean (jefdean) Assigned to: Nobody (None) Summary: Support headers and session variables in http requests Initial Comment: [the following is a duplicate comment from one I posted on the mailing list because rubyforge logins were down for a while...] I'd love to see better support for specifying headers headers and session variables to the http requests - something like: _verb_(action, parameters=nil, session_vars=nil, headers=nil) This way we could write: get(:index, {:id=>1}, {:user=>@user}, {:accept=>'application/...'}) Or add some syntactic sugar such as: get(:index, {}, {}, {:format=>:js}) to simulate xml/javascript/mobile device formats. I'll start working on this shortly unless anyone else has the time to do it easily and quickly. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-14 11:16 Message: Noone has been working on it. Feel free to contribute a patch. Since I last commented on this issue RSpec no longer depends on zentest. ---------------------------------------------------------------------- Comment By: Douglas Tan (bianster) Date: 2007-05-14 10:45 Message: Has any progress been made regarding this? I'll like to help with implementing the feature. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-30 19:24 Message: I don't think anyone is working on it. Make sure you submit specs too :-) I haven't looked into the details, but you might actually have to patch zentest, since rspec on rails builds on it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797 From jamesmead44 at gmail.com Mon May 14 14:09:07 2007 From: jamesmead44 at gmail.com (James Mead) Date: Mon, 14 May 2007 19:09:07 +0100 Subject: [rspec-devel] mock frameworks In-Reply-To: <1d7ddd110705132156vb51eb70vd1c0f6f657a62057@mail.gmail.com> References: <57c63afe0705070443p12046c05off053706e844c129@mail.gmail.com> <1d7ddd110705132156vb51eb70vd1c0f6f657a62057@mail.gmail.com> Message-ID: <1db558f00705141109i369cb652gdd7f644693f407a6@mail.gmail.com> Hi Brian, On 14/05/07, Brian Takita wrote: > I'm considering using Mocha + Mocha Shot. > http://rubyforge.org/projects/mocha-shot Nice one! I like some of the ideas in this. Sorry not to have been more responsive - things are as busy as ever at Reevoo. > There are some things that are in Rspec's mocking framework that are missing > in Mocha though. > For example, in spec/mock, #and_return takes a block that gets executed and > accepts the arguments passed to the method. The Mocha returns() method can currently take an instance of a Proc which you can use to define more complex behaviour. However it is true that the parameters of the method are not passed to this Proc. But this is intentional. Because you are completely and deterministically in control of all the objects involved in the test, you should know what sequence of return values you need to return from the mock. So you can use something like... m = mock() m.stubs(:method).returns(1, 2, 3).then.raises(Exception).then.returns(5). The fact that you need to know the parameters being passed in to the stubbed method in order to work out what to return is probably a sign that you are testing too much at once. Anyway, if you need that degree of control, why not simply use define_method. Or use a Rails-style "mock" (i.e. hard-coded fake class). For similar reasons the ability of the returns() method to take an instance of a Proc will probably be phased out soon. Does that make sense? -- James. http://blog.floehopper.org From noreply at rubyforge.org Tue May 15 00:54:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 May 2007 00:54:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10794 ] Fixtures do not work in Helper Specs Message-ID: <20070515045454.37D675240BE5@rubyforge.org> Bugs item #10794, was opened at 2007-05-12 02:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Fixtures do not work in Helper Specs Initial Comment: It seems that fixture support for Helper examples has been taken out.. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-14 21:54 Message: The fix is to add a call to configure in HelperBehaviour#before_eval. I would add it, but my precommit is failing :( ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 23:21 Message: Strange. Time to do some diff debugging? http://www.martinfowler.com/bliki/DiffDebugging.html ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-13 22:13 Message: They where working as of 0.9.3. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 04:59 Message: Did they ever work? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 From noreply at rubyforge.org Tue May 15 01:42:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 May 2007 01:42:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10794 ] Fixtures do not work in Helper Specs Message-ID: <20070515054247.6C0BD5240C1F@rubyforge.org> Bugs item #10794, was opened at 2007-05-12 09:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: Brian Takita (btakita) Summary: Fixtures do not work in Helper Specs Initial Comment: It seems that fixture support for Helper examples has been taken out.. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-15 05:42 Message: I just fixed a bug in the spec_mate_spec (the spec, not the code) and got pre_commit passing again. Feel free to go ahead an fix this. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-15 04:54 Message: The fix is to add a call to configure in HelperBehaviour#before_eval. I would add it, but my precommit is failing :( ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-14 06:21 Message: Strange. Time to do some diff debugging? http://www.martinfowler.com/bliki/DiffDebugging.html ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-14 05:13 Message: They where working as of 0.9.3. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 11:59 Message: Did they ever work? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 From noreply at rubyforge.org Tue May 15 20:35:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 May 2007 20:35:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10814 ] Runner loads shared code, test cases require them again Message-ID: <20070516003540.C8F6452409FF@rubyforge.org> Feature Requests item #10814, was opened at 2007-05-13 23:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Nobody (None) Summary: Runner loads shared code, test cases require them again Initial Comment: Our test directory contains one file that provides methods and behaviores shared by all other test files. To run individual files, each one requires that shared file. However, when running spec test, RSpec loads all the files from the test directory (and its sub-directories). So the file gets loaded once (by RSpec) and required once (by the test files), and interpreted twice (by Ruby). Some of the code doesn't like that. The current workaround is to detect the second load and ignore it (e.g. unless defined?(SomeConst)). But given the amount of time it took to find the culprit and work around it, can RSpec require the file instead, or allow a directory of shared behaviors not loaded by default? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-16 00:35 Message: How about an "exclude" command line option? spec spec --exclude spec/shared.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 From noreply at rubyforge.org Tue May 15 22:21:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 May 2007 22:21:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10814 ] Runner loads shared code, test cases require them again Message-ID: <20070516022106.BAF3552409B7@rubyforge.org> Feature Requests item #10814, was opened at 2007-05-13 23:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Nobody (None) Summary: Runner loads shared code, test cases require them again Initial Comment: Our test directory contains one file that provides methods and behaviores shared by all other test files. To run individual files, each one requires that shared file. However, when running spec test, RSpec loads all the files from the test directory (and its sub-directories). So the file gets loaded once (by RSpec) and required once (by the test files), and interpreted twice (by Ruby). Some of the code doesn't like that. The current workaround is to detect the second load and ignore it (e.g. unless defined?(SomeConst)). But given the amount of time it took to find the culprit and work around it, can RSpec require the file instead, or allow a directory of shared behaviors not loaded by default? ---------------------------------------------------------------------- >Comment By: Assaf Arkin (assaf) Date: 2007-05-16 02:21 Message: More pain than it's worth. I'm going to have to explain to every developer how to properly run the test cases, they're of course not going to RTFM, so their first attempt will fail miserably. And with each project deciding to exclude a different file ... Is there a particular reason for RSpec to use load instead of require? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-16 00:35 Message: How about an "exclude" command line option? spec spec --exclude spec/shared.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 From noreply at rubyforge.org Tue May 15 23:35:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 May 2007 23:35:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10814 ] Runner loads shared code, test cases require them again Message-ID: <20070516033518.226BE5240C54@rubyforge.org> Feature Requests item #10814, was opened at 2007-05-13 23:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 Category: runner / command line Group: None >Status: Closed Priority: 3 Submitted By: Assaf Arkin (assaf) >Assigned to: David Chelimsky (dchelimsky) Summary: Runner loads shared code, test cases require them again Initial Comment: Our test directory contains one file that provides methods and behaviores shared by all other test files. To run individual files, each one requires that shared file. However, when running spec test, RSpec loads all the files from the test directory (and its sub-directories). So the file gets loaded once (by RSpec) and required once (by the test files), and interpreted twice (by Ruby). Some of the code doesn't like that. The current workaround is to detect the second load and ignore it (e.g. unless defined?(SomeConst)). But given the amount of time it took to find the culprit and work around it, can RSpec require the file instead, or allow a directory of shared behaviors not loaded by default? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-16 03:35 Message: No reason. Fixed in r1958. ---------------------------------------------------------------------- Comment By: Assaf Arkin (assaf) Date: 2007-05-16 02:21 Message: More pain than it's worth. I'm going to have to explain to every developer how to properly run the test cases, they're of course not going to RTFM, so their first attempt will fail miserably. And with each project deciding to exclude a different file ... Is there a particular reason for RSpec to use load instead of require? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-16 00:35 Message: How about an "exclude" command line option? spec spec --exclude spec/shared.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 From noreply at rubyforge.org Wed May 16 00:03:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 May 2007 00:03:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10718 ] Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Message-ID: <20070516040307.07DCA5240A77@rubyforge.org> Feature Requests item #10718, was opened at 2007-05-09 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Chris Hoffman (hoffman_c) Assigned to: Nobody (None) Summary: Add :locals hash to 'it_should_behave_like' method (SharedBehavior) Initial Comment: It would be great if we could pass arbitrary variables into the shared behavior specs, for things such as differing controller actions. Right now, I'm having to do the following: before(:all) do @action = "foo" end it_should_behave_like "CRUD" Instead, I could imagine something like the following, a la partial locals: it_should_behave_like "CRUD", :locals => { :action => "foo" } ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-16 04:03 Message: It happens implicitly. Calling #it_should_behave_like copies all the exampls from the shared behaviour into the current behaviour. Any local variables defined before(:each) example are available in each example. ---------------------------------------------------------------------- Comment By: Chris Hoffman (hoffman_c) Date: 2007-05-09 15:19 Message: how would @thing be assigned in the call to it_should_behave_like in your example? I was imagining that a local 'thing' variable would get assigned, perhaps with block locals. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 15:10 Message: Interesting idea but there's a disconnect. Locals are actually slung over to another scope (the partial), whereas shared examples are all executed in the same scope as any non-shared examples. It's, conceptually, a different animal, that will surely lead to confusion when you start doing this: describe Thing do before(:each) do @thing = Thing.new(:some_state) end it_should_behave_like "other things", :locals => { :thing => Thing.new(:some_other_state) } it "should do something unique" do @thing.should write_novels end end In this case, both assignments to @thing happen in the same context, so the last one executed wins. I, personally, would rather not have to debug that scenario. Other thoughts? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797 From noreply at rubyforge.org Wed May 16 01:00:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 May 2007 01:00:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10814 ] Runner loads shared code, test cases require them again Message-ID: <20070516050043.52C9A5240A77@rubyforge.org> Feature Requests item #10814, was opened at 2007-05-13 23:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 Category: runner / command line Group: None Status: Closed Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: David Chelimsky (dchelimsky) Summary: Runner loads shared code, test cases require them again Initial Comment: Our test directory contains one file that provides methods and behaviores shared by all other test files. To run individual files, each one requires that shared file. However, when running spec test, RSpec loads all the files from the test directory (and its sub-directories). So the file gets loaded once (by RSpec) and required once (by the test files), and interpreted twice (by Ruby). Some of the code doesn't like that. The current workaround is to detect the second load and ignore it (e.g. unless defined?(SomeConst)). But given the amount of time it took to find the culprit and work around it, can RSpec require the file instead, or allow a directory of shared behaviors not loaded by default? ---------------------------------------------------------------------- >Comment By: Assaf Arkin (assaf) Date: 2007-05-16 05:00 Message: Thanks! Assaf ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-16 03:35 Message: No reason. Fixed in r1958. ---------------------------------------------------------------------- Comment By: Assaf Arkin (assaf) Date: 2007-05-16 02:21 Message: More pain than it's worth. I'm going to have to explain to every developer how to properly run the test cases, they're of course not going to RTFM, so their first attempt will fail miserably. And with each project deciding to exclude a different file ... Is there a particular reason for RSpec to use load instead of require? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-16 00:35 Message: How about an "exclude" command line option? spec spec --exclude spec/shared.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797 From evgeny.zislis at gmail.com Wed May 16 06:32:47 2007 From: evgeny.zislis at gmail.com (Evgeny) Date: Wed, 16 May 2007 13:32:47 +0300 Subject: [rspec-devel] More DRY in descriptions Message-ID: Greetings All, I have been writing some code with rSpec (0.9.x) for a new project, and I notice that there is a thing I keep repeating myself on. Best shown in a short example: describe ClassNameForSomeUser, "when first created" do it "should fail when no name provided" do lambda { ClassNameForSomeUser.new(:name => nil) }.should raise_error(ArgumentError, "No name provided") end it "should fail when something else is wrong" do lambda { ClassNameForSomeUser.new(:wrongparam => true) }.should raise_error SomethingBad end end naturally there are many more descriptions in there, so to make it just a little bit more DRY I did this: describe ClassNameForSomeUser, "when first created" do before(:each) do @UCN = ClassNameForSomeUser end it "should fail when no name provided" do lambda { @UCN.new(:name => nil) }.should raise_error(ArgumentError, "No name provided") end it "should fail when something else is wrong" do lambda { @UCN.new(:wrongparam => true) }.should raise_error SomethingBad end end But then I notice that when I write "describe" I specify the class name already, so why not use it in some way? Is it possible to do something like : describe ClassNameForSomeUser, "when first created" do it "should fail when no name provided" do lambda { this_class.new(:name => nil) }.should raise_error(ArgumentError, "No name provided") end it "should fail when something else is wrong" do lambda { this_class.new(:wrongparam => true) }.should raise_error SomethingBad end end is this possible, or anything similar? Regards, - evgeny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070516/1dc89938/attachment.html From noreply at rubyforge.org Wed May 16 18:13:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 May 2007 18:13:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10871 ] 0.9.4 - Focussed spec runner fails to run specs in descriptions with type and string when there is no leading space in the string Message-ID: <20070516221308.17D0F5240A2F@rubyforge.org> Bugs item #10871, was opened at 2007-05-16 22:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10871&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nathan Sobo (nathansobo) Assigned to: Nobody (None) Summary: 0.9.4 - Focussed spec runner fails to run specs in descriptions with type and string when there is no leading space in the string Initial Comment: if there is no space before "bar" like " bar" then the focussed runner breaks. I admit there should be a space there but this is a confusing bug for people that don't know that. Maybe one should be inserted automatically if it is missing. describe Foo, "bar" do it "this does not get run in a focussed spec" do true.should be_true end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10871&group_id=797 From dchelimsky at gmail.com Wed May 16 21:13:26 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 16 May 2007 18:13:26 -0700 Subject: [rspec-devel] More DRY in descriptions In-Reply-To: References: Message-ID: <57c63afe0705161813y71aa0161r16c0c691804f86fb@mail.gmail.com> On 5/16/07, Evgeny wrote: > Greetings All, > > I have been writing some code with rSpec (0.9.x) for a new project, > and I notice that there is a thing I keep repeating myself on. > > Best shown in a short example: > > describe ClassNameForSomeUser, "when first created" do > it "should fail when no name provided" do > lambda { ClassNameForSomeUser.new(:name => nil) }.should > raise_error(ArgumentError, "No name provided") > end > it "should fail when something else is wrong" do > lambda { ClassNameForSomeUser.new(:wrongparam => true) }.should > raise_error SomethingBad > end > end > > naturally there are many more descriptions in there, so to make it just a > little bit more DRY I did this: > > describe ClassNameForSomeUser, "when first created" do > before(:each) do > @UCN = ClassNameForSomeUser > end > it "should fail when no name provided" do > lambda { @UCN.new(:name => nil) }.should raise_error(ArgumentError, "No > name provided") > end > it "should fail when something else is wrong" do > lambda { @UCN.new(:wrongparam => true) }.should raise_error > SomethingBad > end > end > > But then I notice that when I write "describe" I specify the class name > already, so why not use it in some way? > Is it possible to do something like : > > describe ClassNameForSomeUser, "when first created" do > it "should fail when no name provided" do > lambda { this_class.new(:name => nil) }.should > raise_error(ArgumentError, "No name provided") > end > it "should fail when something else is wrong" do > lambda { this_class.new(:wrongparam => true) }.should raise_error > SomethingBad > end > end > > is this possible, or anything similar? Anything's possible, but don't think I'd like to see this added to RSpec. It's not really DRYing things up that much and, in larger examples, will just make things more difficult to understand IMO. I've written about this before - DRY is important, but in tests it is not as important as clarity. The reasons that DRY is useful in subject code don't all apply in tests. DRY is much more about objects than it is about typing a few less variables here and there, and tests are procedural. They might be expressed in objects, but they are still procedures. FWIW. David > > Regards, > > - evgeny > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Fri May 18 19:57:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 19:57:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10920 ] Added support for not implemented examples Message-ID: <20070518235740.15C765240AAA@rubyforge.org> Patches item #10920, was opened at 2007-05-18 19:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10920&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Added support for not implemented examples Initial Comment: This adds support for not implemented examples. This is achieved by creating examples without giving them a block ala: it "should do something awesome in the future" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10920&group_id=797 From noreply at rubyforge.org Fri May 18 19:59:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 19:59:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & amp; amp; quot; not implemented& amp; amp; quot; message for specs yet to be implemented Message-ID: <20070518235914.944FD5240AAA@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 06:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: &amp;amp;quot;not implemented&amp;amp;quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-05-18 19:59 Message: Related to patch #10920 ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 09:53 Message: David, I like that - it puts all the ideas in one consistent way. Not implemented would definitely be best for a spec with no block. Being a TextMate whore, I'm interested to know what the HTML output should be like. (I live off command-R .) I think for the individual specs, fail->red, pass->green, needs fixing->orange, not implemented->blue would be helpful. What I'm not sure about is whether the presence of a "not implemented" or "needs fixing" spec should constitute a failure of the whole spec file. Possibly something like this would help: specify "some unimportant features", :state => :needs_fixing, :blocker => false do # some failing specs end Not sure if this is over-engineering or not - it might be useful for continous integration (we we sadly don't use yet for rails) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 07:48 Message: Sorry - "not implemented" when there is no block or state specified (not "fail"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 07:47 Message: Ashley - between your suggestion of 4 states and Yurii's specify_negatively, I think perhaps something like this might work: specify "description", :state => state Where, for now, state could be any of the 4 you suggested. Also, the default state would be "pass" when there is a block (but no state submitted) and "fail" when there is no block (and no state submitted). WDYT? ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 07:07 Message: I'd really like this feature. I sometimes get into a situation where I need to leave failing specs and work on something else, and the noise is distracting. I'm tempted to suggest that 4 statuses would be useful: pass, fail, not yet implemented, needs fixing. I don't know if that would be a good idea, or over-complex. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-01-28 17:48 Message: At work, we have a tool that generates context/specify blocks from our test case descriptions. Here's what we use: 1) A NonImplementedTest class with an "implemented?" method returning false. 2) A module-level this_test method returning an instance of NonImplementedTest. So our tool can generate blocks that look like this: context "A widget" do specify "should foobar the frobnitz" do # Text from test case: # 1) Click the widget button. # 2) Make sure the frobnitz is foobar'ed. this_test.should_be_implemented end end That way, we start off red until all the tests are implemented and the software passes them. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-27 23:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 19:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 06:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 01:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Fri May 18 19:59:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 19:59:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10920 ] Added support for not implemented examples Message-ID: <20070518235919.2A4C05240B7C@rubyforge.org> Patches item #10920, was opened at 2007-05-18 19:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10920&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Added support for not implemented examples Initial Comment: This adds support for not implemented examples. This is achieved by creating examples without giving them a block ala: it "should do something awesome in the future" ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2007-05-18 19:59 Message: Related to Feature Request #8139 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10920&group_id=797 From noreply at rubyforge.org Fri May 18 20:01:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 20:01:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10097 ] Let rcov_verify allow greater coverages via configuration Message-ID: <20070519000135.22BD55240AAA@rubyforge.org> Feature Requests item #10097, was opened at 2007-04-13 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10097&group_id=797 Category: None Group: None >Status: Deleted Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Let rcov_verify allow greater coverages via configuration Initial Comment: I've attached a patch we use in most of our projects that allows simple configuration of the rcov_verify task. This leaves the default behaviour regarding thresholds, but allows for setting @require_exact_threshold = false to allow for overages. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10097&group_id=797 From noreply at rubyforge.org Fri May 18 20:04:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 20:04:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10921 ] Allow verify_rcov to accept greater than threshold coverage %'s via configuration Message-ID: <20070519000456.2E46F5240AAA@rubyforge.org> Patches item #10921, was opened at 2007-05-18 20:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Allow verify_rcov to accept greater than threshold coverage %'s via configuration Initial Comment: I've attached a patch we use in most of our projects that allows simple configuration of the rcov_verify task. This leaves the default behaviour regarding thresholds, but allows for setting @require_exact_threshold = false to allow for overages. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 From noreply at rubyforge.org Fri May 18 20:10:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 20:10:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10921 ] Allow verify_rcov to accept greater than threshold coverage %'s via configuration Message-ID: <20070519001002.707F75240B36@rubyforge.org> Patches item #10921, was opened at 2007-05-18 20:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: Allow verify_rcov to accept greater than threshold coverage %'s via configuration Initial Comment: I've attached a patch we use in most of our projects that allows simple configuration of the rcov_verify task. This leaves the default behaviour regarding thresholds, but allows for setting @require_exact_threshold = false to allow for overages. ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2007-05-18 20:10 Message: To clarify, sometimes powerpc and intel come up with numbers like 98.2% on intel, and 98.3% on ppc. This yields for wacking fun on your build server ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 From noreply at rubyforge.org Fri May 18 21:12:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 21:12:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10920 ] Added support for not implemented examples Message-ID: <20070519011228.547735240B4E@rubyforge.org> Patches item #10920, was opened at 2007-05-18 23:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10920&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Chad Humphries (spicycode) >Assigned to: David Chelimsky (dchelimsky) Summary: Added support for not implemented examples Initial Comment: This adds support for not implemented examples. This is achieved by creating examples without giving them a block ala: it "should do something awesome in the future" ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-19 01:12 Message: Applied to r1973 ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-05-18 23:59 Message: Related to Feature Request #8139 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10920&group_id=797 From noreply at rubyforge.org Fri May 18 21:15:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 21:15:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-8139 ] & amp; amp; amp; quot; not implemented& amp; amp; amp; quot; message for specs yet to be implemented Message-ID: <20070519011522.5C6435240B4E@rubyforge.org> Feature Requests item #8139, was opened at 2007-01-25 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) >Summary: &amp;amp;amp;quot;not implemented&amp;amp;amp;quot; message for specs yet to be implemented Initial Comment: If I am defining the behaviour of a class, I might make a list like this: Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 - should handle conversion I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them: context "Money behaviour" do specify "should parse" specify "should add" specify "should subtract" specify "should multiply" specify "should handle division by 0" specify "should handle conversion" end Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary: ===== Finished in 3.212354 seconds 647 specifications, 0 failures, 25 not yet implemented ===== Combined with the --format specdoc (or -fs) option, the report would look like this: ===== Money behaviour: - should parse - should add - should subtract - should multiply - should handle division by 0 (NOT IMPLEMENTED - should handle conversion (NOT IMPLEMENTED) Finished in 0.212354 seconds 6 specifications, 0 failures, 2 not yet implemented ===== This would a great aid in monitoring progress during an iteration. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-19 01:15 Message: Fixed by applying 10920 (r1973) ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-05-18 23:59 Message: Related to patch #10920 ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 14:53 Message: David, I like that - it puts all the ideas in one consistent way. Not implemented would definitely be best for a spec with no block. Being a TextMate whore, I'm interested to know what the HTML output should be like. (I live off command-R .) I think for the individual specs, fail->red, pass->green, needs fixing->orange, not implemented->blue would be helpful. What I'm not sure about is whether the presence of a "not implemented" or "needs fixing" spec should constitute a failure of the whole spec file. Possibly something like this would help: specify "some unimportant features", :state => :needs_fixing, :blocker => false do # some failing specs end Not sure if this is over-engineering or not - it might be useful for continous integration (we we sadly don't use yet for rails) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 12:48 Message: Sorry - "not implemented" when there is no block or state specified (not "fail"). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-02-26 12:47 Message: Ashley - between your suggestion of 4 states and Yurii's specify_negatively, I think perhaps something like this might work: specify "description", :state => state Where, for now, state could be any of the 4 you suggested. Also, the default state would be "pass" when there is a block (but no state submitted) and "fail" when there is no block (and no state submitted). WDYT? ---------------------------------------------------------------------- Comment By: Ashley Moran (ashley_moran) Date: 2007-02-26 12:07 Message: I'd really like this feature. I sometimes get into a situation where I need to leave failing specs and work on something else, and the noise is distracting. I'm tempted to suggest that 4 statuses would be useful: pass, fail, not yet implemented, needs fixing. I don't know if that would be a good idea, or over-complex. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-01-28 22:48 Message: At work, we have a tool that generates context/specify blocks from our test case descriptions. Here's what we use: 1) A NonImplementedTest class with an "implemented?" method returning false. 2) A module-level this_test method returning an instance of NonImplementedTest. So our tool can generate blocks that look like this: context "A widget" do specify "should foobar the frobnitz" do # Text from test case: # 1) Click the widget button. # 2) Make sure the frobnitz is foobar'ed. this_test.should_be_implemented end end That way, we start off red until all the tests are implemented and the software passes them. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-01-28 04:41 Message: This looks like a good feature. I like the idea of being able to specify what the software is supposed to do before implementing it. The specify method without a block transition s naturally to implementing a full spec. I remember the conclusion of the other feature request was to use a TODO statement, which in my opinion in not very semantic. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-27 00:12 Message: Hi David, I was just giving you a hard time. I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-01-26 11:29 Message: Hi Wilson, Funny - I forgot about that. OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere. Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword. This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords. I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour". ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2007-01-26 06:32 Message: Duplicate? :) http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797 From noreply at rubyforge.org Fri May 18 22:05:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 22:05:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10921 ] Allow verify_rcov to accept greater than threshold coverage %'s via configuration Message-ID: <20070519020535.41E655240B7D@rubyforge.org> Patches item #10921, was opened at 2007-05-18 20:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Allow verify_rcov to accept greater than threshold coverage %'s via configuration Initial Comment: I've attached a patch we use in most of our projects that allows simple configuration of the rcov_verify task. This leaves the default behaviour regarding thresholds, but allows for setting @require_exact_threshold = false to allow for overages. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-05-18 20:10 Message: To clarify, sometimes powerpc and intel come up with numbers like 98.2% on intel, and 98.3% on ppc. This yields for wacking fun on your build server ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 From noreply at rubyforge.org Fri May 18 22:06:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 22:06:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10794 ] Fixtures do not work in Helper Specs Message-ID: <20070519020648.196205240B80@rubyforge.org> Bugs item #10794, was opened at 2007-05-12 02:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Fixtures do not work in Helper Specs Initial Comment: It seems that fixture support for Helper examples has been taken out.. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-18 19:06 Message: Rev. 1976 We still need to add coverage to the other Rails specs. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-14 22:42 Message: I just fixed a bug in the spec_mate_spec (the spec, not the code) and got pre_commit passing again. Feel free to go ahead an fix this. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-14 21:54 Message: The fix is to add a call to configure in HelperBehaviour#before_eval. I would add it, but my precommit is failing :( ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-13 23:21 Message: Strange. Time to do some diff debugging? http://www.martinfowler.com/bliki/DiffDebugging.html ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-13 22:13 Message: They where working as of 0.9.3. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-12 04:59 Message: Did they ever work? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10794&group_id=797 From noreply at rubyforge.org Fri May 18 22:07:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 22:07:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10921 ] Allow verify_rcov to accept greater than threshold coverage %'s via configuration Message-ID: <20070519020726.805B65240B83@rubyforge.org> Patches item #10921, was opened at 2007-05-18 20:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Allow verify_rcov to accept greater than threshold coverage %'s via configuration Initial Comment: I've attached a patch we use in most of our projects that allows simple configuration of the rcov_verify task. This leaves the default behaviour regarding thresholds, but allows for setting @require_exact_threshold = false to allow for overages. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-05-18 20:10 Message: To clarify, sometimes powerpc and intel come up with numbers like 98.2% on intel, and 98.3% on ppc. This yields for wacking fun on your build server ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 From noreply at rubyforge.org Fri May 18 22:16:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 22:16:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10921 ] Allow verify_rcov to accept greater than threshold coverage %'s via configuration Message-ID: <20070519021635.B727F5240B78@rubyforge.org> Patches item #10921, was opened at 2007-05-18 20:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 Category: runner module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Allow verify_rcov to accept greater than threshold coverage %'s via configuration Initial Comment: I've attached a patch we use in most of our projects that allows simple configuration of the rcov_verify task. This leaves the default behaviour regarding thresholds, but allows for setting @require_exact_threshold = false to allow for overages. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-18 22:16 Message: Applied in r1977 ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2007-05-18 20:10 Message: To clarify, sometimes powerpc and intel come up with numbers like 98.2% on intel, and 98.3% on ppc. This yields for wacking fun on your build server ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10921&group_id=797 From noreply at rubyforge.org Fri May 18 22:20:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 22:20:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10673 ] should & gt; and should & gt; = broken Message-ID: <20070519022049.E49675240B7D@rubyforge.org> Bugs item #10673, was opened at 2007-05-07 23:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: David Chelimsky (dchelimsky) Summary: should &gt; and should &gt;= broken Initial Comment: should == still works ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-19 02:20 Message: Fixed in r1978. All supported operators work with or without "be": == === =~ > >= <= < ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-14 05:33 Message: The convention being proposed has two pulls. Pros: Predictability of syntax (be's usage here can be seen as a special case) Compatible with < 0.9.0 specs Brevity (to a lesser extent) Cons: Not grammatically correct There is also the question of should we support both ways. Here lies the standard more than one way to do it vs. minimalist interface arguments. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-09 22:38 Message: Anything's posssible, but it doesn't read as well that way: "5 should greater than 3"???? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-08 06:30 Message: I got bitten by the same thing the other day. It was very unintuitive to me to have to put the be in front. Is it possible to lose the "be" for these? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-08 01:17 Message: This is really a doc issue. Here is what is supported: should == should_not == should be > should be >= should be <= should be < I'll make sure the docs are clear. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-07 23:27 Message: should < and should <= doesn't work either. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10673&group_id=797 From noreply at rubyforge.org Fri May 18 23:01:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 23:01:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10923 ] have_text matcher does not support should_not Message-ID: <20070519030149.B62155240B7C@rubyforge.org> Bugs item #10923, was opened at 2007-05-19 00:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10923&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: Nobody (None) Summary: have_text matcher does not support should_not Initial Comment: Ruby: 1.8.5-p12 -mswin32 OS: Windows XP SP2 RSpec: 0.9.4 Rails: Edge (r6703) Doing conversion of some test for some controllers, still with integrated views. I have this: it "should not see Join This Group button on profile page as member" do get "show", :id => @group.id response.should be_success response.should_not have_text(/Join This Group/) end But running with spec (0.9.4), drop me the folling error: Matcher does not support should_not. See Spec::Matchers for more information about matchers. Which is contradictory, since RDoc state otherwise: http://rspec.rubyforge.org/rdoc-rails/classes/Spec/Rails/Matchers.html#M000014 response.should have_text(expected) response.should_not have_text(expected) Workaround: response.should_not !have_text(expected) Thanks guys for the work on rSpec! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10923&group_id=797 From noreply at rubyforge.org Fri May 18 23:14:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 May 2007 23:14:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10923 ] have_text matcher does not support should_not Message-ID: <20070519031449.78E225240B78@rubyforge.org> Bugs item #10923, was opened at 2007-05-19 03:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10923&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Luis Lavena (luislavena) >Assigned to: David Chelimsky (dchelimsky) Summary: have_text matcher does not support should_not Initial Comment: Ruby: 1.8.5-p12 -mswin32 OS: Windows XP SP2 RSpec: 0.9.4 Rails: Edge (r6703) Doing conversion of some test for some controllers, still with integrated views. I have this: it "should not see Join This Group button on profile page as member" do get "show", :id => @group.id response.should be_success response.should_not have_text(/Join This Group/) end But running with spec (0.9.4), drop me the folling error: Matcher does not support should_not. See Spec::Matchers for more information about matchers. Which is contradictory, since RDoc state otherwise: http://rspec.rubyforge.org/rdoc-rails/classes/Spec/Rails/Matchers.html#M000014 response.should have_text(expected) response.should_not have_text(expected) Workaround: response.should_not !have_text(expected) Thanks guys for the work on rSpec! ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-19 03:14 Message: I've got this fixed but can't commit to svn from my current location. I'll commit it later tonight. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10923&group_id=797 From noreply at rubyforge.org Sat May 19 00:49:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 19 May 2007 00:49:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10871 ] 0.9.4 - Focussed spec runner fails to run specs in descriptions with type and string when there is no leading space in the string Message-ID: <20070519044903.47AE85240BB4@rubyforge.org> Bugs item #10871, was opened at 2007-05-16 15:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10871&group_id=797 Category: runner module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nathan Sobo (nathansobo) Assigned to: Nobody (None) Summary: 0.9.4 - Focussed spec runner fails to run specs in descriptions with type and string when there is no leading space in the string Initial Comment: if there is no space before "bar" like " bar" then the focussed runner breaks. I admit there should be a space there but this is a confusing bug for people that don't know that. Maybe one should be inserted automatically if it is missing. describe Foo, "bar" do it "this does not get run in a focussed spec" do true.should be_true end end ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-18 21:49 Message: Fixed in Rev. 1979 Still need to add functional specs. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10871&group_id=797 From noreply at rubyforge.org Sat May 19 00:55:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 19 May 2007 00:55:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10923 ] have_text matcher does not support should_not Message-ID: <20070519045530.C582B5240BB4@rubyforge.org> Bugs item #10923, was opened at 2007-05-19 03:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10923&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Luis Lavena (luislavena) Assigned to: David Chelimsky (dchelimsky) Summary: have_text matcher does not support should_not Initial Comment: Ruby: 1.8.5-p12 -mswin32 OS: Windows XP SP2 RSpec: 0.9.4 Rails: Edge (r6703) Doing conversion of some test for some controllers, still with integrated views. I have this: it "should not see Join This Group button on profile page as member" do get "show", :id => @group.id response.should be_success response.should_not have_text(/Join This Group/) end But running with spec (0.9.4), drop me the folling error: Matcher does not support should_not. See Spec::Matchers for more information about matchers. Which is contradictory, since RDoc state otherwise: http://rspec.rubyforge.org/rdoc-rails/classes/Spec/Rails/Matchers.html#M000014 response.should have_text(expected) response.should_not have_text(expected) Workaround: response.should_not !have_text(expected) Thanks guys for the work on rSpec! ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-19 04:55 Message: Fixed in r1981 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-19 03:14 Message: I've got this fixed but can't commit to svn from my current location. I'll commit it later tonight. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10923&group_id=797 From dchelimsky at gmail.com Sat May 19 17:10:04 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 19 May 2007 14:10:04 -0700 Subject: [rspec-devel] [ANN] RSpec 1.0 Message-ID: <57c63afe0705191410w4824da7fxd138998321eeafd5@mail.gmail.com> The RSpec Development Team is extraordinarily pleased to announce the release of RSpec-1.0.0. == RSpec RSpec provides a Domain Specific Language for describing and verifying the behaviour of Ruby code with executable examples. Some people like to call these examples "tests". In fact, they are. But we believe that tests have equally important value as documentation and as a design aid, and that the testing nomenclature and syntax in most unit testing frameworks keep too much focus on only the testing value, and hide the design and documentation value. This belief was a prime motivator for the emergence of Behaviour Driven Development, and RSpec is the original BDD tool in Ruby. == 1.0.0 This release represents a stake in the ground for the current API. While RSpec will certainly continue to grow as more people use it and provide valuable feedback, we are committed to the supporting the current API. Does this mean that we'll never break backwards compatibility again? We hope that it does. Of course, we can not predict all of the great ideas will come along. If we find ourselves in a situation in which such a change requires breaking backwards compatibility, we will only do so in a major release (i.e. 2.0.0), and will continue to support the previous major release for a reasonable amount of time. == Thanks We'd like to thank the 300+ members of the rspec-users and rspec-devel mailing lists who provide us with consistently invaluable feedback. We'd also like to thank the 40 contributors who have helped to fix nearly 200 bugs and 150 feature requests since Steve Baker registered RSpec in July of 2005. See http://rspec.rubyforge.org/community/index.html. == Numbers and facts * 16000 Downloads (ranked 31 on Rubyforge) * 40 contributors (bugfixes and patches) * 2000 svn commits * 890,000 Google hits for rspec+ruby * 100% coverage * 100% Self-describing == The RSpec Development Team is David Chelimsky Aslak Helles?y Brian Takita Dave Astels Steve Baker (the original author) From deanwampler at gmail.com Sat May 19 18:56:19 2007 From: deanwampler at gmail.com (Dean Wampler) Date: Sat, 19 May 2007 17:56:19 -0500 Subject: [rspec-devel] [ANN] RSpec 1.0 In-Reply-To: <57c63afe0705191410w4824da7fxd138998321eeafd5@mail.gmail.com> References: <57c63afe0705191410w4824da7fxd138998321eeafd5@mail.gmail.com> Message-ID: <6cf2a94f0705191556v38e6109et3b85e91740e379bc@mail.gmail.com> Dude, you rock! Congratulations. ;) dean On 5/19/07, David Chelimsky wrote: > > The RSpec Development Team is extraordinarily pleased to announce the > release of RSpec-1.0.0. > > == RSpec > > RSpec provides a Domain Specific Language for describing and verifying > the behaviour of Ruby code with executable examples. > > Some people like to call these examples "tests". In fact, they are. > But we believe that tests have equally important value as > documentation and as a design aid, and that the testing nomenclature > and syntax in most unit testing frameworks keep too much focus on only > the testing value, and hide the design and documentation value. > > This belief was a prime motivator for the emergence of Behaviour > Driven Development, and RSpec is the original BDD tool in Ruby. > > == 1.0.0 > > This release represents a stake in the ground for the current API. > While RSpec will certainly continue to grow as more people use it and > provide valuable feedback, we are committed to the supporting the > current API. > > Does this mean that we'll never break backwards compatibility again? > We hope that it does. Of course, we can not predict all of the great > ideas will come along. If we find ourselves in a situation in which > such a change requires breaking backwards compatibility, we will only > do so in a major release (i.e. 2.0.0), and will continue to support > the previous major release for a reasonable amount of time. > > == Thanks > > We'd like to thank the 300+ members of the rspec-users and rspec-devel > mailing lists who provide us with consistently invaluable feedback. > > We'd also like to thank the 40 contributors who have helped to fix > nearly 200 bugs and 150 feature requests since Steve Baker registered > RSpec in July of 2005. See > http://rspec.rubyforge.org/community/index.html. > > == Numbers and facts > > * 16000 Downloads (ranked 31 on Rubyforge) > * 40 contributors (bugfixes and patches) > * 2000 svn commits > * 890,000 Google hits for rspec+ruby > * 100% coverage > * 100% Self-describing > > == The RSpec Development Team is > > David Chelimsky > Aslak Helles?y > Brian Takita > Dave Astels > Steve Baker (the original author) > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Dean Wampler http://www.objectmentor.com http://www.aspectprogramming.com http://www.contract4j.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070519/47ee9bbc/attachment.html From noreply at rubyforge.org Sun May 20 00:44:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 20 May 2007 00:44:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10932 ] Documentation on upgrading the Rspec on Rails Plugin Message-ID: <20070520044416.6DB695240C5B@rubyforge.org> Feature Requests item #10932, was opened at 2007-05-19 21:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10932&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Documentation on upgrading the Rspec on Rails Plugin Initial Comment: Upgrading rpsec can be a pain. There should be some procedues. e.g. svn mv Rename existing plugin install latest version of plugin remove renamed old version of plugin ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10932&group_id=797 From brian.takita at gmail.com Sun May 20 00:47:23 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 19 May 2007 21:47:23 -0700 Subject: [rspec-devel] mock frameworks In-Reply-To: <1db558f00705141109i369cb652gdd7f644693f407a6@mail.gmail.com> References: <57c63afe0705070443p12046c05off053706e844c129@mail.gmail.com> <1d7ddd110705132156vb51eb70vd1c0f6f657a62057@mail.gmail.com> <1db558f00705141109i369cb652gdd7f644693f407a6@mail.gmail.com> Message-ID: <1d7ddd110705192147g35992c22k94a3b1ebba71a82c@mail.gmail.com> On 5/14/07, James Mead wrote: > Hi Brian, > > On 14/05/07, Brian Takita wrote: > > I'm considering using Mocha + Mocha Shot. > > http://rubyforge.org/projects/mocha-shot > > Nice one! I like some of the ideas in this. Sorry not to have been > more responsive - things are as busy as ever at Reevoo. Thank you problem. I like the idea of plugin gems. It provides a nice experiment to see if something works. > > > There are some things that are in Rspec's mocking framework that are missing > > in Mocha though. > > For example, in spec/mock, #and_return takes a block that gets executed and > > accepts the arguments passed to the method. > > The Mocha returns() method can currently take an instance of a Proc > which you can use to define more complex behaviour. However it is true > that the parameters of the method are not passed to this Proc. But > this is intentional. Because you are completely and deterministically > in control of all the objects involved in the test, you should know > what sequence of return values you need to return from the mock. So > you can use something like... > > m = mock() > m.stubs(:method).returns(1, 2, 3).then.raises(Exception).then.returns(5). > > The fact that you need to know the parameters being passed in to the > stubbed method in order to work out what to return is probably a sign > that you are testing too much at once. > > Anyway, if you need that degree of control, why not simply use > define_method. Or use a Rails-style "mock" (i.e. hard-coded fake > class). > > For similar reasons the ability of the returns() method to take an > instance of a Proc will probably be phased out soon. > > Does that make sense? That makes sense, and I understand how limitation can help make something as dangerous as mocks safer. One pattern I have been doing is as follows: the_method = foo.method(:the_method) foo.should_receive(:the_method).and_return(&the_method) This acts like a "probe". I use the mock only to verify the method was called. This also verifies that the method exists on the object. Of course most of the time I can do: value = foo.the_method foo.expects(:the_method).returns(value) The block is also useful as a catchall to verify certain values when the with expectation handlers and not sufficient. value = nil foo.should_receive(:the_method).with(:anything).and_return {|obj| value = obj} value.should ... I imagine that lots of handlers would mitigate this. Brian > -- > James. > http://blog.floehopper.org > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun May 20 15:06:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 20 May 2007 15:06:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10941 ] Example object should have a reference to its Description object Message-ID: <20070520190612.EA7AD5240C83@rubyforge.org> Feature Requests item #10941, was opened at 2007-05-20 12:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10941&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Example object should have a reference to its Description object Initial Comment: This would assist in plugging in shared before(:each) and after(:each) callbacks. For example Nathan Wilmes had an issue with setting a mock by default and only in certain Behaviour, he wanted to turn off mocks. One possible implementation would be: describe "Storage Service Setup" do before(:each) do unless behaviour.real_storage_service? StorageService.stub!(:something) end end end describe Foo do real_storage_service it_should_behave_like "Storahge Service Setup" end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10941&group_id=797 From noreply at rubyforge.org Sun May 20 16:36:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 20 May 2007 16:36:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-10944 ] Use Pretty Print for Matching Errors Message-ID: <20070520203629.5A14D5240C67@rubyforge.org> Feature Requests item #10944, was opened at 2007-05-20 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10944&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Use Pretty Print for Matching Errors Initial Comment: This would be useful for matching errors where printing the object results in a very long line. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10944&group_id=797 From noreply at rubyforge.org Sun May 20 22:23:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 20 May 2007 22:23:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10951 ] Odd instance variable name in rspec_model template Message-ID: <20070521022308.01DC65240BA9@rubyforge.org> Patches item #10951, was opened at 2007-05-21 02:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10951&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kyle Hargraves (philodespotos) Assigned to: Nobody (None) Summary: Odd instance variable name in rspec_model template Initial Comment: Minor quibble which has been annoying me for a bit. The rspec_model generator's template uses table_name for the instance variable name, which results in models.should be_valid. It seems to read better when the result is model.should be_valid, which is what I've done in the attached patch. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10951&group_id=797 From noreply at rubyforge.org Sun May 20 22:36:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 20 May 2007 22:36:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10951 ] Odd instance variable name in rspec_model template Message-ID: <20070521023632.F091E5240BCF@rubyforge.org> Patches item #10951, was opened at 2007-05-20 22:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10951&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Kyle Hargraves (philodespotos) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Odd instance variable name in rspec_model template Initial Comment: Minor quibble which has been annoying me for a bit. The rspec_model generator's template uses table_name for the instance variable name, which results in models.should be_valid. It seems to read better when the result is model.should be_valid, which is what I've done in the attached patch. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-20 22:36 Message: I fixed that earlier today, and it's been there for months! Funny we should both see it on the same day. Credit added in r1991 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10951&group_id=797 From noreply at rubyforge.org Mon May 21 03:57:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 May 2007 03:57:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10959 ] Focused Examples do not work for Behaviour defined with constant with modules Message-ID: <20070521075759.A099F5240C9B@rubyforge.org> Bugs item #10959, was opened at 2007-05-21 00:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Focused Examples do not work for Behaviour defined with constant with modules Initial Comment: e.g. describe Foo::Bar do it "gets here" do true.should == true end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 From noreply at rubyforge.org Mon May 21 04:12:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 May 2007 04:12:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10959 ] Focused Examples do not work for Behaviour defined with constant with modules Message-ID: <20070521081236.58EAE5240C98@rubyforge.org> Bugs item #10959, was opened at 2007-05-21 00:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Focused Examples do not work for Behaviour defined with constant with modules Initial Comment: e.g. describe Foo::Bar do it "gets here" do true.should == true end end ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-21 01:12 Message: In spec_matcher_spec.rb, there is an example: "should match when behaviour is modularized" The error was caused by changing ExampleMatcher to handle this. What is the purpose of doing the spec_matcher_spec example? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 From noreply at rubyforge.org Mon May 21 04:35:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 May 2007 04:35:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10959 ] Focused Examples do not work for Behaviour defined with constant with modules Message-ID: <20070521083537.639D45240998@rubyforge.org> Bugs item #10959, was opened at 2007-05-21 07:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Focused Examples do not work for Behaviour defined with constant with modules Initial Comment: e.g. describe Foo::Bar do it "gets here" do true.should == true end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 08:35 Message: When you do this: module Space class Thing the output reads: Space::Thing We want to be able to say: spec spec -e "Space::Thing" ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-21 08:12 Message: In spec_matcher_spec.rb, there is an example: "should match when behaviour is modularized" The error was caused by changing ExampleMatcher to handle this. What is the purpose of doing the spec_matcher_spec example? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 From smartgpx at gmail.com Mon May 21 11:10:57 2007 From: smartgpx at gmail.com (DeeJay) Date: Mon, 21 May 2007 16:10:57 +0100 Subject: [rspec-devel] Thanks for V1.0.0, and http://rspec.rubyforge.org/ problem (since 0.9.2?) Message-ID: <533048b70705210810i2c1304c9q8e91c4686ea31429@mail.gmail.com> Congratulation and thanks to everyone involved in getting RSpec 1.0.0released. On the systems I am using there seems to be a problem with the rspec.rubyforge.org website - I'm guessing the problem may have been there since 0.9.2 Using IE6 as the browser, the top-level menu items run DOWN the left of the page instead of across the top, and the trailing black 'space' obliterates/obscures the first dozen lines of the initial page. It looks OK with Firefox. (I can attach a screen shot if needed. Do you want this as a ticket?) DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070521/f6cb0516/attachment.html From noreply at rubyforge.org Mon May 21 15:31:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 May 2007 15:31:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10997 ] Can't run specs without rspec plugin Message-ID: <20070521193147.2D4A45240A4F@rubyforge.org> Bugs item #10997, was opened at 2007-05-21 15:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bryan Helmkamp (brynary) Assigned to: Nobody (None) Summary: Can't run specs without rspec plugin Initial Comment: I'm unable to run the "rake spec" command when I do not have the rspec gem installed, even if I have rspec unpacked into vendor/plugins as described in the installation instructions. The results are: $ rake spec (in /Users/bhelmkamp/p/mcommons_trunk) rake aborted! no such file to load -- spec/rake/spectask /Users/bhelmkamp/p/mcommons_trunk/rakefile:10 (See full trace by running task with --trace) Running script/spec does work as intended, however this seems to defeat the purpose of extracting the plugin into the source tree. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 From noreply at rubyforge.org Mon May 21 19:54:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 May 2007 19:54:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10997 ] Can't run specs without rspec plugin Message-ID: <20070521235409.2C4625240C5E@rubyforge.org> Bugs item #10997, was opened at 2007-05-21 19:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bryan Helmkamp (brynary) Assigned to: Nobody (None) Summary: Can't run specs without rspec plugin Initial Comment: I'm unable to run the "rake spec" command when I do not have the rspec gem installed, even if I have rspec unpacked into vendor/plugins as described in the installation instructions. The results are: $ rake spec (in /Users/bhelmkamp/p/mcommons_trunk) rake aborted! no such file to load -- spec/rake/spectask /Users/bhelmkamp/p/mcommons_trunk/rakefile:10 (See full trace by running task with --trace) Running script/spec does work as intended, however this seems to defeat the purpose of extracting the plugin into the source tree. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 23:54 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 From noreply at rubyforge.org Mon May 21 20:06:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 May 2007 20:06:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10997 ] Can't run specs without rspec plugin Message-ID: <20070522000632.18BD65240C1C@rubyforge.org> Bugs item #10997, was opened at 2007-05-21 15:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bryan Helmkamp (brynary) Assigned to: Nobody (None) Summary: Can't run specs without rspec plugin Initial Comment: I'm unable to run the "rake spec" command when I do not have the rspec gem installed, even if I have rspec unpacked into vendor/plugins as described in the installation instructions. The results are: $ rake spec (in /Users/bhelmkamp/p/mcommons_trunk) rake aborted! no such file to load -- spec/rake/spectask /Users/bhelmkamp/p/mcommons_trunk/rakefile:10 (See full trace by running task with --trace) Running script/spec does work as intended, however this seems to defeat the purpose of extracting the plugin into the source tree. ---------------------------------------------------------------------- >Comment By: Bryan Helmkamp (brynary) Date: 2007-05-21 20:06 Message: Here we go: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.0.0 * Spec::Rails 1.0.0 * Rails 1.2.3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 19:54 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 From noreply at rubyforge.org Mon May 21 20:07:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 May 2007 20:07:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10997 ] Can't run specs without rspec plugin Message-ID: <20070522000753.BC1245240C1C@rubyforge.org> Bugs item #10997, was opened at 2007-05-21 19:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bryan Helmkamp (brynary) Assigned to: Nobody (None) Summary: Can't run specs without rspec plugin Initial Comment: I'm unable to run the "rake spec" command when I do not have the rspec gem installed, even if I have rspec unpacked into vendor/plugins as described in the installation instructions. The results are: $ rake spec (in /Users/bhelmkamp/p/mcommons_trunk) rake aborted! no such file to load -- spec/rake/spectask /Users/bhelmkamp/p/mcommons_trunk/rakefile:10 (See full trace by running task with --trace) Running script/spec does work as intended, however this seems to defeat the purpose of extracting the plugin into the source tree. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-22 00:07 Message: Thanks Bryan - I'll be looking into this. Cheers, David ---------------------------------------------------------------------- Comment By: Bryan Helmkamp (brynary) Date: 2007-05-22 00:06 Message: Here we go: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.0.0 * Spec::Rails 1.0.0 * Rails 1.2.3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 23:54 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 From joevandyk at gmail.com Tue May 22 03:33:49 2007 From: joevandyk at gmail.com (Joe Van Dyk) Date: Tue, 22 May 2007 00:33:49 -0700 Subject: [rspec-devel] specing out a couple controller methods Message-ID: Could someone help me spec out these Rails controller methods? I don't know where to get started, especially with the transaction stuff. Or, if anyone else could suggest ways I could improve the code, that would be great as well. Puzzle has_one Media. Both are AR model objects. class PuzzlesController < ApplicationController # a before_filter fills in @user def create @puzzle = Puzzle.new(params[:puzzle]) @puzzle.user = @user @media = Media.new(:uploaded_data => params[:media]) Puzzle.transaction do @puzzle.media = @media @puzzle.save! && @media.save! flash[:notice] = "Success!" redirect_to puzzle_path(@puzzle) end rescue ActiveRecord::RecordInvalid => e @media.valid? # force checking of errors even if @puzzle.save! failed flash[:error] = "Problem submitting the One Word Wonder..." render :partial => 'new', :layout => true end def update @puzzle = Puzzle.find params[:id] Puzzle.transaction do @puzzle.attributes = params[:puzzle] if params[:media] and params[:media].size > 0 @puzzle.media = Media.new :uploaded_data => params[:media] end @puzzle.save! && @puzzle.media.save! end rescue ActiveRecord::RecordInvalid => e @media.valid? flash[:error] = "Problem updating the One Word Wonder..." render :action => 'edit' end Thanks, Joe VAn Dyk From noreply at rubyforge.org Wed May 23 08:48:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 08:48:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11066 ] http://rspec.rubyforge.org/contribute.html - dead link Message-ID: <20070523124858.B2A825240A41@rubyforge.org> Bugs item #11066, was opened at 2007-05-23 14:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: http://rspec.rubyforge.org/contribute.html - dead link Initial Comment: Sorry for not reading the contribute document, but the link is dead. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 From noreply at rubyforge.org Wed May 23 08:54:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 08:54:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11067 ] spec runner with -c removes all 'a'-characters for output Message-ID: <20070523125424.7A33B524099C@rubyforge.org> Bugs item #11067, was opened at 2007-05-23 14:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: spec runner with -c removes all 'a'-characters for output Initial Comment: ruby 1.8.5 (2006-08-25) [i386-mswin32] rspec 1.0 >From the windows command-line I run spec my_specifications.rb -f s -c Compose SQL - should clen \n nd whitespce Note that all 'a'-characters are missing. If i run _without_ -c, its all good. spec my_specifications.rb -f s Compose SQL - should clean \n and whitespace The colours are really helpful, but so are 'a's. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 From aslak.hellesoy at gmail.com Wed May 23 09:01:42 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 15:01:42 +0200 Subject: [rspec-devel] RSpec inside JRuby Message-ID: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Hi all, The fine JRuby team declared at RailsConf that they will bundle RSpec with JRuby when it ships. That's awesome, thanks again guys. I hope this can be the RSpec 1.0.1 version (not yet released) - it has some minor tweaks that are needed to get all of RSpec's specs to run on JRuby. (This is something Ola Bini and I paired on at RailsConf). We'll release 1.0.1 if the JRuby team ask us for it. I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). LET'S KEEP IT THAT WAY. I'm asking that all RSpec developers make sure RSpec always runs against JRuby until they ship 1.0. Here is how: svn co http://svn.codehaus.org/jruby jruby cd jruby/jruby ant clean ant # put JRuby's bin dir on your PATH cd ../testsuites/rspec mkdir target jruby -S rake checkout_code cd target/rspec jruby bin/spec spec -c I'm getting a bunch of hpricot warnings but otherwise it's 100% green!!!!!!!!!!!: gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple values for a block parameter (4 for 1) (We're only using hpricot in the html_formatter_spec.rb to verify the HTML report) Cheers, Aslak From noreply at rubyforge.org Wed May 23 09:06:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 09:06:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11066 ] http://rspec.rubyforge.org/contribute.html - dead link Message-ID: <20070523130635.B333F524099C@rubyforge.org> Bugs item #11066, was opened at 2007-05-23 08:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: http://rspec.rubyforge.org/contribute.html - dead link Initial Comment: Sorry for not reading the contribute document, but the link is dead. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 09:06 Message: Yes, that target is dead. Where did you see the link? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 From noreply at rubyforge.org Wed May 23 09:09:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 09:09:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11066 ] http://rspec.rubyforge.org/contribute.html - dead link Message-ID: <20070523130945.3D716524099C@rubyforge.org> Bugs item #11066, was opened at 2007-05-23 08:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: http://rspec.rubyforge.org/contribute.html - dead link Initial Comment: Sorry for not reading the contribute document, but the link is dead. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 09:09 Message: The contribute page is here: http://rspec.rubyforge.org/community/contribute.html If you tell us where the dead link is, we'll fix it ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 09:06 Message: Yes, that target is dead. Where did you see the link? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 From aslak.hellesoy at gmail.com Wed May 23 09:25:12 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 15:25:12 +0200 Subject: [rspec-devel] rcov_error_report variable Message-ID: <8d961d900705230625k245e0e89j61fe05e187ad5826@mail.gmail.com> It's in be.rb and it's not used. Why? Aslak From aslak.hellesoy at gmail.com Wed May 23 09:26:01 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 15:26:01 +0200 Subject: [rspec-devel] rcov_error_report variable In-Reply-To: <8d961d900705230625k245e0e89j61fe05e187ad5826@mail.gmail.com> References: <8d961d900705230625k245e0e89j61fe05e187ad5826@mail.gmail.com> Message-ID: <8d961d900705230626m10e867aes48dd9526493482b7@mail.gmail.com> On 5/23/07, aslak hellesoy wrote: > It's in be.rb and it's not used. Why? > Duh never mind > Aslak > From noreply at rubyforge.org Wed May 23 09:48:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 09:48:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11067 ] spec runner with -c removes all 'a'-characters for output Message-ID: <20070523134803.B9FFB5240A41@rubyforge.org> Bugs item #11067, was opened at 2007-05-23 08:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: spec runner with -c removes all 'a'-characters for output Initial Comment: ruby 1.8.5 (2006-08-25) [i386-mswin32] rspec 1.0 >From the windows command-line I run spec my_specifications.rb -f s -c Compose SQL - should clen \n nd whitespce Note that all 'a'-characters are missing. If i run _without_ -c, its all good. spec my_specifications.rb -f s Compose SQL - should clean \n and whitespace The colours are really helpful, but so are 'a's. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 09:48 Message: I'm unable to reproduce this. I am on: ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] rspec 1.0.0 win32console (1.0.8) Could you please attach your spec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 From dan at tastapod.com Wed May 23 09:50:25 2007 From: dan at tastapod.com (Dan North) Date: Wed, 23 May 2007 14:50:25 +0100 Subject: [rspec-devel] mock frameworks In-Reply-To: <57c63afe0705070443p12046c05off053706e844c129@mail.gmail.com> References: <57c63afe0705070443p12046c05off053706e844c129@mail.gmail.com> Message-ID: <465446A1.2020809@tastapod.com> I'm using Mocha. It works like I think.* Nothing against the baked-in rspec mocks, just that I prefer the "dialect" of Mocha. Cheers, Dan * Probably because it's heavily influenced by jmock, where I cut my mocking teeth. David Chelimsky wrote: > Just curious - now that rspec (as of 0.9) let's you choose your mock > framework, how many of you are actually using (or planning to use) > mocha or flexmock? > > Anybody planning to use any other mock framework besides rspec, mocha > or flexmock? > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed May 23 11:39:37 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 10:39:37 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Message-ID: <57c63afe0705230839l47f293c5ye7ffe0c1c8f31efe@mail.gmail.com> On 5/23/07, aslak hellesoy wrote: > Hi all, > > The fine JRuby team declared at RailsConf that they will bundle RSpec > with JRuby when it ships. That's awesome, thanks again guys. > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > some minor tweaks that are needed to get all of RSpec's specs to run > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > We'll release 1.0.1 if the JRuby team ask us for it. > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > LET'S KEEP IT THAT WAY. > > I'm asking that all RSpec developers make sure RSpec always runs > against JRuby until they ship 1.0. Here is how: > > svn co http://svn.codehaus.org/jruby jruby > cd jruby/jruby This isn't exactly right - if you check out as in the first line, you have to cd like this: cd jruby/trunk/jruby > ant clean > ant > # put JRuby's bin dir on your PATH > cd ../testsuites/rspec > mkdir target > jruby -S rake checkout_code > cd target/rspec > jruby bin/spec spec -c > > I'm getting a bunch of hpricot warnings but otherwise it's 100% > green!!!!!!!!!!!: > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > values for a block parameter (4 for 1) > > (We're only using hpricot in the html_formatter_spec.rb to verify the > HTML report) > > Cheers, > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Wed May 23 11:49:35 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 23 May 2007 08:49:35 -0700 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Message-ID: On 5/23/07, aslak hellesoy wrote: > Hi all, > > The fine JRuby team declared at RailsConf that they will bundle RSpec > with JRuby when it ships. That's awesome, thanks again guys. > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > some minor tweaks that are needed to get all of RSpec's specs to run > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > We'll release 1.0.1 if the JRuby team ask us for it. > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > LET'S KEEP IT THAT WAY. > > I'm asking that all RSpec developers make sure RSpec always runs > against JRuby until they ship 1.0. Here is how: > > svn co http://svn.codehaus.org/jruby jruby > cd jruby/jruby > ant clean > ant > # put JRuby's bin dir on your PATH > cd ../testsuites/rspec > mkdir target > jruby -S rake checkout_code > cd target/rspec > jruby bin/spec spec -c > > I'm getting a bunch of hpricot warnings but otherwise it's 100% > green!!!!!!!!!!!: > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > values for a block parameter (4 for 1) This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK Although since RSpec checkout is part of the build, it won't get run when RSpec code changes at the moment. Right now there are 5 failures which come and go, it seems like we (JRuby) have some randomly recurring issue with Object#inspect or something like that, because the actual output only differs by #<...>. One of us will have to look at it. /Nick From dchelimsky at gmail.com Wed May 23 12:00:44 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 11:00:44 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Message-ID: <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> On 5/23/07, Nick Sieger wrote: > On 5/23/07, aslak hellesoy wrote: > > Hi all, > > > > The fine JRuby team declared at RailsConf that they will bundle RSpec > > with JRuby when it ships. That's awesome, thanks again guys. > > > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > > some minor tweaks that are needed to get all of RSpec's specs to run > > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > > We'll release 1.0.1 if the JRuby team ask us for it. > > > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > > > LET'S KEEP IT THAT WAY. > > > > I'm asking that all RSpec developers make sure RSpec always runs > > against JRuby until they ship 1.0. Here is how: > > > > svn co http://svn.codehaus.org/jruby jruby > > cd jruby/jruby > > ant clean > > ant > > # put JRuby's bin dir on your PATH > > cd ../testsuites/rspec > > mkdir target > > jruby -S rake checkout_code I get the following error executing this line. Error opening script file: /Users/david/projects/ruby/jruby/trunk/jruby/bin/rake (No such file or directory) So I tried which rake => /opt/local/bin/rake Then this: $ jruby -S /opt/local/bin/rake checkout_code Error opening script file: /Users/david/projects/ruby/jruby/trunk/jruby/bin/opt/local/bin/rake (No such file or directory) I was able to get it to work w/ just: rake checkout_code But then I did this: $ jruby bin/spec spec -c /Users/david/projects/ruby/jruby/trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in `require': no such file to load -- hpricot (LoadError) $ gem list hpricot *** LOCAL GEMS *** hpricot (0.5) a swift, liberal HTML parser with a fantastic library So it looks like jruby is not able to see my existing path. Suggestions? > > cd target/rspec > > jruby bin/spec spec -c > > > > I'm getting a bunch of hpricot warnings but otherwise it's 100% > > green!!!!!!!!!!!: > > > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > > values for a block parameter (4 for 1) > > This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK > > Although since RSpec checkout is part of the build, it won't get run > when RSpec code changes at the moment. > > Right now there are 5 failures which come and go, it seems like we > (JRuby) have some randomly recurring issue with Object#inspect or > something like that, because the actual output only differs by #<...>. > One of us will have to look at it. > > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Wed May 23 12:06:00 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 18:06:00 +0200 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Message-ID: <8d961d900705230906lfd3eec5kf1a6aa7dc1f5aa7f@mail.gmail.com> On 5/23/07, Nick Sieger wrote: > On 5/23/07, aslak hellesoy wrote: > > Hi all, > > > > The fine JRuby team declared at RailsConf that they will bundle RSpec > > with JRuby when it ships. That's awesome, thanks again guys. > > > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > > some minor tweaks that are needed to get all of RSpec's specs to run > > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > > We'll release 1.0.1 if the JRuby team ask us for it. > > > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > > > LET'S KEEP IT THAT WAY. > > > > I'm asking that all RSpec developers make sure RSpec always runs > > against JRuby until they ship 1.0. Here is how: > > > > svn co http://svn.codehaus.org/jruby jruby > > cd jruby/jruby > > ant clean > > ant > > # put JRuby's bin dir on your PATH > > cd ../testsuites/rspec > > mkdir target > > jruby -S rake checkout_code > > cd target/rspec > > jruby bin/spec spec -c > > > > I'm getting a bunch of hpricot warnings but otherwise it's 100% > > green!!!!!!!!!!!: > > > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > > values for a block parameter (4 for 1) > > This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK > > Although since RSpec checkout is part of the build, it won't get run > when RSpec code changes at the moment. > > Right now there are 5 failures which come and go, it seems like we > (JRuby) have some randomly recurring issue with Object#inspect or > something like that, because the actual output only differs by #<...>. > One of us will have to look at it. > I talked to Tom and Charles about this in Portland, and I have a vague idea about what it *might* be. Search for "rescue nil # Help windows" in trunk/rspec/spec. Try to comment out these rescus completely and see if you can run the specs. You should be able to (for some reason Windows can't delete these files). Aslak > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Wed May 23 12:33:23 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 18:33:23 +0200 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> Message-ID: <8d961d900705230933g1ef6390fy9a5eba0fb9f1d388@mail.gmail.com> On 5/23/07, David Chelimsky wrote: > On 5/23/07, Nick Sieger wrote: > > On 5/23/07, aslak hellesoy wrote: > > > Hi all, > > > > > > The fine JRuby team declared at RailsConf that they will bundle RSpec > > > with JRuby when it ships. That's awesome, thanks again guys. > > > > > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > > > some minor tweaks that are needed to get all of RSpec's specs to run > > > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > > > We'll release 1.0.1 if the JRuby team ask us for it. > > > > > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > > > > > LET'S KEEP IT THAT WAY. > > > > > > I'm asking that all RSpec developers make sure RSpec always runs > > > against JRuby until they ship 1.0. Here is how: > > > > > > svn co http://svn.codehaus.org/jruby jruby This should be: svn co http://svn.codehaus.org/jruby/trunk jruby > > > cd jruby/jruby > > > ant clean > > > ant > > > # put JRuby's bin dir on your PATH > > > cd ../testsuites/rspec > > > mkdir target > > > jruby -S rake checkout_code > > I get the following error executing this line. > > Error opening script file: > /Users/david/projects/ruby/jruby/trunk/jruby/bin/rake (No such file or > directory) > Something went wrong in your checkout it seems. Or your PATH is wrong. Try the corrected line above. Do a which jruby to see where jruby is. This dir should be the one you checked out, and it should have rake, gem etc. If not your PATH is wrong. > So I tried > > which rake > => /opt/local/bin/rake > > Then this: > > $ jruby -S /opt/local/bin/rake checkout_code If jruby -S rake doesn't work, nothing will work. > Error opening script file: > /Users/david/projects/ruby/jruby/trunk/jruby/bin/opt/local/bin/rake > (No such file or directory) > > I was able to get it to work w/ just: > > rake checkout_code > That won't work, because it will install the hpricot gem in ruby, not jruby > But then I did this: > > $ jruby bin/spec spec -c > /Users/david/projects/ruby/jruby/trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in > `require': no such file to load -- hpricot (LoadError) > $ gem list hpricot > Again, "gem" will run ruby, not jruby. All your problems have the same reason - you don't have the appropriate bin files. > *** LOCAL GEMS *** > > hpricot (0.5) > a swift, liberal HTML parser with a fantastic library > > So it looks like jruby is not able to see my existing path. Suggestions? > > > > > cd target/rspec > > > jruby bin/spec spec -c > > > > > > I'm getting a bunch of hpricot warnings but otherwise it's 100% > > > green!!!!!!!!!!!: > > > > > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > > > values for a block parameter (4 for 1) > > > > This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK > > > > Although since RSpec checkout is part of the build, it won't get run > > when RSpec code changes at the moment. > > > > Right now there are 5 failures which come and go, it seems like we > > (JRuby) have some randomly recurring issue with Object#inspect or > > something like that, because the actual output only differs by #<...>. > > One of us will have to look at it. > > > > /Nick > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed May 23 12:40:28 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 11:40:28 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Message-ID: <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> On 5/23/07, aslak hellesoy wrote: > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > some minor tweaks that are needed to get all of RSpec's specs to run > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > We'll release 1.0.1 if the JRuby team ask us for it. I want to release 1.0.1 this week, but I'm coordinating w/ Ryan Davis on new releases of both rspec and zentest to improve the integration between rspec autotest. If a release must go out for jruby before we're ready for zentest we can do it, but I'd prefer to wait until Ryan and I get this to work (hopefully this week) to avoid two releases. From aslak.hellesoy at gmail.com Wed May 23 12:44:25 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 18:44:25 +0200 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705230933g1ef6390fy9a5eba0fb9f1d388@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> <8d961d900705230933g1ef6390fy9a5eba0fb9f1d388@mail.gmail.com> Message-ID: <8d961d900705230944s48267fcfq2580103644b4a935@mail.gmail.com> On 5/23/07, aslak hellesoy wrote: > On 5/23/07, David Chelimsky wrote: > > On 5/23/07, Nick Sieger wrote: > > > On 5/23/07, aslak hellesoy wrote: > > > > Hi all, > > > > > > > > The fine JRuby team declared at RailsConf that they will bundle RSpec > > > > with JRuby when it ships. That's awesome, thanks again guys. > > > > > > > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > > > > some minor tweaks that are needed to get all of RSpec's specs to run > > > > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > > > > We'll release 1.0.1 if the JRuby team ask us for it. > > > > > > > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > > > > > > > LET'S KEEP IT THAT WAY. > > > > > > > > I'm asking that all RSpec developers make sure RSpec always runs > > > > against JRuby until they ship 1.0. Here is how: > > > > > > > > svn co http://svn.codehaus.org/jruby jruby > > This should be: > > svn co http://svn.codehaus.org/jruby/trunk jruby > > > > > cd jruby/jruby > > > > ant clean > > > > ant > > > > # put JRuby's bin dir on your PATH > > > > cd ../testsuites/rspec > > > > mkdir target > > > > jruby -S rake checkout_code > > > > I get the following error executing this line. > > > > Error opening script file: > > /Users/david/projects/ruby/jruby/trunk/jruby/bin/rake (No such file or > > directory) > > > > Something went wrong in your checkout it seems. Or your PATH is wrong. > Try the corrected line above. Do a which jruby to see where jruby is. > This dir should be the one you checked out, and it should have rake, > gem etc. If not your PATH is wrong. > > > So I tried > > > > which rake > > => /opt/local/bin/rake > > > > Then this: > > > > $ jruby -S /opt/local/bin/rake checkout_code > DOH It's because rake is not installed! jruby -S gem install rake --no-ri --no-rdoc > If jruby -S rake doesn't work, nothing will work. > > > Error opening script file: > > /Users/david/projects/ruby/jruby/trunk/jruby/bin/opt/local/bin/rake > > (No such file or directory) > > > > I was able to get it to work w/ just: > > > > rake checkout_code > > > > That won't work, because it will install the hpricot gem in ruby, not jruby > > > But then I did this: > > > > $ jruby bin/spec spec -c > > /Users/david/projects/ruby/jruby/trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in > > `require': no such file to load -- hpricot (LoadError) > > $ gem list hpricot > > > > Again, "gem" will run ruby, not jruby. All your problems have the same > reason - you don't have the appropriate bin files. > > > *** LOCAL GEMS *** > > > > hpricot (0.5) > > a swift, liberal HTML parser with a fantastic library > > > > So it looks like jruby is not able to see my existing path. Suggestions? > > > > > > > > cd target/rspec > > > > jruby bin/spec spec -c > > > > > > > > I'm getting a bunch of hpricot warnings but otherwise it's 100% > > > > green!!!!!!!!!!!: > > > > > > > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > > > > values for a block parameter (4 for 1) > > > > > > This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK > > > > > > Although since RSpec checkout is part of the build, it won't get run > > > when RSpec code changes at the moment. > > > > > > Right now there are 5 failures which come and go, it seems like we > > > (JRuby) have some randomly recurring issue with Object#inspect or > > > something like that, because the actual output only differs by #<...>. > > > One of us will have to look at it. > > > > > > /Nick > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dchelimsky at gmail.com Wed May 23 12:47:01 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 11:47:01 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705230944s48267fcfq2580103644b4a935@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> <8d961d900705230933g1ef6390fy9a5eba0fb9f1d388@mail.gmail.com> <8d961d900705230944s48267fcfq2580103644b4a935@mail.gmail.com> Message-ID: <57c63afe0705230947i32f1beffiad25469924588403@mail.gmail.com> On 5/23/07, aslak hellesoy wrote: > On 5/23/07, aslak hellesoy wrote: > > On 5/23/07, David Chelimsky wrote: > > > On 5/23/07, Nick Sieger wrote: > > > > On 5/23/07, aslak hellesoy wrote: > > > > > Hi all, > > > > > > > > > > The fine JRuby team declared at RailsConf that they will bundle RSpec > > > > > with JRuby when it ships. That's awesome, thanks again guys. > > > > > > > > > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > > > > > some minor tweaks that are needed to get all of RSpec's specs to run > > > > > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > > > > > We'll release 1.0.1 if the JRuby team ask us for it. > > > > > > > > > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > > > > > > > > > LET'S KEEP IT THAT WAY. > > > > > > > > > > I'm asking that all RSpec developers make sure RSpec always runs > > > > > against JRuby until they ship 1.0. Here is how: > > > > > > > > > > svn co http://svn.codehaus.org/jruby jruby > > > > This should be: > > > > svn co http://svn.codehaus.org/jruby/trunk jruby > > > > > > > cd jruby/jruby > > > > > ant clean > > > > > ant > > > > > # put JRuby's bin dir on your PATH > > > > > cd ../testsuites/rspec > > > > > mkdir target > > > > > jruby -S rake checkout_code > > > > > > I get the following error executing this line. > > > > > > Error opening script file: > > > /Users/david/projects/ruby/jruby/trunk/jruby/bin/rake (No such file or > > > directory) > > > > > > > Something went wrong in your checkout it seems. Or your PATH is wrong. > > Try the corrected line above. Do a which jruby to see where jruby is. > > This dir should be the one you checked out, and it should have rake, > > gem etc. If not your PATH is wrong. > > > > > So I tried > > > > > > which rake > > > => /opt/local/bin/rake > > > > > > Then this: > > > > > > $ jruby -S /opt/local/bin/rake checkout_code > > > > DOH > > It's because rake is not installed! > > jruby -S gem install rake --no-ri --no-rdoc God dammit - I just blew away the install :) I didn't understand that jruby needs all its own gems. I'll report back when this is working. > > > If jruby -S rake doesn't work, nothing will work. > > > > > Error opening script file: > > > /Users/david/projects/ruby/jruby/trunk/jruby/bin/opt/local/bin/rake > > > (No such file or directory) > > > > > > I was able to get it to work w/ just: > > > > > > rake checkout_code > > > > > > > That won't work, because it will install the hpricot gem in ruby, not jruby > > > > > But then I did this: > > > > > > $ jruby bin/spec spec -c > > > /Users/david/projects/ruby/jruby/trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in > > > `require': no such file to load -- hpricot (LoadError) > > > $ gem list hpricot > > > > > > > Again, "gem" will run ruby, not jruby. All your problems have the same > > reason - you don't have the appropriate bin files. > > > > > *** LOCAL GEMS *** > > > > > > hpricot (0.5) > > > a swift, liberal HTML parser with a fantastic library > > > > > > So it looks like jruby is not able to see my existing path. Suggestions? > > > > > > > > > > > cd target/rspec > > > > > jruby bin/spec spec -c > > > > > > > > > > I'm getting a bunch of hpricot warnings but otherwise it's 100% > > > > > green!!!!!!!!!!!: > > > > > > > > > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > > > > > values for a block parameter (4 for 1) > > > > > > > > This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK > > > > > > > > Although since RSpec checkout is part of the build, it won't get run > > > > when RSpec code changes at the moment. > > > > > > > > Right now there are 5 failures which come and go, it seems like we > > > > (JRuby) have some randomly recurring issue with Object#inspect or > > > > something like that, because the actual output only differs by #<...>. > > > > One of us will have to look at it. > > > > > > > > /Nick > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From ola.bini at gmail.com Wed May 23 12:29:22 2007 From: ola.bini at gmail.com (Ola Bini) Date: Wed, 23 May 2007 18:29:22 +0200 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Message-ID: <46546BE2.7080109@gmail.com> Nick Sieger wrote: > On 5/23/07, aslak hellesoy wrote: >> Hi all, >> >> The fine JRuby team declared at RailsConf that they will bundle RSpec >> with JRuby when it ships. That's awesome, thanks again guys. >> >> I hope this can be the RSpec 1.0.1 version (not yet released) - it has >> some minor tweaks that are needed to get all of RSpec's specs to run >> on JRuby. (This is something Ola Bini and I paired on at RailsConf). >> We'll release 1.0.1 if the JRuby team ask us for it. >> >> I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). >> >> LET'S KEEP IT THAT WAY. >> >> I'm asking that all RSpec developers make sure RSpec always runs >> against JRuby until they ship 1.0. Here is how: >> >> svn co http://svn.codehaus.org/jruby jruby >> cd jruby/jruby >> ant clean >> ant >> # put JRuby's bin dir on your PATH >> cd ../testsuites/rspec >> mkdir target >> jruby -S rake checkout_code >> cd target/rspec >> jruby bin/spec spec -c >> >> I'm getting a bunch of hpricot warnings but otherwise it's 100% >> green!!!!!!!!!!!: >> >> gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple >> values for a block parameter (4 for 1) > > This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK > > Although since RSpec checkout is part of the build, it won't get run > when RSpec code changes at the moment. > > Right now there are 5 failures which come and go, it seems like we > (JRuby) have some randomly recurring issue with Object#inspect or > something like that, because the actual output only differs by #<...>. > One of us will have to look at it. I actually believe this has something to do with the "hex" string output from Object#inspect not always being the same length. Sometimes it's one char shorter or longer. If there's any regex or similar in RSpec that looks at this, that may be the cause of these failures. -- Ola Bini (http://ola-bini.blogspot.com) JvYAML, RbYAML, JRuby and Jatha contributor System Developer, Karolinska Institutet (http://www.ki.se) OLogix Consulting (http://www.ologix.com) "Yields falsehood when quined" yields falsehood when quined. From dchelimsky at gmail.com Wed May 23 12:57:05 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 11:57:05 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> Message-ID: <57c63afe0705230957n5f999bt3046577b0d74ae37@mail.gmail.com> On 5/23/07, aslak hellesoy wrote: > Hi all, > > The fine JRuby team declared at RailsConf that they will bundle RSpec > with JRuby when it ships. That's awesome, thanks again guys. > > I hope this can be the RSpec 1.0.1 version (not yet released) - it has > some minor tweaks that are needed to get all of RSpec's specs to run > on JRuby. (This is something Ola Bini and I paired on at RailsConf). > We'll release 1.0.1 if the JRuby team ask us for it. > > I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > > LET'S KEEP IT THAT WAY. > > I'm asking that all RSpec developers make sure RSpec always runs > against JRuby until they ship 1.0. Here is how: svn co http://svn.codehaus.org/jruby/trunk jruby cd jruby/jruby ant clean ant # put JRuby's bin dir on your PATH jruby -S gem install rake --no-ri --no-rdoc jruby -S gem install diff-lcs cd ../testsuites/rspec mkdir target jruby -S rake checkout_code cd target/rspec jruby bin/spec spec -c > I'm getting a bunch of hpricot warnings but otherwise it's 100% > green!!!!!!!!!!!: > > gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > values for a block parameter (4 for 1) > > (We're only using hpricot in the html_formatter_spec.rb to verify the > HTML report) > > Cheers, > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Wed May 23 12:57:54 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 23 May 2007 09:57:54 -0700 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> Message-ID: On 5/23/07, David Chelimsky wrote: > I get the following error executing this line. > > Error opening script file: > /Users/david/projects/ruby/jruby/trunk/jruby/bin/rake (No such file or > directory) > > So I tried > > which rake > => /opt/local/bin/rake > > Then this: > > $ jruby -S /opt/local/bin/rake checkout_code > Error opening script file: > /Users/david/projects/ruby/jruby/trunk/jruby/bin/opt/local/bin/rake > (No such file or directory) > > I was able to get it to work w/ just: > > rake checkout_code > > But then I did this: > > $ jruby bin/spec spec -c > /Users/david/projects/ruby/jruby/trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in > `require': no such file to load -- hpricot (LoadError) > $ gem list hpricot > Yeah, we don't yet have Rake in the JRuby repository, and we may not do it (e.g., it may be a build-time thing to install Rails, rather than checking in source). For now, you can simply do jruby -S gem install rake And then everything should work from there. Note that JRuby needs its own version of hpricot that's not on Rubyforge yet, so the :checkout_code target in the testsuites/rspec Rakefile does this for you. /Nick From dchelimsky at gmail.com Wed May 23 12:59:34 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 11:59:34 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> Message-ID: <57c63afe0705230959n283498c5g805343b95e390777@mail.gmail.com> On 5/23/07, Nick Sieger wrote: > On 5/23/07, David Chelimsky wrote: > > I get the following error executing this line. > > > > Error opening script file: > > /Users/david/projects/ruby/jruby/trunk/jruby/bin/rake (No such file or > > directory) > > > > So I tried > > > > which rake > > => /opt/local/bin/rake > > > > Then this: > > > > $ jruby -S /opt/local/bin/rake checkout_code > > Error opening script file: > > /Users/david/projects/ruby/jruby/trunk/jruby/bin/opt/local/bin/rake > > (No such file or directory) > > > > I was able to get it to work w/ just: > > > > rake checkout_code > > > > But then I did this: > > > > $ jruby bin/spec spec -c > > /Users/david/projects/ruby/jruby/trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in > > `require': no such file to load -- hpricot (LoadError) > > $ gem list hpricot > > > > Yeah, we don't yet have Rake in the JRuby repository, and we may not > do it (e.g., it may be a build-time thing to install Rails, rather > than checking in source). For now, you can simply do > > jruby -S gem install rake > > And then everything should work from there. Note that JRuby needs its > own version of hpricot that's not on Rubyforge yet, so the > :checkout_code target in the testsuites/rspec Rakefile does this for > you. Thanks Nick - I got this working now w/ the following steps: svn co http://svn.codehaus.org/jruby/trunk jruby cd jruby/jruby ant clean ant # put JRuby's bin dir on your PATH jruby -S gem install rake --no-ri --no-rdoc jruby -S gem install diff-lcs cd ../testsuites/rspec mkdir target jruby -S rake checkout_code cd target/rspec jruby bin/spec spec -c > > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Wed May 23 13:07:45 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 23 May 2007 10:07:45 -0700 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <57c63afe0705230959n283498c5g805343b95e390777@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230900x34b05c45ua10bbbaa0a7f9919@mail.gmail.com> <57c63afe0705230959n283498c5g805343b95e390777@mail.gmail.com> Message-ID: On 5/23/07, David Chelimsky wrote: > > Thanks Nick - I got this working now w/ the following steps: > > svn co http://svn.codehaus.org/jruby/trunk jruby > cd jruby/jruby > ant clean > ant > # put JRuby's bin dir on your PATH > jruby -S gem install rake --no-ri --no-rdoc > jruby -S gem install diff-lcs > cd ../testsuites/rspec > mkdir target > jruby -S rake checkout_code > cd target/rspec > jruby bin/spec spec -c Not too bad. If you can tolerate maven (don't shoot the messenger!), it can be reduced to this: cd trunk/jruby mvn install cd ../testsuites/rspec mvn clean install /Nick From aslak.hellesoy at gmail.com Wed May 23 13:32:42 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 19:32:42 +0200 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <46546BE2.7080109@gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <46546BE2.7080109@gmail.com> Message-ID: <8d961d900705231032p392bc776jeff49ab1ddd7a06c@mail.gmail.com> On 5/23/07, Ola Bini wrote: > Nick Sieger wrote: > > On 5/23/07, aslak hellesoy wrote: > >> Hi all, > >> > >> The fine JRuby team declared at RailsConf that they will bundle RSpec > >> with JRuby when it ships. That's awesome, thanks again guys. > >> > >> I hope this can be the RSpec 1.0.1 version (not yet released) - it has > >> some minor tweaks that are needed to get all of RSpec's specs to run > >> on JRuby. (This is something Ola Bini and I paired on at RailsConf). > >> We'll release 1.0.1 if the JRuby team ask us for it. > >> > >> I am currently able to run *all* of RSpec core's specs on JRuby (HEAD). > >> > >> LET'S KEEP IT THAT WAY. > >> > >> I'm asking that all RSpec developers make sure RSpec always runs > >> against JRuby until they ship 1.0. Here is how: > >> > >> svn co http://svn.codehaus.org/jruby jruby > >> cd jruby/jruby > >> ant clean > >> ant > >> # put JRuby's bin dir on your PATH > >> cd ../testsuites/rspec > >> mkdir target > >> jruby -S rake checkout_code > >> cd target/rspec > >> jruby bin/spec spec -c > >> > >> I'm getting a bunch of hpricot warnings but otherwise it's 100% > >> green!!!!!!!!!!!: > >> > >> gems/hpricot-0.5.140-jruby/lib/hpricot/parse.rb:15 warning: multiple > >> values for a block parameter (4 for 1) > > > > This is also in CI: http://jruby.thresher.com/browse/RSPEC-TRUNK > > > > Although since RSpec checkout is part of the build, it won't get run > > when RSpec code changes at the moment. > > > > Right now there are 5 failures which come and go, it seems like we > > (JRuby) have some randomly recurring issue with Object#inspect or > > something like that, because the actual output only differs by #<...>. > > One of us will have to look at it. > I actually believe this has something to do with the "hex" string output > from Object#inspect not always being the same length. Sometimes it's one > char shorter or longer. If there's any regex or similar in RSpec that > looks at this, that may be the cause of these failures. > I don't think we have any such specs. What specs are the ones failing for you? I couldn't see it in the bamboo. Stack traces would be great. Aslak > > -- > Ola Bini (http://ola-bini.blogspot.com) > JvYAML, RbYAML, JRuby and Jatha contributor > System Developer, Karolinska Institutet (http://www.ki.se) > OLogix Consulting (http://www.ologix.com) > > "Yields falsehood when quined" yields falsehood when quined. > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed May 23 14:36:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 14:36:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11066 ] http://rspec.rubyforge.org/contribute.html - dead link Message-ID: <20070523183616.75B5D5240B23@rubyforge.org> Bugs item #11066, was opened at 2007-05-23 14:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: http://rspec.rubyforge.org/contribute.html - dead link Initial Comment: Sorry for not reading the contribute document, but the link is dead. ---------------------------------------------------------------------- >Comment By: Jon Egil Strand (jonegil) Date: 2007-05-23 20:36 Message: Sure. The link is on the front page of the bug-tracker: http://rubyforge.org/tracker/?atid=3149&group_id=797&func=browse ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 15:09 Message: The contribute page is here: http://rspec.rubyforge.org/community/contribute.html If you tell us where the dead link is, we'll fix it ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 15:06 Message: Yes, that target is dead. Where did you see the link? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 From noreply at rubyforge.org Wed May 23 14:46:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 14:46:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11066 ] http://rspec.rubyforge.org/contribute.html - dead link Message-ID: <20070523184614.03AE05240A4E@rubyforge.org> Bugs item #11066, was opened at 2007-05-23 08:48 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jon Egil Strand (jonegil) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: http://rspec.rubyforge.org/contribute.html - dead link Initial Comment: Sorry for not reading the contribute document, but the link is dead. ---------------------------------------------------------------------- Comment By: Jon Egil Strand (jonegil) Date: 2007-05-23 14:36 Message: Sure. The link is on the front page of the bug-tracker: http://rubyforge.org/tracker/?atid=3149&group_id=797&func=browse ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 09:09 Message: The contribute page is here: http://rspec.rubyforge.org/community/contribute.html If you tell us where the dead link is, we'll fix it ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 09:06 Message: Yes, that target is dead. Where did you see the link? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11066&group_id=797 From noreply at rubyforge.org Wed May 23 14:52:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 14:52:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11067 ] spec runner with -c removes all 'a'-characters for output Message-ID: <20070523185241.29CEA5240A4E@rubyforge.org> Bugs item #11067, was opened at 2007-05-23 14:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: spec runner with -c removes all 'a'-characters for output Initial Comment: ruby 1.8.5 (2006-08-25) [i386-mswin32] rspec 1.0 >From the windows command-line I run spec my_specifications.rb -f s -c Compose SQL - should clen \n nd whitespce Note that all 'a'-characters are missing. If i run _without_ -c, its all good. spec my_specifications.rb -f s Compose SQL - should clean \n and whitespace The colours are really helpful, but so are 'a's. ---------------------------------------------------------------------- >Comment By: Jon Egil Strand (jonegil) Date: 2007-05-23 20:52 Message: A short version of the spec-file is attached. Note that the 'a' is missing in all specs, both failing and successful. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 15:48 Message: I'm unable to reproduce this. I am on: ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] rspec 1.0.0 win32console (1.0.8) Could you please attach your spec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 From dchelimsky at gmail.com Wed May 23 14:58:39 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 13:58:39 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <46548BD5.1020007@sun.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> Message-ID: <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> On 5/23/07, Charles Oliver Nutter wrote: > David Chelimsky wrote: > > On 5/23/07, aslak hellesoy wrote: > >> I hope this can be the RSpec 1.0.1 version (not yet released) - it has > >> some minor tweaks that are needed to get all of RSpec's specs to run > >> on JRuby. (This is something Ola Bini and I paired on at RailsConf). > >> We'll release 1.0.1 if the JRuby team ask us for it. > > > > I want to release 1.0.1 this week, but I'm coordinating w/ Ryan Davis > > on new releases of both rspec and zentest to improve the integration > > between rspec autotest. If a release must go out for jruby before > > we're ready for zentest we can do it, but I'd prefer to wait until > > Ryan and I get this to work (hopefully this week) to avoid two > > releases. > > FYI, I think the way we're going to handle bundling RSpec is to have the > "dist" process automatically install it. So whatever's current at the > time we release JRuby 1.0 (probably about 1.5wks away) will be installed > when we dist. Are you checking out from rspec's trunk or from a tagged release? > > And BTW, we also plan to ship Rake in the same way, so with a binary > JRuby dist you'll have Rake, RubyGems, and RSpec out of the box. I can't begin to tell you how excited I am about this. Thanks! Cheers, David > > - Charlie From charles.nutter at sun.com Wed May 23 14:45:41 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 23 May 2007 13:45:41 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> Message-ID: <46548BD5.1020007@sun.com> David Chelimsky wrote: > On 5/23/07, aslak hellesoy wrote: >> I hope this can be the RSpec 1.0.1 version (not yet released) - it has >> some minor tweaks that are needed to get all of RSpec's specs to run >> on JRuby. (This is something Ola Bini and I paired on at RailsConf). >> We'll release 1.0.1 if the JRuby team ask us for it. > > I want to release 1.0.1 this week, but I'm coordinating w/ Ryan Davis > on new releases of both rspec and zentest to improve the integration > between rspec autotest. If a release must go out for jruby before > we're ready for zentest we can do it, but I'd prefer to wait until > Ryan and I get this to work (hopefully this week) to avoid two > releases. FYI, I think the way we're going to handle bundling RSpec is to have the "dist" process automatically install it. So whatever's current at the time we release JRuby 1.0 (probably about 1.5wks away) will be installed when we dist. And BTW, we also plan to ship Rake in the same way, so with a binary JRuby dist you'll have Rake, RubyGems, and RSpec out of the box. - Charlie From aslak.hellesoy at gmail.com Wed May 23 15:20:38 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 23 May 2007 21:20:38 +0200 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> Message-ID: <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> On 5/23/07, David Chelimsky wrote: > On 5/23/07, Charles Oliver Nutter wrote: > > David Chelimsky wrote: > > > On 5/23/07, aslak hellesoy wrote: > > >> I hope this can be the RSpec 1.0.1 version (not yet released) - it has > > >> some minor tweaks that are needed to get all of RSpec's specs to run > > >> on JRuby. (This is something Ola Bini and I paired on at RailsConf). > > >> We'll release 1.0.1 if the JRuby team ask us for it. > > > > > > I want to release 1.0.1 this week, but I'm coordinating w/ Ryan Davis > > > on new releases of both rspec and zentest to improve the integration > > > between rspec autotest. If a release must go out for jruby before > > > we're ready for zentest we can do it, but I'd prefer to wait until > > > Ryan and I get this to work (hopefully this week) to avoid two > > > releases. > > > > FYI, I think the way we're going to handle bundling RSpec is to have the > > "dist" process automatically install it. So whatever's current at the > > time we release JRuby 1.0 (probably about 1.5wks away) will be installed > > when we dist. > > Are you checking out from rspec's trunk or from a tagged release? > I hope you'll install a tagged release. 1.0.0 or 1.0.1, but not something inbetween. Aslak > > > > And BTW, we also plan to ship Rake in the same way, so with a binary > > JRuby dist you'll have Rake, RubyGems, and RSpec out of the box. > > I can't begin to tell you how excited I am about this. Thanks! > > Cheers, > David > > > > > - Charlie > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed May 23 15:22:15 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 14:22:15 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> Message-ID: <57c63afe0705231222k1efba46bmf72a73ee53e6c63d@mail.gmail.com> On 5/23/07, aslak hellesoy wrote: > On 5/23/07, David Chelimsky wrote: > > On 5/23/07, Charles Oliver Nutter wrote: > > > David Chelimsky wrote: > > > > On 5/23/07, aslak hellesoy wrote: > > > >> I hope this can be the RSpec 1.0.1 version (not yet released) - it has > > > >> some minor tweaks that are needed to get all of RSpec's specs to run > > > >> on JRuby. (This is something Ola Bini and I paired on at RailsConf). > > > >> We'll release 1.0.1 if the JRuby team ask us for it. > > > > > > > > I want to release 1.0.1 this week, but I'm coordinating w/ Ryan Davis > > > > on new releases of both rspec and zentest to improve the integration > > > > between rspec autotest. If a release must go out for jruby before > > > > we're ready for zentest we can do it, but I'd prefer to wait until > > > > Ryan and I get this to work (hopefully this week) to avoid two > > > > releases. > > > > > > FYI, I think the way we're going to handle bundling RSpec is to have the > > > "dist" process automatically install it. So whatever's current at the > > > time we release JRuby 1.0 (probably about 1.5wks away) will be installed > > > when we dist. > > > > Are you checking out from rspec's trunk or from a tagged release? > > > > I hope you'll install a tagged release. 1.0.0 or 1.0.1, but not > something inbetween. Yes, please! David > > Aslak > > > > > > > And BTW, we also plan to ship Rake in the same way, so with a binary > > > JRuby dist you'll have Rake, RubyGems, and RSpec out of the box. > > > > I can't begin to tell you how excited I am about this. Thanks! > > > > Cheers, > > David > > > > > > > > - Charlie > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed May 23 15:34:39 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 23 May 2007 14:34:39 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <4654960A.6020806@sun.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> <57c63afe0705231222k1efba46bmf72a73ee53e6c63d@mail.gmail.com> <4654960A.6020806@sun.com> Message-ID: <57c63afe0705231234k729e847dke9649c312a5cafac@mail.gmail.com> On 5/23/07, Charles Oliver Nutter wrote: > David Chelimsky wrote: > > On 5/23/07, aslak hellesoy wrote: > >> I hope you'll install a tagged release. 1.0.0 or 1.0.1, but not > >> something inbetween. > > > > Yes, please! > >> > > We will install whatever's the current gem at the time we release JRuby 1.0. OK - Aslak - why don't we go ahead and release 1.0.1 now. As soon as Ryan and I can coordinate on the rspec/autotest integration, we'll do another release. But we should get the changes you made to support jruby released. Agree? From charles.nutter at sun.com Wed May 23 15:29:14 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 23 May 2007 14:29:14 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <57c63afe0705231222k1efba46bmf72a73ee53e6c63d@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> <57c63afe0705231222k1efba46bmf72a73ee53e6c63d@mail.gmail.com> Message-ID: <4654960A.6020806@sun.com> David Chelimsky wrote: > On 5/23/07, aslak hellesoy wrote: >> I hope you'll install a tagged release. 1.0.0 or 1.0.1, but not >> something inbetween. > > Yes, please! >> We will install whatever's the current gem at the time we release JRuby 1.0. - Charlie From nicksieger at gmail.com Wed May 23 15:56:25 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 23 May 2007 12:56:25 -0700 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> Message-ID: On 5/23/07, aslak hellesoy wrote: > I hope you'll install a tagged release. 1.0.0 or 1.0.1, but not > something inbetween. Yes, we'll probaby build/bootstrap JRuby and use rubygems to install a released version into the distributable before archiving it. /Nick From noreply at rubyforge.org Wed May 23 18:21:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 18:21:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11075 ] controller specs fail when using mocha without integrated_views Message-ID: <20070523222143.403F45240AA0@rubyforge.org> Bugs item #11075, was opened at 2007-05-23 22:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11075&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthew Deiters (mdeiters) Assigned to: Nobody (None) Summary: controller specs fail when using mocha without integrated_views Initial Comment: On my controller specs, I am forced to 'integrate_views' as the following code below shows you, the mocking of views is rspec specific. See stub! versus mocha's stub unless block_given? unless integrate_views? @template.stub!(:file_exists?).and_return(true) @template.should_receive(:render_template).any_number_of_times.and_return(true) { |*args| @first_render ||= args[2] } @template.stub!(:find_template_extension_for).and_return("rhtml") @template.stub!(:read_template_file).and_return("this is fake content generated by rspec") end end I am getting the following error: undefined method `stub!' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11075&group_id=797 From noreply at rubyforge.org Wed May 23 20:01:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 20:01:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11079 ] Double Render Errors not raised in Controller Specs Message-ID: <20070524000152.95F285240A4E@rubyforge.org> Bugs item #11079, was opened at 2007-05-23 17:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11079&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Double Render Errors not raised in Controller Specs Initial Comment: This is without integrated views. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11079&group_id=797 From noreply at rubyforge.org Wed May 23 20:04:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 May 2007 20:04:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11079 ] Double Render Errors not raised in Controller Specs Message-ID: <20070524000423.DAD775240A4E@rubyforge.org> Bugs item #11079, was opened at 2007-05-24 00:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11079&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Double Render Errors not raised in Controller Specs Initial Comment: This is without integrated views. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 00:04 Message: are you overriding rescue_action? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11079&group_id=797 From bscofield at gmail.com Wed May 23 21:06:17 2007 From: bscofield at gmail.com (Ben Scofield) Date: Wed, 23 May 2007 21:06:17 -0400 Subject: [rspec-devel] Question re: providing specs with patches In-Reply-To: <20070524000423.DAD775240A4E@rubyforge.org> References: <20070524000423.DAD775240A4E@rubyforge.org> Message-ID: <4654E509.4070208@gmail.com> Hi all, I just patched the rspec_controller generator in rspec_on_rails (it's failing against Edge Rails - it's using the old-style view naming (.rhtml instead of .html.erb)). I wanted to submit the patch, but I couldn't find any specs for the generators... am I missing something obvious? Thanks! Ben Scofield From noreply at rubyforge.org Thu May 24 00:13:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 00:13:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11082 ] RspecResourceGenerator should be RspecScaffoldGenerator Message-ID: <20070524041317.DE0BC5240B62@rubyforge.org> Bugs item #11082, was opened at 2007-05-24 00:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11082&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Edward Ocampo-Gooding (edwardog) Assigned to: Nobody (None) Summary: RspecResourceGenerator should be RspecScaffoldGenerator Initial Comment: When running the rspec_scaffold generator that came with the rspec for rails plugin 1.0.1, I was getting some error about it not being able to find RspecScaffoldGenerator. The problem/fix looks like this: --- vendor/rspec_on_rails/generators/rspec_scaffold/rspec_scaffold_generator.rb +++ (clipboard) @@ -1,4 +1,4 @@ -class RspecResourceGenerator < Rails::Generator::NamedBase +class RspecScaffoldGenerator < Rails::Generator::NamedBase This aside, the plugin/RSpec as a whole is really awesome. Thanks for the release! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11082&group_id=797 From noreply at rubyforge.org Thu May 24 02:31:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 02:31:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10959 ] Focused Examples do not work for Behaviour defined with constant with modules Message-ID: <20070524063139.1D2185240A61@rubyforge.org> Bugs item #10959, was opened at 2007-05-21 00:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Focused Examples do not work for Behaviour defined with constant with modules Initial Comment: e.g. describe Foo::Bar do it "gets here" do true.should == true end end ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-23 23:31 Message: Fixed in Rev. 2011 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 01:35 Message: When you do this: module Space class Thing the output reads: Space::Thing We want to be able to say: spec spec -e "Space::Thing" ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-21 01:12 Message: In spec_matcher_spec.rb, there is an example: "should match when behaviour is modularized" The error was caused by changing ExampleMatcher to handle this. What is the purpose of doing the spec_matcher_spec example? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 From noreply at rubyforge.org Thu May 24 02:31:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 02:31:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10959 ] Focused Examples do not work for Behaviour defined with constant with modules Message-ID: <20070524063151.157495240A61@rubyforge.org> Bugs item #10959, was opened at 2007-05-21 00:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Focused Examples do not work for Behaviour defined with constant with modules Initial Comment: e.g. describe Foo::Bar do it "gets here" do true.should == true end end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-23 23:31 Message: Fixed in Rev. 2011 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 01:35 Message: When you do this: module Space class Thing the output reads: Space::Thing We want to be able to say: spec spec -e "Space::Thing" ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-05-21 01:12 Message: In spec_matcher_spec.rb, there is an example: "should match when behaviour is modularized" The error was caused by changing ExampleMatcher to handle this. What is the purpose of doing the spec_matcher_spec example? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10959&group_id=797 From noreply at rubyforge.org Thu May 24 04:26:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 04:26:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11082 ] RspecResourceGenerator should be RspecScaffoldGenerator Message-ID: <20070524082639.663A65240ADC@rubyforge.org> Bugs item #11082, was opened at 2007-05-24 04:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11082&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Edward Ocampo-Gooding (edwardog) >Assigned to: David Chelimsky (dchelimsky) Summary: RspecResourceGenerator should be RspecScaffoldGenerator Initial Comment: When running the rspec_scaffold generator that came with the rspec for rails plugin 1.0.1, I was getting some error about it not being able to find RspecScaffoldGenerator. The problem/fix looks like this: --- vendor/rspec_on_rails/generators/rspec_scaffold/rspec_scaffold_generator.rb +++ (clipboard) @@ -1,4 +1,4 @@ -class RspecResourceGenerator < Rails::Generator::NamedBase +class RspecScaffoldGenerator < Rails::Generator::NamedBase This aside, the plugin/RSpec as a whole is really awesome. Thanks for the release! ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 08:26 Message: Fixed in r2012 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11082&group_id=797 From noreply at rubyforge.org Thu May 24 06:50:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 06:50:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10997 ] Can't run specs without rspec plugin Message-ID: <20070524105052.D3CB6524099D@rubyforge.org> Bugs item #10997, was opened at 2007-05-21 19:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bryan Helmkamp (brynary) Assigned to: Nobody (None) Summary: Can't run specs without rspec plugin Initial Comment: I'm unable to run the "rake spec" command when I do not have the rspec gem installed, even if I have rspec unpacked into vendor/plugins as described in the installation instructions. The results are: $ rake spec (in /Users/bhelmkamp/p/mcommons_trunk) rake aborted! no such file to load -- spec/rake/spectask /Users/bhelmkamp/p/mcommons_trunk/rakefile:10 (See full trace by running task with --trace) Running script/spec does work as intended, however this seems to defeat the purpose of extracting the plugin into the source tree. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 10:50 Message: This is odd. I have basically the same setup as you and I can't duplicate this problem. I've tried it with and without the rspec gem installed and there seems to be no problem. Anybody else experiencing this? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-22 00:07 Message: Thanks Bryan - I'll be looking into this. Cheers, David ---------------------------------------------------------------------- Comment By: Bryan Helmkamp (brynary) Date: 2007-05-22 00:06 Message: Here we go: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.0.0 * Spec::Rails 1.0.0 * Rails 1.2.3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 23:54 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 From noreply at rubyforge.org Thu May 24 06:54:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 06:54:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11067 ] spec runner with -c removes all 'a'-characters for output Message-ID: <20070524105431.8B32E524096C@rubyforge.org> Bugs item #11067, was opened at 2007-05-23 12:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: spec runner with -c removes all 'a'-characters for output Initial Comment: ruby 1.8.5 (2006-08-25) [i386-mswin32] rspec 1.0 >From the windows command-line I run spec my_specifications.rb -f s -c Compose SQL - should clen \n nd whitespce Note that all 'a'-characters are missing. If i run _without_ -c, its all good. spec my_specifications.rb -f s Compose SQL - should clean \n and whitespace The colours are really helpful, but so are 'a's. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 10:54 Message: I m not running on windows, so I'll let slk tke look t it, but I bsolutely love this bug! ---------------------------------------------------------------------- Comment By: Jon Egil Strand (jonegil) Date: 2007-05-23 18:52 Message: A short version of the spec-file is attached. Note that the 'a' is missing in all specs, both failing and successful. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-23 13:48 Message: I'm unable to reproduce this. I am on: ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] rspec 1.0.0 win32console (1.0.8) Could you please attach your spec? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11067&group_id=797 From noreply at rubyforge.org Thu May 24 07:04:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 07:04:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11075 ] controller specs fail when using mocha without integrated_views Message-ID: <20070524110416.BA0F15240A61@rubyforge.org> Bugs item #11075, was opened at 2007-05-23 22:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11075&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Matthew Deiters (mdeiters) >Assigned to: David Chelimsky (dchelimsky) Summary: controller specs fail when using mocha without integrated_views Initial Comment: On my controller specs, I am forced to 'integrate_views' as the following code below shows you, the mocking of views is rspec specific. See stub! versus mocha's stub unless block_given? unless integrate_views? @template.stub!(:file_exists?).and_return(true) @template.should_receive(:render_template).any_number_of_times.and_return(true) { |*args| @first_render ||= args[2] } @template.stub!(:find_template_extension_for).and_return("rhtml") @template.stub!(:read_template_file).and_return("this is fake content generated by rspec") end end I am getting the following error: undefined method `stub!' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 11:04 Message: Fixed in r2019 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11075&group_id=797 From noreply at rubyforge.org Thu May 24 07:26:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 07:26:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11091 ] mock setup fails in before(:all), but succeeds in before(:each) Message-ID: <20070524112617.0CE05524098A@rubyforge.org> Bugs item #11091, was opened at 2007-05-24 13:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: Nobody (None) Summary: mock setup fails in before(:all), but succeeds in before(:each) Initial Comment: The attached spec shows how setting up a mock fails inconsistently. When setting it up within before(:all), it fails. When setting it up within before(:each), it is ok. When setting it up within before(:each), then within before(:all), both are ok. Parsing data - before(:all) (ERROR - 1) Parsing data - should include 10 persons (ERROR - 2) Parsing data - should include 10 persons (ERROR - 3) 1) NoMethodError in 'Parsing data before(:all)' undefined method `add' for nil:NilClass ./test\spec_bug.rb:5: 2) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:18: 3) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:31: Finished in 0.06 seconds 3 examples, 3 failures ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 From noreply at rubyforge.org Thu May 24 07:41:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 07:41:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11091 ] mock setup fails in before(:all), but succeeds in before(:each) Message-ID: <20070524114124.ECDFF5240A5B@rubyforge.org> Bugs item #11091, was opened at 2007-05-24 11:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Jon Egil Strand (jonegil) >Assigned to: David Chelimsky (dchelimsky) Summary: mock setup fails in before(:all), but succeeds in before(:each) Initial Comment: The attached spec shows how setting up a mock fails inconsistently. When setting it up within before(:all), it fails. When setting it up within before(:each), it is ok. When setting it up within before(:each), then within before(:all), both are ok. Parsing data - before(:all) (ERROR - 1) Parsing data - should include 10 persons (ERROR - 2) Parsing data - should include 10 persons (ERROR - 3) 1) NoMethodError in 'Parsing data before(:all)' undefined method `add' for nil:NilClass ./test\spec_bug.rb:5: 2) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:18: 3) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:31: Finished in 0.06 seconds 3 examples, 3 failures ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 11:41 Message: This is by design. before(:all) is not executed in the same binding as the examples are. Using before(:all) for mocks is a mock-no-no. Doing so would bind your examples together and produce unexpected results. What we need is better documentation about before(:each) and before(:all). I'll work on that for the next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 From noreply at rubyforge.org Thu May 24 09:08:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 09:08:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11091 ] mock setup fails in before(:all), but succeeds in before(:each) Message-ID: <20070524130851.055E5524094F@rubyforge.org> Bugs item #11091, was opened at 2007-05-24 13:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: David Chelimsky (dchelimsky) Summary: mock setup fails in before(:all), but succeeds in before(:each) Initial Comment: The attached spec shows how setting up a mock fails inconsistently. When setting it up within before(:all), it fails. When setting it up within before(:each), it is ok. When setting it up within before(:each), then within before(:all), both are ok. Parsing data - before(:all) (ERROR - 1) Parsing data - should include 10 persons (ERROR - 2) Parsing data - should include 10 persons (ERROR - 3) 1) NoMethodError in 'Parsing data before(:all)' undefined method `add' for nil:NilClass ./test\spec_bug.rb:5: 2) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:18: 3) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:31: Finished in 0.06 seconds 3 examples, 3 failures ---------------------------------------------------------------------- >Comment By: Jon Egil Strand (jonegil) Date: 2007-05-24 15:08 Message: Not meaning to make this an open discussion, but actually, before(:all) mocks are more of a yes-yes than a no-no. I set this thing up as follows: describe "Heavy parser process" do before(:all) do log = mock("log") log.should_receive(:informative_message).once #Let's say this is a very slow (1 minute) process @heavy = HeavyParser.new('path/to/data', log) end it "should contain expected data" do @heavy.data.should include(:expected) end it "should not contain surprises" do @heavy.data.should_not include(:surprise) end end Since the before(:all) is _slow_ I like to be able to do it just once. Am I missing out on something? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 13:41 Message: This is by design. before(:all) is not executed in the same binding as the examples are. Using before(:all) for mocks is a mock-no-no. Doing so would bind your examples together and produce unexpected results. What we need is better documentation about before(:each) and before(:all). I'll work on that for the next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 From noreply at rubyforge.org Thu May 24 09:56:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 09:56:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11091 ] mock setup fails in before(:all), but succeeds in before(:each) Message-ID: <20070524135624.2DC145240AA1@rubyforge.org> Bugs item #11091, was opened at 2007-05-24 07:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: David Chelimsky (dchelimsky) Summary: mock setup fails in before(:all), but succeeds in before(:each) Initial Comment: The attached spec shows how setting up a mock fails inconsistently. When setting it up within before(:all), it fails. When setting it up within before(:each), it is ok. When setting it up within before(:each), then within before(:all), both are ok. Parsing data - before(:all) (ERROR - 1) Parsing data - should include 10 persons (ERROR - 2) Parsing data - should include 10 persons (ERROR - 3) 1) NoMethodError in 'Parsing data before(:all)' undefined method `add' for nil:NilClass ./test\spec_bug.rb:5: 2) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:18: 3) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:31: Finished in 0.06 seconds 3 examples, 3 failures ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 09:56 Message: Perhaps mock() should not even be available in the before(:all) block? Or - it could be available, but raise an error with a good explanation. ---------------------------------------------------------------------- Comment By: Jon Egil Strand (jonegil) Date: 2007-05-24 09:08 Message: Not meaning to make this an open discussion, but actually, before(:all) mocks are more of a yes-yes than a no-no. I set this thing up as follows: describe "Heavy parser process" do before(:all) do log = mock("log") log.should_receive(:informative_message).once #Let's say this is a very slow (1 minute) process @heavy = HeavyParser.new('path/to/data', log) end it "should contain expected data" do @heavy.data.should include(:expected) end it "should not contain surprises" do @heavy.data.should_not include(:surprise) end end Since the before(:all) is _slow_ I like to be able to do it just once. Am I missing out on something? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 07:41 Message: This is by design. before(:all) is not executed in the same binding as the examples are. Using before(:all) for mocks is a mock-no-no. Doing so would bind your examples together and produce unexpected results. What we need is better documentation about before(:each) and before(:all). I'll work on that for the next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 From noreply at rubyforge.org Thu May 24 10:58:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 10:58:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11093 ] Add a RSS on changes log in the public web site Message-ID: <20070524145811.2D2C35240A88@rubyforge.org> Feature Requests item #11093, was opened at 2007-05-24 16:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11093&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Jean-Michel Garnier (garnierjm) Assigned to: Nobody (None) Summary: Add a RSS on changes log in the public web site Initial Comment: As the public web site seems to not contain a blog or RSS feed, I have used the excellent tool page2rss.com to generate a RSS feed on the http://rspec.rubyforge.org/changes.html page. To receive updates for this page in RSS format copy-paste http://page2rss.com/page/rss?url=rspec.rubyforge.org/changes.html into your feed reader. I have posted on my blog more details: http://21croissants.blogspot.com/2007/05/rspec-changes-log-rss.html Maybe, this RSS link could be added in the web site? On a sidenote, it would be great to be able see the site map of the documentation web site at the bottom of each page or in the header. Apart from that, documentation content is great and style is quite cool, I am willing to contribute with more examples in the near future. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11093&group_id=797 From noreply at rubyforge.org Thu May 24 11:31:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 11:31:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11091 ] mock setup fails in before(:all), but succeeds in before(:each) Message-ID: <20070524153114.C6A815240AF0@rubyforge.org> Bugs item #11091, was opened at 2007-05-24 11:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 Category: mock module Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Jon Egil Strand (jonegil) Assigned to: David Chelimsky (dchelimsky) Summary: mock setup fails in before(:all), but succeeds in before(:each) Initial Comment: The attached spec shows how setting up a mock fails inconsistently. When setting it up within before(:all), it fails. When setting it up within before(:each), it is ok. When setting it up within before(:each), then within before(:all), both are ok. Parsing data - before(:all) (ERROR - 1) Parsing data - should include 10 persons (ERROR - 2) Parsing data - should include 10 persons (ERROR - 3) 1) NoMethodError in 'Parsing data before(:all)' undefined method `add' for nil:NilClass ./test\spec_bug.rb:5: 2) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:18: 3) Spec::Mocks::MockExpectationError in 'Parsing data should include 10 persons' Mock 'gui' expected :increment with (any args) once, but received it 0 times ./test\spec_bug.rb:31: Finished in 0.06 seconds 3 examples, 3 failures ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 15:31 Message: Jon - you cite an interesting case, but a problematic one as well. The philosophical problem is that "log.should_receive(:informative_message).once" sets an expectation, but it is not part of any example, which means that you lose the documentation value (i.e. it is never expressed in any report). The practical problem is that mocks and stubs get torn down implicitly after(:each) example. This means that should_receive will be effective in the first example that is run, but not in the second. So in this case, if all you need is stubs, you could use something like openstruct: require 'ostruct' describe "Heavy parser process" do before(:all) do log = OpenStruct.new(:informative_message => true) @heavy = HeavyParser.new('path/to/data', log) end ... and then if you really want to set a mock expectation to express a requirement that something gets logged, you can do THAT like this: it "should receive an informative message" @heavy.log. should_receive(:informative_message). with("very informative") @heavy.parse(something) end end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 13:56 Message: Perhaps mock() should not even be available in the before(:all) block? Or - it could be available, but raise an error with a good explanation. ---------------------------------------------------------------------- Comment By: Jon Egil Strand (jonegil) Date: 2007-05-24 13:08 Message: Not meaning to make this an open discussion, but actually, before(:all) mocks are more of a yes-yes than a no-no. I set this thing up as follows: describe "Heavy parser process" do before(:all) do log = mock("log") log.should_receive(:informative_message).once #Let's say this is a very slow (1 minute) process @heavy = HeavyParser.new('path/to/data', log) end it "should contain expected data" do @heavy.data.should include(:expected) end it "should not contain surprises" do @heavy.data.should_not include(:surprise) end end Since the before(:all) is _slow_ I like to be able to do it just once. Am I missing out on something? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 11:41 Message: This is by design. before(:all) is not executed in the same binding as the examples are. Using before(:all) for mocks is a mock-no-no. Doing so would bind your examples together and produce unexpected results. What we need is better documentation about before(:each) and before(:all). I'll work on that for the next release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11091&group_id=797 From noreply at rubyforge.org Thu May 24 17:11:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 17:11:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11101 ] StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Message-ID: <20070524211200.292265240A61@rubyforge.org> Bugs item #11101, was opened at 2007-05-24 16:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 Category: rails plugin Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: sinclair bain (sinclair) Assigned to: Nobody (None) Summary: StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Initial Comment: rails plugin : rspec 1_0_0 file: rspec/lib/spec/expectations/extensions/string_and_symbol.rb The starts_with? implementation assume that the _prefix_ arg is a string in that it calls #length without a #to_s (for example) so if it is passed an Fixnum, or nil then it ends abruptly. module Spec module Expectations module StringHelpers def starts_with?(prefix) to_s[0..(prefix.length - 1)] == prefix end end end end By changing the implementation to call #to_s on prefix (for example) the method is slightly more forgiving - along the lines of: def starts_with?(prefix = '') to_s[0..(prefix.to_s.length - 1)] == prefix.to_s end By doing this there is no requirement on the caller to assume any particular implementation. Hope this helps, sinclair ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 From noreply at rubyforge.org Thu May 24 17:17:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 17:17:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11101 ] StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Message-ID: <20070524211750.BED665240A61@rubyforge.org> Bugs item #11101, was opened at 2007-05-24 21:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 Category: rails plugin Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: sinclair bain (sinclair) >Assigned to: David Chelimsky (dchelimsky) Summary: StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Initial Comment: rails plugin : rspec 1_0_0 file: rspec/lib/spec/expectations/extensions/string_and_symbol.rb The starts_with? implementation assume that the _prefix_ arg is a string in that it calls #length without a #to_s (for example) so if it is passed an Fixnum, or nil then it ends abruptly. module Spec module Expectations module StringHelpers def starts_with?(prefix) to_s[0..(prefix.length - 1)] == prefix end end end end By changing the implementation to call #to_s on prefix (for example) the method is slightly more forgiving - along the lines of: def starts_with?(prefix = '') to_s[0..(prefix.to_s.length - 1)] == prefix.to_s end By doing this there is no requirement on the caller to assume any particular implementation. Hope this helps, sinclair ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 21:17 Message: That's a pretty good idea. Feel like making a patch w/ specs? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 From noreply at rubyforge.org Thu May 24 17:54:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 17:54:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11101 ] StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Message-ID: <20070524215401.EFFF05240A5B@rubyforge.org> Bugs item #11101, was opened at 2007-05-24 17:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 Category: rails plugin Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: sinclair bain (sinclair) Assigned to: David Chelimsky (dchelimsky) Summary: StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Initial Comment: rails plugin : rspec 1_0_0 file: rspec/lib/spec/expectations/extensions/string_and_symbol.rb The starts_with? implementation assume that the _prefix_ arg is a string in that it calls #length without a #to_s (for example) so if it is passed an Fixnum, or nil then it ends abruptly. module Spec module Expectations module StringHelpers def starts_with?(prefix) to_s[0..(prefix.length - 1)] == prefix end end end end By changing the implementation to call #to_s on prefix (for example) the method is slightly more forgiving - along the lines of: def starts_with?(prefix = '') to_s[0..(prefix.to_s.length - 1)] == prefix.to_s end By doing this there is no requirement on the caller to assume any particular implementation. Hope this helps, sinclair ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 17:54 Message: Out of curiosity, is the current implementation causing specs to fail? If so, can you give an example? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 17:17 Message: That's a pretty good idea. Feel like making a patch w/ specs? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 From noreply at rubyforge.org Thu May 24 18:03:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 18:03:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11101 ] StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Message-ID: <20070524220311.D01E35240A5B@rubyforge.org> Bugs item #11101, was opened at 2007-05-24 17:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 Category: rails plugin Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: sinclair bain (sinclair) Assigned to: David Chelimsky (dchelimsky) Summary: StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Initial Comment: rails plugin : rspec 1_0_0 file: rspec/lib/spec/expectations/extensions/string_and_symbol.rb The starts_with? implementation assume that the _prefix_ arg is a string in that it calls #length without a #to_s (for example) so if it is passed an Fixnum, or nil then it ends abruptly. module Spec module Expectations module StringHelpers def starts_with?(prefix) to_s[0..(prefix.length - 1)] == prefix end end end end By changing the implementation to call #to_s on prefix (for example) the method is slightly more forgiving - along the lines of: def starts_with?(prefix = '') to_s[0..(prefix.to_s.length - 1)] == prefix.to_s end By doing this there is no requirement on the caller to assume any particular implementation. Hope this helps, sinclair ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 18:03 Message: Applied in r2026 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 17:54 Message: Out of curiosity, is the current implementation causing specs to fail? If so, can you give an example? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 17:17 Message: That's a pretty good idea. Feel like making a patch w/ specs? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 From noreply at rubyforge.org Thu May 24 18:03:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 18:03:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11101 ] StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Message-ID: <20070524220351.B97415240ACE@rubyforge.org> Bugs item #11101, was opened at 2007-05-24 17:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 >Category: runner module Group: v1.0 (example) >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: sinclair bain (sinclair) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: StringHelpers.starts_with?(prefix) assumes a string parameter for _prefix_ Initial Comment: rails plugin : rspec 1_0_0 file: rspec/lib/spec/expectations/extensions/string_and_symbol.rb The starts_with? implementation assume that the _prefix_ arg is a string in that it calls #length without a #to_s (for example) so if it is passed an Fixnum, or nil then it ends abruptly. module Spec module Expectations module StringHelpers def starts_with?(prefix) to_s[0..(prefix.length - 1)] == prefix end end end end By changing the implementation to call #to_s on prefix (for example) the method is slightly more forgiving - along the lines of: def starts_with?(prefix = '') to_s[0..(prefix.to_s.length - 1)] == prefix.to_s end By doing this there is no requirement on the caller to assume any particular implementation. Hope this helps, sinclair ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 18:03 Message: Applied in r2026 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 17:54 Message: Out of curiosity, is the current implementation causing specs to fail? If so, can you give an example? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 17:17 Message: That's a pretty good idea. Feel like making a patch w/ specs? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11101&group_id=797 From noreply at rubyforge.org Thu May 24 18:05:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 18:05:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10750 ] spec_translator doesn't handle non_parenthesized arguments to expectations. Message-ID: <20070524220538.51ADA5240ACE@rubyforge.org> Bugs item #10750, was opened at 2007-05-10 15:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10750&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Ed Howland (edhowland) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: spec_translator doesn't handle non_parenthesized arguments to expectations. Initial Comment: An example is .should include 'arg = ?' This get translated to .should include('arg = )?' Here is some before and after specs: context "OldSchool" do class OldSchool attr_accessor collection def initialize @collection = [] end def add_new(item) @collection << item end end specify "should include string with '?'" do school = OldSchool.new school.add_item 'like ?' school.collection.should_include 'like ?' end end The specify clause gets translated to: it "should include string with '?'" do school = OldSchool.new school.add_item 'like ?' school.collection.should include('like)?' end Which ruby won't parse. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-24 18:05 Message: At this point we'll only accept patches for spec_translator. Bugs without fixes will not be fixed by us. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10750&group_id=797 From noreply at rubyforge.org Thu May 24 19:02:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 19:02:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11104 ] Website uses old "specify" notation Message-ID: <20070524230246.6D26C5240A61@rubyforge.org> Bugs item #11104, was opened at 2007-05-24 16:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11104&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Dees (undees) Assigned to: Nobody (None) Summary: Website uses old "specify" notation Initial Comment: On http://rspec.rubyforge.org/documentation/index.html, the example under the "Helper Methods" heading contains the following snippet: specify "..." do helper_method end Is this intentional? Since the excerpt is inside a "describe" block, it might make more sense to have the example expressed as an "it" clause instead. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11104&group_id=797 From noreply at rubyforge.org Thu May 24 19:12:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 24 May 2007 19:12:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11104 ] Website uses old "specify" notation Message-ID: <20070524231209.2E047A970002@rubyforge.org> Bugs item #11104, was opened at 2007-05-24 23:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11104&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ian Dees (undees) >Assigned to: David Chelimsky (dchelimsky) >Summary: Website uses old "specify" notation Initial Comment: On http://rspec.rubyforge.org/documentation/index.html, the example under the "Helper Methods" heading contains the following snippet: specify "..." do helper_method end Is this intentional? Since the excerpt is inside a "describe" block, it might make more sense to have the example expressed as an "it" clause instead. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 23:12 Message: Just an oversight. Fixed in r2027. Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11104&group_id=797 From noreply at rubyforge.org Fri May 25 08:58:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 08:58:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11116 ] constant repo url for managing plugins Message-ID: <20070525125802.1803252409C1@rubyforge.org> Feature Requests item #11116, was opened at 2007-05-25 07:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: constant repo url for managing plugins Initial Comment: Would it be possible to get a CURRENT tag added to the repo? I would love to be able to manage rspec using piston, but I can't due to the changing tags. If you create something like svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec which points to the latest release, that would make my life easier. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 From noreply at rubyforge.org Fri May 25 09:24:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 09:24:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11116 ] constant repo url for managing plugins Message-ID: <20070525132457.281895240A3A@rubyforge.org> Feature Requests item #11116, was opened at 2007-05-25 12:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: constant repo url for managing plugins Initial Comment: Would it be possible to get a CURRENT tag added to the repo? I would love to be able to manage rspec using piston, but I can't due to the changing tags. If you create something like svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec which points to the latest release, that would make my life easier. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 13:24 Message: I like this idea and think we should do it. Anybody have any recommendations on process for this? It's not as simple as a symlink cuz it's in svn. Or is it? Suggestions please. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 From noreply at rubyforge.org Fri May 25 09:52:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 09:52:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11116 ] constant repo url for managing plugins Message-ID: <20070525135252.E7E2D5240A3A@rubyforge.org> Feature Requests item #11116, was opened at 2007-05-25 08:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: constant repo url for managing plugins Initial Comment: Would it be possible to get a CURRENT tag added to the repo? I would love to be able to manage rspec using piston, but I can't due to the changing tags. If you create something like svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec which points to the latest release, that would make my life easier. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-25 09:52 Message: Here is how: svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/trunk svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn rm svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 09:24 Message: I like this idea and think we should do it. Anybody have any recommendations on process for this? It's not as simple as a symlink cuz it's in svn. Or is it? Suggestions please. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 From noreply at rubyforge.org Fri May 25 10:34:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 10:34:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11116 ] constant repo url for managing plugins Message-ID: <20070525143430.921A65240A72@rubyforge.org> Feature Requests item #11116, was opened at 2007-05-25 12:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: constant repo url for managing plugins Initial Comment: Would it be possible to get a CURRENT tag added to the repo? I would love to be able to manage rspec using piston, but I can't due to the changing tags. If you create something like svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec which points to the latest release, that would make my life easier. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 14:34 Message: I figured it would be that simple. I just added CURRENT, so you can install the rails plugin using: ruby script/plugin install svn://rubyforge.org/var/svn/rspec/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/CURRENT/rspec_on_rails We'll be doing a release 1.0.3 soon and I'll make sure this is part of the build. Cheers, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-25 13:52 Message: Here is how: svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/trunk svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn rm svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 13:24 Message: I like this idea and think we should do it. Anybody have any recommendations on process for this? It's not as simple as a symlink cuz it's in svn. Or is it? Suggestions please. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 From noreply at rubyforge.org Fri May 25 10:44:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 10:44:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11116 ] constant repo url for managing plugins Message-ID: <20070525144426.24E475240A3C@rubyforge.org> Feature Requests item #11116, was opened at 2007-05-25 12:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: constant repo url for managing plugins Initial Comment: Would it be possible to get a CURRENT tag added to the repo? I would love to be able to manage rspec using piston, but I can't due to the changing tags. If you create something like svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec which points to the latest release, that would make my life easier. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 14:44 Message: Actually, I moved it to tags/CURRENT, per Aslak's recommendation. ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 14:34 Message: I figured it would be that simple. I just added CURRENT, so you can install the rails plugin using: ruby script/plugin install svn://rubyforge.org/var/svn/rspec/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/CURRENT/rspec_on_rails We'll be doing a release 1.0.3 soon and I'll make sure this is part of the build. Cheers, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-25 13:52 Message: Here is how: svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/trunk svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn rm svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 13:24 Message: I like this idea and think we should do it. Anybody have any recommendations on process for this? It's not as simple as a symlink cuz it's in svn. Or is it? Suggestions please. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 From noreply at rubyforge.org Fri May 25 10:53:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 10:53:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-11116 ] constant repo url for managing plugins Message-ID: <20070525145339.BCC715240B0A@rubyforge.org> Feature Requests item #11116, was opened at 2007-05-25 08:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: constant repo url for managing plugins Initial Comment: Would it be possible to get a CURRENT tag added to the repo? I would love to be able to manage rspec using piston, but I can't due to the changing tags. If you create something like svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec which points to the latest release, that would make my life easier. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-25 10:53 Message: David, when you do - could you add this URL to the docs too? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 10:44 Message: Actually, I moved it to tags/CURRENT, per Aslak's recommendation. ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 10:34 Message: I figured it would be that simple. I just added CURRENT, so you can install the rails plugin using: ruby script/plugin install svn://rubyforge.org/var/svn/rspec/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/CURRENT/rspec_on_rails We'll be doing a release 1.0.3 soon and I'll make sure this is part of the build. Cheers, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-25 09:52 Message: Here is how: svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/trunk svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn rm svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT svn cp svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/REL_X_Y_Z svn+ssh://developername at rubyforge.org/var/svn/rspec/tags/CURRENT ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-25 09:24 Message: I like this idea and think we should do it. Anybody have any recommendations on process for this? It's not as simple as a symlink cuz it's in svn. Or is it? Suggestions please. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11116&group_id=797 From dchelimsky at gmail.com Fri May 25 11:03:54 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 25 May 2007 10:03:54 -0500 Subject: [rspec-devel] Question re: providing specs with patches In-Reply-To: <4654E509.4070208@gmail.com> References: <20070524000423.DAD775240A4E@rubyforge.org> <4654E509.4070208@gmail.com> Message-ID: <57c63afe0705250803h14ebb711tc9b01f03c1d0cc54@mail.gmail.com> On 5/23/07, Ben Scofield wrote: > Hi all, > > I just patched the rspec_controller generator in rspec_on_rails (it's > failing against Edge Rails - it's using the old-style view naming > (.rhtml instead of .html.erb)). I wanted to submit the patch, but I > couldn't find any specs for the generators... am I missing something > obvious? Hi Ben - you're not missing anything obvious. The rspec_scaffold generator gets tested in our pre_commit cycle, but the others (controllers and models) are not. Go ahead and submit your patch and we'll see about adding some automated testing for them. BDD'ish, not really. Pragmatic, indeed. Cheers, David > > Thanks! > Ben Scofield > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Fri May 25 14:27:01 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 14:27:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11079 ] Double Render Errors not raised in Controller Specs Message-ID: <20070525182702.34BDE5240C20@rubyforge.org> Bugs item #11079, was opened at 2007-05-23 17:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11079&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Double Render Errors not raised in Controller Specs Initial Comment: This is without integrated views. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2007-05-25 11:27 Message: Yes, we overrode the rescue_action and broke it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-23 17:04 Message: are you overriding rescue_action? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11079&group_id=797 From dchelimsky at gmail.com Fri May 25 16:49:13 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 25 May 2007 15:49:13 -0500 Subject: [rspec-devel] [ANN] RSpec-1.0.3 Message-ID: <57c63afe0705251349l6f83b574sa5cc43fd0abba4f6@mail.gmail.com> The RSpec Development Team is pleased to announce the release of RSpec-1.0.3. == Changes This is the compatibility release! * Compatible with autotest!!!! (As of ZenTest 3.6.0 - see below) * Compatible with edge rails (as of r6825). * Compatible with jruby (since release 1.0.1) See http://rspec.rubyforge.org/changes.html for more detail. == About RSpec RSpec is a framework which provides programmers with a Domain Specific Language to describe the behaviour of Ruby code with readable, executable examples that guide you in the design process and serve well as both documentation and tests. == Autotest compatibility ZenTest-3.6.0 boasts a new autodiscovery and plugin model that other frameworks can register with and plug into. RSpec-1.0.3 ships with the necessary plugin code, so all you need to do is download and go: For Rails apps: gem install ZenTest --version '>= 3.6.0' rails myproject cd myproject ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails script/generate rspec autotest ... and off you go For a non-rails app, you'll need to follow the convention of parallel lib and spec directories. For example: gem install ZenTest --version '>= 3.6.0' gem install rspec --version '>= 1.0.3' mkdir stuff cd stuff mkdir lib mkdir spec autotest Enjoy! From noreply at rubyforge.org Fri May 25 18:31:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 25 May 2007 18:31:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11137 ] rspec incorrectly handles flash after resetting the session Message-ID: <20070525223128.9B22A5240BB1@rubyforge.org> Bugs item #11137, was opened at 2007-05-25 16:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11137&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: devin c (quixoten) Assigned to: Nobody (None) Summary: rspec incorrectly handles flash after resetting the session Initial Comment: given an action: def clobber_session reset_session flash[:notice] = 'where's my flash?' end flash[:notice] should equal 'where's my flash?', and indeed it does when tested in rails, but when tested in the spec flash is empty def clobber_session flash[:notice] = 'available to rails and should be available to the spec' reset_session end however in this case, the flash should be empty because it was set before the session was cleared. again, when tested in rails the flash is cleared as expected, but for some reason it is still available in the specs. I've attached some failing tests that demonstrate this behavior. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11137&group_id=797 From noreply at rubyforge.org Sat May 26 03:53:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 03:53:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11143 ] Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Message-ID: <20070526075352.B00AC5240C20@rubyforge.org> Bugs item #11143, was opened at 2007-05-26 00:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Coda Hale (codahale) Assigned to: Nobody (None) Summary: Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Initial Comment: I just updated to Rails r6731 and RSpec 1.0.3, and all my controller specs exploded: 1) ActionView::ActionViewError in 'FavoritesController handling GET /user/1/favorites should be successful' Couldn't find template file for favorites/index in ["/Users/coda/Project/app/views"] /Users/coda/Project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/coda/Project/app/controllers/favorites_controller.rb:10:in `index' spec/controllers/favorites_controller_spec.rb:41:in `do_get' spec/controllers/favorites_controller_spec.rb:45: spec/controllers/favorites_controller_spec.rb:31: The view is in app/views/favorites/index.html.erb, and the call to render it is just the default: respond_to do |format| format.html # index.html.erb end The code works fine in development -- renders the right view and everything. This code used to pass with an older revision of Edge and RSpec 1.0.0, and I noticed that Spec::Rails::DSL::ControllerInstanceMethods#render has changed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 From noreply at rubyforge.org Sat May 26 06:06:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 06:06:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11143 ] Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Message-ID: <20070526100623.4BEAE5240977@rubyforge.org> Bugs item #11143, was opened at 2007-05-26 03:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Coda Hale (codahale) Assigned to: Nobody (None) Summary: Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Initial Comment: I just updated to Rails r6731 and RSpec 1.0.3, and all my controller specs exploded: 1) ActionView::ActionViewError in 'FavoritesController handling GET /user/1/favorites should be successful' Couldn't find template file for favorites/index in ["/Users/coda/Project/app/views"] /Users/coda/Project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/coda/Project/app/controllers/favorites_controller.rb:10:in `index' spec/controllers/favorites_controller_spec.rb:41:in `do_get' spec/controllers/favorites_controller_spec.rb:45: spec/controllers/favorites_controller_spec.rb:31: The view is in app/views/favorites/index.html.erb, and the call to render it is just the default: respond_to do |format| format.html # index.html.erb end The code works fine in development -- renders the right view and everything. This code used to pass with an older revision of Edge and RSpec 1.0.0, and I noticed that Spec::Rails::DSL::ControllerInstanceMethods#render has changed. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-26 06:06 Message: David, this is what I mentioned the other day. I haven't found a solution yet. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 From noreply at rubyforge.org Sat May 26 10:49:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 10:49:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11143 ] Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Message-ID: <20070526144943.C3CD752409F8@rubyforge.org> Bugs item #11143, was opened at 2007-05-26 07:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Coda Hale (codahale) Assigned to: Nobody (None) Summary: Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Initial Comment: I just updated to Rails r6731 and RSpec 1.0.3, and all my controller specs exploded: 1) ActionView::ActionViewError in 'FavoritesController handling GET /user/1/favorites should be successful' Couldn't find template file for favorites/index in ["/Users/coda/Project/app/views"] /Users/coda/Project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/coda/Project/app/controllers/favorites_controller.rb:10:in `index' spec/controllers/favorites_controller_spec.rb:41:in `do_get' spec/controllers/favorites_controller_spec.rb:45: spec/controllers/favorites_controller_spec.rb:31: The view is in app/views/favorites/index.html.erb, and the call to render it is just the default: respond_to do |format| format.html # index.html.erb end The code works fine in development -- renders the right view and everything. This code used to pass with an older revision of Edge and RSpec 1.0.0, and I noticed that Spec::Rails::DSL::ControllerInstanceMethods#render has changed. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 14:49 Message: Coda, can you post the spec please? I'm not able to reproduce this error. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-26 10:06 Message: David, this is what I mentioned the other day. I haven't found a solution yet. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 From noreply at rubyforge.org Sat May 26 11:01:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 11:01:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11143 ] Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Message-ID: <20070526150100.8FE055240A47@rubyforge.org> Bugs item #11143, was opened at 2007-05-26 07:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Coda Hale (codahale) Assigned to: Nobody (None) Summary: Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Initial Comment: I just updated to Rails r6731 and RSpec 1.0.3, and all my controller specs exploded: 1) ActionView::ActionViewError in 'FavoritesController handling GET /user/1/favorites should be successful' Couldn't find template file for favorites/index in ["/Users/coda/Project/app/views"] /Users/coda/Project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/coda/Project/app/controllers/favorites_controller.rb:10:in `index' spec/controllers/favorites_controller_spec.rb:41:in `do_get' spec/controllers/favorites_controller_spec.rb:45: spec/controllers/favorites_controller_spec.rb:31: The view is in app/views/favorites/index.html.erb, and the call to render it is just the default: respond_to do |format| format.html # index.html.erb end The code works fine in development -- renders the right view and everything. This code used to pass with an older revision of Edge and RSpec 1.0.0, and I noticed that Spec::Rails::DSL::ControllerInstanceMethods#render has changed. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 15:01 Message: Making some progress. I was able to duplicate this by defining rescue_action. It turns out that this is due to a change in rails, not the changes in RSpec. Spec::Rails::DSL::ControllerInstanceMethods#render is never being called in the example I've got failing!!!! Still looking. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 14:49 Message: Coda, can you post the spec please? I'm not able to reproduce this error. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-26 10:06 Message: David, this is what I mentioned the other day. I haven't found a solution yet. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 From noreply at rubyforge.org Sat May 26 11:01:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 11:01:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11143 ] Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Message-ID: <20070526150117.604125240A56@rubyforge.org> Bugs item #11143, was opened at 2007-05-26 07:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Coda Hale (codahale) >Assigned to: David Chelimsky (dchelimsky) Summary: Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Initial Comment: I just updated to Rails r6731 and RSpec 1.0.3, and all my controller specs exploded: 1) ActionView::ActionViewError in 'FavoritesController handling GET /user/1/favorites should be successful' Couldn't find template file for favorites/index in ["/Users/coda/Project/app/views"] /Users/coda/Project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/coda/Project/app/controllers/favorites_controller.rb:10:in `index' spec/controllers/favorites_controller_spec.rb:41:in `do_get' spec/controllers/favorites_controller_spec.rb:45: spec/controllers/favorites_controller_spec.rb:31: The view is in app/views/favorites/index.html.erb, and the call to render it is just the default: respond_to do |format| format.html # index.html.erb end The code works fine in development -- renders the right view and everything. This code used to pass with an older revision of Edge and RSpec 1.0.0, and I noticed that Spec::Rails::DSL::ControllerInstanceMethods#render has changed. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 15:01 Message: Making some progress. I was able to duplicate this by defining rescue_action. It turns out that this is due to a change in rails, not the changes in RSpec. Spec::Rails::DSL::ControllerInstanceMethods#render is never being called in the example I've got failing!!!! Still looking. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 14:49 Message: Coda, can you post the spec please? I'm not able to reproduce this error. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-26 10:06 Message: David, this is what I mentioned the other day. I haven't found a solution yet. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 From noreply at rubyforge.org Sat May 26 11:21:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 11:21:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11143 ] Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Message-ID: <20070526152107.54FE65240A47@rubyforge.org> Bugs item #11143, was opened at 2007-05-26 07:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Coda Hale (codahale) Assigned to: David Chelimsky (dchelimsky) Summary: Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Initial Comment: I just updated to Rails r6731 and RSpec 1.0.3, and all my controller specs exploded: 1) ActionView::ActionViewError in 'FavoritesController handling GET /user/1/favorites should be successful' Couldn't find template file for favorites/index in ["/Users/coda/Project/app/views"] /Users/coda/Project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/coda/Project/app/controllers/favorites_controller.rb:10:in `index' spec/controllers/favorites_controller_spec.rb:41:in `do_get' spec/controllers/favorites_controller_spec.rb:45: spec/controllers/favorites_controller_spec.rb:31: The view is in app/views/favorites/index.html.erb, and the call to render it is just the default: respond_to do |format| format.html # index.html.erb end The code works fine in development -- renders the right view and everything. This code used to pass with an older revision of Edge and RSpec 1.0.0, and I noticed that Spec::Rails::DSL::ControllerInstanceMethods#render has changed. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 15:21 Message: No - that was wrong. Working on it though. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 15:01 Message: Making some progress. I was able to duplicate this by defining rescue_action. It turns out that this is due to a change in rails, not the changes in RSpec. Spec::Rails::DSL::ControllerInstanceMethods#render is never being called in the example I've got failing!!!! Still looking. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 14:49 Message: Coda, can you post the spec please? I'm not able to reproduce this error. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-26 10:06 Message: David, this is what I mentioned the other day. I haven't found a solution yet. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 From noreply at rubyforge.org Sat May 26 14:23:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 14:23:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11143 ] Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Message-ID: <20070526182351.80CFD5240A47@rubyforge.org> Bugs item #11143, was opened at 2007-05-26 07:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Coda Hale (codahale) Assigned to: David Chelimsky (dchelimsky) Summary: Views code for ActionController::Base#render broke between 1.0.0 and 1.0.3 on Rails Edge r6731 Initial Comment: I just updated to Rails r6731 and RSpec 1.0.3, and all my controller specs exploded: 1) ActionView::ActionViewError in 'FavoritesController handling GET /user/1/favorites should be successful' Couldn't find template file for favorites/index in ["/Users/coda/Project/app/views"] /Users/coda/Project/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render' /Users/coda/Project/app/controllers/favorites_controller.rb:10:in `index' spec/controllers/favorites_controller_spec.rb:41:in `do_get' spec/controllers/favorites_controller_spec.rb:45: spec/controllers/favorites_controller_spec.rb:31: The view is in app/views/favorites/index.html.erb, and the call to render it is just the default: respond_to do |format| format.html # index.html.erb end The code works fine in development -- renders the right view and everything. This code used to pass with an older revision of Edge and RSpec 1.0.0, and I noticed that Spec::Rails::DSL::ControllerInstanceMethods#render has changed. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 18:23 Message: Fixed in r2041. The problem was two-fold. We recently removed the implicit re-raising (using rescue_action) of errors in controller examples to fix another bug. This had the unfortunate side effect of hiding errors. Additionally, there was a change in rails that caused rspec to fall down in controller examples with isolated views. The rescue_action issue is now resolved by adding a method available in controller examples named "raise_controller_errors". This gets called from the generated spec_helper: config.before(:each, :behaviour_type => :controller) do raise_controller_errors end The render problem is resolved by overriding render_file instead of render_template in Spec::Rails::DSL::ControllerInstanceMethods#render. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 15:21 Message: No - that was wrong. Working on it though. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 15:01 Message: Making some progress. I was able to duplicate this by defining rescue_action. It turns out that this is due to a change in rails, not the changes in RSpec. Spec::Rails::DSL::ControllerInstanceMethods#render is never being called in the example I've got failing!!!! Still looking. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 14:49 Message: Coda, can you post the spec please? I'm not able to reproduce this error. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-26 10:06 Message: David, this is what I mentioned the other day. I haven't found a solution yet. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11143&group_id=797 From noreply at rubyforge.org Sat May 26 14:30:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 14:30:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11147 ] Autotest continually runs specs that are failing when no file has been modified. Message-ID: <20070526183035.D511D5240A56@rubyforge.org> Bugs item #11147, was opened at 2007-05-26 12:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 Category: rails plugin Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: Martin Emde (zraii) Assigned to: Nobody (None) Summary: Autotest continually runs specs that are failing when no file has been modified. Initial Comment: I posted this in the ZenTest bugs list and was redirected here. More details at this link: http://rubyforge.org/tracker/index.php?func=detail&aid=11142&group_id=419&atid=1678 Using RSpec 1.0.3 and ZenTest 3.6.0. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 From noreply at rubyforge.org Sat May 26 14:42:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 14:42:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11147 ] Autotest continually runs specs that are failing when no file has been modified. Message-ID: <20070526184245.2FBDD5240A47@rubyforge.org> Bugs item #11147, was opened at 2007-05-26 18:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 Category: rails plugin Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: Martin Emde (zraii) >Assigned to: David Chelimsky (dchelimsky) Summary: Autotest continually runs specs that are failing when no file has been modified. Initial Comment: I posted this in the ZenTest bugs list and was redirected here. More details at this link: http://rubyforge.org/tracker/index.php?func=detail&aid=11142&group_id=419&atid=1678 Using RSpec 1.0.3 and ZenTest 3.6.0. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 18:42 Message: Whenever you upgrade you need to run the following: script/generate rspec This replaces spec/spec.opts with a new version that excludes the following lines: --format failing_examples:previous_failures.txt --example previous_failures.txt If you get rid of those now, you should be OK. I'll also add previous_failures.txt to the list of files that are ignored by autotest. Leaving this open until that's committed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 From noreply at rubyforge.org Sat May 26 15:08:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 15:08:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11147 ] Autotest continually runs specs that are failing when no file has been modified. Message-ID: <20070526190828.7A6825240977@rubyforge.org> Bugs item #11147, was opened at 2007-05-26 18:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 Category: rails plugin Group: v1.0 (example) >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Martin Emde (zraii) Assigned to: David Chelimsky (dchelimsky) Summary: Autotest continually runs specs that are failing when no file has been modified. Initial Comment: I posted this in the ZenTest bugs list and was redirected here. More details at this link: http://rubyforge.org/tracker/index.php?func=detail&aid=11142&group_id=419&atid=1678 Using RSpec 1.0.3 and ZenTest 3.6.0. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 19:08 Message: Actually, ZenTest doesn't currently support ignoring individual files. I've submitted a report to ZenTest (http://rubyforge.org/tracker/index.php?group_id=419&atid=1681), but in the mean time you'll have to just make sure that these lines: --format failing_examples:previous_failures.txt --example previous_failures.txt are not in spec/spec.opts. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 18:42 Message: Whenever you upgrade you need to run the following: script/generate rspec This replaces spec/spec.opts with a new version that excludes the following lines: --format failing_examples:previous_failures.txt --example previous_failures.txt If you get rid of those now, you should be OK. I'll also add previous_failures.txt to the list of files that are ignored by autotest. Leaving this open until that's committed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 From noreply at rubyforge.org Sat May 26 15:37:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 15:37:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11137 ] rspec incorrectly handles flash after resetting the session Message-ID: <20070526193702.DCA0D5240A67@rubyforge.org> Bugs item #11137, was opened at 2007-05-25 22:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11137&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: devin c (quixoten) >Assigned to: David Chelimsky (dchelimsky) Summary: rspec incorrectly handles flash after resetting the session Initial Comment: given an action: def clobber_session reset_session flash[:notice] = 'where's my flash?' end flash[:notice] should equal 'where's my flash?', and indeed it does when tested in rails, but when tested in the spec flash is empty def clobber_session flash[:notice] = 'available to rails and should be available to the spec' reset_session end however in this case, the flash should be empty because it was set before the session was cleared. again, when tested in rails the flash is cleared as expected, but for some reason it is still available in the specs. I've attached some failing tests that demonstrate this behavior. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11137&group_id=797 From noreply at rubyforge.org Sat May 26 16:21:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 16:21:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11137 ] rspec incorrectly handles flash after resetting the session Message-ID: <20070526202141.DF6C95240AA4@rubyforge.org> Bugs item #11137, was opened at 2007-05-25 22:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11137&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: devin c (quixoten) Assigned to: David Chelimsky (dchelimsky) Summary: rspec incorrectly handles flash after resetting the session Initial Comment: given an action: def clobber_session reset_session flash[:notice] = 'where's my flash?' end flash[:notice] should equal 'where's my flash?', and indeed it does when tested in rails, but when tested in the spec flash is empty def clobber_session flash[:notice] = 'available to rails and should be available to the spec' reset_session end however in this case, the flash should be empty because it was set before the session was cleared. again, when tested in rails the flash is cleared as expected, but for some reason it is still available in the specs. I've attached some failing tests that demonstrate this behavior. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 20:21 Message: Fixed in r2044. Thanks for the examples. Very helpful. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11137&group_id=797 From noreply at rubyforge.org Sat May 26 19:44:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 19:44:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11147 ] Autotest continually runs specs that are failing when no file has been modified. Message-ID: <20070526234448.655025240A60@rubyforge.org> Bugs item #11147, was opened at 2007-05-26 12:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 Category: rails plugin Group: v1.0 (example) Status: Closed Resolution: Rejected Priority: 3 Submitted By: Martin Emde (zraii) Assigned to: David Chelimsky (dchelimsky) Summary: Autotest continually runs specs that are failing when no file has been modified. Initial Comment: I posted this in the ZenTest bugs list and was redirected here. More details at this link: http://rubyforge.org/tracker/index.php?func=detail&aid=11142&group_id=419&atid=1678 Using RSpec 1.0.3 and ZenTest 3.6.0. ---------------------------------------------------------------------- >Comment By: Martin Emde (zraii) Date: 2007-05-26 17:44 Message: Thank you guys, I appreciate all your work on this gem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 13:08 Message: Actually, ZenTest doesn't currently support ignoring individual files. I've submitted a report to ZenTest (http://rubyforge.org/tracker/index.php?group_id=419&atid=1681), but in the mean time you'll have to just make sure that these lines: --format failing_examples:previous_failures.txt --example previous_failures.txt are not in spec/spec.opts. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-26 12:42 Message: Whenever you upgrade you need to run the following: script/generate rspec This replaces spec/spec.opts with a new version that excludes the following lines: --format failing_examples:previous_failures.txt --example previous_failures.txt If you get rid of those now, you should be OK. I'll also add previous_failures.txt to the list of files that are ignored by autotest. Leaving this open until that's committed. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11147&group_id=797 From noreply at rubyforge.org Sat May 26 23:26:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 23:26:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10731 ] response.should be_a_success Message-ID: <20070527032649.7D412524096C@rubyforge.org> Patches item #10731, was opened at 2007-05-09 23:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: response.should be_a_success Initial Comment: The current rails controller/resource generators output code like the following: response.should be_success I think it reads much better like this: response.should be_a_success This is a tiny little patch that changes those instances in the generators ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 03:26 Message: I agree w/ Aslak on this. Both be_x and be_a_x are supported by rspec. This is just about generated code. You're free to change it after its generated. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 20:03 Message: I think it only looks more cluttered if the it blocks read "it should be successful". If the it blocks read "it should be a success", then I think it gives a uniformity to the spec. WDYT? Reject it if you still think the same. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:34 Message: I think be_a_success looks more cluttered than be_success ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10731&group_id=797 From noreply at rubyforge.org Sat May 26 23:41:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 26 May 2007 23:41:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070527034107.497AB5240B3F@rubyforge.org> Patches item #10574, was opened at 2007-05-04 15:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 03:41 Message: Antti - can you resubmit this as a diff? I want to be able to see what you're actually changing. ---------------------------------------------------------------------- Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-10 15:24 Message: The purpose is to add specs to it so that we know that we don't break it when we change it. In the original form, it was too complicated to spec in a reasonable manner. For an example of the type of problems that can go unnoticed without specs, see patch 10315. http://rubyforge.org/tracker/index.php?func=detail&aid=10315&group_id=797&atid=3151 In my opinion, although it is "just" the build code it should not be left unspecced. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:35 Message: What's the purpose of this refactoring? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 15:37 Message: Just a quick heads up before I look at this. I just removed the call to config.breakpoint_server, so that shouldn't be an issue any more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From noreply at rubyforge.org Sun May 27 00:55:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 27 May 2007 00:55:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10645 ] removal of --examples when appropriate Message-ID: <20070527045545.E6AE35240BA6@rubyforge.org> Patches item #10645, was opened at 2007-05-07 05:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: removal of --examples when appropriate Initial Comment: See ticket: #10545 "Removal of --options when appropriate" http://rubyforge.org/tracker/index.php?func=detail&aid=10545&group_id=797&atid=3151 David/Aslak: I added a an attribute reader for @where in the base text formatter, and called the method output. Feel free to change this as you wish. It is only referenced in the Options class, under the method I've added: remove_extraneous_examples! ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-27 04:55 Message: Feel free to close this one. The last patch doesn't do what I thought it did (Obviously I should have included specs). I don't know a good way to get around the problem except by implementing some logic similar to what I have done in the first patch. It can be cleaned up a bit, but otherwise I don't see a way to do it simply & cleanly. Let me know if you have any other ideas. Otherwise, reject it. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-11 22:31 Message: Well, now that I look at it, it appears as though it isn't that simple, because if you want the example switch to touch the file, it *needs to know* that it is a file, and not a simple example (this is why there was the complicated logic in my patch). On the other hand, the --formatter switch does touch the file. So the bug looks like it only occurs when you specify --examples before --formatter, because ::OptionParser parses options sequentially, as they are given on the command line. I've opted for a low-tech solution (in this version of the patch), so that --help will specify that --examples should come after the corresponding formatter. Another low-tech solution exists, of course, and that would be to have an --example switch which only processes named examples, and an --example-file switch which would process a formatted file. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-10 20:01 Message: I agree, Aslak. Although I don't think touch would be the appropriate thing to use here, because it modifies the mtimes, and that would be a problem for autotest. I'll rework the code. btw: thanks for applying the other patch ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:41 Message: I'm not so keen on applying this. It seems like a complicated solution to a simple problem. An easier solution is this: $ touch previous_failures.txt ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10645&group_id=797 From noreply at rubyforge.org Sun May 27 06:46:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 27 May 2007 06:46:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070527104623.041835240844@rubyforge.org> Patches item #10574, was opened at 2007-05-04 18:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- >Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-27 13:46 Message: Here's an updated version of the patch. Changes: - It's a real diff (the old patch was also a diff, but in a parallel directory structure, so you couldn't see what was removed). - Doesn't support Rails 1.1.6 anymore. - Uses rspec_scaffold instead of rspec_resource. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 06:41 Message: Antti - can you resubmit this as a diff? I want to be able to see what you're actually changing. ---------------------------------------------------------------------- Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-10 18:24 Message: The purpose is to add specs to it so that we know that we don't break it when we change it. In the original form, it was too complicated to spec in a reasonable manner. For an example of the type of problems that can go unnoticed without specs, see patch 10315. http://rubyforge.org/tracker/index.php?func=detail&aid=10315&group_id=797&atid=3151 In my opinion, although it is "just" the build code it should not be left unspecced. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 16:35 Message: What's the purpose of this refactoring? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 18:37 Message: Just a quick heads up before I look at this. I just removed the call to config.breakpoint_server, so that shouldn't be an issue any more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From dchelimsky at gmail.com Sun May 27 06:48:13 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 27 May 2007 05:48:13 -0500 Subject: [rspec-devel] deprecations Message-ID: <57c63afe0705270348u68e92371mbd5bd3e7a5f0f763@mail.gmail.com> Hey all - I just deprecated the symbol mock argument constraints (which have always felt a little dirty to me) and added methods to replace them. So instead of these: mock.should_receive(:message).with(:anything) mock.should_receive(:message).with(:boolean) mock.should_receive(:message).with(:numeric) mock.should_receive(:message).with(:string) you can do this: mock.should_receive(:message).with(anything()) mock.should_receive(:message).with(boolean()) mock.should_receive(:message).with(an_instance_of(Numeric)) mock.should_receive(:message).with(an_instance_of(String)) For the moment, I've got deprecation warnings going to STDERR, so you'll see them when you run rspec's own examples. I'm going to try to get something a little nicer in place soon. Any recommendations? I have a couple of ideas, but I want to hear yours. Cheers, David From noreply at rubyforge.org Sun May 27 06:53:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 27 May 2007 06:53:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070527105304.365715240844@rubyforge.org> Patches item #10574, was opened at 2007-05-04 15:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 10:53 Message: Much better. Thanks. Kinda swamped right now but one of us will look at this soon. Cheers, David ---------------------------------------------------------------------- Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-27 10:46 Message: Here's an updated version of the patch. Changes: - It's a real diff (the old patch was also a diff, but in a parallel directory structure, so you couldn't see what was removed). - Doesn't support Rails 1.1.6 anymore. - Uses rspec_scaffold instead of rspec_resource. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 03:41 Message: Antti - can you resubmit this as a diff? I want to be able to see what you're actually changing. ---------------------------------------------------------------------- Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-10 15:24 Message: The purpose is to add specs to it so that we know that we don't break it when we change it. In the original form, it was too complicated to spec in a reasonable manner. For an example of the type of problems that can go unnoticed without specs, see patch 10315. http://rubyforge.org/tracker/index.php?func=detail&aid=10315&group_id=797&atid=3151 In my opinion, although it is "just" the build code it should not be left unspecced. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 13:35 Message: What's the purpose of this refactoring? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 15:37 Message: Just a quick heads up before I look at this. I just removed the call to config.breakpoint_server, so that shouldn't be an issue any more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From noreply at rubyforge.org Sun May 27 07:11:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 27 May 2007 07:11:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11161 ] ActionView render_template should return string, not boolean Message-ID: <20070527111110.C64B75240844@rubyforge.org> Bugs item #11161, was opened at 2007-05-27 14:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11161&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Denis Grankin (liquidautumn) Assigned to: Nobody (None) Summary: ActionView render_template should return string, not boolean Initial Comment: lib/spec/rails/dsl/behaviour/controller.rb:61 overrides render_template method, it returns true and causing error at action_controller/response.rb:73 in set_content_length!. This method expecting body to be String, while override provided TrueClass instead. lib/spec/rails/dsl/behaviour/controller.rb:63 -true +'' fixed things ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11161&group_id=797 From noreply at rubyforge.org Sun May 27 11:28:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 27 May 2007 11:28:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11161 ] ActionView render_template should return string, not boolean Message-ID: <20070527152844.4157552409A3@rubyforge.org> Bugs item #11161, was opened at 2007-05-27 11:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11161&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Denis Grankin (liquidautumn) >Assigned to: David Chelimsky (dchelimsky) Summary: ActionView render_template should return string, not boolean Initial Comment: lib/spec/rails/dsl/behaviour/controller.rb:61 overrides render_template method, it returns true and causing error at action_controller/response.rb:73 in set_content_length!. This method expecting body to be String, while override provided TrueClass instead. lib/spec/rails/dsl/behaviour/controller.rb:63 -true +'' fixed things ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11161&group_id=797 From noreply at rubyforge.org Sun May 27 11:32:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 27 May 2007 11:32:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11161 ] ActionView render_template should return string, not boolean Message-ID: <20070527153257.75B3552409A3@rubyforge.org> Bugs item #11161, was opened at 2007-05-27 11:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11161&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Denis Grankin (liquidautumn) Assigned to: David Chelimsky (dchelimsky) Summary: ActionView render_template should return string, not boolean Initial Comment: lib/spec/rails/dsl/behaviour/controller.rb:61 overrides render_template method, it returns true and causing error at action_controller/response.rb:73 in set_content_length!. This method expecting body to be String, while override provided TrueClass instead. lib/spec/rails/dsl/behaviour/controller.rb:63 -true +'' fixed things ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 15:32 Message: We're not overriding render_template anymore. Now it just overrides render_file, and it does return a string. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11161&group_id=797 From dchelimsky at gmail.com Sun May 27 18:44:48 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 27 May 2007 17:44:48 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> Message-ID: <57c63afe0705271544l4ab64174i92e870cdcd471ddb@mail.gmail.com> All - I need to reiterate Aslak's initial plea. I am guilty of not heeding it myself and just decided to check back to make sure jruby was still happy and it wasn't. After a not very short time, I found the offending commit which changed the html formatting but didn't also update the html_formatted-1.8.5-jruby.html file. I've now updated the file and made sure everything's cool w/ JRuby, but we have to treat this a bit more seriously until they release JRuby 1.0, which is soon!!!!!! What I would do is make checking against JRuby a manual step that you personally add to pre-commit, doing svn export against your local rspec directories, not from svn. That's what I plan to do. Cheers, David On 5/23/07, Nick Sieger wrote: > On 5/23/07, aslak hellesoy wrote: > > I hope you'll install a tagged release. 1.0.0 or 1.0.1, but not > > something inbetween. > > Yes, we'll probaby build/bootstrap JRuby and use rubygems to install a > released version into the distributable before archiving it. > > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Mon May 28 07:33:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 28 May 2007 07:33:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11181 ] behaviour_type scoping of config.before(:each) is not working Message-ID: <20070528113339.A6D7F5240AEB@rubyforge.org> Bugs item #11181, was opened at 2007-05-28 11:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11181&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: behaviour_type scoping of config.before(:each) is not working Initial Comment: trunk rev 2051 This causes controller errors to be raised: describe SomeController do raise_controller_errors ... end This does not (but should): #in spec_helper: config.before(:each, :behaviour_type => :controller) do raise_controller_errors end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11181&group_id=797 From noreply at rubyforge.org Mon May 28 07:35:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 28 May 2007 07:35:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11181 ] behaviour_type scoping of config.before(:each) is not working Message-ID: <20070528113554.818705240AEB@rubyforge.org> Bugs item #11181, was opened at 2007-05-28 11:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11181&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: behaviour_type scoping of config.before(:each) is not working Initial Comment: trunk rev 2051 This causes controller errors to be raised: describe SomeController do raise_controller_errors ... end This does not (but should): #in spec_helper: config.before(:each, :behaviour_type => :controller) do raise_controller_errors end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-28 11:35 Message: Fixed in r2052. model, view, controller and helper behaviours were not correctly reporting their behaviour_type ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11181&group_id=797 From noreply at rubyforge.org Tue May 29 15:54:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 29 May 2007 15:54:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10997 ] Can't run specs without rspec plugin Message-ID: <20070529195431.2679E5240C76@rubyforge.org> Bugs item #10997, was opened at 2007-05-21 15:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Bryan Helmkamp (brynary) Assigned to: Nobody (None) Summary: Can't run specs without rspec plugin Initial Comment: I'm unable to run the "rake spec" command when I do not have the rspec gem installed, even if I have rspec unpacked into vendor/plugins as described in the installation instructions. The results are: $ rake spec (in /Users/bhelmkamp/p/mcommons_trunk) rake aborted! no such file to load -- spec/rake/spectask /Users/bhelmkamp/p/mcommons_trunk/rakefile:10 (See full trace by running task with --trace) Running script/spec does work as intended, however this seems to defeat the purpose of extracting the plugin into the source tree. ---------------------------------------------------------------------- >Comment By: Bryan Helmkamp (brynary) Date: 2007-05-29 15:54 Message: This was an issue with one of our custom rake task files. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-24 06:50 Message: This is odd. I have basically the same setup as you and I can't duplicate this problem. I've tried it with and without the rspec gem installed and there seems to be no problem. Anybody else experiencing this? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 20:07 Message: Thanks Bryan - I'll be looking into this. Cheers, David ---------------------------------------------------------------------- Comment By: Bryan Helmkamp (brynary) Date: 2007-05-21 20:06 Message: Here we go: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.0.0 * Spec::Rails 1.0.0 * Rails 1.2.3 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-21 19:54 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10997&group_id=797 From noreply at rubyforge.org Wed May 30 01:47:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 01:47:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11221 ] Autotest support does not work w/o Rails Gem installed Message-ID: <20070530054740.3A6DD5240B8B@rubyforge.org> Patches item #11221, was opened at 2007-05-29 22:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: Nobody (None) Summary: Autotest support does not work w/o Rails Gem installed Initial Comment: Currently autotest support only works if you have the Rails gem installed due to a call to require 'active_support' in rails_spec.rb. This causes problems for those of us who "vendor everything" and don't have any gems installed as ActiveSupport is not loaded until environment.rb is called. Attached patch removes the call to require, which doesn't appear to even be used. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 From noreply at rubyforge.org Wed May 30 01:54:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 01:54:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11221 ] Autotest support does not work w/o Rails Gem installed Message-ID: <20070530055415.08A225240C9D@rubyforge.org> Patches item #11221, was opened at 2007-05-30 05:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Josh Knowles (joshknowles) >Assigned to: David Chelimsky (dchelimsky) Summary: Autotest support does not work w/o Rails Gem installed Initial Comment: Currently autotest support only works if you have the Rails gem installed due to a call to require 'active_support' in rails_spec.rb. This causes problems for those of us who "vendor everything" and don't have any gems installed as ActiveSupport is not loaded until environment.rb is called. Attached patch removes the call to require, which doesn't appear to even be used. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 05:54 Message: Applied to r2060. Gotta love the one-liner patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 From noreply at rubyforge.org Wed May 30 04:07:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 04:07:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11223 ] Unable to access flash from rails helper specs Message-ID: <20070530080757.5A7125240B90@rubyforge.org> Bugs item #11223, was opened at 2007-05-30 01:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11223&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: Nobody (None) Summary: Unable to access flash from rails helper specs Initial Comment: The changes made with changeset 2044 to fix issue 11137 appear to have broken the ability to access the flash from helper specs (unless I'm doing something completely wrong...). While I haven't had time to investigate the internals of the TestResponse logic I have attached a failing helper spec (spec/helpers) for the time being. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11223&group_id=797 From noreply at rubyforge.org Wed May 30 10:52:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 10:52:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11231 ] fixtures don't load with before(:all) Message-ID: <20070530145200.EDFDC52409AF@rubyforge.org> Bugs item #11231, was opened at 2007-05-30 09:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Stephens (viking415) Assigned to: Nobody (None) Summary: fixtures don't load with before(:all) Initial Comment: Fixtures only load when using before(:each). If I use before(:all), they don't get loaded at all. To reproduce this, run these commands in a shell: rails -d sqlite3 jungle cd jungle ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails script/generate rspec script/generate rspec_model monkey name:string rake db:migrate Then edit spec/models/monkey_spec.rb to include the following: ############# require File.dirname(__FILE__) + '/../spec_helper' describe "monkey with a before(:each)" do fixtures :monkeys before(:each) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end describe "monkey with a before(:all)" do fixtures :monkeys before(:all) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end ############# Run rake spec:models, and watch the first pass and the second fail. I'm running Kubuntu (Feisty) with Rails 1.2.3 and RSpec SVN r2060 (1.0.4). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 From noreply at rubyforge.org Wed May 30 12:45:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 12:45:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-8145 ] fixture use in context_setup bails Message-ID: <20070530164509.174765240A0F@rubyforge.org> Bugs item #8145, was opened at 2007-01-25 15:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Jodi Showers (jodishowers) Assigned to: David Chelimsky (dchelimsky) Summary: fixture use in context_setup bails Initial Comment: It appears that fixtures are not permissible within a context_setup. context "Given a Project fixture, " do fixtures :projects context_setup do @project = projects(:project_one) end .... end Results: 1) NoMethodError in 'Given a Project fixture, context_setup' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.[] ./spec/models/project_spec.rb:56: ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 16:45 Message: I'm going to close this because it's out of date (syntax has changed) and a duplicate has been raised using the new syntax. http://rubyforge.org/tracker/index.php?func=detail&aid=11231&group_id=797&atid=3149 I'll refer back to this discussion in that report. ---------------------------------------------------------------------- Comment By: Jodi Showers (jodishowers) Date: 2007-03-10 16:45 Message: yes. Given your explanation I agree that documentation would help. But first, I'd like to propose that if context_setup could reference fixtures, and a transaction wrapped the entire context, then a all specifies could share global 'context'. My experience (not a lot mind you) so far with rspec, tells me that a number of my specs would be less repetitive and easier to group under contexts if I could have some fixtures rollback (setup), and some persist across the entire context. init_context #internal requirements for a context Context.transaction do context_setup {} context "..." do setup {} specify do ... end end end + since contexts currently don't give access to fixtures, then this change wouldn't impact any current specs(?). But perhaps it would break the design goals? WDYT? thanx for your inclusiveness David. Jodi ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-03-10 15:13 Message: context_setup is a bit confusing because it looks like it lives inside the context, but in reality it is processed BEFORE the context is processed. Just as setup is processed before each specify block. So what's really happening is: context_setup {} context "..." do setup {} specify do ... end end So I think that the problem here is one of documentation/perception. WDYT? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797 From noreply at rubyforge.org Wed May 30 12:51:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 12:51:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11231 ] fixtures don't load with before(:all) Message-ID: <20070530165137.59FE15240A54@rubyforge.org> Bugs item #11231, was opened at 2007-05-30 14:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Stephens (viking415) Assigned to: Nobody (None) Summary: fixtures don't load with before(:all) Initial Comment: Fixtures only load when using before(:each). If I use before(:all), they don't get loaded at all. To reproduce this, run these commands in a shell: rails -d sqlite3 jungle cd jungle ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails script/generate rspec script/generate rspec_model monkey name:string rake db:migrate Then edit spec/models/monkey_spec.rb to include the following: ############# require File.dirname(__FILE__) + '/../spec_helper' describe "monkey with a before(:each)" do fixtures :monkeys before(:each) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end describe "monkey with a before(:all)" do fixtures :monkeys before(:all) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end ############# Run rake spec:models, and watch the first pass and the second fail. I'm running Kubuntu (Feisty) with Rails 1.2.3 and RSpec SVN r2060 (1.0.4). ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 16:51 Message: This was brought up a while back (using the old syntax): http://rubyforge.org/tracker/index.php?func=detail&aid=8145&group_id=797&atid=3149 The basic problem is that fixtures get rolled back between each example if you're using transactional fixtures (which seems to be the way to go). So if we support fixtures in before(:all) and you create @monkey, when the fixtures roll back the @monkey will remain the same - keeping its state through each example. This goes against conventional wisdom, which suggests that state should not be shared between examples. So my instinct is to implement fixtures in before(:all) such that it raises an error saying you can't do it and should use before(:each). But I'm open to other thoughts on the matter, so please feel free to make a case. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 From noreply at rubyforge.org Wed May 30 14:19:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 14:19:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11231 ] fixtures don't load with before(:all) Message-ID: <20070530181943.EF7655240B24@rubyforge.org> Bugs item #11231, was opened at 2007-05-30 09:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Stephens (viking415) Assigned to: Nobody (None) Summary: fixtures don't load with before(:all) Initial Comment: Fixtures only load when using before(:each). If I use before(:all), they don't get loaded at all. To reproduce this, run these commands in a shell: rails -d sqlite3 jungle cd jungle ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails script/generate rspec script/generate rspec_model monkey name:string rake db:migrate Then edit spec/models/monkey_spec.rb to include the following: ############# require File.dirname(__FILE__) + '/../spec_helper' describe "monkey with a before(:each)" do fixtures :monkeys before(:each) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end describe "monkey with a before(:all)" do fixtures :monkeys before(:all) do @monkey = Monkey.find_by_id(1) end it "should not be nil" do @monkey.should_not be_nil end end ############# Run rake spec:models, and watch the first pass and the second fail. I'm running Kubuntu (Feisty) with Rails 1.2.3 and RSpec SVN r2060 (1.0.4). ---------------------------------------------------------------------- >Comment By: Jeremy Stephens (viking415) Date: 2007-05-30 13:19 Message: My original reason for wanting to use fixtures in before(:all) was to test a userstamp plugin for Rails/ActiveRecord which automatically sets a 'created_by' or 'updated_by' field when a record is saved. In my tests, I wanted to login an existing user before each example, and it seemed wasteful to me at the time for that login to happen every time. It really isn't a big deal to use before(:each) instead; I guess it just struck me as odd that fixtures weren't available for before(:all). After reading your argument, though, I see your point. I think if you choose to outlaw using fixtures during a before(:all), an error message would definitely be helpful. Thanks! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 11:51 Message: This was brought up a while back (using the old syntax): http://rubyforge.org/tracker/index.php?func=detail&aid=8145&group_id=797&atid=3149 The basic problem is that fixtures get rolled back between each example if you're using transactional fixtures (which seems to be the way to go). So if we support fixtures in before(:all) and you create @monkey, when the fixtures roll back the @monkey will remain the same - keeping its state through each example. This goes against conventional wisdom, which suggests that state should not be shared between examples. So my instinct is to implement fixtures in before(:all) such that it raises an error saying you can't do it and should use before(:each). But I'm open to other thoughts on the matter, so please feel free to make a case. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11231&group_id=797 From noreply at rubyforge.org Wed May 30 14:28:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 14:28:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11221 ] Autotest support does not work w/o Rails Gem installed Message-ID: <20070530182858.CC7325240B20@rubyforge.org> Patches item #11221, was opened at 2007-05-30 07:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: David Chelimsky (dchelimsky) Summary: Autotest support does not work w/o Rails Gem installed Initial Comment: Currently autotest support only works if you have the Rails gem installed due to a call to require 'active_support' in rails_spec.rb. This causes problems for those of us who "vendor everything" and don't have any gems installed as ActiveSupport is not loaded until environment.rb is called. Attached patch removes the call to require, which doesn't appear to even be used. ---------------------------------------------------------------------- Comment By: Jean-Michel Garnier (garnierjm) Date: 2007-05-30 20:28 Message: I have a project using rspec 1.0.4 + ZenTest 3.6.0 and rspec_on_rails + rspec installed in my vendor/plugins. My list of gems is in http://rafb.net/p/212ywT51.html This patch caused me the following failure: $ autotest loading autotest/rails_rspec ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:33:in `initialize': undefined method `singularize' for ".svn/text-base/user":String (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:395:in `tests_for_file' from ./vendor/plugins/rspec/lib/autotest/rspec.rb:19:in `tests_for_file' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:319:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:318:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:373:in `reset' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:164:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:123:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/bin/autotest:48 from /usr/bin/autotest:16 it could not find the method `singularize' in the following code: def initialize # :nodoc: super @spec_command = "script/spec" @exceptions = %r%^\./(?:coverage|db|doc|log|public|script|vendor\/rails|previous_failures.txt)% @test_mappings = { %r%^(test|spec)/fixtures/(.*).yml% => proc { |_, m| ["spec/models/#{m[2].singularize}_spec.rb"] + files_matching(%r%^spec\/views\/#{m[2]}/.*_spec\.rb$%) }, When I put back the require 'active_support', I got everything worked as a charm, including my hook defined in .autotest The fact I have rails 1.2.1 installed in my gems might be the reason why it did work. I'd love to write a spec for this bug but I haven't got enough exp with ruby & rspec ... Any thought? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 07:54 Message: Applied to r2060. Gotta love the one-liner patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 From noreply at rubyforge.org Wed May 30 14:47:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 14:47:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11221 ] Autotest support does not work w/o Rails Gem installed Message-ID: <20070530184717.0A9025240AF8@rubyforge.org> Patches item #11221, was opened at 2007-05-29 22:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: David Chelimsky (dchelimsky) Summary: Autotest support does not work w/o Rails Gem installed Initial Comment: Currently autotest support only works if you have the Rails gem installed due to a call to require 'active_support' in rails_spec.rb. This causes problems for those of us who "vendor everything" and don't have any gems installed as ActiveSupport is not loaded until environment.rb is called. Attached patch removes the call to require, which doesn't appear to even be used. ---------------------------------------------------------------------- Comment By: Josh Knowles (joshknowles) Date: 2007-05-30 11:47 Message: Ok I see the problem... I'm not using fixtures thus didn't notice the call the singularize. Initial soltion off top of head is to check for vendor/rails otherwise fall back to gems. Any better solutions? If not I'll patch. ---------------------------------------------------------------------- Comment By: Jean-Michel Garnier (garnierjm) Date: 2007-05-30 11:28 Message: I have a project using rspec 1.0.4 + ZenTest 3.6.0 and rspec_on_rails + rspec installed in my vendor/plugins. My list of gems is in http://rafb.net/p/212ywT51.html This patch caused me the following failure: $ autotest loading autotest/rails_rspec ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:33:in `initialize': undefined method `singularize' for ".svn/text-base/user":String (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:395:in `tests_for_file' from ./vendor/plugins/rspec/lib/autotest/rspec.rb:19:in `tests_for_file' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:319:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:318:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:373:in `reset' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:164:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:123:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/bin/autotest:48 from /usr/bin/autotest:16 it could not find the method `singularize' in the following code: def initialize # :nodoc: super @spec_command = "script/spec" @exceptions = %r%^\./(?:coverage|db|doc|log|public|script|vendor\/rails|previous_failures.txt)% @test_mappings = { %r%^(test|spec)/fixtures/(.*).yml% => proc { |_, m| ["spec/models/#{m[2].singularize}_spec.rb"] + files_matching(%r%^spec\/views\/#{m[2]}/.*_spec\.rb$%) }, When I put back the require 'active_support', I got everything worked as a charm, including my hook defined in .autotest The fact I have rails 1.2.1 installed in my gems might be the reason why it did work. I'd love to write a spec for this bug but I haven't got enough exp with ruby & rspec ... Any thought? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-29 22:54 Message: Applied to r2060. Gotta love the one-liner patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 From noreply at rubyforge.org Wed May 30 16:23:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 16:23:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11221 ] Autotest support does not work w/o Rails Gem installed Message-ID: <20070530202329.A03EC5240C47@rubyforge.org> Patches item #11221, was opened at 2007-05-29 22:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 Category: rails plugin Group: None >Status: Open Resolution: Accepted Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: David Chelimsky (dchelimsky) Summary: Autotest support does not work w/o Rails Gem installed Initial Comment: Currently autotest support only works if you have the Rails gem installed due to a call to require 'active_support' in rails_spec.rb. This causes problems for those of us who "vendor everything" and don't have any gems installed as ActiveSupport is not loaded until environment.rb is called. Attached patch removes the call to require, which doesn't appear to even be used. ---------------------------------------------------------------------- >Comment By: Josh Knowles (joshknowles) Date: 2007-05-30 13:23 Message: So I played around with this a bit at lunch and I believe I have a solution that works for both gems and vendor. Jean-Michel Garnier can you test the newly attached patch please? ---------------------------------------------------------------------- Comment By: Josh Knowles (joshknowles) Date: 2007-05-30 11:47 Message: Ok I see the problem... I'm not using fixtures thus didn't notice the call the singularize. Initial soltion off top of head is to check for vendor/rails otherwise fall back to gems. Any better solutions? If not I'll patch. ---------------------------------------------------------------------- Comment By: Jean-Michel Garnier (garnierjm) Date: 2007-05-30 11:28 Message: I have a project using rspec 1.0.4 + ZenTest 3.6.0 and rspec_on_rails + rspec installed in my vendor/plugins. My list of gems is in http://rafb.net/p/212ywT51.html This patch caused me the following failure: $ autotest loading autotest/rails_rspec ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:33:in `initialize': undefined method `singularize' for ".svn/text-base/user":String (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:395:in `tests_for_file' from ./vendor/plugins/rspec/lib/autotest/rspec.rb:19:in `tests_for_file' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:319:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:318:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:373:in `reset' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:164:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:123:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/bin/autotest:48 from /usr/bin/autotest:16 it could not find the method `singularize' in the following code: def initialize # :nodoc: super @spec_command = "script/spec" @exceptions = %r%^\./(?:coverage|db|doc|log|public|script|vendor\/rails|previous_failures.txt)% @test_mappings = { %r%^(test|spec)/fixtures/(.*).yml% => proc { |_, m| ["spec/models/#{m[2].singularize}_spec.rb"] + files_matching(%r%^spec\/views\/#{m[2]}/.*_spec\.rb$%) }, When I put back the require 'active_support', I got everything worked as a charm, including my hook defined in .autotest The fact I have rails 1.2.1 installed in my gems might be the reason why it did work. I'd love to write a spec for this bug but I haven't got enough exp with ruby & rspec ... Any thought? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-29 22:54 Message: Applied to r2060. Gotta love the one-liner patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 From noreply at rubyforge.org Wed May 30 17:26:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 May 2007 17:26:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11221 ] Autotest support does not work w/o Rails Gem installed Message-ID: <20070530212651.C99345240A6E@rubyforge.org> Patches item #11221, was opened at 2007-05-30 05:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: David Chelimsky (dchelimsky) Summary: Autotest support does not work w/o Rails Gem installed Initial Comment: Currently autotest support only works if you have the Rails gem installed due to a call to require 'active_support' in rails_spec.rb. This causes problems for those of us who "vendor everything" and don't have any gems installed as ActiveSupport is not loaded until environment.rb is called. Attached patch removes the call to require, which doesn't appear to even be used. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 21:26 Message: Applied 2nd patch to r2061 ---------------------------------------------------------------------- Comment By: Josh Knowles (joshknowles) Date: 2007-05-30 20:23 Message: So I played around with this a bit at lunch and I believe I have a solution that works for both gems and vendor. Jean-Michel Garnier can you test the newly attached patch please? ---------------------------------------------------------------------- Comment By: Josh Knowles (joshknowles) Date: 2007-05-30 18:47 Message: Ok I see the problem... I'm not using fixtures thus didn't notice the call the singularize. Initial soltion off top of head is to check for vendor/rails otherwise fall back to gems. Any better solutions? If not I'll patch. ---------------------------------------------------------------------- Comment By: Jean-Michel Garnier (garnierjm) Date: 2007-05-30 18:28 Message: I have a project using rspec 1.0.4 + ZenTest 3.6.0 and rspec_on_rails + rspec installed in my vendor/plugins. My list of gems is in http://rafb.net/p/212ywT51.html This patch caused me the following failure: $ autotest loading autotest/rails_rspec ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:33:in `initialize': undefined method `singularize' for ".svn/text-base/user":String (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:395:in `tests_for_file' from ./vendor/plugins/rspec/lib/autotest/rspec.rb:19:in `tests_for_file' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:319:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:318:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:373:in `reset' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:164:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:123:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/bin/autotest:48 from /usr/bin/autotest:16 it could not find the method `singularize' in the following code: def initialize # :nodoc: super @spec_command = "script/spec" @exceptions = %r%^\./(?:coverage|db|doc|log|public|script|vendor\/rails|previous_failures.txt)% @test_mappings = { %r%^(test|spec)/fixtures/(.*).yml% => proc { |_, m| ["spec/models/#{m[2].singularize}_spec.rb"] + files_matching(%r%^spec\/views\/#{m[2]}/.*_spec\.rb$%) }, When I put back the require 'active_support', I got everything worked as a charm, including my hook defined in .autotest The fact I have rails 1.2.1 installed in my gems might be the reason why it did work. I'd love to write a spec for this bug but I haven't got enough exp with ruby & rspec ... Any thought? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 05:54 Message: Applied to r2060. Gotta love the one-liner patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 From nicksieger at gmail.com Wed May 30 23:51:21 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 30 May 2007 22:51:21 -0500 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: <57c63afe0705271544l4ab64174i92e870cdcd471ddb@mail.gmail.com> References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> <57c63afe0705271544l4ab64174i92e870cdcd471ddb@mail.gmail.com> Message-ID: On 5/27/07, David Chelimsky wrote: > All - I need to reiterate Aslak's initial plea. I am guilty of not > heeding it myself and just decided to check back to make sure jruby > was still happy and it wasn't. After a not very short time, I found > the offending commit which changed the html formatting but didn't also > update the html_formatted-1.8.5-jruby.html file. I've now updated the > file and made sure everything's cool w/ JRuby, but we have to treat > this a bit more seriously until they release JRuby 1.0, which is > soon!!!!!! We now have a bit more backup! Finally successful builds in our CI! Woot! Now, only issue is that our build isn't triggered by changes to RSpec. If anyone on the RSpec team is interested in an account on our build server that would allow you to manually trigger a build, let me know. http://jruby.thresher.com/browse/RSPEC-TRUNK-66 /Nick From dchelimsky at gmail.com Wed May 30 23:54:20 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 30 May 2007 23:54:20 -0400 Subject: [rspec-devel] RSpec inside JRuby In-Reply-To: References: <8d961d900705230601q6dd50dbdt348e97bcd4a4e7cc@mail.gmail.com> <57c63afe0705230940j36b85a09ge526a9eb46ff7325@mail.gmail.com> <46548BD5.1020007@sun.com> <57c63afe0705231158q18f73831y6d4f4d8747ba86fe@mail.gmail.com> <8d961d900705231220p78934828y3a469aab2431f43c@mail.gmail.com> <57c63afe0705271544l4ab64174i92e870cdcd471ddb@mail.gmail.com> Message-ID: <57c63afe0705302054ydd031c4o6354bfe0373f6294@mail.gmail.com> On 5/30/07, Nick Sieger wrote: > On 5/27/07, David Chelimsky wrote: > > All - I need to reiterate Aslak's initial plea. I am guilty of not > > heeding it myself and just decided to check back to make sure jruby > > was still happy and it wasn't. After a not very short time, I found > > the offending commit which changed the html formatting but didn't also > > update the html_formatted-1.8.5-jruby.html file. I've now updated the > > file and made sure everything's cool w/ JRuby, but we have to treat > > this a bit more seriously until they release JRuby 1.0, which is > > soon!!!!!! > > We now have a bit more backup! Finally successful builds in our CI! Woot! > > Now, only issue is that our build isn't triggered by changes to RSpec. > If anyone on the RSpec team is interested in an account on our build > server that would allow you to manually trigger a build, let me know. DEFINITELY. I'll follow up off-list. Cheers, David > > http://jruby.thresher.com/browse/RSPEC-TRUNK-66 > > /Nick > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu May 31 01:52:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 01:52:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11247 ] standalone autotest doesn't work because of unneeded autotest.rb Message-ID: <20070531055253.83D255240AF8@rubyforge.org> Bugs item #11247, was opened at 2007-05-31 08:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mikko Lehtonen (scoopr) Assigned to: Nobody (None) Summary: standalone autotest doesn't work because of unneeded autotest.rb Initial Comment: there is $RSPECDIR/lib/autotest.rb which is completely unneeded as far as I can see, but interferes with autotest. More specifially, lib/autotest/rspec.rb requires 'autotest' (and expects to get zentest's Autotest class) but gets that dummy file instead. Everything works for me when I rename/remove that file. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 From noreply at rubyforge.org Thu May 31 06:38:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 06:38:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11247 ] standalone autotest doesn't work because of unneeded autotest.rb Message-ID: <20070531103849.1D6185240AAD@rubyforge.org> Bugs item #11247, was opened at 2007-05-31 05:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mikko Lehtonen (scoopr) Assigned to: Nobody (None) Summary: standalone autotest doesn't work because of unneeded autotest.rb Initial Comment: there is $RSPECDIR/lib/autotest.rb which is completely unneeded as far as I can see, but interferes with autotest. More specifially, lib/autotest/rspec.rb requires 'autotest' (and expects to get zentest's Autotest class) but gets that dummy file instead. Everything works for me when I rename/remove that file. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 10:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 From noreply at rubyforge.org Thu May 31 07:03:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 07:03:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11247 ] standalone autotest doesn't work because of unneeded autotest.rb Message-ID: <20070531110302.BDF9B5240AD1@rubyforge.org> Bugs item #11247, was opened at 2007-05-31 08:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mikko Lehtonen (scoopr) Assigned to: Nobody (None) Summary: standalone autotest doesn't work because of unneeded autotest.rb Initial Comment: there is $RSPECDIR/lib/autotest.rb which is completely unneeded as far as I can see, but interferes with autotest. More specifially, lib/autotest/rspec.rb requires 'autotest' (and expects to get zentest's Autotest class) but gets that dummy file instead. Everything works for me when I rename/remove that file. ---------------------------------------------------------------------- >Comment By: Mikko Lehtonen (scoopr) Date: 2007-05-31 14:03 Message: Ah of course, sorry. os x 10.4.9 (latest tiger) ruby 1.8.5 (2006-08-25) [i686-darwin8.8.1] (self built) RSpec-1.0.4 (r2054) - BDD for Ruby (latest gem) And this was standalone, so no rails used, but rails 1.2.3 installed. I haven't tried trunk, but I stronly believe that the autotest.rb file included with rspec conflicts with the actual autotest.rb from zentest, and that file is still in trunk from what I can see. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 13:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 From noreply at rubyforge.org Thu May 31 07:40:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 07:40:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11247 ] standalone autotest doesn't work because of unneeded autotest.rb Message-ID: <20070531114050.CED4C52409AD@rubyforge.org> Bugs item #11247, was opened at 2007-05-31 05:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Mikko Lehtonen (scoopr) >Assigned to: David Chelimsky (dchelimsky) Summary: standalone autotest doesn't work because of unneeded autotest.rb Initial Comment: there is $RSPECDIR/lib/autotest.rb which is completely unneeded as far as I can see, but interferes with autotest. More specifially, lib/autotest/rspec.rb requires 'autotest' (and expects to get zentest's Autotest class) but gets that dummy file instead. Everything works for me when I rename/remove that file. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 11:40 Message: Fixed in r2062 ---------------------------------------------------------------------- Comment By: Mikko Lehtonen (scoopr) Date: 2007-05-31 11:03 Message: Ah of course, sorry. os x 10.4.9 (latest tiger) ruby 1.8.5 (2006-08-25) [i686-darwin8.8.1] (self built) RSpec-1.0.4 (r2054) - BDD for Ruby (latest gem) And this was standalone, so no rails used, but rails 1.2.3 installed. I haven't tried trunk, but I stronly believe that the autotest.rb file included with rspec conflicts with the actual autotest.rb from zentest, and that file is still in trunk from what I can see. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 10:38 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11247&group_id=797 From noreply at rubyforge.org Thu May 31 07:59:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 07:59:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11252 ] Should be able to re-load file containing shared behaviours without raising an exception Message-ID: <20070531115958.819355240A63@rubyforge.org> Patches item #11252, was opened at 2007-05-31 11:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11252&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Should be able to re-load file containing shared behaviours without raising an exception Initial Comment: As discussed on rspec-users (), this patch allows shared behaviours to be placed in spec_helper.rb, or required from spec_helper.rb or elsewhere repeatedly without raising ArgumentErrors. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11252&group_id=797 From noreply at rubyforge.org Thu May 31 08:04:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 08:04:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11252 ] Should be able to re-load file containing shared behaviours without raising an exception Message-ID: <20070531120409.CDAF45240ABC@rubyforge.org> Patches item #11252, was opened at 2007-05-31 11:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11252&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Should be able to re-load file containing shared behaviours without raising an exception Initial Comment: As discussed on rspec-users (), this patch allows shared behaviours to be placed in spec_helper.rb, or required from spec_helper.rb or elsewhere repeatedly without raising ArgumentErrors. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11252&group_id=797 From noreply at rubyforge.org Thu May 31 10:37:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 10:37:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11253 ] Tweaks to autotest file mappings Message-ID: <20070531143734.46FA45240B17@rubyforge.org> Patches item #11253, was opened at 2007-05-31 14:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11253&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: Tweaks to autotest file mappings Initial Comment: As discussed on rspec-users (), this patch updates the autotest file mappings for Rails so that changes to spec/shared will cause all specs to run again. It also updates the non-rails file mappings so that changes to spec/spec_helper.rb or spec/shared cause all specs to run again. I also tightened up some of the regexps (some where missing $ or had unescaped periods). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11253&group_id=797 From noreply at rubyforge.org Thu May 31 10:43:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 10:43:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070531144304.BD05A5240C45@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Thu May 31 10:45:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 10:45:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070531144500.4A1855240B20@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Nobody (None) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Thu May 31 11:42:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 11:42:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11221 ] Autotest support does not work w/o Rails Gem installed Message-ID: <20070531154248.83D0A5240C04@rubyforge.org> Patches item #11221, was opened at 2007-05-30 07:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Josh Knowles (joshknowles) Assigned to: David Chelimsky (dchelimsky) Summary: Autotest support does not work w/o Rails Gem installed Initial Comment: Currently autotest support only works if you have the Rails gem installed due to a call to require 'active_support' in rails_spec.rb. This causes problems for those of us who "vendor everything" and don't have any gems installed as ActiveSupport is not loaded until environment.rb is called. Attached patch removes the call to require, which doesn't appear to even be used. ---------------------------------------------------------------------- Comment By: Jean-Michel Garnier (garnierjm) Date: 2007-05-31 17:42 Message: Josh, the newly attached patch works well with & without rails in my gems. Cheers for you super fast reaction! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 23:26 Message: Applied 2nd patch to r2061 ---------------------------------------------------------------------- Comment By: Josh Knowles (joshknowles) Date: 2007-05-30 22:23 Message: So I played around with this a bit at lunch and I believe I have a solution that works for both gems and vendor. Jean-Michel Garnier can you test the newly attached patch please? ---------------------------------------------------------------------- Comment By: Josh Knowles (joshknowles) Date: 2007-05-30 20:47 Message: Ok I see the problem... I'm not using fixtures thus didn't notice the call the singularize. Initial soltion off top of head is to check for vendor/rails otherwise fall back to gems. Any better solutions? If not I'll patch. ---------------------------------------------------------------------- Comment By: Jean-Michel Garnier (garnierjm) Date: 2007-05-30 20:28 Message: I have a project using rspec 1.0.4 + ZenTest 3.6.0 and rspec_on_rails + rspec installed in my vendor/plugins. My list of gems is in http://rafb.net/p/212ywT51.html This patch caused me the following failure: $ autotest loading autotest/rails_rspec ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:33:in `initialize': undefined method `singularize' for ".svn/text-base/user":String (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:395:in `tests_for_file' from ./vendor/plugins/rspec/lib/autotest/rspec.rb:19:in `tests_for_file' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:319:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:318:in `find_files_to_test' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:373:in `reset' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:164:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:123:in `run' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/bin/autotest:48 from /usr/bin/autotest:16 it could not find the method `singularize' in the following code: def initialize # :nodoc: super @spec_command = "script/spec" @exceptions = %r%^\./(?:coverage|db|doc|log|public|script|vendor\/rails|previous_failures.txt)% @test_mappings = { %r%^(test|spec)/fixtures/(.*).yml% => proc { |_, m| ["spec/models/#{m[2].singularize}_spec.rb"] + files_matching(%r%^spec\/views\/#{m[2]}/.*_spec\.rb$%) }, When I put back the require 'active_support', I got everything worked as a charm, including my hook defined in .autotest The fact I have rails 1.2.1 installed in my gems might be the reason why it did work. I'd love to write a spec for this bug but I haven't got enough exp with ruby & rspec ... Any thought? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-30 07:54 Message: Applied to r2060. Gotta love the one-liner patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11221&group_id=797 From noreply at rubyforge.org Thu May 31 12:02:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 12:02:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11252 ] Should be able to re-load file containing shared behaviours without raising an exception Message-ID: <20070531160220.7B78752409EA@rubyforge.org> Patches item #11252, was opened at 2007-05-31 11:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11252&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Wincent Colaiuta (wincent) >Assigned to: David Chelimsky (dchelimsky) Summary: Should be able to re-load file containing shared behaviours without raising an exception Initial Comment: As discussed on rspec-users (), this patch allows shared behaviours to be placed in spec_helper.rb, or required from spec_helper.rb or elsewhere repeatedly without raising ArgumentErrors. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 16:02 Message: Applied to r2063. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11252&group_id=797 From noreply at rubyforge.org Thu May 31 12:12:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 12:12:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11253 ] Tweaks to autotest file mappings Message-ID: <20070531161223.DCDA65240B20@rubyforge.org> Patches item #11253, was opened at 2007-05-31 14:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11253&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Wincent Colaiuta (wincent) >Assigned to: David Chelimsky (dchelimsky) Summary: Tweaks to autotest file mappings Initial Comment: As discussed on rspec-users (), this patch updates the autotest file mappings for Rails so that changes to spec/shared will cause all specs to run again. It also updates the non-rails file mappings so that changes to spec/spec_helper.rb or spec/shared cause all specs to run again. I also tightened up some of the regexps (some where missing $ or had unescaped periods). ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 16:12 Message: Applied to r2064. Good stuff. Small favor - can you name future patches .patch instead of .txt? Firefox likes to show me .txt files in the browser instead of letting me download them. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11253&group_id=797 From noreply at rubyforge.org Thu May 31 12:46:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 12:46:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11253 ] Tweaks to autotest file mappings Message-ID: <20070531164645.6C61952409EA@rubyforge.org> Patches item #11253, was opened at 2007-05-31 14:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11253&group_id=797 Category: None Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: David Chelimsky (dchelimsky) Summary: Tweaks to autotest file mappings Initial Comment: As discussed on rspec-users (), this patch updates the autotest file mappings for Rails so that changes to spec/shared will cause all specs to run again. It also updates the non-rails file mappings so that changes to spec/spec_helper.rb or spec/shared cause all specs to run again. I also tightened up some of the regexps (some where missing $ or had unescaped periods). ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-05-31 16:46 Message: Sure thing... will use ".patch" in the future. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 16:12 Message: Applied to r2064. Good stuff. Small favor - can you name future patches .patch instead of .txt? Firefox likes to show me .txt files in the browser instead of letting me download them. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11253&group_id=797 From noreply at rubyforge.org Thu May 31 15:04:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 15:04:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11258 ] windows: autotest won't run Message-ID: <20070531190438.DE4635240951@rubyforge.org> Bugs item #11258, was opened at 2007-05-31 12:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11258&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Erik Ostrom (eostrom) Assigned to: Nobody (None) Summary: windows: autotest won't run Initial Comment: 'script/spec' is not a valid command on Windows, which doesn't know about #! scripts. c:/ruby/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:209:in `open?: No such file or directory ? script/spec -O spec/spec.opts [... long list of specs?] (Errno::ENOENT) I think I fixed this by changing "script/spec" to "ruby script/spec" in rails_rspec.rb. I believe this would run on most UNIX systems, but if the script specified a version of Ruby, it wouldn't honor that choice. So maybe something more sophisticated would be better--even just making the command configurable. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11258&group_id=797 From noreply at rubyforge.org Thu May 31 15:15:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 15:15:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11259 ] windows?: autotest suppresses output Message-ID: <20070531191545.F3A1A5240AC1@rubyforge.org> Bugs item #11259, was opened at 2007-05-31 12:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Erik Ostrom (eostrom) Assigned to: Nobody (None) Summary: windows?: autotest suppresses output Initial Comment: When I run rspec under autotest (with the change I noted in 11258), it seems to run okay; it detects specs that should be run anew; it runs them (as evidenced by test.log); but it never, ever shows me any output from the spec runner. Even a test known to fail shows me nothing. If I use rspec without autotest, everything works fine. If I use Test::Unit instead of rspec, autotest shows me the full test runner output. So it must be a problem with the way rspec and autotest interact. (I don't know if this is actually a Windows problem, but it seems plausible.) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 From noreply at rubyforge.org Thu May 31 15:26:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 31 May 2007 15:26:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11258 ] windows: autotest won't run Message-ID: <20070531192624.2365E52408D9@rubyforge.org> Bugs item #11258, was opened at 2007-05-31 19:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11258&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Erik Ostrom (eostrom) >Assigned to: David Chelimsky (dchelimsky) Summary: windows: autotest won't run Initial Comment: 'script/spec' is not a valid command on Windows, which doesn't know about #! scripts. c:/ruby/lib/ruby/gems/1.8/gems/ZenTest-3.6.0/lib/autotest.rb:209:in `open?: No such file or directory ? script/spec -O spec/spec.opts [... long list of specs?] (Errno::ENOENT) I think I fixed this by changing "script/spec" to "ruby script/spec" in rails_rspec.rb. I believe this would run on most UNIX systems, but if the script specified a version of Ruby, it wouldn't honor that choice. So maybe something more sophisticated would be better--even just making the command configurable. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 19:26 Message: script/spec refers to the spec file that is installed into to the script directory in your Rails application when you run script/generate_rspec, not #! scripts, so pre-pending ruby should work just fine for this. I can't get to svn right now, but I'll commit this fix tonight. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11258&group_id=797 From noreply at rubyforge.org Thu