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 #