From aslak.hellesoy at gmail.com Sat Jul 1 21:32:55 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 1 Jul 2006 20:32:55 -0500 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> Message-ID: <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> Hi Jonathan, This is great! I haven't had the chance to try it yet, but I will next week. Would you be ok with us adding it to RSpce's svn? (vendor/textmate - to be distributed as a separate package from the Rspec gem). We'll credit you duly in the docs. Cheers, Aslak On 6/30/06, Jonathan del Strother wrote: > Don't know how many TextMate users we've got here, but: > > I was getting a little tired of tweaking a spec file, swapping to > Terminal, running specs, and swapping back again, so I came up with a > TextMate command to do this for me. It runs 'rake spec' and display > the output, complete with clickable links to any files. > > > > === > > #!/usr/bin/env ruby > > def process_for_html(string) > string.gsub!("\n", "
") > > #try to find file names and make them into proper links > string.gsub! /\.(\/[^:]*):([\d]*)/ do |m| > path = Dir.pwd + $1 > "#{m}" > end > string > end > > Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) > > output = `rake spec` > output.gsub!("\n", "
") > > #try to find file names and make them into proper links > output.gsub! /\.(\/[^:]*):([\d]*)/ do |m| > path = Dir.pwd + $1 > "#{m}" > end > > puts "#{"

rspec

"+output} body>" > > > === > > > Just create a new bundle command, and set its output to 'Show as > HTML', and you should be good to go. > > > There's a few limitations though - mainly that stderr isn't captured, > so any stderr gets dumped at the top of the file , without > formatting. This includes the ruby invocation commands (ruby -Ilib "/ > usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/models/ > active_user_spec.rb"), and any syntax errors in your specs. I've > been trying for the past hour to properly capture stderr and > interpolate it into the normal output, without success. popen3 just > gives you stdout and stderr as separate objects, with no way of re- > joining them up in the order they occurred. > So, if anyone has a fix to the stderr problem, or any other additions > & improvements, I'd love to see them. > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brianvh at Alum.Dartmouth.ORG Sat Jul 1 21:44:35 2006 From: brianvh at Alum.Dartmouth.ORG (Brian Hughes) Date: Sat, 1 Jul 2006 21:44:35 -0400 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> Message-ID: I think it looks like a great script, as well. I should also mention that I've been working on a semi-full rSpec bundle for TextMate, and the spec runner script was a big part of what I was missing. I've kind of put the project on the shelf, however, because there's currently no way for TM to select the language bundle based on a portion of the file name that isn't the file extension. So *_spec.rb is the same as every other *.rb file, which means you can't have a single project with Ruby, Rails and rSpec files in it. -Brian On Jul 1, 2006, at 09:32 PM, aslak hellesoy wrote: > This is great! I haven't had the chance to try it yet, but I will > next week. > > Would you be ok with us adding it to RSpce's svn? (vendor/textmate - > to be distributed as a separate package from the Rspec gem). We'll > credit you duly in the docs. > > Cheers, > Aslak > > On 6/30/06, Jonathan del Strother wrote: >> Don't know how many TextMate users we've got here, but: >> >> I was getting a little tired of tweaking a spec file, swapping to >> Terminal, running specs, and swapping back again, so I came up with a >> TextMate command to do this for me. It runs 'rake spec' and display >> the output, complete with clickable links to any files. >> >> === >> >> #!/usr/bin/env ruby >> >> def process_for_html(string) >> string.gsub!("\n", "
") >> >> #try to find file names and make them into proper links >> string.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >> path = Dir.pwd + $1 >> "#{m}" >> end >> string >> end >> >> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) >> >> output = `rake spec` >> output.gsub!("\n", "
") >> >> #try to find file names and make them into proper links >> output.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >> path = Dir.pwd + $1 >> "#{m}" >> end >> >> puts "#{"

rspec> h1>"+output}> body>" >> >> === >> >> Just create a new bundle command, and set its output to 'Show as >> HTML', and you should be good to go. >> >> There's a few limitations though - mainly that stderr isn't captured, >> so any stderr gets dumped at the top of the file , without >> formatting. This includes the ruby invocation commands (ruby - >> Ilib "/ >> usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/models/ >> active_user_spec.rb"), and any syntax errors in your specs. I've >> been trying for the past hour to properly capture stderr and >> interpolate it into the normal output, without success. popen3 just >> gives you stdout and stderr as separate objects, with no way of re- >> joining them up in the order they occurred. >> So, if anyone has a fix to the stderr problem, or any other additions >> & improvements, I'd love to see them. From jon.borgthorsson at gmail.com Sat Jul 1 22:47:46 2006 From: jon.borgthorsson at gmail.com (Jon Gretar Borgthorsson) Date: Sun, 2 Jul 2006 02:47:46 +0000 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> Message-ID: On 7/2/06, Brian Hughes wrote: > > I think it looks like a great script, as well. I should also mention > that I've been working on a semi-full rSpec bundle for TextMate, and > the spec runner script was a big part of what I was missing. I've > kind of put the project on the shelf, however, because there's > currently no way for TM to select the language bundle based on a > portion of the file name that isn't the file extension. So *_spec.rb > is the same as every other *.rb file, which means you can't have a > single project with Ruby, Rails and rSpec files in it. But you should be able to define this using the scope. Right? I'm at least using a bundle that allows me to switch between the controller and the model with a key combo. Shouldn't a similar approach help you? -- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/ From aslak.hellesoy at gmail.com Sun Jul 2 03:17:42 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 2 Jul 2006 02:17:42 -0500 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> Message-ID: <8d961d900607020017m7f8bc48cs795190ff9bf84b8f@mail.gmail.com> On 7/1/06, Brian Hughes wrote: > > I think it looks like a great script, as well. I should also mention > that I've been working on a semi-full rSpec bundle for TextMate, and > the spec runner script was a big part of what I was missing. I've > kind of put the project on the shelf, however, because there's > currently no way for TM to select the language bundle based on a > portion of the file name that isn't the file extension. So *_spec.rb > is the same as every other *.rb file, which means you can't have a > single project with Ruby, Rails and rSpec files in it. > We've thought about encouraging a new naming convention for spec files. Instead of mooky_spec.rb you would have mooky.spec Would that solve your problems? And also - feel free to contribute your bundle - even if it's not "quite there" yet. All of the RSpec developers are on os x/textmate. Bring it out and let others help improve it. Aslak > -Brian > > On Jul 1, 2006, at 09:32 PM, aslak hellesoy wrote: > > This is great! I haven't had the chance to try it yet, but I will > > next week. > > > > Would you be ok with us adding it to RSpce's svn? (vendor/textmate - > > to be distributed as a separate package from the Rspec gem). We'll > > credit you duly in the docs. > > > > Cheers, > > Aslak > > > > On 6/30/06, Jonathan del Strother wrote: > >> Don't know how many TextMate users we've got here, but: > >> > >> I was getting a little tired of tweaking a spec file, swapping to > >> Terminal, running specs, and swapping back again, so I came up with a > >> TextMate command to do this for me. It runs 'rake spec' and display > >> the output, complete with clickable links to any files. > >> > >> === > >> > >> #!/usr/bin/env ruby > >> > >> def process_for_html(string) > >> string.gsub!("\n", "
") > >> > >> #try to find file names and make them into proper links > >> string.gsub! /\.(\/[^:]*):([\d]*)/ do |m| > >> path = Dir.pwd + $1 > >> "#{m}" > >> end > >> string > >> end > >> > >> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) > >> > >> output = `rake spec` > >> output.gsub!("\n", "
") > >> > >> #try to find file names and make them into proper links > >> output.gsub! /\.(\/[^:]*):([\d]*)/ do |m| > >> path = Dir.pwd + $1 > >> "#{m}" > >> end > >> > >> puts "#{"

rspec >> h1>"+output} >> body>" > >> > >> === > >> > >> Just create a new bundle command, and set its output to 'Show as > >> HTML', and you should be good to go. > >> > >> There's a few limitations though - mainly that stderr isn't captured, > >> so any stderr gets dumped at the top of the file , without > >> formatting. This includes the ruby invocation commands (ruby - > >> Ilib "/ > >> usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/models/ > >> active_user_spec.rb"), and any syntax errors in your specs. I've > >> been trying for the past hour to properly capture stderr and > >> interpolate it into the normal output, without success. popen3 just > >> gives you stdout and stderr as separate objects, with no way of re- > >> joining them up in the order they occurred. > >> So, if anyone has a fix to the stderr problem, or any other additions > >> & improvements, I'd love to see them. > > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From maillist at steelskies.com Sun Jul 2 08:16:14 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Sun, 2 Jul 2006 13:16:14 +0100 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> Message-ID: Feel free to include it, though I suspect it could do with some cleaning up - this is my first TextMate plugin and I'm sure I'm ignoring all sorts of conventions and useful utility functions... I've just come up with an updated version: === #!/usr/bin/env ruby require 'cgi' #try and remove unnecessary '..'s from paths. #Eg collapse 'config/../app/controllers/../../public' to 'public'. Hopefully. def rationalize_path(path) components = path.split("/") real_components = [] components.each do |c| if (c == "..") && (real_components.size > 0) && (real_components.last != "..") real_components.pop else real_components.push c end end File.join(real_components) end Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) output = `rake spec 2>&1` output = CGI.escapeHTML(output) #rationalize paths (strip out unnecessary '..'s etc) output.gsub! /(\.\/|\/)[^:\n]+\.[^:\n]+/ do |m| rationalize_path(m) end #Find local file names and make them into proper links #It ignores any paths that don't start with './'. # (This is a feature, IMO - too many links if you find every single path in the output.) output.gsub! /\.(\/[^:]+):([\d]+)/ do |m| path = Dir.pwd + $1 "#{m}" end #Find the result lines (x specification(s), y failure(s)) and style them output.gsub! /^[\d]+ specifications?, [\d]+ failures?/ do |m| "#{m}" end #Remove unnecessary repetition of the project path: output.gsub! /#{Dir.pwd}\//, './' output.gsub!("\n", "
") puts < rspec results

rspec

#{output} END == which properly feeds stderr into the output, and makes a few attempts to cut down on the amount of unnecessary text - eg collapsing paths with '..' in them. Oh, and the rspec results get their own style. It's a shame we don't have a proper runner for this yet, to avoid setting up the rails environment every time you launch 'rake spec'. What happened to rspecRunner? And is it suitable for running with rspec on rails? On 2 Jul 2006, at 02:32, aslak hellesoy wrote: > Hi Jonathan, > > This is great! I haven't had the chance to try it yet, but I will > next week. > > Would you be ok with us adding it to RSpce's svn? (vendor/textmate - > to be distributed as a separate package from the Rspec gem). We'll > credit you duly in the docs. > > Cheers, > Aslak > > On 6/30/06, Jonathan del Strother wrote: >> Don't know how many TextMate users we've got here, but: >> >> I was getting a little tired of tweaking a spec file, swapping to >> Terminal, running specs, and swapping back again, so I came up with a >> TextMate command to do this for me. It runs 'rake spec' and display >> the output, complete with clickable links to any files. >> >> >> >> === >> >> #!/usr/bin/env ruby >> >> def process_for_html(string) >> string.gsub!("\n", "
") >> >> #try to find file names and make them into proper links >> string.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >> path = Dir.pwd + $1 >> "#{m}" >> end >> string >> end >> >> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) >> >> output = `rake spec` >> output.gsub!("\n", "
") >> >> #try to find file names and make them into proper links >> output.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >> path = Dir.pwd + $1 >> "#{m}" >> end >> >> puts "#{"

rspec> h1>"+output}> body>" >> >> >> === >> >> >> Just create a new bundle command, and set its output to 'Show as >> HTML', and you should be good to go. >> >> >> There's a few limitations though - mainly that stderr isn't captured, >> so any stderr gets dumped at the top of the file , without >> formatting. This includes the ruby invocation commands (ruby - >> Ilib "/ >> usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/models/ >> active_user_spec.rb"), and any syntax errors in your specs. I've >> been trying for the past hour to properly capture stderr and >> interpolate it into the normal output, without success. popen3 just >> gives you stdout and stderr as separate objects, with no way of re- >> joining them up in the order they occurred. >> So, if anyone has a fix to the stderr problem, or any other additions >> & improvements, I'd love to see them. >> >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2114 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060702/6cb4e49a/attachment-0001.bin From lists-rspec at shopwatch.org Sun Jul 2 22:49:16 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 02 Jul 2006 22:49:16 -0400 Subject: [Rspec-devel] Some handy rails helpers Message-ID: <44A885AC.3040103@shopwatch.org> I've been using these in spec_helper: class Spec::Runner::ExecutionContext def form_should_have_fields(obj, fields) for field in fields response.body.should_have_tag :tag => "input", :attributes => { :name => "#{obj}[#{field}]" } end end end class Spec::Runner::Context def fields_should_start_empty(obj, *fields) fields.flatten.each do |f| specify "should have an empty #{f} field" do eval(obj.id2name + ".#{f}.should.be.nil") end end end def fields_cant_stay_empty(obj, *fields) fields.flatten.each do |f| specify "should disallow an empty #{f} field" do o = eval(obj.id2name) o.send("#{f}=", nil) o.should.not.be.valid o.errors.on(f).should.equal "can't be blank" end end end end --- Usage: in a controller_spec.rb: specify "get the new receipt form" do get 'new' response.should.be.success response.should_render 'new' form_should_have_fields("receipt", ["vendor", "purchased_at"]) end in a model spec.rb, where :valid is a fixture for a valid receipt: context "A newly created receipt" do setup do @receipt = Receipt.new end fields_should_start_empty(:@receipt, :vendor, :purchased_at) end context "An otherwise valid receipt" do fixtures :receipts setup do @receipt = receipts(:valid) end specify "should start out valid" do @receipt.should.be.valid end fields_cant_stay_empty(:@receipt, :vendor, :purchased_at) end From luke at agileevolved.com Mon Jul 3 05:35:07 2006 From: luke at agileevolved.com (Luke Redpath) Date: Mon, 3 Jul 2006 10:35:07 +0100 Subject: [Rspec-devel] Some handy rails helpers In-Reply-To: <44A885AC.3040103@shopwatch.org> References: <44A885AC.3040103@shopwatch.org> Message-ID: Hi Jay These look really cool, and your post got my thinking. I've always hated how clunky the assert_tag function that come with Rails is. Wouldn't it be really cool to have a DSL that merges in with rSpec for testing your HTML output - kind of like integration tests but I was thinking more about speccing particular controller actions (under their various contexts) and their resulting views. Something like this would be really cool: tag('h1', :id => 'pageheader').should_contain('My Great Website') Or even better: h1(:id => 'pageheader').should_contain('My Great Website') div(:id => 'somediv').should_have_class_name('hidden') And based on your helpers: form(:id => 'myform').should_have_fields("name", "email", "username", "passsword") Luke Redpath Senior Software Engineer Agile Evolved Limited E. luke at agileevolved.com W. www.agileevolved.com On 3 Jul 2006, at 03:49, Jay Levitt wrote: > I've been using these in spec_helper: > > class Spec::Runner::ExecutionContext > def form_should_have_fields(obj, fields) > for field in fields > response.body.should_have_tag :tag => "input", > :attributes => { :name => "#{obj}[#{field}]" } > end > end > end > > class Spec::Runner::Context > def fields_should_start_empty(obj, *fields) > fields.flatten.each do |f| > specify "should have an empty #{f} field" do > eval(obj.id2name + ".#{f}.should.be.nil") > end > end > end > > def fields_cant_stay_empty(obj, *fields) > fields.flatten.each do |f| > specify "should disallow an empty #{f} field" do > o = eval(obj.id2name) > o.send("#{f}=", nil) > o.should.not.be.valid > o.errors.on(f).should.equal "can't be blank" > end > end > end > end > > --- > > Usage: > > in a controller_spec.rb: > > specify "get the new receipt form" do > get 'new' > response.should.be.success > response.should_render 'new' > form_should_have_fields("receipt", ["vendor", "purchased_at"]) > end > > in a model spec.rb, where :valid is a fixture for a valid receipt: > > context "A newly created receipt" do > setup do > @receipt = Receipt.new > end > > fields_should_start_empty(:@receipt, :vendor, :purchased_at) > end > > context "An otherwise valid receipt" do > fixtures :receipts > > setup do > @receipt = receipts(:valid) > end > > specify "should start out valid" do > @receipt.should.be.valid > end > > fields_cant_stay_empty(:@receipt, :vendor, :purchased_at) > end > > _______________________________________________ > 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/20060703/3cbf5563/attachment.html From maillist at steelskies.com Mon Jul 3 06:17:11 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Mon, 3 Jul 2006 11:17:11 +0100 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> Message-ID: <25374F9A-B23C-4D50-B4C8-BC7C171930C2@steelskies.com> Ooops. Looks like there's a few path issues with the below script, and with the recent changes to RubyMate, it fails to find rake in the path. So, take the script, strip off the shebang line (first line), and move it all to Rails.bundle/Support/bin/spec_helper.rb Then in TextMate's bundle menu, use this command to load the spec helper, which will keep your search path intact: RUBYLIB="$TM_BUNDLE_SUPPORT/lib:$RUBYLIB" "${TM_RUBY:=ruby}" -- "${TM_BUNDLE_SUPPORT}/bin/spec_helper.rb" On 2 Jul 2006, at 13:16, Jonathan del Strother wrote: > Feel free to include it, though I suspect it could do with some > cleaning up - this is my first TextMate plugin and I'm sure I'm > ignoring all sorts of conventions and useful utility functions... > > I've just come up with an updated version: > > > === > > #!/usr/bin/env ruby > require 'cgi' > > #try and remove unnecessary '..'s from paths. > #Eg collapse 'config/../app/controllers/../../public' to 'public'. > Hopefully. > def rationalize_path(path) > components = path.split("/") > real_components = [] > components.each do |c| > if (c == "..") && (real_components.size > 0) && > (real_components.last != "..") > real_components.pop > else > real_components.push c > end > end > > File.join(real_components) > end > > > > Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) > > output = `rake spec 2>&1` > output = CGI.escapeHTML(output) > > #rationalize paths (strip out unnecessary '..'s etc) > output.gsub! /(\.\/|\/)[^:\n]+\.[^:\n]+/ do |m| > rationalize_path(m) > end > > #Find local file names and make them into proper links > #It ignores any paths that don't start with './'. > # (This is a feature, IMO - too many links if you find every single > path in the output.) > output.gsub! /\.(\/[^:]+):([\d]+)/ do |m| > path = Dir.pwd + $1 > "#{m}" > end > > > #Find the result lines (x specification(s), y failure(s)) and style > them > output.gsub! /^[\d]+ specifications?, [\d]+ failures?/ do |m| > "#{m}" > end > > #Remove unnecessary repetition of the project path: > output.gsub! /#{Dir.pwd}\//, './' > > > output.gsub!("\n", "
") > > puts < > > rspec results > > > >

rspec

> #{output} > > > END > > > == > > > which properly feeds stderr into the output, and makes a few > attempts to cut down on the amount of unnecessary text - eg > collapsing paths with '..' in them. Oh, and the rspec results > get their own style. > > > It's a shame we don't have a proper runner for this yet, to avoid > setting up the rails environment every time you launch 'rake > spec'. What happened to rspecRunner? And is it suitable for > running with rspec on rails? > > > > > > On 2 Jul 2006, at 02:32, aslak hellesoy wrote: > >> Hi Jonathan, >> >> This is great! I haven't had the chance to try it yet, but I will >> next week. >> >> Would you be ok with us adding it to RSpce's svn? (vendor/textmate - >> to be distributed as a separate package from the Rspec gem). We'll >> credit you duly in the docs. >> >> Cheers, >> Aslak >> >> On 6/30/06, Jonathan del Strother wrote: >>> Don't know how many TextMate users we've got here, but: >>> >>> I was getting a little tired of tweaking a spec file, swapping to >>> Terminal, running specs, and swapping back again, so I came up >>> with a >>> TextMate command to do this for me. It runs 'rake spec' and display >>> the output, complete with clickable links to any files. >>> >>> >>> >>> === >>> >>> #!/usr/bin/env ruby >>> >>> def process_for_html(string) >>> string.gsub!("\n", "
") >>> >>> #try to find file names and make them into proper links >>> string.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >>> path = Dir.pwd + $1 >>> "#{m}>> a>" >>> end >>> string >>> end >>> >>> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) >>> >>> output = `rake spec` >>> output.gsub!("\n", "
") >>> >>> #try to find file names and make them into proper links >>> output.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >>> path = Dir.pwd + $1 >>> "#{m}" >>> end >>> >>> puts "#{"

rspec>> h1>"+output}>> body>" >>> >>> >>> === >>> >>> >>> Just create a new bundle command, and set its output to 'Show as >>> HTML', and you should be good to go. >>> >>> >>> There's a few limitations though - mainly that stderr isn't >>> captured, >>> so any stderr gets dumped at the top of the file , without >>> formatting. This includes the ruby invocation commands (ruby - >>> Ilib "/ >>> usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/ >>> models/ >>> active_user_spec.rb"), and any syntax errors in your specs. I've >>> been trying for the past hour to properly capture stderr and >>> interpolate it into the normal output, without success. popen3 just >>> gives you stdout and stderr as separate objects, with no way of re- >>> joining them up in the order they occurred. >>> So, if anyone has a fix to the stderr problem, or any other >>> additions >>> & improvements, I'd love to see them. >>> >>> >>> _______________________________________________ >>> 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 maillist at steelskies.com Mon Jul 3 11:20:31 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Mon, 3 Jul 2006 16:20:31 +0100 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: <25374F9A-B23C-4D50-B4C8-BC7C171930C2@steelskies.com> References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> <25374F9A-B23C-4D50-B4C8-BC7C171930C2@steelskies.com> Message-ID: <2385AB27-9C45-4360-9CB0-9F39B3CA0E29@steelskies.com> ....and I managed to break the file paths with that last update. So rather than continuing to spam the list with small fixes, I'll just point you to here - http://www.snipplr.com/users/Catfish/ - which should stay up to date with any changes I make. On 3 Jul 2006, at 11:17, Jonathan del Strother wrote: > Ooops. Looks like there's a few path issues with the below script, > and with the recent changes to RubyMate, it fails to find rake in the > path. > > So, take the script, strip off the shebang line (first line), and > move it all to Rails.bundle/Support/bin/spec_helper.rb > Then in TextMate's bundle menu, use this command to load the spec > helper, which will keep your search path intact: > > RUBYLIB="$TM_BUNDLE_SUPPORT/lib:$RUBYLIB" > "${TM_RUBY:=ruby}" -- "${TM_BUNDLE_SUPPORT}/bin/spec_helper.rb" > > > > On 2 Jul 2006, at 13:16, Jonathan del Strother wrote: > >> Feel free to include it, though I suspect it could do with some >> cleaning up - this is my first TextMate plugin and I'm sure I'm >> ignoring all sorts of conventions and useful utility functions... >> >> I've just come up with an updated version: >> >> >> === >> >> #!/usr/bin/env ruby >> require 'cgi' >> >> #try and remove unnecessary '..'s from paths. >> #Eg collapse 'config/../app/controllers/../../public' to 'public'. >> Hopefully. >> def rationalize_path(path) >> components = path.split("/") >> real_components = [] >> components.each do |c| >> if (c == "..") && (real_components.size > 0) && >> (real_components.last != "..") >> real_components.pop >> else >> real_components.push c >> end >> end >> >> File.join(real_components) >> end >> >> >> >> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) >> >> output = `rake spec 2>&1` >> output = CGI.escapeHTML(output) >> >> #rationalize paths (strip out unnecessary '..'s etc) >> output.gsub! /(\.\/|\/)[^:\n]+\.[^:\n]+/ do |m| >> rationalize_path(m) >> end >> >> #Find local file names and make them into proper links >> #It ignores any paths that don't start with './'. >> # (This is a feature, IMO - too many links if you find every single >> path in the output.) >> output.gsub! /\.(\/[^:]+):([\d]+)/ do |m| >> path = Dir.pwd + $1 >> "#{m}" >> end >> >> >> #Find the result lines (x specification(s), y failure(s)) and style >> them >> output.gsub! /^[\d]+ specifications?, [\d]+ failures?/ do |m| >> "#{m}" >> end >> >> #Remove unnecessary repetition of the project path: >> output.gsub! /#{Dir.pwd}\//, './' >> >> >> output.gsub!("\n", "
") >> >> puts <> >> >> rspec results >> >> >> >>

rspec

>> #{output} >> >> >> END >> >> >> == >> >> >> which properly feeds stderr into the output, and makes a few >> attempts to cut down on the amount of unnecessary text - eg >> collapsing paths with '..' in them. Oh, and the rspec results >> get their own style. >> >> >> It's a shame we don't have a proper runner for this yet, to avoid >> setting up the rails environment every time you launch 'rake >> spec'. What happened to rspecRunner? And is it suitable for >> running with rspec on rails? >> >> >> >> >> >> On 2 Jul 2006, at 02:32, aslak hellesoy wrote: >> >>> Hi Jonathan, >>> >>> This is great! I haven't had the chance to try it yet, but I will >>> next week. >>> >>> Would you be ok with us adding it to RSpce's svn? (vendor/textmate - >>> to be distributed as a separate package from the Rspec gem). We'll >>> credit you duly in the docs. >>> >>> Cheers, >>> Aslak >>> >>> On 6/30/06, Jonathan del Strother wrote: >>>> Don't know how many TextMate users we've got here, but: >>>> >>>> I was getting a little tired of tweaking a spec file, swapping to >>>> Terminal, running specs, and swapping back again, so I came up >>>> with a >>>> TextMate command to do this for me. It runs 'rake spec' and >>>> display >>>> the output, complete with clickable links to any files. >>>> >>>> >>>> >>>> === >>>> >>>> #!/usr/bin/env ruby >>>> >>>> def process_for_html(string) >>>> string.gsub!("\n", "
") >>>> >>>> #try to find file names and make them into proper links >>>> string.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >>>> path = Dir.pwd + $1 >>>> "#{m}>>> a>" >>>> end >>>> string >>>> end >>>> >>>> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) >>>> >>>> output = `rake spec` >>>> output.gsub!("\n", "
") >>>> >>>> #try to find file names and make them into proper links >>>> output.gsub! /\.(\/[^:]*):([\d]*)/ do |m| >>>> path = Dir.pwd + $1 >>>> "#{m}" >>>> end >>>> >>>> puts "#{"

rspec>>> h1>"+output}>>> body>" >>>> >>>> >>>> === >>>> >>>> >>>> Just create a new bundle command, and set its output to 'Show as >>>> HTML', and you should be good to go. >>>> >>>> >>>> There's a few limitations though - mainly that stderr isn't >>>> captured, >>>> so any stderr gets dumped at the top of the file , without >>>> formatting. This includes the ruby invocation commands (ruby - >>>> Ilib "/ >>>> usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/ >>>> models/ >>>> active_user_spec.rb"), and any syntax errors in your specs. I've >>>> been trying for the past hour to properly capture stderr and >>>> interpolate it into the normal output, without success. popen3 >>>> just >>>> gives you stdout and stderr as separate objects, with no way of re- >>>> joining them up in the order they occurred. >>>> So, if anyone has a fix to the stderr problem, or any other >>>> additions >>>> & improvements, I'd love to see them. >>>> >>>> >>>> _______________________________________________ >>>> 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2114 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060703/5ac9a13c/attachment.bin From aslak.hellesoy at gmail.com Mon Jul 3 19:40:15 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 3 Jul 2006 18:40:15 -0500 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: <2385AB27-9C45-4360-9CB0-9F39B3CA0E29@steelskies.com> References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> <25374F9A-B23C-4D50-B4C8-BC7C171930C2@steelskies.com> <2385AB27-9C45-4360-9CB0-9F39B3CA0E29@steelskies.com> Message-ID: <8d961d900607031640r4c2f71a0u3611144ee6a48245@mail.gmail.com> On 7/3/06, Jonathan del Strother wrote: > ....and I managed to break the file paths with that last update. So > rather than continuing to spam the list with small fixes, I'll just > point you to here - http://www.snipplr.com/users/Catfish/ - which > should stay up to date with any changes I make. > > > On 3 Jul 2006, at 11:17, Jonathan del Strother wrote: > > > Ooops. Looks like there's a few path issues with the below script, > > and with the recent changes to RubyMate, it fails to find rake in the > > path. > > > > So, take the script, strip off the shebang line (first line), and > > move it all to Rails.bundle/Support/bin/spec_helper.rb > > Then in TextMate's bundle menu, use this command to load the spec > > helper, which will keep your search path intact: > > > > RUBYLIB="$TM_BUNDLE_SUPPORT/lib:$RUBYLIB" > > "${TM_RUBY:=ruby}" -- "${TM_BUNDLE_SUPPORT}/bin/spec_helper.rb" > > > > > > > > On 2 Jul 2006, at 13:16, Jonathan del Strother wrote: > > > >> Feel free to include it, though I suspect it could do with some > >> cleaning up - this is my first TextMate plugin and I'm sure I'm > >> ignoring all sorts of conventions and useful utility functions... > >> > >> I've just come up with an updated version: > >> > >> > >> === > >> > >> #!/usr/bin/env ruby > >> require 'cgi' > >> > >> #try and remove unnecessary '..'s from paths. > >> #Eg collapse 'config/../app/controllers/../../public' to 'public'. > >> Hopefully. > >> def rationalize_path(path) > >> components = path.split("/") > >> real_components = [] > >> components.each do |c| > >> if (c == "..") && (real_components.size > 0) && > >> (real_components.last != "..") > >> real_components.pop > >> else > >> real_components.push c > >> end > >> end > >> > >> File.join(real_components) > >> end > >> > >> > >> > >> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) > >> > >> output = `rake spec 2>&1` > >> output = CGI.escapeHTML(output) > >> > >> #rationalize paths (strip out unnecessary '..'s etc) > >> output.gsub! /(\.\/|\/)[^:\n]+\.[^:\n]+/ do |m| > >> rationalize_path(m) > >> end > >> > >> #Find local file names and make them into proper links > >> #It ignores any paths that don't start with './'. > >> # (This is a feature, IMO - too many links if you find every single > >> path in the output.) > >> output.gsub! /\.(\/[^:]+):([\d]+)/ do |m| > >> path = Dir.pwd + $1 > >> "#{m}" > >> end > >> > >> > >> #Find the result lines (x specification(s), y failure(s)) and style > >> them > >> output.gsub! /^[\d]+ specifications?, [\d]+ failures?/ do |m| > >> "#{m}" > >> end > >> > >> #Remove unnecessary repetition of the project path: > >> output.gsub! /#{Dir.pwd}\//, './' > >> > >> > >> output.gsub!("\n", "
") > >> > >> puts < >> > >> > >> rspec results > >> > >> > >> > >>

rspec

> >> #{output} > >> > >> > >> END > >> > >> > >> == > >> > >> > >> which properly feeds stderr into the output, and makes a few > >> attempts to cut down on the amount of unnecessary text - eg > >> collapsing paths with '..' in them. Oh, and the rspec results > >> get their own style. > >> > >> > >> It's a shame we don't have a proper runner for this yet, to avoid > >> setting up the rails environment every time you launch 'rake > >> spec'. What happened to rspecRunner? And is it suitable for > >> running with rspec on rails? > >> > >> > >> > >> > >> > >> On 2 Jul 2006, at 02:32, aslak hellesoy wrote: > >> > >>> Hi Jonathan, > >>> > >>> This is great! I haven't had the chance to try it yet, but I will > >>> next week. > >>> > >>> Would you be ok with us adding it to RSpce's svn? (vendor/textmate - > >>> to be distributed as a separate package from the Rspec gem). We'll > >>> credit you duly in the docs. > >>> > >>> Cheers, > >>> Aslak > >>> > >>> On 6/30/06, Jonathan del Strother wrote: > >>>> Don't know how many TextMate users we've got here, but: > >>>> > >>>> I was getting a little tired of tweaking a spec file, swapping to > >>>> Terminal, running specs, and swapping back again, so I came up > >>>> with a > >>>> TextMate command to do this for me. It runs 'rake spec' and > >>>> display > >>>> the output, complete with clickable links to any files. > >>>> > >>>> > >>>> > >>>> === > >>>> > >>>> #!/usr/bin/env ruby > >>>> > >>>> def process_for_html(string) > >>>> string.gsub!("\n", "
") > >>>> > >>>> #try to find file names and make them into proper links > >>>> string.gsub! /\.(\/[^:]*):([\d]*)/ do |m| > >>>> path = Dir.pwd + $1 > >>>> "#{m} >>>> a>" > >>>> end > >>>> string > >>>> end > >>>> > >>>> Dir.chdir(ENV['TM_PROJECT_DIRECTORY']) > >>>> > >>>> output = `rake spec` > >>>> output.gsub!("\n", "
") > >>>> > >>>> #try to find file names and make them into proper links > >>>> output.gsub! /\.(\/[^:]*):([\d]*)/ do |m| > >>>> path = Dir.pwd + $1 > >>>> "#{m}" > >>>> end > >>>> > >>>> puts "#{"

rspec >>>> h1>"+output} >>>> body>" > >>>> > >>>> > >>>> === > >>>> > >>>> > >>>> Just create a new bundle command, and set its output to 'Show as > >>>> HTML', and you should be good to go. > >>>> > >>>> > >>>> There's a few limitations though - mainly that stderr isn't > >>>> captured, > >>>> so any stderr gets dumped at the top of the file , without > >>>> formatting. This includes the ruby invocation commands (ruby - > >>>> Ilib "/ > >>>> usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/ > >>>> models/ > >>>> active_user_spec.rb"), and any syntax errors in your specs. I've > >>>> been trying for the past hour to properly capture stderr and > >>>> interpolate it into the normal output, without success. popen3 > >>>> just > >>>> gives you stdout and stderr as separate objects, with no way of re- > >>>> joining them up in the order they occurred. > >>>> So, if anyone has a fix to the stderr problem, or any other > >>>> additions > >>>> & improvements, I'd love to see them. > >>>> I'm a TextMate user, but I have to admit I'm not yet too familiar with bundles. I have a couple of questions and suggestions: 1) How do I install the bundle? Where do I put the file? 2) Would it be possible to decouple it from rake? I'd like to be able to run all specs in a directory (spec dir) or the currently focused context or spec. 3) Would it be possible to decouple it from rails? From what I read it seems it's somewhat rails-dependent. I think it's a good idea to host it on snipplr.com for now. We can always put it in svn when it matures. Aslak > >>>> > >>>> _______________________________________________ > >>>> 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 brianvh at Alum.Dartmouth.ORG Mon Jul 3 19:57:32 2006 From: brianvh at Alum.Dartmouth.ORG (Brian Hughes) Date: Mon, 3 Jul 2006 19:57:32 -0400 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: <8d961d900607031640r4c2f71a0u3611144ee6a48245@mail.gmail.com> References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> <25374F9A-B23C-4D50-B4C8-BC7C171930C2@steelskies.com> <2385AB27-9C45-4360-9CB0-9F39B3CA0E29@steelskies.com> <8d961d900607031640r4c2f71a0u3611144ee6a48245@mail.gmail.com> Message-ID: On Jul 3, 2006, at 07:40 PM, aslak hellesoy wrote: > I'm a TextMate user, but I have to admit I'm not yet too familiar with > bundles. I have a couple of questions and suggestions: > > 1) How do I install the bundle? Where do I put the file? The file goes into your ~/Library/Application Support/TextMate/ Bundles folder. > 2) Would it be possible to decouple it from rake? I'd like to be able > to run all specs in a directory (spec dir) or the currently focused > context or spec. That should be possible. TextMate doesn't specifically know anything about Rake, so that's simply a choice made in the current script. > 3) Would it be possible to decouple it from rails? From what I read it > seems it's somewhat rails-dependent. This could be a bit harder, depending on how the language side of the bundle has been configured. But it's also possible to base the language off the Ruby bundle, rather than the Rails bundle. > I think it's a good idea to host it on snipplr.com for now. We can > always put it in svn when it matures. Hmm... I've never been to snipplr.com. I'll have to check them out... -Brian From dharple at generalconsumption.org Mon Jul 3 21:31:34 2006 From: dharple at generalconsumption.org (Daniel Harple) Date: Mon, 3 Jul 2006 21:31:34 -0400 Subject: [Rspec-devel] TextMate rSpec Bundle Message-ID: Hi, I have put together a small rSpec bundle for TextMate. The main feature is a command to insert the underscores in a should statement. So you type ?foo should be 3? and hit Control-Space, and it will turn into ?foo.should_be 3?, or ?lambda { blah.some_method } should raise SomeError? -> ?lambda { blah.some_method }.should_raise SomeError? Feature Overview: * Command to insert underscores in should statements * Snippets for ?context? (con), ?specify? (spe), and ?should? (s). To install just unzip and double-click the bundle. -------------- next part -------------- A non-text attachment was scrubbed... Name: rSpec.zip Type: application/zip Size: 3496 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060703/baaf6581/attachment-0001.zip -------------- next part -------------- -- Daniel From aslak.hellesoy at gmail.com Mon Jul 3 21:51:15 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 3 Jul 2006 20:51:15 -0500 Subject: [Rspec-devel] TextMate rSpec Bundle In-Reply-To: References: Message-ID: <8d961d900607031851x3de375c4we54e3266fd05331c@mail.gmail.com> sweet. would it make sense to eventualy put this into the bundle developed by jonathan? aslak On 7/3/06, Daniel Harple wrote: > Hi, > > I have put together a small rSpec bundle for TextMate. The main > feature is a command to insert the underscores in a should statement. > So you type "foo should be 3" and hit Control-Space, and it will turn > into "foo.should_be 3", or "lambda { blah.some_method } should raise > SomeError" -> "lambda { blah.some_method }.should_raise SomeError" > > Feature Overview: > * Command to insert underscores in should statements > * Snippets for "context" (con), "specify" (spe), and "should" (s). > > To install just unzip and double-click the bundle. > > > > > -- Daniel > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From sl4mmy at zerosphere.org Mon Jul 3 21:57:13 2006 From: sl4mmy at zerosphere.org (Kent R. Spillner) Date: Mon, 03 Jul 2006 20:57:13 -0500 Subject: [Rspec-devel] TextMate command for RSpec on Rails In-Reply-To: <8d961d900607020017m7f8bc48cs795190ff9bf84b8f@mail.gmail.com> References: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com> <8d961d900607011832m15b33a06m348d551aa0df93e9@mail.gmail.com> <8d961d900607020017m7f8bc48cs795190ff9bf84b8f@mail.gmail.com> Message-ID: <44A9CAF9.1090402@zerosphere.org> Hi, Aslak- aslak hellesoy wrote: > We've thought about encouraging a new naming convention for spec > files. Instead of > > mooky_spec.rb > > you would have > > mooky.spec -1, boo! :) Best, Kent From aslak.hellesoy at gmail.com Mon Jul 3 22:00:08 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 3 Jul 2006 21:00:08 -0500 Subject: [Rspec-devel] run specs FAST with rails_spec Message-ID: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com> In subversion I just added an additional feature to the rails stuff. After doing a 'ruby script/generate rspec' you will have two new files: script/rails_spec script/rails_spec_runner The first one has the same command line interface as the traditional 'spec' command. It talks DRB to a server (script/rails_spec_runner) which runs in the background with a preloaded rails environment. To the TextMate bundle and other IDE hackers out there: Please add an option to run this script/rails_spec command from the editor/IDE for rails project. This will give us FAST specs for rails apps in a more integrated environment. The latest gem doesn't have this code yet, so for now you will have to do a rake package from svn and install the rspec and rspec_generators from your file system. Enjoy! Aslak From lists-rspec at shopwatch.org Tue Jul 4 09:16:07 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Tue, 04 Jul 2006 09:16:07 -0400 Subject: [Rspec-devel] Some handy rails helpers In-Reply-To: References: <44A885AC.3040103@shopwatch.org> Message-ID: <44AA6A17.9020206@rubyforge.org> Luke Redpath wrote: > Hi Jay > > These look really cool, and your post got my thinking. I've always hated > how clunky the assert_tag function that come with Rails is. Wouldn't it > be really cool to have a DSL that merges in with rSpec for testing your > HTML output - kind of like integration tests but I was thinking more > about speccing particular controller actions (under their various > contexts) and their resulting views. Something like this would be really > cool: > > tag('h1', :id => 'pageheader').should_contain('My Great Website') > > Or even better: > > h1(:id => 'pageheader').should_contain('My Great Website') > div(:id => 'somediv').should_have_class_name('hidden') Oh, I like that a lot! And your improved syntax for the should_have_fields helper, too. Unfortunately, I don't know nearly enough Ruby metaprogramming to do them - at least not yet - but perhaps someone else will step up in the mean time... Otherwise, ping me in a few months and we'll see what I've learned. Jay > > And based on your helpers: > > form(:id => 'myform').should_have_fields("name", "email", "username", > "passsword") > > *Luke Redpath* > /Senior Software Engineer/ > > Agile Evolved Limited > *E. *luke at agileevolved.com > *W. *www.agileevolved.com > > > On 3 Jul 2006, at 03:49, Jay Levitt wrote: > >> I've been using these in spec_helper: >> >> class Spec::Runner::ExecutionContext >> def form_should_have_fields(obj, fields) >> for field in fields >> response.body.should_have_tag :tag => "input", >> :attributes => { :name => "#{obj}[#{field}]" } >> end >> end >> end >> >> class Spec::Runner::Context >> def fields_should_start_empty(obj, *fields) >> fields.flatten.each do |f| >> specify "should have an empty #{f} field" do >> eval(obj.id2name + ".#{f}.should.be.nil") >> end >> end >> end >> >> def fields_cant_stay_empty(obj, *fields) >> fields.flatten.each do |f| >> specify "should disallow an empty #{f} field" do >> o = eval(obj.id2name) >> o.send("#{f}=", nil) >> o.should.not.be.valid >> o.errors.on(f).should.equal "can't be blank" >> end >> end >> end >> end >> >> --- >> >> Usage: >> >> in a controller_spec.rb: >> >> specify "get the new receipt form" do >> get 'new' >> response.should.be.success >> response.should_render 'new' >> form_should_have_fields("receipt", ["vendor", "purchased_at"]) >> end >> >> in a model spec.rb, where :valid is a fixture for a valid receipt: >> >> context "A newly created receipt" do >> setup do >> @receipt = Receipt.new >> end >> >> fields_should_start_empty(:@receipt, :vendor, :purchased_at) >> end >> >> context "An otherwise valid receipt" do >> fixtures :receipts >> >> setup do >> @receipt = receipts(:valid) >> end >> >> specify "should start out valid" do >> @receipt.should.be.valid >> end >> >> fields_cant_stay_empty(:@receipt, :vendor, :purchased_at) >> end >> >> _______________________________________________ >> 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 lists-rspec at shopwatch.org Tue Jul 4 09:25:05 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Tue, 04 Jul 2006 09:25:05 -0400 Subject: [Rspec-devel] run specs FAST with rails_spec In-Reply-To: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com> References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com> Message-ID: <44AA6C31.5040703@rubyforge.org> aslak hellesoy wrote: > In subversion I just added an additional feature to the rails stuff. > After doing a 'ruby script/generate rspec' you will have two new > files: This is REALLY exciting! This was my #1 hope for rspec. (#2 is integration testing, now that you're all freed up...) > > The latest gem doesn't have this code yet, so for now you will have to > do a rake package from svn and install the rspec and rspec_generators > from your file system. To spell that out, this seems to be: svn export svn://rubyforge.org//var/svn/rspec/trunk cd rspec/trunk rake package rake package_rails The rspec_generator is cleverly hidden in vendor/rspec_on_rails/vendor/generators/rspec/pkg. I installed both of these, and then installed the two gems. I went back to my app and redid script/generate rspec I then ran the script/rails_spec_runner, and when it said "Ready", I ran "script/rails_spec spec" in another window. The rails_spec_runner complained: /cygdrive/c/dev/src/eclipse/inventory/config/environment.rb:8: warning: already initialized constant RAILS_GEM_VERSION Probably nothing. The tests completed in no time! But then I ran them again, and they all failed, with errors like: FixtureClassNotFound in 'The BBB receipt can handle adding the bunny slippers' The class "Receipt" was not found. /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/fixtures.rb:403:in `find' ./spec/models/receipt_spec.rb:68:in `setup' script/rails_spec_runner:25:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform' /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' script/rails_spec_runner:46 Finished in 0.341 seconds 32 specifications, 32 failures Did I miss a step, or is this a bug with rails_spec_runner's handling of fixtures? > > Enjoy! > > Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Tue Jul 4 10:59:57 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 4 Jul 2006 09:59:57 -0500 Subject: [Rspec-devel] run specs FAST with rails_spec In-Reply-To: <44AA6C31.5040703@rubyforge.org> References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com> <44AA6C31.5040703@rubyforge.org> Message-ID: <8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com> On 7/4/06, Jay Levitt wrote: > aslak hellesoy wrote: > > In subversion I just added an additional feature to the rails stuff. > > After doing a 'ruby script/generate rspec' you will have two new > > files: > > This is REALLY exciting! This was my #1 hope for rspec. (#2 is > integration testing, now that you're all freed up...) > We'll get there, but don't hold your breath for me to do it. It might take some time. But I think it will be easy. Rails has an app() method that gives straight access to most of the integration stuff. > > > > The latest gem doesn't have this code yet, so for now you will have to > > do a rake package from svn and install the rspec and rspec_generators > > from your file system. > > To spell that out, this seems to be: > > svn export svn://rubyforge.org//var/svn/rspec/trunk > cd rspec/trunk > rake package > rake package_rails > > The rspec_generator is cleverly hidden in > vendor/rspec_on_rails/vendor/generators/rspec/pkg. > Thanks for summarizing that Jay. This is the right process. If you just want to hack on the stuff and improve it it's probably better to stand in the demo rails app under vendor/rspec_on_rails. You don't have to build the gem and install it from here. > I installed both of these, and then installed the two gems. I went back > to my app and redid > > script/generate rspec > > I then ran the script/rails_spec_runner, and when it said "Ready", I ran > "script/rails_spec spec" in another window. The rails_spec_runner > complained: > > /cygdrive/c/dev/src/eclipse/inventory/config/environment.rb:8: warning: > already initialized constant RAILS_GEM_VERSION > I updated to the latest Rails version (1.1.4) > Probably nothing. The tests completed in no time! But then I ran them > again, and they all failed, with errors like: > I get a similar error running from the demo app. However it's the model classes that aren't found - not the ficture ones: $ script/rails_spec spec/models/person_spec.rb 1) NameError in 'The Person model should find an existing person' uninitialized constant Person etc..... > FixtureClassNotFound in 'The BBB receipt can handle adding the bunny > slippers' > The class "Receipt" was not found. > /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/fixtures.rb:403:in > `find' > ./spec/models/receipt_spec.rb:68:in `setup' > script/rails_spec_runner:25:in `run' > /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' > /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run' > /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > script/rails_spec_runner:46 > > Finished in 0.341 seconds > > 32 specifications, 32 failures > > Did I miss a step, or is this a bug with rails_spec_runner's handling of > fixtures? > This is definitely a bug, and it's not fixture specific. Nothing works on a second run. I don't know what's causing this yet. And it needs to get fixed! Aslak > > > > Enjoy! > > > > Aslak > > _______________________________________________ > > 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 brian.takita at gmail.com Tue Jul 4 18:01:27 2006 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 4 Jul 2006 15:01:27 -0700 Subject: [Rspec-devel] Rspec/Test::Unit Integration Message-ID: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> Hello, I had a conversation with David at the Rails Conference about integrating Rspec into Test::Unit. I want to start using Rspec at my workplace. We have alot of code in descendants of Test::Unit::TestCase as well as several libraries that extend its behaviour. An obstacle I ran into is the Rspec DSL is an evolutionary improvement over Test::Unit (i.e. you can make the same assertions and format your tests to look like "specs"). This being the case, I don't have a compelling reason to go through the effort to port all of our tests into specs. If Rspec where to user Test::Unit::TestCase to make its assertions, it would be easier to transition into using Rspec from Test::Unit. Anyways, I did a little proof of concept with the patch attached to this email. The example is at the bottom of this email. Rails fixtures would work in this case. Thanks, Brian Takita require File.dirname(__FILE__) + '/../lib/spec' require 'test/unit' class RspecIntegrationTest < Test::Unit::TestCase extend Spec::Runner::SpecTestCase def setup @test_case_setup_called = true end def teardown puts "Test::Unit::TestCase#teardown is called too" end def test_something end def helper_method @helper_method_called = true end context "Rspec should integrate with Test::Unit::TestCase" do setup do @rspec_setup_called = true end specify "TestCase#setup should be called." do @rspec_setup_called.should_be true @test_case_setup_called.should_be true end specify "Rspec should be able to access TestCase methods" do helper_method @helper_method_called.should_be true end end end -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060704/071a3556/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: test_unit_integration.patch Type: text/x-patch Size: 9124 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060704/071a3556/attachment-0001.bin From aslak.hellesoy at gmail.com Tue Jul 4 23:37:50 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 4 Jul 2006 22:37:50 -0500 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> Message-ID: <8d961d900607042037k49b4a0f0r8537d3143af35912@mail.gmail.com> On 7/4/06, Brian Takita wrote: > Hello, > > I had a conversation with David at the Rails Conference about integrating > Rspec into Test::Unit. > > I want to start using Rspec at my workplace. We have alot of code in > descendants of Test::Unit::TestCase as well as several libraries that extend > its behaviour. > An obstacle I ran into is the Rspec DSL is an evolutionary improvement over > Test::Unit (i.e. you can make the same assertions and format your tests to > look like "specs"). This being the case, I don't have a compelling reason to > go through the effort to port all of our tests into specs. > Have you tried test2spec? http://rspec.rubyforge.org/tools/test2spec.html This works fairly well with 'vanilla' Test::Unit. For Rails tests, also see the test2spec tweaks for rails: http://rspec.rubyforge.org/tools/rails.html > If Rspec where to user Test::Unit::TestCase to make its assertions, it would > be easier to transition into using Rspec from Test::Unit. > > Anyways, I did a little proof of concept with the patch attached to this > email. > The example is at the bottom of this email. Rails fixtures would work in > this case. > Rails fixtures also work with RSpec on Rails. >From what I understand this patch allows you to use contexts inside Test::Unit::TestCase classes. Are you trying to work on existing Test::Unit::TestCase classes and keep them a mix of both test methods and contexts/specs? If you really want to stick to the Test::Unit structure, how about this: require 'test/unit' require 'spec' class MyTest < Test::Unit::TestCase def test_should_allow_shoulds_in_tests (1+2).should_equal 3 end end My point here is that using context and specify inside a Test::Unit::TestCase doesn't really buy you that much. Sure, the context/specify DSL looks nice, but the real value of this DSL (IMO) is the integration with the spec command line and the ability to output specdocs with --format specdoc. When things are inside a Test::Unit::TestCase you still have to use the Test::Unit runner, and you won't get the spec commandline goodies. The second value - being able to do myobject.should_* is easily achievable as shown in the example above. Or am I missing something? Cheers, Aslak > Thanks, > Brian Takita > > require File.dirname(__FILE__) + '/../lib/spec' > require 'test/unit' > > class RspecIntegrationTest < Test::Unit::TestCase > extend Spec::Runner::SpecTestCase > > def setup > @test_case_setup_called = true > end > > def teardown > puts "Test::Unit::TestCase#teardown is called too" > end > > def test_something > end > > def helper_method > @helper_method_called = true > end > > context "Rspec should integrate with Test::Unit::TestCase" do > setup do > @rspec_setup_called = true > end > specify "TestCase#setup should be called." do > @rspec_setup_called.should_be true > @test_case_setup_called.should_be true > end > > specify "Rspec should be able to access TestCase methods" do > helper_method > @helper_method_called.should_be true > end > end > end > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From srbaker at pobox.com Tue Jul 4 20:07:18 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Tue, 4 Jul 2006 17:07:18 -0700 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> Message-ID: <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> > I had a conversation with David at the Rails Conference about > integrating Rspec into Test::Unit [snip] > If Rspec where to user Test::Unit::TestCase to make its assertions, > it would be easier to transition into using Rspec from Test::Unit. This is a very interesting point; David and I discussed this at RailsConf as well. I would have liked to meet you at RailsConf, but I wasn't aware of your attendance. (If we did cross paths in the confusion, accept my apologies.) Be sure to track me down at the next one! Ironically, the first version of RSpec was a wrapper around Test::Unit, as you demonstrate. It started life in this way, and I find it amusing that people keep requesting that it wrap Test::Unit as a new feature. (I don't remember why I changed this behaviour, but there are many good reasons to have done so.) It's time for discussion. This is not the first, nor less than the fifth, time this has come up that I am aware of. It also came up at least twice on the Argon Express. An additional benefit of Test::Unit wrappage is that the existing tools for Test::Unit will Just Work. This includes the rake tasks, Eclipse plugins, TDDmate, etc, as well as Rails integration, autotest, and any other tools that are dependent on Test::Unit. However... The main thing we're doing with BDD is changing the language. Specifically, removing the test-laden vocabulary from what we're actually practicing (and preaching). Wrapping "testing" frameworks so that we can use "testing tools" is probably not a good way to spread the word. Additionally, RSpec is quite a bit faster, and significantly less code than Test::Unit. I consider this to be a feature, as well. I'm not sure that deliberate incompatibility with Test::Unit is a good way to proceed, but I'm also not sure that building on top of what we're essentially replacing is necessarily better. I don't really have a strong opinion in either direction on this issue, though: I see both sides. Since I'm not particularly partial to one side or the other, it should go up for discussion. RSpec has never been about evangelizing BDD. From the beginning, it has been about enabling BDD. A framework is no place for evangelism: it's a place for enablement. Specifically, I want to know what the people who are using RSpec every day (or often, at least) would like to see. Thoughts? -Steven From brasten at nagilum.com Wed Jul 5 15:07:55 2006 From: brasten at nagilum.com (Brasten Sager) Date: Wed, 5 Jul 2006 12:07:55 -0700 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> Message-ID: > Specifically, I want to know what the people who are using RSpec > every day (or often, at least) would like to see. > Thoughts? I use RSpec on Rails every day. I'm using it on two projects in development right now, and in a couple others that have since been delivered to clients to put into production. I submitted a patch and a lengthy description to this list about 3 weeks ago regarding some changes I think would be useful (I continue to improve on them and use them daily), but there was no discussion. So since you're asking, I'll again raise the patch I submitted for discussion. Below are links to the original posts. Thanks! -Brasten http://rubyforge.org/pipermail/rspec-devel/2006-June/000241.html http://rubyforge.org/pipermail/rspec-devel/2006-June/000246.html From nicksieger at gmail.com Wed Jul 5 23:53:53 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 5 Jul 2006 22:53:53 -0500 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> Message-ID: On 7/4/06, Steven R. Baker wrote: > > > I had a conversation with David at the Rails Conference about > > integrating Rspec into Test::Unit > > [snip] > > > If Rspec where to user Test::Unit::TestCase to make its assertions, > > it would be easier to transition into using Rspec from Test::Unit. > > This is a very interesting point; David and I discussed this at > RailsConf as well. I would have liked to meet you at RailsConf, but > I wasn't aware of your attendance. (If we did cross paths in the > confusion, accept my apologies.) Be sure to track me down at the > next one! I half-participated/eavesdropped in a conversation with Aslak and another fellow (sorry didn't catch your name!) after Aslak's lightning talk on this subject also -- don't know if it was the same conversation or not. First a disclaimer -- I have not used Rspec regularly yet, but have known about it, and being a developer-testing advocate for a while, having used and promoted the ideas espoused by tools like agiledox, I feel like I *got* it pretty quickly after seeing Aslak's demo. My idea for Test::Unit integration is this: don't touch the spec DSL itself, instead enable a mode (perhaps the default?) where executing a spec generates and runs a subclass of Test::Unit instead. This in theory would allow you to mix "should" behavior specs with assertions inside of a "specify" block. The code to do this is pretty simple: | require 'spec/version' | require 'spec/api' | require 'spec/runner' | require 'test/unit' | | module Spec | module Runner | TEST_CLASSES = [] | class TestunitContext < Context | def initialize(name, &context_block) | @test_class = Class.new(Test::Unit::TestCase) | super | TEST_CLASSES << @test_class | end | | def setup(&block) | @test_class.send(:define_method, :setup, &block) | end | | def teardown(&block) | @test_class.send(:define_method, :teardown, &block) | end | | def specify(spec_name, &block) | @test_class.send(:define_method, "test #{spec_name}".to_sym, &block) | end | end | end | end | | module Kernel | def context(name, &block) | Spec::Runner::TestunitContext.new(name, &block) | end | end By putting this code in a file called 'specunit.rb' (also attached) in your load path and requiring it instead of 'spec' in the file containing your specs, I get Test::Unit execution: ruby stack_spec.rb Loaded suite stack_spec Started .................. Finished in 0.006394 seconds. 18 tests, 0 assertions, 0 failures, 0 errors Again, I'm new to the list, so apologies if this sort of thing has been proposed before. Cheers, /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060705/89a9291f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: specunit.rb Type: application/octet-stream Size: 828 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060705/89a9291f/attachment.obj From brian.takita at gmail.com Thu Jul 6 03:01:59 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 6 Jul 2006 00:01:59 -0700 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> Message-ID: <1d7ddd110607060001y544d690atf5bcbfc2e8e11bed@mail.gmail.com> > > An additional benefit of Test::Unit wrappage is that the existing > tools for Test::Unit will Just Work. This includes the rake tasks, > Eclipse plugins, TDDmate, etc, as well as Rails integration, > autotest, and any other tools that are dependent on Test::Unit. I'm not sure that deliberate incompatibility with Test::Unit is a > good way to proceed, but I'm also not sure that building on top of > what we're essentially replacing is necessarily better. > I think wrapping Test::Unit is the "pragmatic" way to transition into Rspec in certain situations. Old habits die hard and culture is hard to influence. It seems injecting specs in place of tests that should be specs are a gentler way to introduce Rspec. But yes, you do have something that does need differentiation from Test::Unit and it seems easy enough to be labeled "just another testing framework". The main thing we're doing with BDD is changing the language. > Specifically, removing the test-laden vocabulary from what we're > actually practicing (and preaching). Wrapping "testing" frameworks > so that we can use "testing tools" is probably not a good way to > spread the word. Additionally, RSpec is quite a bit faster, and > significantly less code than Test::Unit. I consider this to be a > feature, as well. > Thanks for explaining (again) the reasons why you moved in this direction. Are tests and specs mutually exclusive? If not, when would one want to use specs vs using tests and vice versa? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060706/ac4a03e5/attachment.html From dchelimsky at gmail.com Thu Jul 6 09:24:21 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 6 Jul 2006 08:24:21 -0500 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> Message-ID: <57c63afe0607060624v77bb79aen9c83c337a3edaad6@mail.gmail.com> On 7/5/06, Nick Sieger wrote: > My idea for Test::Unit integration is this: don't touch the spec DSL > itself, instead enable a mode (perhaps the default?) where executing a spec > generates and runs a subclass of Test::Unit instead. This in theory would > allow you to mix "should" behavior specs with assertions inside of a > "specify" block. The code to do this is pretty simple: > > | require 'spec/version' > | require 'spec/api' > | require 'spec/runner' > | require 'test/unit' > | > | module Spec > | module Runner > | TEST_CLASSES = [] > | class TestunitContext < Context > | def initialize(name, &context_block) > | @test_class = Class.new(Test::Unit::TestCase) > | super > | TEST_CLASSES << @test_class > | end > | > | def setup(&block) > | @test_class.send(:define_method, :setup, &block) > | end > | > | def teardown(&block) > | @test_class.send(:define_method, :teardown, > &block) > | end > | > | def specify(spec_name, &block) > | @test_class.send(:define_method, "test > #{spec_name}".to_sym, &block) > | end > | end > | end > | end > | > | module Kernel > | def context(name, &block) > | Spec::Runner:: TestunitContext.new(name, &block) > | end > | end > > By putting this code in a file called 'specunit.rb' (also attached) in your > load path and requiring it instead of 'spec' in the file containing your > specs, I get Test::Unit execution: > > ruby stack_spec.rb > Loaded suite stack_spec > Started > .................. > Finished in 0.006394 seconds. > > 18 tests, 0 assertions, 0 failures, 0 errors > > Again, I'm new to the list, so apologies if this sort of thing has been > proposed before. > > Cheers, > /Nick Nick - haven't had a chance to try this, but if it's that simple and works that cleanly I'm all for it. Thanks for the contribution. I've been using the expectation syntax (subject.should...) in some Test::Unit tests on a rails project I'm working on and mixing that in w/ test/unit does work quite nicely. Though Aslak is correct to point out that this violates our goal of changing the language and is also slower than just running specs. Cheers, David From dchelimsky at gmail.com Thu Jul 6 09:27:27 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 6 Jul 2006 08:27:27 -0500 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <1d7ddd110607060001y544d690atf5bcbfc2e8e11bed@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> <1d7ddd110607060001y544d690atf5bcbfc2e8e11bed@mail.gmail.com> Message-ID: <57c63afe0607060627s788dfbabg2fe0122ecdfa46a1@mail.gmail.com> On 7/6/06, Brian Takita wrote: > Are tests and specs mutually exclusive? Apparently not. > If not, when would one want to use specs vs using tests and vice versa? I think mixing them is confusing. Ideally, I want to move towards all specs, all the time. But if comingling tests and specs gets me there gradually, that's fine w/ me as a temporary measure. For example, right now the rails plugin doesn't do everything I want it to do, so I'm using test/unit but mixing in rspec expectation syntax. It's a step. From brian.takita at gmail.com Thu Jul 6 12:07:52 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 6 Jul 2006 09:07:52 -0700 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <57c63afe0607060627s788dfbabg2fe0122ecdfa46a1@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> <1d7ddd110607060001y544d690atf5bcbfc2e8e11bed@mail.gmail.com> <57c63afe0607060627s788dfbabg2fe0122ecdfa46a1@mail.gmail.com> Message-ID: <1d7ddd110607060907t3f626ba0sefeb5312b5c68be9@mail.gmail.com> > > Ideally, I want to move towards all > specs, all the time. But if comingling tests and specs gets me there > gradually, that's fine w/ me as a temporary measure. I slept on this a little bit. In the patch, I am still (or at least intent on) using the ContextRunner, thus using the Rspec framework. A new class the extended the TestCase was created, as well as extending it with the ContextMethods module and including the ExecutionContextMethods module. I extracted the methods of Context and ExecutionContext into the modules. This gives access to the setup and teardown methods in TestCase. So bascially, the instance of the TestCase subclass became the ExecutionContext. ExecutionContext by itself seems very clean (not many methods). If Rspec can provide a hook to extend it, then you can use other libraries inside the your specs. Something like context "Integrating with Test::Unit" < Test::Unit::TestCase do end or context "Integrating with Test::Unit" do inherit Test::Unit::TestCase end perhaps? It's unfortunate that TestCases are not easily extendable. On 7/6/06, David Chelimsky wrote: > > On 7/6/06, Brian Takita wrote: > > Are tests and specs mutually exclusive? > > Apparently not. > > > If not, when would one want to use specs vs using tests and vice versa? > > I think mixing them is confusing. Ideally, I want to move towards all > specs, all the time. But if comingling tests and specs gets me there > gradually, that's fine w/ me as a temporary measure. For example, > right now the rails plugin doesn't do everything I want it to do, so > I'm using test/unit but mixing in rspec expectation syntax. It's a > step. > _______________________________________________ > 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/20060706/177a8d31/attachment.html From nicksieger at gmail.com Thu Jul 6 12:36:04 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Thu, 6 Jul 2006 11:36:04 -0500 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <57c63afe0607060624v77bb79aen9c83c337a3edaad6@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <0D437F1F-88B1-4B12-95C3-646725230074@pobox.com> <57c63afe0607060624v77bb79aen9c83c337a3edaad6@mail.gmail.com> Message-ID: On 7/6/06, David Chelimsky wrote: > > Nick - haven't had a chance to try this, but if it's that simple and > works that cleanly I'm all for it. Thanks for the contribution. Well, it's a start at least. I've only tried it with the stack_spec as a proof-of-concept. It didn't include the methods from Spec::Runner::ExecutionContext. Attached is one that does, and verifies any mocks in the tear down of the test. It now can run all the example specs. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060706/83281372/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: specunit.rb Type: application/octet-stream Size: 1557 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060706/83281372/attachment.obj From brian.takita at gmail.com Fri Jul 7 00:52:40 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 6 Jul 2006 21:52:40 -0700 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <8d961d900607042037k49b4a0f0r8537d3143af35912@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <8d961d900607042037k49b4a0f0r8537d3143af35912@mail.gmail.com> Message-ID: <1d7ddd110607062152q19658262r7f398a70d8a6630a@mail.gmail.com> > > Have you tried test2spec? > http://rspec.rubyforge.org/tools/test2spec.html I have not tried test2spec yet. It does look interesting. It looks like it does its job very well. I would like to introduce it to my workplace, but going around and converting all of our tests into specs seems heavy handed. We could have a pilot project, but it would be nice to just have it work within the context of our existing tests and libraries. I was also looking at the converted test and defining helper methods inside setup seems a bit unintuitive. It seems strange to have to define your methods inside of the setup block. Can it be done inside context instead? When things are inside a Test::Unit::TestCase you still have to use > the Test::Unit runner, and you won't get the spec commandline goodies. I'm not too familiar with the command line tools you have now, but they do look interesting. These tools do seem like a very strong feature. Pardon me if I'm missing the point, but the tools can read contexts defined inside a Test::Unit::TestCase by only parsing the file. Rails fixtures also work with RSpec on Rails. Unfortunetely it appears that you needed to duplicate code. If you want to do integration tests, you would need to hook it into RSpec, and the same goes for Selenium tests. >From what I understand this patch allows you to use contexts inside > Test::Unit::TestCase classes. > > Are you trying to work on existing Test::Unit::TestCase classes and > keep them a mix of both test methods and contexts/specs? Probably not. It's just a proof of concept. I'll email you another patch with a "better" syntax. If you really want to stick to the Test::Unit structure, how about this: > > require 'test/unit' > require 'spec' > > class MyTest < Test::Unit::TestCase > def test_should_allow_shoulds_in_tests > (1+2).should_equal 3 > end > end Thats cool. I'm glad you pointed that out. My point here is that using context and specify inside a > Test::Unit::TestCase doesn't really buy you that much. Sure, the > context/specify DSL looks nice, but the real value of this DSL (IMO) > is the integration with the spec command line and the ability to > output specdocs with --format specdoc. > When things are inside a Test::Unit::TestCase you still have to use > the Test::Unit runner, and you won't get the spec commandline goodies. Actually it does call runner.add_context(context). This makes it supportable by the tools, right? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060706/96bc62d4/attachment.html From aslak.hellesoy at gmail.com Fri Jul 7 01:34:30 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 7 Jul 2006 00:34:30 -0500 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <1d7ddd110607062152q19658262r7f398a70d8a6630a@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <8d961d900607042037k49b4a0f0r8537d3143af35912@mail.gmail.com> <1d7ddd110607062152q19658262r7f398a70d8a6630a@mail.gmail.com> Message-ID: <8d961d900607062234r55707ea9ia454f35f30669fd0@mail.gmail.com> On 7/6/06, Brian Takita wrote: > > > > Have you tried test2spec? > > http://rspec.rubyforge.org/tools/test2spec.html > > > I have not tried test2spec yet. It does look interesting. It looks like it > does its job very well. > I would like to introduce it to my workplace, but going around and > converting all of our tests into specs seems heavy handed. We could have a > pilot project, but it would be nice to just have it work within the context > of our existing tests and libraries. > > I was also looking at the converted test and defining helper methods inside > setup seems a bit unintuitive. > It seems strange to have to define your methods inside of the setup block. > Can it be done inside context instead? > Currently not. Every spec runs in the context of a new instance of ExecutionContext, and in order to be able to call any helper methods, they also have to be defined on the current execution context object - which is why it has to be done in setup. If you have a lot of helper methods in your specs that's a smell of complexity, so as long as things are not smelly, I think a couple or three helpers in setup is ok. > > When things are inside a Test::Unit::TestCase you still have to use > > the Test::Unit runner, and you won't get the spec commandline goodies. > > > I'm not too familiar with the command line tools you have now, but they do > look interesting. These tools do seem like a very strong feature. > Pardon me if I'm missing the point, but the tools can read contexts defined > inside a Test::Unit::TestCase by only parsing the file. > > > Rails fixtures also work with RSpec on Rails. > > > Unfortunetely it appears that you needed to duplicate code. If you want to > do integration tests, you would need to hook it into RSpec, and the same > goes for Selenium tests. > Integration test support in RSpec on Rails is high on the priority list. I'd recommend using rails integration tests OR selenium/watir, but not both. They sort of cover the same thing. > > > >From what I understand this patch allows you to use contexts inside > > Test::Unit::TestCase classes. > > > > Are you trying to work on existing Test::Unit::TestCase classes and > > keep them a mix of both test methods and contexts/specs? > > > Probably not. It's just a proof of concept. I'll email you another patch > with a "better" syntax. > > > If you really want to stick to the Test::Unit structure, how about this: > > > > require 'test/unit' > > require 'spec' > > > > class MyTest < Test::Unit::TestCase > > def test_should_allow_shoulds_in_tests > > (1+2).should_equal 3 > > end > > end > > > Thats cool. I'm glad you pointed that out. > If you're stuck with Test::Unit, why not just use Test::Unit? (possibly with should_* as shown above). I still don't see the benefits of being able to use the context and specify keywords inside Test::Unit classes. How is this better than 'pure' Test::Unit? I hear the 'smooth migration path' argument, but in order to be a migration path I'd assume that some time down the road it would lead to a RSpec-only codebase. But I don't see how this solution is leading to that. I don't mean to be negative - I just don't get it (yet) ;-) Aslak > > My point here is that using context and specify inside a > > Test::Unit::TestCase doesn't really buy you that much. Sure, the > > context/specify DSL looks nice, but the real value of this DSL (IMO) > > is the integration with the spec command line and the ability to > > output specdocs with --format specdoc. > > When things are inside a Test::Unit::TestCase you still have to use > > the Test::Unit runner, and you won't get the spec commandline goodies. > > > Actually it does call runner.add_context(context). This makes it supportable > by the tools, right? > > Thanks, > Brian > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From brian.takita at gmail.com Fri Jul 7 02:27:16 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 6 Jul 2006 23:27:16 -0700 Subject: [Rspec-devel] RSpec Extension Patch Message-ID: <1d7ddd110607062327h7cd8dc2bi43f3454d345748d@mail.gmail.com> Hello, Based off of the great feedback from the Test::Unit Integration thread, I came up with a new patch that I think will be more useful. I added the following methods, with tests!!! - inherit - include With inherit, you now get most of the "power" of the superclass. You can use the class methods Now this is possible... ---------------------------------------- require File.dirname(__FILE__) + '/../lib/spec' require 'test/unit' class RspecIntegrationTest < Test::Unit::TestCase def self.a_class_method puts "a_class_method called" end def self.fixtures(*args) puts "we can do fixtures too..." end def setup @test_case_setup_called = true end def teardown puts "Test::Unit::TestCase#teardown is called too" end def run(result) end def helper_method @helper_method_called = true end end module RandomHelperModule def random_task @random_task_called = true end end context "Rspec should integrate with Test::Unit::TestCase" do inherit RspecIntegrationTest a_class_method fixtures :some_table include RandomHelperModule setup do @rspec_setup_called = true end specify "TestCase#setup should be called." do @test_case_setup_called.should_be true @rspec_setup_called.should_be true end specify "Rspec should be able to access TestCase methods" do helper_method @helper_method_called.should_be true end specify "Rspec should be able to accept included modules" do random_task @random_task_called.should_be true end end ----------------------------------------------- I havn't tried it, but adding integration tests should be as easy as... ------------------------------------ context "Rspec should play with Integration Tests" do inherit ActionController::IntegrationTest end ------------------------------------ If this doesn't work right now, it doesn't seem like too much more effort to implement. Thanks, Brian Takita -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060706/34c15c04/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: extension.patch Type: text/x-patch Size: 12849 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060706/34c15c04/attachment-0001.bin From brian.takita at gmail.com Fri Jul 7 02:35:14 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 6 Jul 2006 23:35:14 -0700 Subject: [Rspec-devel] Rspec/Test::Unit Integration In-Reply-To: <8d961d900607062234r55707ea9ia454f35f30669fd0@mail.gmail.com> References: <1d7ddd110607041501x46248d63j51bc2eb46568d78d@mail.gmail.com> <8d961d900607042037k49b4a0f0r8537d3143af35912@mail.gmail.com> <1d7ddd110607062152q19658262r7f398a70d8a6630a@mail.gmail.com> <8d961d900607062234r55707ea9ia454f35f30669fd0@mail.gmail.com> Message-ID: <1d7ddd110607062335g29bc7a62we7f204508075fdc9@mail.gmail.com> > > Integration test support in RSpec on Rails is high on the priority list. > I'd recommend using rails integration tests OR selenium/watir, but not > both. They sort of cover the same thing. > You get more coverage with selenium/watir, particularly if you are doing alot of custom javascript. I assume Rails Integration Tests (I havn't used it myself), is faster to run than selenium, however. I bet the tests are also easier to write. If you have a lot of helper methods in your specs that's a smell of > complexity, so as long as things are not smelly, I think a couple or > three helpers in setup is ok. > My kneejerk reaction is not to agree with you here. Helper methods seems modular and is a powerful tool against duplication. I still don't see the benefits of being able to use the context and > specify keywords inside Test::Unit classes. How is this better than > 'pure' Test::Unit? I agree. I've been converted. :) Please see the thread RSpec Extension Patch. Thanks, Brian Takita On 7/6/06, aslak hellesoy wrote: > > On 7/6/06, Brian Takita wrote: > > > > > > > Have you tried test2spec? > > > http://rspec.rubyforge.org/tools/test2spec.html > > > > > > I have not tried test2spec yet. It does look interesting. It looks like > it > > does its job very well. > > I would like to introduce it to my workplace, but going around and > > converting all of our tests into specs seems heavy handed. We could have > a > > pilot project, but it would be nice to just have it work within the > context > > of our existing tests and libraries. > > > > I was also looking at the converted test and defining helper methods > inside > > setup seems a bit unintuitive. > > It seems strange to have to define your methods inside of the setup > block. > > Can it be done inside context instead? > > > > Currently not. Every spec runs in the context of a new instance of > ExecutionContext, and in order to be able to call any helper methods, > they also have to be defined on the current execution context object - > which is why it has to be done in setup. > > If you have a lot of helper methods in your specs that's a smell of > complexity, so as long as things are not smelly, I think a couple or > three helpers in setup is ok. > > > > When things are inside a Test::Unit::TestCase you still have to use > > > the Test::Unit runner, and you won't get the spec commandline goodies. > > > > > > I'm not too familiar with the command line tools you have now, but they > do > > look interesting. These tools do seem like a very strong feature. > > Pardon me if I'm missing the point, but the tools can read contexts > defined > > inside a Test::Unit::TestCase by only parsing the file. > > > > > Rails fixtures also work with RSpec on Rails. > > > > > > Unfortunetely it appears that you needed to duplicate code. If you want > to > > do integration tests, you would need to hook it into RSpec, and the same > > goes for Selenium tests. > > > > Integration test support in RSpec on Rails is high on the priority list. > I'd recommend using rails integration tests OR selenium/watir, but not > both. They sort of cover the same thing. > > > > > > >From what I understand this patch allows you to use contexts inside > > > Test::Unit::TestCase classes. > > > > > > Are you trying to work on existing Test::Unit::TestCase classes and > > > keep them a mix of both test methods and contexts/specs? > > > > > > Probably not. It's just a proof of concept. I'll email you another patch > > with a "better" syntax. > > > > > If you really want to stick to the Test::Unit structure, how about > this: > > > > > > require 'test/unit' > > > require 'spec' > > > > > > class MyTest < Test::Unit::TestCase > > > def test_should_allow_shoulds_in_tests > > > (1+2).should_equal 3 > > > end > > > end > > > > > > Thats cool. I'm glad you pointed that out. > > > > If you're stuck with Test::Unit, why not just use Test::Unit? > (possibly with should_* as shown above). > > I still don't see the benefits of being able to use the context and > specify keywords inside Test::Unit classes. How is this better than > 'pure' Test::Unit? > > I hear the 'smooth migration path' argument, but in order to be a > migration path I'd assume that some time down the road it would lead > to a RSpec-only codebase. But I don't see how this solution is leading > to that. > > I don't mean to be negative - I just don't get it (yet) ;-) > > Aslak > > > > My point here is that using context and specify inside a > > > Test::Unit::TestCase doesn't really buy you that much. Sure, the > > > context/specify DSL looks nice, but the real value of this DSL (IMO) > > > is the integration with the spec command line and the ability to > > > output specdocs with --format specdoc. > > > When things are inside a Test::Unit::TestCase you still have to use > > > the Test::Unit runner, and you won't get the spec commandline goodies. > > > > > > Actually it does call runner.add_context(context). This makes it > supportable > > by the tools, right? > > > > Thanks, > > Brian > > > > _______________________________________________ > > 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/20060706/54e43650/attachment.html From aslak.hellesoy at gmail.com Fri Jul 7 02:49:40 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 7 Jul 2006 01:49:40 -0500 Subject: [Rspec-devel] RSpec Extension Patch In-Reply-To: <1d7ddd110607062327h7cd8dc2bi43f3454d345748d@mail.gmail.com> References: <1d7ddd110607062327h7cd8dc2bi43f3454d345748d@mail.gmail.com> Message-ID: <8d961d900607062349k4712aec6gab3dca874773b537@mail.gmail.com> On 7/7/06, Brian Takita wrote: > Hello, > > Based off of the great feedback from the Test::Unit Integration thread, I > came up with a new patch that I think will be more useful. > I added the following methods, with tests!!! > > inherit > includeWith inherit, you now get most of the "power" of the superclass. You > can use the class methods > > Now this is possible... > ---------------------------------------- > require File.dirname(__FILE__) + '/../lib/spec' > require 'test/unit' > > class RspecIntegrationTest < Test::Unit::TestCase > def self.a_class_method > puts "a_class_method called" > end > > def self.fixtures(*args) > puts "we can do fixtures too..." > end > > def setup > @test_case_setup_called = true > end > > def teardown > puts "Test::Unit::TestCase#teardown is called too" > end > > def run(result) > end > > def helper_method > @helper_method_called = true > end > end > > module RandomHelperModule > def random_task > @random_task_called = true > end > end > > context "Rspec should integrate with Test::Unit::TestCase" do > inherit RspecIntegrationTest > a_class_method > fixtures :some_table > include RandomHelperModule > > setup do > @rspec_setup_called = true > end > specify "TestCase#setup should be called." do > @test_case_setup_called.should_be true > @rspec_setup_called.should_be true > end > > specify "Rspec should be able to access TestCase methods" do > helper_method > @helper_method_called.should_be true > end > > specify "Rspec should be able to accept included modules" do > random_task > @random_task_called.should_be true > end > end > > ----------------------------------------------- > > I havn't tried it, but adding integration tests should be as easy as... > ------------------------------------ > context "Rspec should play with Integration Tests" do > inherit ActionController::IntegrationTest > end > ------------------------------------ > If this doesn't work right now, it doesn't seem like too much more effort to > implement. > Now, all of this looks really interesting!! If this solves the 'ouch we have to reimplement all of that rails testing stuff' problem it would be fantastic! Could you please create a patch in the issue tracker on rubyforge? Looking forward to playing more with this stuff! Cheers, Aslak > Thanks, > Brian Takita > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From brian.takita at gmail.com Fri Jul 7 11:36:48 2006 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 7 Jul 2006 08:36:48 -0700 Subject: [Rspec-devel] RSpec Extension Patch In-Reply-To: <8d961d900607062349k4712aec6gab3dca874773b537@mail.gmail.com> References: <1d7ddd110607062327h7cd8dc2bi43f3454d345748d@mail.gmail.com> <8d961d900607062349k4712aec6gab3dca874773b537@mail.gmail.com> Message-ID: <1d7ddd110607070836u32525672h658de5af0dc1611b@mail.gmail.com> Done. Its at http://rubyforge.org/tracker/index.php?func=detail&aid=4971&group_id=797&atid=3151 On 7/6/06, aslak hellesoy wrote: > > On 7/7/06, Brian Takita wrote: > > Hello, > > > > Based off of the great feedback from the Test::Unit Integration thread, > I > > came up with a new patch that I think will be more useful. > > I added the following methods, with tests!!! > > > > inherit > > includeWith inherit, you now get most of the "power" of the superclass. > You > > can use the class methods > > > > Now this is possible... > > ---------------------------------------- > > require File.dirname(__FILE__) + '/../lib/spec' > > require 'test/unit' > > > > class RspecIntegrationTest < Test::Unit::TestCase > > def self.a_class_method > > puts "a_class_method called" > > end > > > > def self.fixtures(*args) > > puts "we can do fixtures too..." > > end > > > > def setup > > @test_case_setup_called = true > > end > > > > def teardown > > puts "Test::Unit::TestCase#teardown is called too" > > end > > > > def run(result) > > end > > > > def helper_method > > @helper_method_called = true > > end > > end > > > > module RandomHelperModule > > def random_task > > @random_task_called = true > > end > > end > > > > context "Rspec should integrate with Test::Unit::TestCase" do > > inherit RspecIntegrationTest > > a_class_method > > fixtures :some_table > > include RandomHelperModule > > > > setup do > > @rspec_setup_called = true > > end > > specify "TestCase#setup should be called." do > > @test_case_setup_called.should_be true > > @rspec_setup_called.should_be true > > end > > > > specify "Rspec should be able to access TestCase methods" do > > helper_method > > @helper_method_called.should_be true > > end > > > > specify "Rspec should be able to accept included modules" do > > random_task > > @random_task_called.should_be true > > end > > end > > > > ----------------------------------------------- > > > > I havn't tried it, but adding integration tests should be as easy as... > > ------------------------------------ > > context "Rspec should play with Integration Tests" do > > inherit ActionController::IntegrationTest > > end > > ------------------------------------ > > If this doesn't work right now, it doesn't seem like too much more > effort to > > implement. > > > > Now, all of this looks really interesting!! > If this solves the 'ouch we have to reimplement all of that rails > testing stuff' problem it would be fantastic! > > Could you please create a patch in the issue tracker on rubyforge? > > Looking forward to playing more with this stuff! > > Cheers, > Aslak > > > Thanks, > > Brian Takita > > > > _______________________________________________ > > 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/20060707/ef53178d/attachment.html From luke at agileevolved.com Fri Jul 7 12:55:23 2006 From: luke at agileevolved.com (Luke Redpath) Date: Fri, 7 Jul 2006 17:55:23 +0100 Subject: [Rspec-devel] Rails controller testing/view testing Message-ID: Hi Guys I was wondering how integration of Rails' controller testing features into rSpec is coming along. I posted a suggestion on here the other day based on something Jay Levitt mentioned for testing your views without using something like the horrible assert_tag functionality. I've put something together that works with Test::Unit using _why's new Hpricot HTML parser library and I'd be interested on ideas for working this into rSpec for Rails view/controller testing. I'm not really familiar with rSpec under the hood yet and have only used it for non-Rails stuff so far. Here's what I've got so far: http://www.lukeredpath.co.uk/index.php/2006/07/07/testing-your-rails- views-with-hpricot/ Cheers Luke Redpath www.lukeredpath.co.uk From aslak.hellesoy at gmail.com Sat Jul 8 12:03:18 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 8 Jul 2006 11:03:18 -0500 Subject: [Rspec-devel] RSpec Extension Patch In-Reply-To: <1d7ddd110607070836u32525672h658de5af0dc1611b@mail.gmail.com> References: <1d7ddd110607062327h7cd8dc2bi43f3454d345748d@mail.gmail.com> <8d961d900607062349k4712aec6gab3dca874773b537@mail.gmail.com> <1d7ddd110607070836u32525672h658de5af0dc1611b@mail.gmail.com> Message-ID: <8d961d900607080903r65c4e439pddf008c84cda6b1b@mail.gmail.com> On 7/7/06, Brian Takita wrote: > Done. > > Its at > http://rubyforge.org/tracker/index.php?func=detail&aid=4971&group_id=797&atid=3151 > Committed! Aslak > > On 7/6/06, aslak hellesoy wrote: > > On 7/7/06, Brian Takita wrote: > > > Hello, > > > > > > Based off of the great feedback from the Test::Unit Integration thread, > I > > > came up with a new patch that I think will be more useful. > > > I added the following methods, with tests!!! > > > > > > inherit > > > includeWith inherit, you now get most of the "power" of the superclass. > You > > > can use the class methods > > > > > > Now this is possible... > > > ---------------------------------------- > > > require File.dirname(__FILE__) + '/../lib/spec' > > > require 'test/unit' > > > > > > class RspecIntegrationTest < Test::Unit::TestCase > > > def self.a_class_method > > > puts "a_class_method called" > > > end > > > > > > def self.fixtures(*args) > > > puts "we can do fixtures too..." > > > end > > > > > > def setup > > > @test_case_setup_called = true > > > end > > > > > > def teardown > > > puts "Test::Unit::TestCase#teardown is called too" > > > end > > > > > > def run(result) > > > end > > > > > > def helper_method > > > @helper_method_called = true > > > end > > > end > > > > > > module RandomHelperModule > > > def random_task > > > @random_task_called = true > > > end > > > end > > > > > > context "Rspec should integrate with Test::Unit::TestCase" do > > > inherit RspecIntegrationTest > > > a_class_method > > > fixtures :some_table > > > include RandomHelperModule > > > > > > setup do > > > @rspec_setup_called = true > > > end > > > specify "TestCase#setup should be called." do > > > @test_case_setup_called.should_be true > > > @rspec_setup_called.should_be true > > > end > > > > > > specify "Rspec should be able to access TestCase methods" do > > > helper_method > > > @helper_method_called.should_be true > > > end > > > > > > specify "Rspec should be able to accept included modules" do > > > random_task > > > @random_task_called.should_be true > > > end > > > end > > > > > > ----------------------------------------------- > > > > > > I havn't tried it, but adding integration tests should be as easy as... > > > ------------------------------------ > > > context "Rspec should play with Integration Tests" do > > > inherit ActionController::IntegrationTest > > > end > > > ------------------------------------ > > > If this doesn't work right now, it doesn't seem like too much more > effort to > > > implement. > > > > > > > Now, all of this looks really interesting!! > > If this solves the 'ouch we have to reimplement all of that rails > > testing stuff' problem it would be fantastic! > > > > Could you please create a patch in the issue tracker on rubyforge? > > > > Looking forward to playing more with this stuff! > > > > Cheers, > > Aslak > > > > > Thanks, > > > Brian Takita > > > > > > _______________________________________________ > > > 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 Sat Jul 8 12:33:48 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 8 Jul 2006 11:33:48 -0500 Subject: [Rspec-devel] Rails controller testing/view testing In-Reply-To: References: Message-ID: <8d961d900607080933h45e7da88t4564e66201e06139@mail.gmail.com> On 7/7/06, Luke Redpath wrote: > Hi Guys > > I was wondering how integration of Rails' controller testing features > into rSpec is coming along. > It's in flux and we're still exploring the best way to do it. Brian Takita's extension patch that just went in might result in our being able to leverage more of Rails' built-in tetsing stuff without reimplementing it ourself. In any case, here is how I'd like to work with the controller/view layer: == Integration == I'd prefer to use in-browser testing using Watir/Sahi/Selenium rather than Rails' integration testing approach. -Even if we could do it with RSpec. -But we should support Rails integration testing with RSpec too - other people might prefer that over in-browser testing. == Controller specs == The broader rails community seems to favor integration tests more than controller (functional) tests these days. Personally, I'd like to be able to write controller specs that verify the behaviour of the controller still. I agree with you that the assert_tag approach is clunky, and I'd love to be able to use hpricot. I'd also love to be able to run specs over the controllers without even having to worry about the view. > I posted a suggestion on here the other day based on something Jay > Levitt mentioned for testing your views without using something like > the horrible assert_tag functionality. I've put something together > that works with Test::Unit using _why's new Hpricot HTML parser > library and I'd be interested on ideas for working this into rSpec > for Rails view/controller testing. I'm not really familiar with rSpec > under the hood yet and have only used it for non-Rails stuff so far. > > Here's what I've got so far: > http://www.lukeredpath.co.uk/index.php/2006/07/07/testing-your-rails- > views-with-hpricot/ > This looks *very* interesting. In fact, I'd like to explore whether we should support hpricot out of the RSpec box and ditch an assert_tag-equivalent approach altogether. Would you be willing to donate your hpriocot wrapper to RSpec under our BSD licence? I can help integrate it more tightly with the RSpec innards. Cheers, Aslak > Cheers > Luke Redpath > www.lukeredpath.co.uk > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From luke at agileevolved.com Sat Jul 8 15:25:05 2006 From: luke at agileevolved.com (Luke Redpath) Date: Sat, 8 Jul 2006 20:25:05 +0100 Subject: [Rspec-devel] Rails controller testing/view testing In-Reply-To: <8d961d900607080933h45e7da88t4564e66201e06139@mail.gmail.com> References: <8d961d900607080933h45e7da88t4564e66201e06139@mail.gmail.com> Message-ID: <6394CB30-FF04-4753-95C7-29ED92B781B4@agileevolved.com> > == Integration == > I'd prefer to use in-browser testing using Watir/Sahi/Selenium rather > than Rails' integration testing approach. -Even if we could do it with > RSpec. -But we should support Rails integration testing with RSpec too > - other people might prefer that over in-browser testing. Agreed. In fact, I've always found it strange how Rails refers to controller tests as "functional" tests when in essence they are unit tests for your controllers and that is all. I'd like to be able to spec out my controller actions under their various contexts to test they work at the code level, which is what I currently do using Test::Unit (in a BDD-fashion). When it comes to proper functional/acceptance testing I also agree that Watir/Selenium are the better approach to take as you can test things such as AJAX and Javascript more easily. I don't think its worth rSpec trying to tackle this problem. > > This looks *very* interesting. In fact, I'd like to explore whether we > should support hpricot out of the RSpec box and ditch an > assert_tag-equivalent approach altogether. > > Would you be willing to donate your hpriocot wrapper to RSpec under > our BSD licence? > I can help integrate it more tightly with the RSpec innards. Definately. I chose the MIT license because thats what Rails uses but its virtually the same as the BSD license. It would be great to see it rolled into rSpec and playing nicely with the should_* expectations. Cheers Luke From aslak.hellesoy at gmail.com Sat Jul 8 23:41:17 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 8 Jul 2006 22:41:17 -0500 Subject: [Rspec-devel] Rails controller testing/view testing In-Reply-To: <6394CB30-FF04-4753-95C7-29ED92B781B4@agileevolved.com> References: <8d961d900607080933h45e7da88t4564e66201e06139@mail.gmail.com> <6394CB30-FF04-4753-95C7-29ED92B781B4@agileevolved.com> Message-ID: <8d961d900607082041k629b6f69ga5a6629a825aad03@mail.gmail.com> On 7/8/06, Luke Redpath wrote: > > == Integration == > > I'd prefer to use in-browser testing using Watir/Sahi/Selenium rather > > than Rails' integration testing approach. -Even if we could do it with > > RSpec. -But we should support Rails integration testing with RSpec too > > - other people might prefer that over in-browser testing. > > Agreed. In fact, I've always found it strange how Rails refers to > controller tests as "functional" tests when in essence they are unit > tests for your controllers and that is all. Probably partly for propaganda reasons, but also a different understanding of what's the meaning of 'functional'. > I'd like to be able to > spec out my controller actions under their various contexts to test > they work at the code level, which is what I currently do using > Test::Unit (in a BDD-fashion). > Me too. For Rails apps I try to always flesh out new functionality on the UI level first. The next natural step is often to translate your UI 'requirement' into a very behaviour-centric controller spec. Example: When I POST to create a new record should be created and it should be rendered in such and such way. When what I should really worry about is that my controller should interact with the model and view tier in a such and such way. (Take it from the model and give it to the view - pun intended). > When it comes to proper functional/acceptance testing I also agree > that Watir/Selenium are the better approach to take as you can test > things such as AJAX and Javascript more easily. I don't think its > worth rSpec trying to tackle this problem. > Ideally - yes. But the in-browser testing tools still have rathe por ajax support in that none of them are event-driven but very sequential in their nature. > > > > This looks *very* interesting. In fact, I'd like to explore whether we > > should support hpricot out of the RSpec box and ditch an > > assert_tag-equivalent approach altogether. > > > > Would you be willing to donate your hpriocot wrapper to RSpec under > > our BSD licence? > > I can help integrate it more tightly with the RSpec innards. > > > Definately. I chose the MIT license because thats what Rails uses but > its virtually the same as the BSD license. It would be great to see > it rolled into rSpec and playing nicely with the should_* expectations. > Great. Do you have any idea whether hpricot will be available as a binary win32 gem? (There are C extebsions in there). While I don't have a great deal of sympathy with the win32 community I don't want to be racist either :-). Finally, do you have any thoughts on whether you'd like view-only RSpec support? If so, it would be interesting to see how you'd like that to look. Any new ideas since you blogged about it? Cheers, Aslak > Cheers > Luke > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Jul 8 23:43:40 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 8 Jul 2006 22:43:40 -0500 Subject: [Rspec-devel] Rails controller testing/view testing In-Reply-To: <8d961d900607082041k629b6f69ga5a6629a825aad03@mail.gmail.com> References: <8d961d900607080933h45e7da88t4564e66201e06139@mail.gmail.com> <6394CB30-FF04-4753-95C7-29ED92B781B4@agileevolved.com> <8d961d900607082041k629b6f69ga5a6629a825aad03@mail.gmail.com> Message-ID: <8d961d900607082043l2a5595f9k284616c355ff6545@mail.gmail.com> On 7/8/06, aslak hellesoy wrote: > On 7/8/06, Luke Redpath wrote: > > > == Integration == > > > I'd prefer to use in-browser testing using Watir/Sahi/Selenium rather > > > than Rails' integration testing approach. -Even if we could do it with > > > RSpec. -But we should support Rails integration testing with RSpec too > > > - other people might prefer that over in-browser testing. > > > > Agreed. In fact, I've always found it strange how Rails refers to > > controller tests as "functional" tests when in essence they are unit > > tests for your controllers and that is all. > > Probably partly for propaganda reasons, but also a different > understanding of what's the meaning of 'functional'. > > > I'd like to be able to > > spec out my controller actions under their various contexts to test > > they work at the code level, which is what I currently do using > > Test::Unit (in a BDD-fashion). > > > > Me too. For Rails apps I try to always flesh out new functionality on > the UI level first. The next natural step is often to translate your > UI 'requirement' into a very behaviour-centric controller spec. > Example: When I POST to create a new record should be created and it > should be rendered in such and such way. > > When what I should really worry about is that my controller should > interact with the model and view tier in a such and such way. (Take it > from the model and give it to the view - pun intended). > > > When it comes to proper functional/acceptance testing I also agree > > that Watir/Selenium are the better approach to take as you can test > > things such as AJAX and Javascript more easily. I don't think its > > worth rSpec trying to tackle this problem. > > > > Ideally - yes. But the in-browser testing tools still have rathe por > ajax support in that none of them are event-driven but very sequential > in their nature. > Of course, Rails' integration testing doesn't even try to deal with any of the javascript behaviour and it probably never will. I still thinks that RSpec should show how it's done if it can be done easily (maybe with the new inheritance support). > > > > > > This looks *very* interesting. In fact, I'd like to explore whether we > > > should support hpricot out of the RSpec box and ditch an > > > assert_tag-equivalent approach altogether. > > > > > > Would you be willing to donate your hpriocot wrapper to RSpec under > > > our BSD licence? > > > I can help integrate it more tightly with the RSpec innards. > > > > > > Definately. I chose the MIT license because thats what Rails uses but > > its virtually the same as the BSD license. It would be great to see > > it rolled into rSpec and playing nicely with the should_* expectations. > > > > Great. Do you have any idea whether hpricot will be available as a > binary win32 gem? (There are C extebsions in there). While I don't > have a great deal of sympathy with the win32 community I don't want to > be racist either :-). > > Finally, do you have any thoughts on whether you'd like view-only > RSpec support? If so, it would be interesting to see how you'd like > that to look. Any new ideas since you blogged about it? > > Cheers, > Aslak > > > Cheers > > Luke > > > > > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dharple at generalconsumption.org Tue Jul 4 21:10:56 2006 From: dharple at generalconsumption.org (Daniel Harple) Date: Tue, 4 Jul 2006 21:10:56 -0400 Subject: [Rspec-devel] TextMate rSpec Bundle In-Reply-To: <8d961d900607031851x3de375c4we54e3266fd05331c@mail.gmail.com> References: <8d961d900607031851x3de375c4we54e3266fd05331c@mail.gmail.com> Message-ID: <20060705011056.GB20433@generalconsumption.org> * aslak hellesoy at 2006-07-03T20:51-0500 wrote: > sweet. > > would it make sense to eventually put this into the bundle developed by > jonathan? Sure. If the rSpec bundle gets fleshed out we should commit it to the TextMate bundle repository, or maybe they can just use svn:externals and you keep it your repository. BTW, I think I missed some ?should? words for the ?Add Underscores to Should Statement?. Are these all of them? /\b(a|an|be|equal|have|include|instance|kind|match|not|raise|respond|satisfy|throw)\b/ From dchelimsky at gmail.com Sun Jul 9 06:51:24 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 9 Jul 2006 05:51:24 -0500 Subject: [Rspec-devel] Some handy rails helpers In-Reply-To: <44AA6A17.9020206@rubyforge.org> References: <44A885AC.3040103@shopwatch.org> <44AA6A17.9020206@rubyforge.org> Message-ID: <57c63afe0607090351x65c50ccake4930df2214071b6@mail.gmail.com> On 7/4/06, Jay Levitt wrote: > Luke Redpath wrote: > > Hi Jay > > > > These look really cool, and your post got my thinking. I've always hated > > how clunky the assert_tag function that come with Rails is. Wouldn't it > > be really cool to have a DSL that merges in with rSpec for testing your > > HTML output - kind of like integration tests but I was thinking more > > about speccing particular controller actions (under their various > > contexts) and their resulting views. Something like this would be really > > cool: > > > > tag('h1', :id => 'pageheader').should_contain('My Great Website') > > > > Or even better: > > > > h1(:id => 'pageheader').should_contain('My Great Website') > > div(:id => 'somediv').should_have_class_name('hidden') YES! Much more rspec-ish. Luke - have you done any work on this? From aslak.hellesoy at gmail.com Sun Jul 9 10:47:18 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 9 Jul 2006 09:47:18 -0500 Subject: [Rspec-devel] Some handy rails helpers In-Reply-To: <57c63afe0607090351x65c50ccake4930df2214071b6@mail.gmail.com> References: <44A885AC.3040103@shopwatch.org> <44AA6A17.9020206@rubyforge.org> <57c63afe0607090351x65c50ccake4930df2214071b6@mail.gmail.com> Message-ID: <8d961d900607090747y1b573bbcy8c0b7ad18a5d7020@mail.gmail.com> On 7/9/06, David Chelimsky wrote: > On 7/4/06, Jay Levitt wrote: > > Luke Redpath wrote: > > > Hi Jay > > > > > > These look really cool, and your post got my thinking. I've always hated > > > how clunky the assert_tag function that come with Rails is. Wouldn't it > > > be really cool to have a DSL that merges in with rSpec for testing your > > > HTML output - kind of like integration tests but I was thinking more > > > about speccing particular controller actions (under their various > > > contexts) and their resulting views. Something like this would be really > > > cool: > > > > > > tag('h1', :id => 'pageheader').should_contain('My Great Website') > > > > > > Or even better: > > > > > > h1(:id => 'pageheader').should_contain('My Great Website') > > > div(:id => 'somediv').should_have_class_name('hidden') > > YES! Much more rspec-ish. Luke - have you done any work on this? I think building something like this on top of hpricot or Rails' html scanner should be fairly straightforward. Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sun Jul 9 21:06:35 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 9 Jul 2006 18:06:35 -0700 Subject: [Rspec-devel] Patch that allows method definitions inside of a context Message-ID: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> Hello, I submitted a patch that allows you to define methods inside of the context block rather than inside of the setup method block. http://rubyforge.org/tracker/index.php?group_id=797&atid=3151 For example, this patch allows: require File.dirname(__FILE__) + '/../lib/spec' context "Rspec allow you to define custom methods" do specify "Rspec should allow you to define methods" do a_method @a_method_called.should.be true end def a_method @a_method_called = true end end This patch also does not break the behaviour where methods can be defined inside of the setup block. Thank you, Brian Takita -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060709/df6e6a7c/attachment.html From aslak.hellesoy at gmail.com Sun Jul 9 22:54:09 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 9 Jul 2006 21:54:09 -0500 Subject: [Rspec-devel] Patch that allows method definitions inside of a context In-Reply-To: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> References: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> Message-ID: <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> Great stuff Brian - you're a metaprogramming whiz! I'd like to apply this patch, what do you others think? Aslak On 7/9/06, Brian Takita wrote: > Hello, > > I submitted a patch that allows you to define methods inside of the context > block rather than inside of the setup method block. > http://rubyforge.org/tracker/index.php?group_id=797&atid=3151 > > For example, this patch allows: > require File.dirname(__FILE__) + '/../lib/spec' > > context "Rspec allow you to define custom methods" do > specify "Rspec should allow you to define methods" do > > a_method > @a_method_called.should.be true > end > > def a_method > @a_method_called = true > end > end > This patch also does not break the behaviour where methods can be defined > inside of the setup block. > > Thank you, > Brian Takita > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Sun Jul 9 23:02:23 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 9 Jul 2006 22:02:23 -0500 Subject: [Rspec-devel] Patch that allows method definitions inside of a context In-Reply-To: <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> References: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> Message-ID: <57c63afe0607092002p98dfd72sffe262fe7cc725a1@mail.gmail.com> On 7/9/06, aslak hellesoy wrote: > Great stuff Brian - you're a metaprogramming whiz! > > I'd like to apply this patch, what do you others think? I haven't looked at the patch yet, but the ability certainly seems nicer than defining helper methods in the setup block. > > Aslak > > On 7/9/06, Brian Takita wrote: > > Hello, > > > > I submitted a patch that allows you to define methods inside of the context > > block rather than inside of the setup method block. > > http://rubyforge.org/tracker/index.php?group_id=797&atid=3151 > > > > For example, this patch allows: > > require File.dirname(__FILE__) + '/../lib/spec' > > > > context "Rspec allow you to define custom methods" do > > specify "Rspec should allow you to define methods" do > > > > a_method > > @a_method_called.should.be true > > end > > > > def a_method > > @a_method_called = true > > end > > end > > This patch also does not break the behaviour where methods can be defined > > inside of the setup block. > > > > Thank you, > > Brian Takita > > > > _______________________________________________ > > 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 lachiec at gmail.com Sun Jul 9 23:46:00 2006 From: lachiec at gmail.com (Lachie) Date: Mon, 10 Jul 2006 13:46:00 +1000 Subject: [Rspec-devel] Patch that allows method definitions inside of a context In-Reply-To: <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> References: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> Message-ID: <2c5e719e0607092046j9d1b2dcg61c9e0c659b248f@mail.gmail.com> +1 Are the methods scoped to the context? Is there a clean way of sharing them across contexts? On 7/10/06, aslak hellesoy wrote: > Great stuff Brian - you're a metaprogramming whiz! > > I'd like to apply this patch, what do you others think? > > Aslak > > On 7/9/06, Brian Takita wrote: > > Hello, > > > > I submitted a patch that allows you to define methods inside of the context > > block rather than inside of the setup method block. > > http://rubyforge.org/tracker/index.php?group_id=797&atid=3151 > > > > For example, this patch allows: > > require File.dirname(__FILE__) + '/../lib/spec' > > > > context "Rspec allow you to define custom methods" do > > specify "Rspec should allow you to define methods" do > > > > a_method > > @a_method_called.should.be true > > end > > > > def a_method > > @a_method_called = true > > end > > end > > This patch also does not break the behaviour where methods can be defined > > inside of the setup block. > > > > Thank you, > > Brian Takita > > > > _______________________________________________ > > 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 > -- Lachie http://lachie.info/ http://www.flickr.com/photos/lachie/ From brian.takita at gmail.com Mon Jul 10 01:51:10 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 9 Jul 2006 22:51:10 -0700 Subject: [Rspec-devel] Patch that allows method definitions inside of a context In-Reply-To: <2c5e719e0607092046j9d1b2dcg61c9e0c659b248f@mail.gmail.com> References: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> <2c5e719e0607092046j9d1b2dcg61c9e0c659b248f@mail.gmail.com> Message-ID: <1d7ddd110607092251yb51507exa2205fa9476003a0@mail.gmail.com> > > Are the methods scoped to the context? Yes. Is there a clean way of sharing them across contexts? > If you have the latest version of the Trunk, you can either use: context "Should include SomeModule" do include SomeModule end or context "Should inherit SomeClass" do inherit SomeClass end Ruby's inheritance and mixin rules apply to contexts. On 7/9/06, Lachie wrote: > > +1 > > Are the methods scoped to the context? Is there a clean way of sharing > them across contexts? > > On 7/10/06, aslak hellesoy wrote: > > Great stuff Brian - you're a metaprogramming whiz! > > > > I'd like to apply this patch, what do you others think? > > > > Aslak > > > > On 7/9/06, Brian Takita < brian.takita at gmail.com> wrote: > > > Hello, > > > > > > I submitted a patch that allows you to define methods inside of the > context > > > block rather than inside of the setup method block. > > > http://rubyforge.org/tracker/index.php?group_id=797&atid=3151 > > > > > > For example, this patch allows: > > > require File.dirname(__FILE__) + '/../lib/spec' > > > > > > context "Rspec allow you to define custom methods" do > > > specify "Rspec should allow you to define methods" do > > > > > > a_method > > > @a_method_called.should.be true > > > end > > > > > > def a_method > > > @a_method_called = true > > > end > > > end > > > This patch also does not break the behaviour where methods can be > defined > > > inside of the setup block. > > > > > > Thank you, > > > Brian Takita > > > > > > _______________________________________________ > > > 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 > > > > > -- > Lachie > http://lachie.info/ > http://www.flickr.com/photos/lachie/ > _______________________________________________ > 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/20060709/510161bc/attachment.html From brian.takita at gmail.com Mon Jul 10 02:57:40 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 9 Jul 2006 23:57:40 -0700 Subject: [Rspec-devel] Patch that allows method definitions inside of a context In-Reply-To: <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> References: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> Message-ID: <1d7ddd110607092357t45c0dc4as55818a3aa40f86f1@mail.gmail.com> > > Great stuff Brian - you're a metaprogramming whiz! Thank you Aslak. I'm happy to contribute. On 7/9/06, aslak hellesoy wrote: > > Great stuff Brian - you're a metaprogramming whiz! > > I'd like to apply this patch, what do you others think? > > Aslak > > On 7/9/06, Brian Takita wrote: > > Hello, > > > > I submitted a patch that allows you to define methods inside of the > context > > block rather than inside of the setup method block. > > http://rubyforge.org/tracker/index.php?group_id=797&atid=3151 > > > > For example, this patch allows: > > require File.dirname(__FILE__) + '/../lib/spec' > > > > context "Rspec allow you to define custom methods" do > > specify "Rspec should allow you to define methods" do > > > > a_method > > @a_method_called.should.be true > > end > > > > def a_method > > @a_method_called = true > > end > > end > > This patch also does not break the behaviour where methods can be > defined > > inside of the setup block. > > > > Thank you, > > Brian Takita > > > > _______________________________________________ > > 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/20060709/a3bb1ab3/attachment.html From luke at agileevolved.com Mon Jul 10 03:48:30 2006 From: luke at agileevolved.com (Luke Redpath) Date: Mon, 10 Jul 2006 08:48:30 +0100 Subject: [Rspec-devel] Patch that allows method definitions inside of a context In-Reply-To: <57c63afe0607092002p98dfd72sffe262fe7cc725a1@mail.gmail.com> References: <1d7ddd110607091806o259fe8deh6b3f765fcb798c8@mail.gmail.com> <8d961d900607091954o536ad5d1m5d1c46ba6e53c052@mail.gmail.com> <57c63afe0607092002p98dfd72sffe262fe7cc725a1@mail.gmail.com> Message-ID: +1 here. Much nicer. Cheers Luke On 10 Jul 2006, at 04:02, David Chelimsky wrote: > On 7/9/06, aslak hellesoy wrote: >> Great stuff Brian - you're a metaprogramming whiz! >> >> I'd like to apply this patch, what do you others think? > > > I haven't looked at the patch yet, but the ability certainly seems > nicer than defining helper methods in the setup block. > > >> >> Aslak >> >> On 7/9/06, Brian Takita wrote: >>> Hello, >>> >>> I submitted a patch that allows you to define methods inside of >>> the context >>> block rather than inside of the setup method block. >>> http://rubyforge.org/tracker/index.php?group_id=797&atid=3151 >>> >>> For example, this patch allows: >>> require File.dirname(__FILE__) + '/../lib/spec' >>> >>> context "Rspec allow you to define custom methods" do >>> specify "Rspec should allow you to define methods" do >>> >>> a_method >>> @a_method_called.should.be true >>> end >>> >>> def a_method >>> @a_method_called = true >>> end >>> end >>> This patch also does not break the behaviour where methods can be >>> defined >>> inside of the setup block. >>> >>> Thank you, >>> Brian Takita >>> >>> _______________________________________________ >>> 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 Wed Jul 12 22:57:51 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 12 Jul 2006 21:57:51 -0500 Subject: [Rspec-devel] another option for verifying view contents Message-ID: <8d961d900607121957i4191ae3bsc009f38d91fadb52@mail.gmail.com> today i came across scrapi: http://blog.labnotes.org/2006/07/11/scraping-with-style-scrapi-toolkit-for-ruby/ which is based on uformatparser: http://rubyforge.org/projects/uformatparser/ and http://blog.labnotes.org/2005/11/20/microformat-parser-for-ruby/ any thoughts on basing rspec's future view support on uformatparsr versus _why's hpricot? aslak From kognition at gmail.com Thu Jul 13 09:08:44 2006 From: kognition at gmail.com (First Name Last Name) Date: Thu, 13 Jul 2006 14:08:44 +0100 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? Message-ID: Hi everybody, I have a specific question relating to BDD, not RSpec specifically - I have spent a good hour trying to find a list and cannot find any - please forgive me. My question relates to MVP and how to drive it. I am working on a Presenter, its context being "A newly created xxxpresenter". When a method is invoked on the Presenter from the View, the Model is updated. "Testing" that the Presenter picks up the View event (OnCreateAccount), the Presenter asks the Model to create a default account. The model raises an event that the view picks up. I want to avoid having the Presenter do EVERYTHING, and I want the Model to be observable as in vanilla MVP. I have something like this: [Test] public void ShouldAllowNewAccountToBeCreated() { int numberOfAccounts = myAccountsModel.Accounts; myView.RaiseOnCreateNewAccountEvent(); Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts); } This code isnt perfect by a long shot, and its the BDD I am more focused on. Here the View raises an event which the Presenter subscribed to. When the event is picked up in the Presenter, it calls onto the model to ask it to create a new account. After this, the number of accounts should have changed. What I need to test, and is the reason for my confusion, is at what point do I deal with the View picking up the OnAccountCreated model event? My feeling is that I need to be creating a specification for the View object, and it is there that all the specifications for how the view should behave are defined. At the same time, I could do the following with the above test (!): [Test] public void ShouldAllowNewAccountToBeCreated() { int numberOfAccounts = myAccountsModel.Accounts; myView.RaiseOnCreateNewAccountEvent(); Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts); Assert.IsNotNil(myView.Account); } This leads me to the next question. If I created a new context, "OnCreateNewAccount raised", I could then check the model Accounts value, and check the View. But this feels like I am slowly but surely sliding off the plank of BDD theory. Any help on this, much appreciated! Karl. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060713/b9302c18/attachment.html From dchelimsky at gmail.com Thu Jul 13 09:46:44 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 13 Jul 2006 08:46:44 -0500 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: References: Message-ID: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> On 7/13/06, First Name Last Name wrote: > > Hi everybody, > > I have a specific question relating to BDD, not RSpec specifically - I have > spent a good hour trying to find a list and cannot find any - please forgive > me. There is currently no BDD list that I am aware of. You could try the TDD list (testdrivendevelopment at yahoogroups.com) - there are plenty of BDD folk listening there. > > My question relates to MVP and how to drive it. You should check out Presenter First from Atomic Objects: http://atomicobject.com/presenterfirst.page. They're talking about TDD, but the approach is pretty awesome and provides a good solution to your question. The basic idea is that you have interfaces for the Model and the View, and you construct your Presenter with references to each, so you can mock the Model and the View and limit the Presenter to doing what it's supposed to do: sling event messages around from one to the other. David From kognition at gmail.com Thu Jul 13 14:41:18 2006 From: kognition at gmail.com (First Name Last Name) Date: Thu, 13 Jul 2006 19:41:18 +0100 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> Message-ID: On 7/13/06, David Chelimsky wrote: > > On 7/13/06, First Name Last Name wrote: > > > > > My question relates to MVP and how to drive it. > > You should check out Presenter First from Atomic Objects: > http://atomicobject.com/presenterfirst.page. They're talking about > TDD, but the approach is pretty awesome and provides a good solution > to your question. > > The basic idea is that you have interfaces for the Model and the View, > and you construct your Presenter with references to each, so you can > mock the Model and the View and limit the Presenter to doing what it's > supposed to do: sling event messages around from one to the other. David the link is well received, thanks. I have looked at the Presenter First pattern before, and its ok but I prefer state based testing over mocking, and I also like the ability to have the views subscribe to the model - using TDD I have so far not had a problem in testing the parts. I now understand my question is not so much MVP related, but is more BDD related. Given there is no formal group to discuss BDD, could anybody offer some names of open source projects I may be able to look at that apply BDD? I notice lots of people are using it, and I am new to the concepts and would benefit from seeing how others are applying it. Your example and tutorial is really good and has helped me a lot, but now I am getting into more complicated scenarios I want to make sure I am still on track with the concepts. David > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060713/fc9eb82d/attachment.html From dchelimsky at gmail.com Thu Jul 13 18:35:17 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 13 Jul 2006 17:35:17 -0500 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> Message-ID: <57c63afe0607131535o53852ad2ve866884a0a7ce14e@mail.gmail.com> On 7/13/06, First Name Last Name wrote: > David the link is well received, thanks. I have looked at the Presenter > First pattern before, and its ok but I prefer state based testing over > mocking That's pretty much the opposite of what I view as the BDD mindset. BDD is about specifying, not testing. Mocks allow you to specify the observable behaviour of an object. In fairness, I've not used Presenter First, I've only read about it - but from what I can tell, it's a great solution for approaching the MVP pattern with BDD. That's my 2 cents. Just one opinion though. Looking forward to others. Cheers, David From aslak.hellesoy at gmail.com Thu Jul 13 22:32:15 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 13 Jul 2006 21:32:15 -0500 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> Message-ID: <8d961d900607131932x69f9350em2b8ed54ece24242@mail.gmail.com> On 7/13/06, First Name Last Name wrote: > > On 7/13/06, David Chelimsky wrote: > > > On 7/13/06, First Name Last Name wrote: > > > > > My question relates to MVP and how to drive it. > > You should check out Presenter First from Atomic Objects: > http://atomicobject.com/presenterfirst.page . They're > talking about > TDD, but the approach is pretty awesome and provides a good solution > to your question. > > The basic idea is that you have interfaces for the Model and the View, > and you construct your Presenter with references to each, so you can > mock the Model and the View and limit the Presenter to doing what it's > supposed to do: sling event messages around from one to the other. > > > David the link is well received, thanks. I have looked at the Presenter > First pattern before, and its ok but I prefer state based testing over > mocking, and I also like the ability to have the views subscribe to the > model - using TDD I have so far not had a problem in testing the parts. > > I now understand my question is not so much MVP related, but is more BDD > related. Given there is no formal group to discuss BDD, could anybody offer > some names of open source projects I may be able to look at that apply BDD? Take a look at JBehave. That's where BDD originated. Also take a look at JMock. > I notice lots of people are using it, and I am new to the concepts and would > benefit from seeing how others are applying it. Your example and tutorial > is really good and has helped me a lot, but now I am getting into more > complicated scenarios I want to make sure I am still on track with the > concepts. > > > David > > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From aslak.hellesoy at gmail.com Fri Jul 14 00:58:28 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 13 Jul 2006 23:58:28 -0500 Subject: [Rspec-devel] New proc.should_increment method Message-ID: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> I just added a new little goodie: arr = [] lambda { arr << "something" }.should_increment arr, :length See http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5055&group_id=797 A little bit on the state side of the fence (as opposed to behavioural), but it's still a nice little feature methinks. Aslak From aslak.hellesoy at gmail.com Fri Jul 14 01:22:46 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 00:22:46 -0500 Subject: [Rspec-devel] [ANN] 0.5.14 released Message-ID: <8d961d900607132222l61dac02dsef9d5e55062835c6@mail.gmail.com> Release notes here: http://rubyforge.org/frs/shownotes.php?release_id=5999 We have some bugs/annoyances that should be fixed: http://rubyforge.org/tracker/index.php?group_id=797&atid=3149 If anyone wants to contribute patches for these it would be great! Cheers, Aslak From kognition at gmail.com Fri Jul 14 03:18:03 2006 From: kognition at gmail.com (First Name Last Name) Date: Fri, 14 Jul 2006 08:18:03 +0100 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: <57c63afe0607131535o53852ad2ve866884a0a7ce14e@mail.gmail.com> References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> <57c63afe0607131535o53852ad2ve866884a0a7ce14e@mail.gmail.com> Message-ID: On 7/13/06, David Chelimsky wrote: > > On 7/13/06, First Name Last Name wrote: > > David the link is well received, thanks. I have looked at the Presenter > > First pattern before, and its ok but I prefer state based testing over > > mocking > > That's pretty much the opposite of what I view as the BDD mindset. > > BDD is about specifying, not testing. Mocks allow you to specify the > observable behaviour of an object. > > In fairness, I've not used Presenter First, I've only read about it - > but from what I can tell, it's a great solution for approaching the > MVP pattern with BDD. > > That's my 2 cents. Just one opinion though. Looking forward to others. David, Thanks for your comments. This could be why I am struggling a little with BDD - my TDD has slanted towards state-based design, using Mocks ONLY if I REALLY need to. At the same time, though I am new to BDD, I dont see why not mocking circumvents the ability to specify something - I need to think about that some more. Thanks David, Karl. Cheers, > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060714/8a104233/attachment-0001.html From jchris at mfdz.com Fri Jul 14 04:13:08 2006 From: jchris at mfdz.com (Chris Anderson) Date: Fri, 14 Jul 2006 01:13:08 -0700 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> <57c63afe0607131535o53852ad2ve866884a0a7ce14e@mail.gmail.com> Message-ID: Hi all, Just a little chime in here: It seems like explicitly raising the new account created event from the view, has a little bit too much of the internals of the view being messed with in your test. If there is a way to provoke the view to raise that event based on the input it usually recieves in normal operation, that would seem more like a spec to me. Of course, you may not want to couple your view to tightly to your client parameters, but at some point in your testing you'll want to ensure that your application responds to client input as it should. Your view seems smarter than the one's I'm familiar with (I'm a Rails guy) but maybe that is the Presenter pattern. To me, the details of translating a client request into a new account (the parameter mapping) should happen in the application code, not the view. But, again, I am naive about your context, and there are certainly things that weigh in favor of the simplicity of your specification. Do any of you on the list have opinions about whether the request-response cycle should happen in the setup or the specify block? -- Chris Anderson http://jchris.mfdz.com/ From kognition at gmail.com Fri Jul 14 06:54:55 2006 From: kognition at gmail.com (First Name Last Name) Date: Fri, 14 Jul 2006 11:54:55 +0100 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> <57c63afe0607131535o53852ad2ve866884a0a7ce14e@mail.gmail.com> Message-ID: Hi Chris, I think the problem I have is that the spec. I have created isnt clear. In the View, all it does is pick up a button event, and then raise that Action event. The Presenter is the object that listens for that business event and then maps it to the model by asking to create an account. The view does nothing other than render and raise events from the UI. In my problem the question I am facing is, do I get the presenter to invoke on the model, then, take the new account from the model and pass it up to the view (this would be Presenter First). Or, do I allow the presenter to call onto the model, and have the view listen to events on the model as well. When the model raises the OnCreatedNewAccount event, the view picks this up and renders it - because it specifically subscribed to that model event for a reason. However, I never actually test the view with this approach. To test the true view, I need to drag over the actual C# WinForms/UserControl for testing, testing that it actually sets its Account when the model raises an event. I can do this, and have done this, rather than mocking view which would mena I dont actually test the view. I did some benchmarks today, and a simple fixture of 5 tests using the latest NUnit takes half a second longer when calling onto the UserControl view. When view is stubbed, the tests run at 0.51 secs, without stubbing they run at 0.98 consistently. Theres only 5 tests so this is a doubling in the time it takes to run the tests, and is an alarm bell to me to consider Presenter First just for the testing forces it works with. Thanks, Karl. On 7/14/06, Chris Anderson wrote: > > Hi all, > Just a little chime in here: > > It seems like explicitly raising the new account created event from > the view, has a little bit too much of the internals of the view being > messed with in your test. If there is a way to provoke the view to > raise that event based on the input it usually recieves in normal > operation, that would seem more like a spec to me. Of course, you may > not want to couple your view to tightly to your client parameters, but > at some point in your testing you'll want to ensure that your > application responds to client input as it should. > > Your view seems smarter than the one's I'm familiar with (I'm a Rails > guy) but maybe that is the Presenter pattern. To me, the details of > translating a client request into a new account (the parameter > mapping) should happen in the application code, not the view. > > But, again, I am naive about your context, and there are certainly > things that weigh in favor of the simplicity of your specification. > > Do any of you on the list have opinions about whether the > request-response cycle should happen in the setup or the specify > block? > > > -- > Chris Anderson > http://jchris.mfdz.com/ > _______________________________________________ > 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/20060714/d3d1a7fc/attachment.html From kognition at gmail.com Fri Jul 14 07:07:06 2006 From: kognition at gmail.com (First Name Last Name) Date: Fri, 14 Jul 2006 12:07:06 +0100 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> <57c63afe0607131535o53852ad2ve866884a0a7ce14e@mail.gmail.com> Message-ID: Hi, Another question I have is is related to your last point Chris. When the View raises the OnCreateNewAccount event two things need to happen within the presenter: 1. The presenter calls onto the model and the model creates new account 2. The presenter sets the new account onto the view My "context" is "A newly created Presenter", and I am specifiying what happens when the OnCreateNewAccount event is raised in this context. I have two specs now with duplication: 1. [Test] public void ShouldAllowNewAccountToBeCreated() { int numberOfAccounts = myAccountsModel.Accounts; myView.RaiseOnCreateNewAccountEvent(); Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts); } 2. [Test] public void ShouldAssignNewAccountOntoTheView() { myView.RaiseOnCreateNewAccountEvent(); Assert.IsNotNull(myView.CurrentAccount); } Here the myView... line is duplicated in both specs. Is this ok, or should I be thinking about pulling this out some how? My other thought is that this approach of raising the View event, which is taken from Martin Fowlers MVP discussion, doesnt actually make anything clear. It feels better to be more explicit in the spec: [Test] public void ShouldAllowNewAccountToBeCreated() { int numberOfAccounts = myAccountsModel.Accounts; /*** Change the View invoke to Presenter ***/ myPresenter.CreateNewAccountEventRaised(); Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts); } Any thoughts? Karl. On 7/14/06, First Name Last Name wrote: > > Hi Chris, > > I think the problem I have is that the spec. I have created isnt clear. > In the View, all it does is pick up a button event, and then raise that > Action event. The Presenter is the object that listens for that business > event and then maps it to the model by asking to create an account. The > view does nothing other than render and raise events from the UI. > > In my problem the question I am facing is, do I get the presenter to > invoke on the model, then, take the new account from the model and pass it > up to the view (this would be Presenter First). Or, do I allow the > presenter to call onto the model, and have the view listen to events on the > model as well. When the model raises the OnCreatedNewAccount event, the > view picks this up and renders it - because it specifically subscribed to > that model event for a reason. However, I never actually test the view with > this approach. To test the true view, I need to drag over the actual C# > WinForms/UserControl for testing, testing that it actually sets its Account > when the model raises an event. I can do this, and have done this, rather > than mocking view which would mena I dont actually test the view. I did > some benchmarks today, and a simple fixture of 5 tests using the latest > NUnit takes half a second longer when calling onto the UserControl view. > When view is stubbed, the tests run at 0.51 secs, without stubbing they > run at 0.98 consistently. Theres only 5 tests so this is a doubling in > the time it takes to run the tests, and is an alarm bell to me to consider > Presenter First just for the testing forces it works with. > > Thanks, > > Karl. > > > On 7/14/06, Chris Anderson wrote: > > > > Hi all, > > Just a little chime in here: > > > > It seems like explicitly raising the new account created event from > > the view, has a little bit too much of the internals of the view being > > messed with in your test. If there is a way to provoke the view to > > raise that event based on the input it usually recieves in normal > > operation, that would seem more like a spec to me. Of course, you may > > not want to couple your view to tightly to your client parameters, but > > at some point in your testing you'll want to ensure that your > > application responds to client input as it should. > > > > Your view seems smarter than the one's I'm familiar with (I'm a Rails > > guy) but maybe that is the Presenter pattern. To me, the details of > > translating a client request into a new account (the parameter > > mapping) should happen in the application code, not the view. > > > > But, again, I am naive about your context, and there are certainly > > things that weigh in favor of the simplicity of your specification. > > > > Do any of you on the list have opinions about whether the > > request-response cycle should happen in the setup or the specify > > block? > > > > > > -- > > Chris Anderson > > http://jchris.mfdz.com/ > > _______________________________________________ > > 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/20060714/630d97b1/attachment.html From dchelimsky at gmail.com Fri Jul 14 09:21:29 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 14 Jul 2006 08:21:29 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> Message-ID: <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> On 7/13/06, aslak hellesoy wrote: > I just added a new little goodie: > > arr = [] > lambda { arr << "something" }.should_increment arr, :length > > See http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5055&group_id=797 > > A little bit on the state side of the fence (as opposed to > behavioural), but it's still a nice little feature methinks. -1 I saw in the page linked above "State based testing isn't ALWAYS bad". I agree w/ that statement, but I also think that it's important that rspec offers better solutions rather than conveniences. In the case of the rails controller tests, I've been working on an acts_as_mock plugin that allows you to mock the class methods as well as instance methods, allowing for this (expressed in test/unit for the time being - apologies): def test_create_should_redirect_to_list_when_successful Story.should_receive(:new).and_return(@story) @story.should_receive(:save).and_return(true) post :create assert_response :redirect assert_template nil end def test_create_should_re_render_new_when_NOT_successful Story.should_receive(:new).and_return(@story) @story.should_receive(:save).and_return(false) post :create assert_response :success assert_template 'new' end To me, this is the direction we should be moving, rather than making it convenient to do things that we want to generally discourage. This also brings up an important, higher level discussion vis a vis what features should be going into rspec. I'll get that rolling in a separate thread. David From dchelimsky at gmail.com Fri Jul 14 09:35:58 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 14 Jul 2006 08:35:58 -0500 Subject: [Rspec-devel] rspec features - core vs extensions Message-ID: <57c63afe0607140635h2182fa36obbb25ce832803739@mail.gmail.com> My initial reaction to the recent addition of should_increment was pretty negative because I felt as though it violated what I view as a core ethos of rspec: encourage good design by making it easy to do things that encourage good design and less convenient to do things that encourage bad design. This is a tough nut to crack because "good design" is a VERY subjective thing, and there tends to be a lot of passion around discussions of such because of the subjectivity. The rspec committer group comes from a world in which TDD has been butchered and we want to foster better TDD through the introduction, discussion and exploration of BDD. There's a bit of dogma that comes along with that - it's sort of a rebellion - and while I think it is important to keep dogma at bay, it's also important to refer back to it so we remember why we're even bothering with all of this. Then we have the issue of adoption. We want to encourage people to use this tool, and some of those people are going to want to use it the way they are used to using test/unit. So how do we satisfy the needs of those people without distorting the vision/intent of BDD and rspec? Personally, I think the rails model is the one to follow here. The rails committers turned off a lot of people by not trying to turn rails into something it is not. The rails plugin system has resolved this problem by offering an entry point for anyone to use rails virtually any way they want without bloating core, distorting their vision, or committing to supporting things that go against their vision. I'd like to take the same approach w/ rspec. I think we should not be adding expectations like "should_increment", but we absolutely SHOULD provide a mechanism for anyone to write custom extensions and a mechanism to publish those extensions for community use. If you got this far, thanks for your time reading this. Thoughts? David From dastels at daveastels.com Fri Jul 14 10:32:42 2006 From: dastels at daveastels.com (David Astels) Date: Fri, 14 Jul 2006 11:32:42 -0300 Subject: [Rspec-devel] rspec features - core vs extensions In-Reply-To: <57c63afe0607140635h2182fa36obbb25ce832803739@mail.gmail.com> References: <57c63afe0607140635h2182fa36obbb25ce832803739@mail.gmail.com> Message-ID: <2444FAB7-C8B8-43E2-A408-E9D9C98DA2AE@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14-Jul-06, at 10:35 AM, David Chelimsky wrote: > This is a tough nut to crack because "good design" is a VERY > subjective thing, and there tends to be a lot of passion around > discussions of such because of the subjectivity. I tend to disagree. While the small details of what is a good design do get quite subjective... the difference between good & bad is pretty objective & plain... although not always easy to put into words. The difference between good & better is where the real subjectivity lies. > The rspec committer group comes from a world in which TDD has been > butchered and we want to foster better TDD through the introduction, > discussion and exploration of BDD. There's a bit of dogma that comes > along with that - it's sort of a rebellion - and while I think it is > important to keep dogma at bay, it's also important to refer back to > it so we remember why we're even bothering with all of this. Dogma is ok.. it sets up a position. It's like planning in Agile... dogma is ok.. being dogmatic isn't. > Personally, I think the rails model is the one to follow here. The > rails committers turned off a lot of people by not trying to turn > rails into something it is not. The rails plugin system has resolved > this problem by offering an entry point for anyone to use rails > virtually any way they want without bloating core, distorting their > vision, or committing to supporting things that go against their > vision. > > I'd like to take the same approach w/ rspec. I think we should not be > adding expectations like "should_increment", but we absolutely SHOULD > provide a mechanism for anyone to write custom extensions and a > mechanism to publish those extensions for community use. I fully agree. What we do with rSpec (both in terms of its use & its feature set) provides an example to people looking at it & using it. We want to avoid explicitly or implicitly saying "it's ok to do things the bad way" Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEt6sKauez/L4x7g4RAuZVAJ0Qga/M9lBgraXuENtktvhBm107nACcCmED Yqze0nuqdZr9+5sJVF+p5aE= =AG4B -----END PGP SIGNATURE----- From aslak.hellesoy at gmail.com Fri Jul 14 13:41:14 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 12:41:14 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> Message-ID: <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> On 7/14/06, David Chelimsky wrote: > On 7/13/06, aslak hellesoy wrote: > > I just added a new little goodie: > > > > arr = [] > > lambda { arr << "something" }.should_increment arr, :length > > > > See http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5055&group_id=797 > > > > A little bit on the state side of the fence (as opposed to > > behavioural), but it's still a nice little feature methinks. > > -1 > > I saw in the page linked above "State based testing isn't ALWAYS bad". > I agree w/ that statement, but I also think that it's important that > rspec offers better solutions rather than conveniences. > I should have mailed the list before adding this. I had a case for when it was convenient, and with the lack of a better solution I went ahead and added it. I'm all for removing the feature from RSpec - it's easy enough for me to monkey patch ShouldHelper in my own project to add should_increment. > In the case of the rails controller tests, I've been working on an > acts_as_mock plugin that allows you to mock the class methods as well > as instance methods, allowing for this (expressed in test/unit for the > time being - apologies): > > def test_create_should_redirect_to_list_when_successful > Story.should_receive(:new).and_return(@story) > @story.should_receive(:save).and_return(true) > > post :create > > assert_response :redirect > assert_template nil > end > > def test_create_should_re_render_new_when_NOT_successful > Story.should_receive(:new).and_return(@story) > @story.should_receive(:save).and_return(false) > > post :create > > assert_response :success > assert_template 'new' > end > > > To me, this is the direction we should be moving, rather than making > it convenient to do things that we want to generally discourage. > I agree. Would it make sense to add your acts_as_mock plugin to RSpec core? > This also brings up an important, higher level discussion vis a vis > what features should be going into rspec. I'll get that rolling in a > separate thread. > The protocol should still be what I just violated - email the list and see what people think. The committers will decide based on input from others. I like what you said about avoiding dirty conveniences. Aslak > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From jchris at mfdz.com Fri Jul 14 13:57:22 2006 From: jchris at mfdz.com (Chris Anderson) Date: Fri, 14 Jul 2006 10:57:22 -0700 Subject: [Rspec-devel] BDD Question - wheres the BDD help forums? In-Reply-To: References: <57c63afe0607130646l153566b5va0f768d3c8b53bb4@mail.gmail.com> <57c63afe0607131535o53852ad2ve866884a0a7ce14e@mail.gmail.com> Message-ID: Karl, If your context really is the Presenter, then you'd do well to spec the Presenter in isolation. You'll want to spec the behaviour of the view as well, but not in this context, it seems. To that end, the last example you provided looks the healthiest to me: > [Test] > public void ShouldAllowNewAccountToBeCreated() { > int numberOfAccounts = myAccountsModel.Accounts; > > > /*** Change the View invoke to Presenter ***/ > myPresenter.CreateNewAccountEventRaised(); > > > Assert.AreEqual(numberOfAccounts + 1, myAccountsModel.Accounts); > } > But I'm still a little spooked by the myPresenter.CreateNewAccountEventRaised() call. Is that a method that gets invoked in the standard operations of the Presenter? It looks like a private method, based on the name, and specifications tend to work better when they are more coarse-grained, and focussed on the public methods of your object. Again, please forgive my naiveity about your framework. > I did > some benchmarks today, and a simple fixture of 5 tests using the latest > NUnit takes half a second longer when calling onto the UserControl view. I might differ from others on this point - but unless your tests are calling some external API, and taking waaaaaay too long to execute (and there are plenty of reasons this is bad), a slight performance drag is no problem, or at least, not something to water your tests down over. One final consideration - your specification framework should reward you for writing specs first, and then coding to meet those specs. That is the main advantage I find of RSpec over Test::Unit in Ruby. While it is possible to use the both specs and tests to exercise the same code in the same ways, I find that I write specs first, and think of them as specifications, while I tend to write unit tests after or concurrently with writing the unit code itself. Those unit tests are usually more tied to the internals of the units, than specs are - precisely because specifications are speculative - they tell me what I'd *like* the API to be, before it even exists. So take care that your spec implementation rewards spec-first behaviour. Otherwise you may as well be writing unit tests (which I find quite handy, but in a different way from specs). Best, Chris From dchelimsky at gmail.com Fri Jul 14 14:28:53 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 14 Jul 2006 13:28:53 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> Message-ID: <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> On 7/14/06, aslak hellesoy wrote: > Would it make sense to add your acts_as_mock plugin to RSpec core? Definitely. That's my plan, but right now it's fairly alpha. I did create a branch called mocks_as_module in which I'm exploring merging the act_as_mocks concepts w/ the current rspec mocking framework by moving the rspec methods to a module that gets included in the Mock class. Then the plugin can include the same stuff in ActiveRecord::Base and we're off and running. Nothing committed there yet, but there will be in the next day or so. David From dchelimsky at gmail.com Fri Jul 14 14:30:04 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 14 Jul 2006 13:30:04 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> Message-ID: <57c63afe0607141130j42f32ddapfd282399f7daf57c@mail.gmail.com> On 7/14/06, aslak hellesoy wrote: > The protocol should still be what I just violated - email the list and > see what people think. The committers will decide based on input from > others. Agreed. > I like what you said about avoiding dirty conveniences. That sounds funny out of context. But thanks! From dchelimsky at gmail.com Fri Jul 14 14:33:21 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 14 Jul 2006 13:33:21 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> Message-ID: <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> > On 7/13/06, aslak hellesoy wrote: > I'm all for removing the feature from RSpec - it's easy enough for me > to monkey patch ShouldHelper in my own project to add > should_increment. Is it in a rails app? If so, why not make it a plugin? From aslak.hellesoy at gmail.com Fri Jul 14 15:14:07 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 14:14:07 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> Message-ID: <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> On 7/14/06, David Chelimsky wrote: > On 7/14/06, aslak hellesoy wrote: > > Would it make sense to add your acts_as_mock plugin to RSpec core? > > Definitely. That's my plan, but right now it's fairly alpha. > > I did create a branch called mocks_as_module in which I'm exploring > merging the act_as_mocks concepts w/ the current rspec mocking > framework by moving the rspec methods to a module that gets included > in the Mock class. Then the plugin can include the same stuff in > ActiveRecord::Base and we're off and running. Nothing committed there > yet, but there will be in the next day or so. > That sounds good. I'm looking forward to that. One thing I'd like to instead of: thing = mock("thing") is to do: thing = mock(Thing) # passing a class rather than a string -and have the mock fail if you tell it to expect a message that is not defined by Thing. This goes against duck typing, but it can also be useful in 'forcing' the implementation of certain methods in your mocked roles/collaborators. -Which is a common design technique with mock libraries for static languages. How would this fit with your acts_as_mock? Aslak > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Fri Jul 14 15:15:07 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 14:15:07 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> Message-ID: <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> On 7/14/06, David Chelimsky wrote: > > On 7/13/06, aslak hellesoy wrote: > > I'm all for removing the feature from RSpec - it's easy enough for me > > to monkey patch ShouldHelper in my own project to add > > should_increment. > > Is it in a rails app? If so, why not make it a plugin? I will > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Fri Jul 14 16:28:44 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 14 Jul 2006 15:28:44 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> Message-ID: <57c63afe0607141328m11c2232al12e35bdee0f897a2@mail.gmail.com> On 7/14/06, aslak hellesoy wrote: > That sounds good. I'm looking forward to that. > > One thing I'd like to instead of: > > thing = mock("thing") > > is to do: > > thing = mock(Thing) # passing a class rather than a string > The way it works now does something similar, but is implemented differently. You tell a class to act like a mock: class Thing; acts_as_mock; end Then you can do this: thing = Thing.new thing.should_receive(:some_message) Thing.should_receive(:new).and_return(thing) post :create Thing.__verify thing.__verify etc (Once fully integrated w/ rspec the verification should be automagic.) Now you've got a handle on the object that is acting like a mock. If you want you can do this: thing = Mock.new("thing") thing.should_receive(:some_message) Thing.should_receive(:new).and_return(thing) instead. Then you'd get an instance of Mock rather than an instance of Thing that's acting like one. Also, the way acts_as_mock handles messages is a bit different from rspecs current mocks. Rather than using message_missing and comparing the message to expectations, it actually adds methods to the mock when you set expectations. So when you do this: mock.should_receive(:message).and_return(:object) this is what happens internally: def should_receive message (class << self; self; end).class_eval do define_method(message.to_s, lambda {received_message message}) end @messages_expected << message self end received_message (which gets called by the newly created method) then checks against @messages_expected. There's more to it than that, but that's the basic idea. More soon........ > -and have the mock fail if you tell it to expect a message that is not defined by Thing. Interesting, but that goes against something I'm shooting for in rails controller tests. I want to decouple them completely from the db. Since AR defines methods on the fly based on DB structure, those methods wouldn't be there and the mock would fail. There is something interesting here though - maybe we could have an argument to acts_as_mock that tells it to behave this way when we want to (raising flags when methods aren't part of the class), but otherwise not. When testing controllers, we could set that flag and force the controller to only call methods that we actually write in to the model classes, and therefore not use any of the read accessors that are created for attributes by AR. Then, when testing views, we would turn the flag off and tell the mock to return an empty string for any getters it calls that we haven't specified how the mock should behave. Too complex? Maybe. This is all stuff we can add later if we agree it makes sense. First things first. Thoughts? From dastels at daveastels.com Fri Jul 14 16:47:40 2006 From: dastels at daveastels.com (David Astels) Date: Fri, 14 Jul 2006 17:47:40 -0300 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> Message-ID: <9D89AE59-6883-4B63-9B10-E5003308C82A@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14-Jul-06, at 4:14 PM, aslak hellesoy wrote: > > One thing I'd like to instead of: > > thing = mock("thing") > > is to do: > > thing = mock(Thing) # passing a class rather than a string > > -and have the mock fail if you tell it to expect a message that is not > defined by Thing. So.. only being able to mock classes that exist. I don't like that at all. That doesn't let you use mocks to explore & discover the interface. Maybe as a flavour of mock... but not as the only way to do it. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEuALsauez/L4x7g4RAvJdAKCTenKZFBfnyLaMwg7DJ/1YifMO5QCgwBVD SKjNzUK0SFtpzxKEXOocXDo= =PAsE -----END PGP SIGNATURE----- From aslak.hellesoy at gmail.com Fri Jul 14 17:22:42 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 16:22:42 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607141328m11c2232al12e35bdee0f897a2@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> <57c63afe0607141328m11c2232al12e35bdee0f897a2@mail.gmail.com> Message-ID: <8d961d900607141422s1d78b8f3pfc7ba19151ff6292@mail.gmail.com> On 7/14/06, David Chelimsky wrote: > On 7/14/06, aslak hellesoy wrote: > > That sounds good. I'm looking forward to that. > > > > One thing I'd like to instead of: > > > > thing = mock("thing") > > > > is to do: > > > > thing = mock(Thing) # passing a class rather than a string > > > The way it works now does something similar, but is implemented > differently. You tell a class to act like a mock: > > class Thing; acts_as_mock; end > > Then you can do this: > > thing = Thing.new > thing.should_receive(:some_message) > Thing.should_receive(:new).and_return(thing) > > post :create > > Thing.__verify > thing.__verify > > etc > > (Once fully integrated w/ rspec the verification should be automagic.) > > Now you've got a handle on the object that is acting like a mock. If > you want you can do this: > > thing = Mock.new("thing") > thing.should_receive(:some_message) > Thing.should_receive(:new).and_return(thing) > > instead. Then you'd get an instance of Mock rather than an instance of > Thing that's acting like one. > > Also, the way acts_as_mock handles messages is a bit different from > rspecs current mocks. Rather than using message_missing and comparing > the message to expectations, it actually adds methods to the mock when > you set expectations. So when you do this: > > mock.should_receive(:message).and_return(:object) > > this is what happens internally: > > def should_receive message > (class << self; self; end).class_eval do > define_method(message.to_s, lambda {received_message message}) > end > @messages_expected << message > self > end > > received_message (which gets called by the newly created method) then > checks against @messages_expected. There's more to it than that, but > that's the basic idea. > I like that, and I think we should refactor the vanilla mocks to use this approach too. There is no need to use method_missing really. Aslak > More soon........ > > > -and have the mock fail if you tell it to expect a message that is not defined by Thing. > > Interesting, but that goes against something I'm shooting for in rails > controller tests. I want to decouple them completely from the db. > Since AR defines methods on the fly based on DB structure, those > methods wouldn't be there and the mock would fail. > > There is something interesting here though - maybe we could have an > argument to acts_as_mock that tells it to behave this way when we want > to (raising flags when methods aren't part of the class), but > otherwise not. > > When testing controllers, we could set that flag and force the > controller to only call methods that we actually write in to the model > classes, and therefore not use any of the read accessors that are > created for attributes by AR. > > Then, when testing views, we would turn the flag off and tell the mock > to return an empty string for any getters it calls that we haven't > specified how the mock should behave. > > Too complex? Maybe. This is all stuff we can add later if we agree it > makes sense. First things first. > > Thoughts? > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Fri Jul 14 17:25:16 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 16:25:16 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <9D89AE59-6883-4B63-9B10-E5003308C82A@daveastels.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> <9D89AE59-6883-4B63-9B10-E5003308C82A@daveastels.com> Message-ID: <8d961d900607141425m2b6794b0uabc1b320150db38c@mail.gmail.com> On 7/14/06, David Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 14-Jul-06, at 4:14 PM, aslak hellesoy wrote: > > > > One thing I'd like to instead of: > > > > thing = mock("thing") > > > > is to do: > > > > thing = mock(Thing) # passing a class rather than a string > > > > -and have the mock fail if you tell it to expect a message that is not > > defined by Thing. > > So.. only being able to mock classes that exist. I don't like that > at all. That doesn't let you use mocks to explore & discover the > interface. > I didn't mean it should be the only way. In my specs I'd like to start out with strings, and once I think it looks good (i.e. I have discovered the interface), I'd like to change it to use a class, which would then lead me to implement that new interface. Aslak > Maybe as a flavour of mock... but not as the only way to do it. > > Dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > > iD8DBQFEuALsauez/L4x7g4RAvJdAKCTenKZFBfnyLaMwg7DJ/1YifMO5QCgwBVD > SKjNzUK0SFtpzxKEXOocXDo= > =PAsE > -----END PGP SIGNATURE----- > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Fri Jul 14 17:31:50 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 16:31:50 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607141328m11c2232al12e35bdee0f897a2@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141128r286000ffi4c48f319ed3e8e35@mail.gmail.com> <8d961d900607141214k5db3c104oc795ecebe883dcd0@mail.gmail.com> <57c63afe0607141328m11c2232al12e35bdee0f897a2@mail.gmail.com> Message-ID: <8d961d900607141431i1055bd9r82874264f898faa5@mail.gmail.com> On 7/14/06, David Chelimsky wrote: > On 7/14/06, aslak hellesoy wrote: > > That sounds good. I'm looking forward to that. > > > > One thing I'd like to instead of: > > > > thing = mock("thing") > > > > is to do: > > > > thing = mock(Thing) # passing a class rather than a string > > > The way it works now does something similar, but is implemented > differently. You tell a class to act like a mock: > > class Thing; acts_as_mock; end > > Then you can do this: > > thing = Thing.new > thing.should_receive(:some_message) > Thing.should_receive(:new).and_return(thing) > > post :create > > Thing.__verify > thing.__verify > > etc > > (Once fully integrated w/ rspec the verification should be automagic.) > > Now you've got a handle on the object that is acting like a mock. If > you want you can do this: > > thing = Mock.new("thing") > thing.should_receive(:some_message) > Thing.should_receive(:new).and_return(thing) > > instead. Then you'd get an instance of Mock rather than an instance of > Thing that's acting like one. > > Also, the way acts_as_mock handles messages is a bit different from > rspecs current mocks. Rather than using message_missing and comparing > the message to expectations, it actually adds methods to the mock when > you set expectations. So when you do this: > > mock.should_receive(:message).and_return(:object) > > this is what happens internally: > > def should_receive message > (class << self; self; end).class_eval do > define_method(message.to_s, lambda {received_message message}) > end > @messages_expected << message > self > end > > received_message (which gets called by the newly created method) then > checks against @messages_expected. There's more to it than that, but > that's the basic idea. > > More soon........ > > > -and have the mock fail if you tell it to expect a message that is not defined by Thing. > > Interesting, but that goes against something I'm shooting for in rails > controller tests. I want to decouple them completely from the db. > Since AR defines methods on the fly based on DB structure, those > methods wouldn't be there and the mock would fail. > True, so AR is probably not a good candidate for this approach. But there is more to ruby/rspec than rails. I think it's useful in other scenarios. > There is something interesting here though - maybe we could have an > argument to acts_as_mock that tells it to behave this way when we want > to (raising flags when methods aren't part of the class), but > otherwise not. > > When testing controllers, we could set that flag and force the > controller to only call methods that we actually write in to the model > classes, and therefore not use any of the read accessors that are > created for attributes by AR. > > Then, when testing views, we would turn the flag off and tell the mock > to return an empty string for any getters it calls that we haven't > specified how the mock should behave. > > Too complex? Maybe. This is all stuff we can add later if we agree it > makes sense. First things first. > > Thoughts? > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From srbaker at pobox.com Fri Jul 14 17:36:57 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 14 Jul 2006 14:36:57 -0700 Subject: [Rspec-devel] RSpec Users List Message-ID: <07EB98EF-CE77-4E9C-8BD6-2E1059436871@pobox.com> Everyone, I have created a new mailing list: rspec-users. This list is for people who are using RSpec on projects, and developers who wish to provide assistance to those users. The intention is to keep rspec-devel strictly for discussion of development of new features on RSpec, so anyone who is using RSpec currently, but is not contributing patches or committing is encouraged to switch to the rspec-users list. The link to subscribe to rspec-users is: http://rubyforge.org/mailman/listinfo/rspec-users If you are not developing for RSpec and wish to unsubscribe from this list, please visit: http://rubyforge.org/mailman/listinfo/rspec-devel The archives for the -devel list are public. And can be viewed online at: http://rubyforge.org/pipermail/rspec-devel/ -Steven From lachiec at gmail.com Fri Jul 14 19:29:26 2006 From: lachiec at gmail.com (Lachie) Date: Sat, 15 Jul 2006 09:29:26 +1000 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> Message-ID: <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> On 7/15/06, aslak hellesoy wrote: > On 7/14/06, David Chelimsky wrote: > > > On 7/13/06, aslak hellesoy wrote: > > > I'm all for removing the feature from RSpec - it's easy enough for me > > > to monkey patch ShouldHelper in my own project to add > > > should_increment. > > > > Is it in a rails app? If so, why not make it a plugin? > > I will I'd love to see this as an example of adding bespoke expectations from rails plugins, as well as in more general apps. From aslak.hellesoy at gmail.com Fri Jul 14 19:50:14 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 14 Jul 2006 18:50:14 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> Message-ID: <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> On 7/14/06, Lachie wrote: > On 7/15/06, aslak hellesoy wrote: > > On 7/14/06, David Chelimsky wrote: > > > > On 7/13/06, aslak hellesoy wrote: > > > > I'm all for removing the feature from RSpec - it's easy enough for me > > > > to monkey patch ShouldHelper in my own project to add > > > > should_increment. > > > > > > Is it in a rails app? If so, why not make it a plugin? > > > > I will > > I'd love to see this as an example of adding bespoke expectations from > rails plugins, as well as in more general apps. Right now I'm achieving this by simply monkey patching RSpec. Stick this in vendor/plugins/rspec_ext/init.rb: require 'spec' module Spec class ShouldHelper < ShouldBase def increment(object, method, difference=1) initial_value = object.__send__(method) @target.call object.__send__(method).should.equal(initial_value + difference) end def decrement(object, method, difference=1) increment(object, method, -difference) end end class ShouldNegator < ShouldBase def change(object, method) initial_value = object.__send__(method) @target.call object.__send__(method).should.equal(initial_value) end end end This is the recently reverted code that allows you to do: arr = ["something"] lambda { arr.pop }.should.decrement arr, :length -Which is not BDD, but still useful in Rails while waiting for better mock support in rails. Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From lachiec at gmail.com Fri Jul 14 20:03:56 2006 From: lachiec at gmail.com (Lachie) Date: Sat, 15 Jul 2006 10:03:56 +1000 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> Message-ID: <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> Thanks :) > -Which is not BDD, but still useful in Rails while waiting for better > mock support in rails. In the rails-and-pure-BDD context, do you guys see mocking replacing AR connecting to a DB in model specs? This is somewhere I'd always want to write state-bases specs, pure BDD notwithstanding, because of AR's thorough integration with my tables. The subclasses don't really come to life without some very dirty conveniences. Lachie From dchelimsky at gmail.com Fri Jul 14 22:05:29 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 14 Jul 2006 21:05:29 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> Message-ID: <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> On 7/14/06, Lachie wrote: > Thanks :) > > > -Which is not BDD, but still useful in Rails while waiting for better > > mock support in rails. > > In the rails-and-pure-BDD context, do you guys see mocking replacing > AR connecting to a DB in model specs? I was talking to Steve about this today. He's working on an a memory_connection_adapter that you could use instead of a DB as long as you don't write any in-line sql. My thinking is that it's ok to use the DB for AR-backed models and high level acceptance tests (integration tests), but that's all. > > This is somewhere I'd always want to write state-bases specs, pure BDD > notwithstanding, because of AR's thorough integration with my tables. It's not just integration w/ the tables - it's complete reliance on the tables for the data structure. In my view, they are PART of the models and should be included when you're testing the models. I just don't think you need them when you're testing everything else. From ryan at platte.name Sat Jul 15 02:28:58 2006 From: ryan at platte.name (Ryan Platte) Date: Sat, 15 Jul 2006 01:28:58 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> Message-ID: <2f1a1dcb0607142328j420095ecwb7614efd2e1392d5@mail.gmail.com> On 7/14/06, David Chelimsky wrote: > > In the rails-and-pure-BDD context, do you guys see mocking replacing > > AR connecting to a DB in model specs? > > I was talking to Steve about this today. He's working on an a > memory_connection_adapter that you could use instead of a DB as long > as you don't write any in-line sql. Bless him. That's quite a challenge, I tried and quit. The adapter layer really wants you to talk SQL with it. When Madeleine model support was being considered, DHH strongly recommended it go in as a separate thing rather than via an adapter. Custom model objects are quite easy to hook up, even validations mix right in with just, about, one method added. My thought is on my next Rails app I'm going to wrap AR objects with my own models and spec mine first, likely putting validations in mine instead of AR objects. Just apply the shield pattern to AR as I would anything that made my (b|t)dd life more difficult. Thoughts? -- Ryan Platte From brian.takita at gmail.com Sat Jul 15 16:27:41 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 15 Jul 2006 13:27:41 -0700 Subject: [Rspec-devel] [#5072] Test::UnitMigration custom methods are outside of setup Message-ID: <1d7ddd110607151327s9053c11g9e75a66677041ab4@mail.gmail.com> I added a patch that makes the Test::UnitMigration move method declarations outside of the setup block. http://rubyforge.org/tracker/index.php?func=detail&aid=5072&group_id=797&atid=3151 What does everybody else think? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060715/eabd5f3d/attachment.html From brian.takita at gmail.com Sat Jul 15 16:51:16 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 15 Jul 2006 13:51:16 -0700 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> Message-ID: <1d7ddd110607151351p2479b369l6eacdda6ab238ac9@mail.gmail.com> > > I was talking to Steve about this today. He's working on an a > memory_connection_adapter that you could use instead of a DB as long > as you don't write any in-line sql. Even in the case of in-line sql a mock can handle the custom inline sql, providing both assertions and return values. For example we test our deploy scripts by adding a Spy that collects all of the shell commands. We then assert the correct commands are called. Its not deterministic, but its a quick way to verify the external API doesn't change unless you want it to. It's not just integration w/ the tables - it's complete reliance on > the tables for the data structure. In my view, they are PART of the > models and should be included when you're testing the models. I just > don't think you need them when you're testing everything else. Would it be wise to On 7/14/06, David Chelimsky wrote: > > On 7/14/06, Lachie wrote: > > Thanks :) > > > > > -Which is not BDD, but still useful in Rails while waiting for better > > > mock support in rails. > > > > In the rails-and-pure-BDD context, do you guys see mocking replacing > > AR connecting to a DB in model specs? > > I was talking to Steve about this today. He's working on an a > memory_connection_adapter that you could use instead of a DB as long > as you don't write any in-line sql. > > My thinking is that it's ok to use the DB for AR-backed models and > high level acceptance tests (integration tests), but that's all. > > > > > This is somewhere I'd always want to write state-bases specs, pure BDD > > notwithstanding, because of AR's thorough integration with my tables. > > It's not just integration w/ the tables - it's complete reliance on > the tables for the data structure. In my view, they are PART of the > models and should be included when you're testing the models. I just > don't think you need them when you're testing everything else. > _______________________________________________ > 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/20060715/c2679ce1/attachment.html From dchelimsky at gmail.com Sat Jul 15 18:45:26 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 15 Jul 2006 17:45:26 -0500 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <1d7ddd110607151351p2479b369l6eacdda6ab238ac9@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> <1d7ddd110607151351p2479b369l6eacdda6ab238ac9@mail.gmail.com> Message-ID: <57c63afe0607151545h4f890221w3dbfd24ef427ec35@mail.gmail.com> On 7/15/06, Brian Takita wrote: > > It's not just integration w/ the tables - it's complete reliance on > > the tables for the data structure. In my view, they are PART of the > > models and should be included when you're testing the models. I just > > don't think you need them when you're testing everything else. > > Would it be wise to It might be. Wise to what? From brian.takita at gmail.com Sun Jul 16 01:43:48 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 15 Jul 2006 22:43:48 -0700 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607151545h4f890221w3dbfd24ef427ec35@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> <1d7ddd110607151351p2479b369l6eacdda6ab238ac9@mail.gmail.com> <57c63afe0607151545h4f890221w3dbfd24ef427ec35@mail.gmail.com> Message-ID: <1d7ddd110607152243r666daddfw8d851296dd7abd44@mail.gmail.com> > > > > It's not just integration w/ the tables - it's complete reliance on > > > the tables for the data structure. In my view, they are PART of the > > > models and should be included when you're testing the models. I just > > > don't think you need them when you're testing everything else. > > > > Would it be wise to > > It might be. Wise to what? > Sorry about that. I meant to delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060715/ae7cb314/attachment.html From brian.takita at gmail.com Sun Jul 16 01:49:12 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 15 Jul 2006 22:49:12 -0700 Subject: [Rspec-devel] [#5072] Test::UnitMigration custom methods are outside of setup In-Reply-To: <1d7ddd110607151327s9053c11g9e75a66677041ab4@mail.gmail.com> References: <1d7ddd110607151327s9053c11g9e75a66677041ab4@mail.gmail.com> Message-ID: <1d7ddd110607152249p57711ffdm20ed6ed8e6b4e3e6@mail.gmail.com> I'm going to go ahead and commit this. On 7/15/06, Brian Takita wrote: > > I added a patch that makes the Test::UnitMigration move method > declarations outside of the setup block. > > http://rubyforge.org/tracker/index.php?func=detail&aid=5072&group_id=797&atid=3151 > > > What does everybody else think? > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060715/c562b2af/attachment.html From brian.takita at gmail.com Sun Jul 16 03:42:14 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 16 Jul 2006 00:42:14 -0700 Subject: [Rspec-devel] What is a context? Message-ID: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> Hello, I was working adding the inherit and include methods into the documentation, when I noticed that there is nothing about contexts or specifications in the Core Api page. http://rspec.rubyforge.org/documentation/index.html I'm thinking of adding documentation about contexts and specifications, however I'm not sure how to define a context. >From the Stack tutorial, I noticed that a context is used to describet the state of the stack. Are context's meant to be limited to describing the state of the object? Should a context be used to describe a use case? What are the best practices? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060716/6c3b6c48/attachment.html From lists-rspec at shopwatch.org Sun Jul 16 09:06:29 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 16 Jul 2006 09:06:29 -0400 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <57c63afe0607151545h4f890221w3dbfd24ef427ec35@mail.gmail.com> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607140621k53632987k9ca8dea8c7c383a0@mail.gmail.com> <8d961d900607141041s65d328ddue6d523caf79e6d35@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> <1d7ddd110607151351p2479b369l6eacdda6ab238ac9@mail.gmail.com> <57c63afe0607151545h4f890221w3dbfd24ef427ec35@mail.gmail.com> Message-ID: <44BA39D5.1040407@rubyforge.org> David Chelimsky wrote: > On 7/15/06, Brian Takita wrote: >>> It's not just integration w/ the tables - it's complete reliance on >>> the tables for the data structure. In my view, they are PART of the >>> models and should be included when you're testing the models. I just >>> don't think you need them when you're testing everything else. >> Would it be wise to > > It might be. Wise to what? Just, you know, in general. Jay From dchelimsky at gmail.com Sun Jul 16 09:32:52 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 16 Jul 2006 08:32:52 -0500 Subject: [Rspec-devel] What is a context? In-Reply-To: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> Message-ID: <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> On 7/16/06, Brian Takita wrote: > I'm thinking of adding documentation about contexts and specifications, > however I'm not sure how to define a context. > > From the Stack tutorial, I noticed that a context is used to describet the > state of the stack. Are context's meant to be limited to describing the > state of the object? Should a context be used to describe a use case? The approach demonstrated in the stack spec is as you describe - an object or set of objects in a known state. This leads to specs organized like this: context "object, when in state 1" do specify "should do z in response to message a" do end specify "should do y in response to message b" do end end I think that the combination of context and specification names provide use case (granular) descriptions: object, when in state 1 - should do z in response to message a - should do y in response to message b This make sense? Anyone else see it differently? context and specify work well for class level use cases, but It does occur to me that there is room for some other structures for higher level specs that a customer might understand. Maybe context and specify are enough. Thoughts? From lists-rspec at shopwatch.org Sun Jul 16 09:48:43 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 16 Jul 2006 09:48:43 -0400 Subject: [Rspec-devel] What is a context? In-Reply-To: <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> Message-ID: <44BA43BB.1090003@rubyforge.org> David Chelimsky wrote: > > context and specify work well for class level use cases, but It does > occur to me that there is room for some other structures for higher > level specs that a customer might understand. Maybe context and > specify are enough. Thoughts? I've been wondering about this while writing rails specs. For my model, I end up with specs like An otherwise valid receipt - should start out valid - should disallow an empty vendor field - should disallow future purchases - should allow an empty image So, as you say, that maps well. But when I get into the controller specs, they start looking funnier: The ReceiptController - should be a ReceiptController To create a receipt, - get the new receipt form - post a good receipt - post a bad receipt Elsewhere in the receipts controller, - check the receipts list Some of the specs are more like task-lists. Many of the actual specs are now buried down at the should-be level, where they aren't seen in the specdoc. I can't push them up to the specification level, or else I end up with specs depending on other specs - and each spec is executed in a fully-rolled-back context with transactional fixtures, so that doesn't work. The simplest solution would be to allow the "shoulds" to optionally appear in the specdoc. I'm not sure what a more complex solution would look like. Jay > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Sun Jul 16 11:08:22 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 16 Jul 2006 10:08:22 -0500 Subject: [Rspec-devel] What is a context? In-Reply-To: <44BA43BB.1090003@rubyforge.org> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> Message-ID: <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> On 7/16/06, Jay Levitt wrote: > David Chelimsky wrote: > > > > context and specify work well for class level use cases, but It does > > occur to me that there is room for some other structures for higher > > level specs that a customer might understand. Maybe context and > > specify are enough. Thoughts? > > I've been wondering about this while writing rails specs. For my model, > I end up with specs like > > An otherwise valid receipt > - should start out valid > - should disallow an empty vendor field > - should disallow future purchases > - should allow an empty image > > So, as you say, that maps well. But when I get into the controller > specs, they start looking funnier: > > The ReceiptController > - should be a ReceiptController > > To create a receipt, > - get the new receipt form > - post a good receipt > - post a bad receipt > > Elsewhere in the receipts controller, > - check the receipts list > > Some of the specs are more like task-lists. Many of the actual specs > are now buried down at the should-be level, where they aren't seen in > the specdoc. I can't push them up to the specification level, or else I > end up with specs depending on other specs - and each spec is executed > in a fully-rolled-back context with transactional fixtures, so that > doesn't work. Great observations Jay. I think the problem is that the rspec DSL works really well for specifying behaviour of an individual object, while controller specs, as they currently work, are sub-system level integration tests. If you think about the built-in rails functional testing, it's really got its own DSL that is separate from that provided for "unit" and "integration" tests. So probably what we need in rspec_on_rails is a custom DSL - not only at the expectations level (i.e. response.should_blah) but at the structural level as well: context "a new session" do setup do ... end request :controller => :stories, :action => :new do ... end specify "should redirect to login action" do ... end specify "should render login page" do ... end end > > The simplest solution would be to allow the "shoulds" to optionally > appear in the specdoc. I'm not sure what a more complex solution would > look like. We talked about that some months ago. The problem is that the code doesn't always know how far up the call stack to look for the target object: @target.should_equal expected_value @target.property.should_equal expected_value It also complicates the structure a bit. Right now we've got context/specify. To support expectations generating their own reporting we'd probably want context/event/expectations. Then the above example might look more like this: context "a new session" do setup do ... end event :request, :controller => :stories, :action => :new do ... response.should_redirect_to :login end end which could output: given a new session - when a request is received for 'stories/new' - the response should be a redirect to login >From what I've seen, JBehave works more like this. You define contexts, events and expectations in their own classes. Then you define behaviours by stringing them together. It might be a bit more DRY than what we've got, but it also means you have to look in a few different places to understand a failure. Whereas rspec pushes you to keep ALL of the context within a single context. Some people on the list have requested nested contexts and we've been resistant because we want to encourage clarity in specs. However, perhaps events could be the intermediate structure that we're looking for. Thoughts? David From lists-rspec at shopwatch.org Sun Jul 16 12:25:56 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 16 Jul 2006 12:25:56 -0400 Subject: [Rspec-devel] What is a context? In-Reply-To: <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> Message-ID: <44BA6894.4080707@rubyforge.org> David Chelimsky wrote: > Some people on the list have requested nested contexts and we've been > resistant because we want to encourage clarity in specs. However, > perhaps events could be the intermediate structure that we're looking > for. Hmm.. actually, looking at your controller example: > context "a new session" do > setup do > ... > end > > request :controller => :stories, :action => :new do > ... > end > > specify "should redirect to login action" do > ... > end > > specify "should render login page" do > ... > end > > end it makes me wonder if the simplest solution isn't just "in a controller spec, don't roll back between specifications". Each context would still roll back, but within a context, you'd be able to keep pushing forward. In fact, I could see that as a generally useful tool, so it could be an option to context context "a new session", :rollback => false do this that the other that depends on this end It might be useful in certain models, but the default would be "true" for models and "false" for controllers (taken care of by the generator script). Does that cause new problems? It seems easier than events, and solves many of the problems. Jay From dchelimsky at gmail.com Sun Jul 16 12:57:14 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 16 Jul 2006 11:57:14 -0500 Subject: [Rspec-devel] What is a context? In-Reply-To: <44BA6894.4080707@rubyforge.org> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> Message-ID: <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> On 7/16/06, Jay Levitt wrote: > David Chelimsky wrote: > > > Some people on the list have requested nested contexts and we've been > > resistant because we want to encourage clarity in specs. However, > > perhaps events could be the intermediate structure that we're looking > > for. > > Hmm.. actually, looking at your controller example: > > > > context "a new session" do > > setup do > > ... > > end > > > > request :controller => :stories, :action => :new do > > ... > > end > > > > specify "should redirect to login action" do > > ... > > end > > > > specify "should render login page" do > > ... > > end > > > > end > > it makes me wonder if the simplest solution isn't just "in a controller > spec, don't roll back between specifications". Each context would still > roll back, but within a context, you'd be able to keep pushing forward. > > In fact, I could see that as a generally useful tool, so it could be an > option to context > > context "a new session", :rollback => false do > this > that > the other that depends on this > end > > It might be useful in certain models, but the default would be "true" > for models and "false" for controllers (taken care of by the generator > script). > > Does that cause new problems? It seems easier than events, and solves > many of the problems. The main problem it causes is philosophical. There is a guideline in TDD (that we actually like) that tests (in this case specs) should not depend on one another. That said, this is something that could be very useful for scenario testing. I think I'd rather come up w/ a different structure - one that more explicit in stating that we're dealing w/ a sequence of events. Something like this: context "new session" do setup do end scenario "new user registration" do step "user navigates to registration page" do end step "user submits registration form" do end end end The problem I see is how this maps to expectations and how we print out the documentation. As important as it is to have clear and DRY ways to express different levels of specs, it is every bit as important that the resulting docs are clear as well. From lists-rspec at shopwatch.org Sun Jul 16 13:55:00 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 16 Jul 2006 13:55:00 -0400 Subject: [Rspec-devel] What is a context? In-Reply-To: <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> Message-ID: <44BA7D74.4010902@rubyforge.org> David Chelimsky wrote: > That said, this is something that could be very useful for scenario > testing. I think I'd rather come up w/ a different structure - one > that more explicit in stating that we're dealing w/ a sequence of > events. Something like this: > > context "new session" do > setup do > end > scenario "new user registration" do > step "user navigates to registration page" do > end > step "user submits registration form" do > end > end > end I like that a LOT. I wonder if it should be called "story" - is that a more common term for BDD? - but either one sounds good, actually. I especially like calling them "steps". > The problem I see is how this maps to expectations and how we print > out the documentation. Howbout this: Today, a context calls setup, teardown, and rollback. Tomorrow, a context calls setup and teardown, but a scenario calls rollback. A step is just a synonym for a specification. A context has an anonymous scenario by default, so that if we hit a spec with no explicit scenario, rollback still works the way it does today. Mind you, I have yet to get brave enough to look at RSpec's internals, and I'm still a Ruby novice, so that might make no sense in this.. well... context. As important as it is to have clear and DRY > ways to express different levels of specs, it is every bit as > important that the resulting docs are clear as well. Oh, I agree. That's the thing that attracted me to rspec in the first place, even though I'm the only one I'm printing specdocs for. It shows me how far I've got in the design. Jay From dchelimsky at gmail.com Sun Jul 16 14:02:17 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 16 Jul 2006 13:02:17 -0500 Subject: [Rspec-devel] What is a context? In-Reply-To: <44BA7D74.4010902@rubyforge.org> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> <44BA7D74.4010902@rubyforge.org> Message-ID: <57c63afe0607161102j151799f5p962612e963966c94@mail.gmail.com> On 7/16/06, Jay Levitt wrote: > David Chelimsky wrote: > > > That said, this is something that could be very useful for scenario > > testing. I think I'd rather come up w/ a different structure - one > > that more explicit in stating that we're dealing w/ a sequence of > > events. Something like this: > > > > context "new session" do > > setup do > > end > > scenario "new user registration" do > > step "user navigates to registration page" do > > end > > step "user submits registration form" do > > end > > end > > end > > I like that a LOT. I wonder if it should be called "story" - is that a > more common term for BDD? - but either one sounds good, actually. I > especially like calling them "steps" Glad you like this. I think story is higher level - a story contains several scenarios (each of which might be in a different context, so it's not a direct hierarchical mapping). > > > The problem I see is how this maps to expectations and how we print > > out the documentation. > > Howbout this: > > Today, a context calls setup, teardown, and rollback. Tomorrow, a > context calls setup and teardown, but a scenario calls rollback. A step > is just a synonym for a specification. A context has an anonymous > scenario by default, so that if we hit a spec with no explicit scenario, > rollback still works the way it does today. I'd really like to avoid rollback and go straight for "tomorrow". The term rollback brings all sorts of implications that I'd rather avoid, for one. The other thing is that I don't want to start gumming up the DSL with attributes like that - especially if it's only temporary! > > Mind you, I have yet to get brave enough to look at RSpec's internals, > and I'm still a Ruby novice, so that might make no sense in this.. > well... context. ;) It's a bit too easy to make that joke, and I've fallen into the same trap many times before. > As important as it is to have clear and DRY > > ways to express different levels of specs, it is every bit as > > important that the resulting docs are clear as well. > > Oh, I agree. That's the thing that attracted me to rspec in the first > place, even though I'm the only one I'm printing specdocs for. It shows > me how far I've got in the design. That's what it's there for. Glad it's proving helpful as intended! Thanks Jay, David From lists-rspec at shopwatch.org Sun Jul 16 14:04:31 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 16 Jul 2006 14:04:31 -0400 Subject: [Rspec-devel] What is a context? In-Reply-To: <57c63afe0607161102j151799f5p962612e963966c94@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> <44BA7D74.4010902@rubyforge.org> <57c63afe0607161102j151799f5p962612e963966c94@mail.gmail.com> Message-ID: <44BA7FAF.3090506@rubyforge.org> David Chelimsky wrote: > On 7/16/06, Jay Levitt wrote: > Glad you like this. I think story is higher level - a story contains > several scenarios (each of which might be in a different context, so > it's not a direct hierarchical mapping). Yes, that makes sense. >> Today, a context calls setup, teardown, and rollback. Tomorrow, a >> context calls setup and teardown, but a scenario calls rollback. A step >> is just a synonym for a specification. A context has an anonymous >> scenario by default, so that if we hit a spec with no explicit scenario, >> rollback still works the way it does today. > > I'd really like to avoid rollback and go straight for "tomorrow". The > term rollback brings all sorts of implications that I'd rather avoid, > for one. The other thing is that I don't want to start gumming up the > DSL with attributes like that - especially if it's only temporary! Oh, I meant that this is how RSpec works today, in my mind. If that's not really how it works, then my brilliant idea doesn't work at all. Jay From dchelimsky at gmail.com Sun Jul 16 14:09:52 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 16 Jul 2006 13:09:52 -0500 Subject: [Rspec-devel] What is a context? In-Reply-To: <44BA7FAF.3090506@rubyforge.org> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> <44BA7D74.4010902@rubyforge.org> <57c63afe0607161102j151799f5p962612e963966c94@mail.gmail.com> <44BA7FAF.3090506@rubyforge.org> Message-ID: <57c63afe0607161109t62bbc63xac952cdc2c44d85f@mail.gmail.com> On 7/16/06, Jay Levitt wrote: > > I'd really like to avoid rollback and go straight for "tomorrow". The > > term rollback brings all sorts of implications that I'd rather avoid, > > for one. The other thing is that I don't want to start gumming up the > > DSL with attributes like that - especially if it's only temporary! > > Oh, I meant that this is how RSpec works today, in my mind. If that's > not really how it works, then my brilliant idea doesn't work at all. There is currently no control of whether to rollback the context or not. It just does it. It's a good idea, and the implementation will have to do something like that under the hood - I just prefer to use a different word (scenario) rather than making the existing word (specify) more flexible. Cheers, David From brian.takita at gmail.com Sun Jul 16 14:33:01 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 16 Jul 2006 11:33:01 -0700 Subject: [Rspec-devel] What is a context? In-Reply-To: <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> Message-ID: <1d7ddd110607161133t533c4983k8335d197f9cee4bd@mail.gmail.com> > > context "new session" do > setup do > end > scenario "new user registration" do > step "user navigates to registration page" do > end > step "user submits registration form" do > end > end > end Superficially, this looks more like a test rathern than a specification. class TestSession < Test::Unit::TestCase def test_new_user_registration__user_navigates_to_registration_page end def test_new_user_registration__user_submits_registration_form end end Your proposed syntax is more elegant that expressing it with the should syntax: context "new session with new user registration" do setup do end specify "should allow user to navigate to registration page" do end specify "should allow user to submit registration form after navigating to registration page" do end end Some people on the list have requested nested contexts and we've been > resistant because we want to encourage clarity in specs. However, > perhaps events could be the intermediate structure that we're looking > for. The programmer in me really want's the ability to nest the context. I probably won't use it much, and it would probably make it less readable, it makes the DSL more "elegant". Nesting context's are also a very generic solution, which means it communicates less than more specialized language. context > scenerio > step communicates a use case better than context > context > specify. I just wonder if we want to have the nested contexts as a baseline generic language structure that would serve those edge cases where the more specialized language structures do not apply. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060716/c92ec502/attachment.html From dchelimsky at gmail.com Sun Jul 16 14:44:55 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 16 Jul 2006 13:44:55 -0500 Subject: [Rspec-devel] What is a context? In-Reply-To: <1d7ddd110607161133t533c4983k8335d197f9cee4bd@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> <1d7ddd110607161133t533c4983k8335d197f9cee4bd@mail.gmail.com> Message-ID: <57c63afe0607161144y513e7fd6v7fb24ba08eeb2a0d@mail.gmail.com> On 7/16/06, Brian Takita wrote: > The programmer in me really want's the ability to nest the context. I > probably won't use it much, and it would probably make it less readable, it > makes the DSL more "elegant". "slick" maybe. "elegant" implies beauty. Not so sure that this would make things more beautiful. > Nesting context's are also a very generic solution, which means it > communicates less than more specialized language. > context > scenerio > step communicates a use case better than context > > context > specify . > > I just wonder if we want to have the nested contexts as a baseline generic > language structure that would serve those edge cases where the more > specialized language structures do not apply. I really appreciate what you're driving at here. And there is a developer in me as well that would like the convenience of nested contexts for when I'm writing the specs. There are a couple of problems we need to solve to make this work while encouraging readability I'm getting ready to head out, but I'll try to follow up w/ more detail later. David From brian.takita at gmail.com Sun Jul 16 14:58:16 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 16 Jul 2006 11:58:16 -0700 Subject: [Rspec-devel] New proc.should_increment method In-Reply-To: <44BA39D5.1040407@rubyforge.org> References: <8d961d900607132158m7053e30dt704c88d1962ae903@mail.gmail.com> <57c63afe0607141133v5f16d423vbbec53cad3eddd42@mail.gmail.com> <8d961d900607141215r64c472edp14265ebb0c4fc02e@mail.gmail.com> <2c5e719e0607141629n371f2772j3b3f6511ed45c4f8@mail.gmail.com> <8d961d900607141650l79c693a8ga93b9be0e6079de2@mail.gmail.com> <2c5e719e0607141703u38a47adcwaf524523904ab400@mail.gmail.com> <57c63afe0607141905v44ce2932s1fc18516f18cd681@mail.gmail.com> <1d7ddd110607151351p2479b369l6eacdda6ab238ac9@mail.gmail.com> <57c63afe0607151545h4f890221w3dbfd24ef427ec35@mail.gmail.com> <44BA39D5.1040407@rubyforge.org> Message-ID: <1d7ddd110607161158p1a46a9a0qc188421ec2404e78@mail.gmail.com> :) Yeah, thats what I meant to say. On 7/16/06, Jay Levitt wrote: > > David Chelimsky wrote: > > On 7/15/06, Brian Takita wrote: > >>> It's not just integration w/ the tables - it's complete reliance on > >>> the tables for the data structure. In my view, they are PART of the > >>> models and should be included when you're testing the models. I just > >>> don't think you need them when you're testing everything else. > >> Would it be wise to > > > > It might be. Wise to what? > > Just, you know, in general. > > Jay > > _______________________________________________ > 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/20060716/19bd752a/attachment.html From brian.takita at gmail.com Mon Jul 17 12:32:28 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 17 Jul 2006 09:32:28 -0700 Subject: [Rspec-devel] What is a context? In-Reply-To: <57c63afe0607161144y513e7fd6v7fb24ba08eeb2a0d@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> <1d7ddd110607161133t533c4983k8335d197f9cee4bd@mail.gmail.com> <57c63afe0607161144y513e7fd6v7fb24ba08eeb2a0d@mail.gmail.com> Message-ID: <1d7ddd110607170932i7909e679md80568d42454d227@mail.gmail.com> > > > I just wonder if we want to have the nested contexts as a baseline > generic > > language structure that would serve those edge cases where the more > > specialized language structures do not apply. > > I really appreciate what you're driving at here. And there is a > developer in me as well that would like the convenience of nested > contexts for when I'm writing the specs. There are a couple of > problems we need to solve to make this work while encouraging > readability > > I'm getting ready to head out, but I'll try to follow up w/ more detail > later. Sounds good. In the mean time, I punted on giving a definition of a context and just added an example. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060717/8d3dbae7/attachment.html From dastels at daveastels.com Wed Jul 19 19:01:12 2006 From: dastels at daveastels.com (David Astels) Date: Wed, 19 Jul 2006 20:01:12 -0300 Subject: [Rspec-devel] tweak to arbitrary predicate support In-Reply-To: <1d7ddd110607170932i7909e679md80568d42454d227@mail.gmail.com> References: <1d7ddd110607160042u603f3ff1x6d9e204b050dbee@mail.gmail.com> <57c63afe0607160632m7393ed5bmcc73aff08d3b5124@mail.gmail.com> <44BA43BB.1090003@rubyforge.org> <57c63afe0607160808m2b06a53ax69d1e5c93f47930b@mail.gmail.com> <44BA6894.4080707@rubyforge.org> <57c63afe0607160957u508b1f85nefb4b3ca20e520e1@mail.gmail.com> <1d7ddd110607161133t533c4983k8335d197f9cee4bd@mail.gmail.com> <57c63afe0607161144y513e7fd6v7fb24ba08eeb2a0d@mail.gmail.com> <1d7ddd110607170932i7909e679md80568d42454d227@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guys, Here's a tweak to ShouldHelper.method_missing to look for (and use) pred as well as pred? when you say something like result.should.be.> 0 Here's my revised version of the method... I haven't committed it... there's probably a cleaner way to do it. Dave def method_missing(sym, *args) message = default_message("should be #{sym}" + (args.empty? ? '' : (' ' + args.join(', ')))) if @target.respond_to?("#{sym}?") then return if @target.send("#{sym}?", *args) fail_with_message(message) end if @target.respond_to?(sym) then return if @target.send(sym, *args) fail_with_message(message) end Kernel::raise(NoMethodError.new(sym, *args)) end -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEvrm4auez/L4x7g4RAjW+AJ4mzXPwY/f5qy6gHjX4z34uZUMt6wCgjI1n aQNFBXXYfyFJcm2kjB4TL1c= =0SR+ -----END PGP SIGNATURE----- From aslak.hellesoy at gmail.com Fri Jul 21 09:04:55 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 08:04:55 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN Message-ID: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> I think the recent inherit/include features completely broke the RSpec on Rails. If I go to the vendor/rspec_on_rails, follow the instructions in the README and run rake spec I get: /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/api/sugar.rb:17:in `method_missing': undefined method `fixtures' for Object:Class (NoMethodError) from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/context_eval.rb:39:in `method_missing' from ./spec/models/animal_spec.rb:4 from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/context.rb:10:in `initialize' from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/kernel_ext.rb:3:in `context' from ./spec/models/animal_spec.rb:3 from /Users/aslakhellesoy/scm/rspec/trunk/bin/spec:13 from /Users/aslakhellesoy/scm/rspec/trunk/bin/spec:7 Can anyone else reproduce this? Aslak From dchelimsky at gmail.com Fri Jul 21 10:47:29 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 21 Jul 2006 09:47:29 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> Message-ID: <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> Yes, except that mine says /Users/david/ ;) The same thing was happening to me w/ the failing_examples last week and I believe you fixed it. This brings up, once again, two issues that I think we need to resolve: One is that we don't have an automated way to run all of the tests. To me, ensuring that changes don't break the ability to run the examples, failing_examples and the rails examples must be part of the commit process. We need to either agree to do this manually, chopping off the hands of those who fail to comply, or we need to pursue a CI setup that includes the execution of these tasks on every commit. The other is this whole sugar thing. This is like the 5th time it's come up as a problem w/ changes we're making. I propose that we draw a line in the sand right now. We're either committed to it, which means that all changes must be tested to not conflict w/ sugar (which means there should be tests that are expressed using the _ syntax) or we should bag the thing. I'm leaning more and more towards bagging it, but I understand the desires of users to have the more rubyish syntax. It's just that it makes rspec brittle. Maybe it's just that we need an implementation that is less ticklish. Thoughts? David On 7/21/06, aslak hellesoy wrote: > I think the recent inherit/include features completely broke the RSpec on Rails. > > If I go to the vendor/rspec_on_rails, follow the instructions in the > README and run rake spec I get: > > /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/api/sugar.rb:17:in > `method_missing': undefined method `fixtures' for Object:Class > (NoMethodError) > from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/context_eval.rb:39:in > `method_missing' > from ./spec/models/animal_spec.rb:4 > from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/context.rb:10:in > `initialize' > from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/kernel_ext.rb:3:in > `context' > from ./spec/models/animal_spec.rb:3 > from /Users/aslakhellesoy/scm/rspec/trunk/bin/spec:13 > from /Users/aslakhellesoy/scm/rspec/trunk/bin/spec:7 > > Can anyone else reproduce this? > > Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dastels at daveastels.com Fri Jul 21 11:33:31 2006 From: dastels at daveastels.com (David Astels) Date: Fri, 21 Jul 2006 12:33:31 -0300 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21-Jul-06, at 11:47 AM, David Chelimsky wrote: > The other is this whole sugar thing. This is like the 5th time it's > come up as a problem w/ changes we're making. I propose that we draw a > line in the sand right now. We're either committed to it, which means > that all changes must be tested to not conflict w/ sugar (which means > there should be tests that are expressed using the _ syntax) or we > should bag the thing. I'm leaning more and more towards bagging it, > but I understand the desires of users to have the more rubyish syntax. > It's just that it makes rspec brittle. Maybe it's just that we need an > implementation that is less ticklish. > > Thoughts? Bag it & tag it. For the trouble it's caused, it doesn't bring much to the table... 0 functionallity. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEwPPLauez/L4x7g4RAuzpAKDYribvY0gqhmiSOu4qy9o7a90zkwCfWC7S plggcOWqoeU62rnxBdpVjkE= =R/pK -----END PGP SIGNATURE----- From srbaker at pobox.com Fri Jul 21 12:17:21 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 21 Jul 2006 09:17:21 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> Message-ID: <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> >> The other is this whole sugar thing. This is like the 5th time it's >> come up as a problem w/ changes we're making. I propose that we >> draw a >> line in the sand right now. We're either committed to it, which means >> that all changes must be tested to not conflict w/ sugar (which means >> there should be tests that are expressed using the _ syntax) or we >> should bag the thing. I'm leaning more and more towards bagging it, >> but I understand the desires of users to have the more rubyish >> syntax. >> It's just that it makes rspec brittle. Maybe it's just that we >> need an >> implementation that is less ticklish. >> >> Thoughts? > > Bag it & tag it. > Nope. It's what the users want. It'll be made to work. > For the trouble it's caused, it doesn't bring much to the table... 0 > functionallity. -Steven From aslak.hellesoy at gmail.com Fri Jul 21 12:33:11 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 11:33:11 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> Message-ID: <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> On 7/21/06, Steven R. Baker wrote: > >> The other is this whole sugar thing. This is like the 5th time it's > >> come up as a problem w/ changes we're making. I propose that we > >> draw a > >> line in the sand right now. We're either committed to it, which means > >> that all changes must be tested to not conflict w/ sugar (which means > >> there should be tests that are expressed using the _ syntax) or we > >> should bag the thing. I'm leaning more and more towards bagging it, > >> but I understand the desires of users to have the more rubyish > >> syntax. > >> It's just that it makes rspec brittle. Maybe it's just that we > >> need an > >> implementation that is less ticklish. > >> > >> Thoughts? > > > > Bag it & tag it. > > > > Nope. It's what the users want. It'll be made to work. > Make it work. Then say nope. Not the other way around. Aslak > > For the trouble it's caused, it doesn't bring much to the table... 0 > > functionallity. > > -Steven > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From srbaker at pobox.com Fri Jul 21 12:41:36 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 21 Jul 2006 09:41:36 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> Message-ID: <3840ABE9-BA0D-49A8-8C1F-77D60EECC771@pobox.com> >>> Bag it & tag it. >>> >> >> Nope. It's what the users want. It'll be made to work. >> > > Make it work. > Then say nope. > > Not the other way around. Underscores are a requirement. It's already been decided. Now I'm dealing with implementation details. -Steven From dchelimsky at gmail.com Fri Jul 21 12:43:21 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 21 Jul 2006 11:43:21 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> Message-ID: <57c63afe0607210943x1d9610ccl4c776b106970f48@mail.gmail.com> On 7/21/06, Steven R. Baker wrote: > >> The other is this whole sugar thing. This is like the 5th time it's > >> come up as a problem w/ changes we're making. I propose that we > >> draw a > >> line in the sand right now. We're either committed to it, which means > >> that all changes must be tested to not conflict w/ sugar (which means > >> there should be tests that are expressed using the _ syntax) or we > >> should bag the thing. I'm leaning more and more towards bagging it, > >> but I understand the desires of users to have the more rubyish > >> syntax. > >> It's just that it makes rspec brittle. Maybe it's just that we > >> need an > >> implementation that is less ticklish. > >> > >> Thoughts? > > > > Bag it & tag it. > > > > Nope. It's what the users want. It'll be made to work. It's what users want based on the question "what do you want, dots or underscores?" Ask the question "what do you want, underscores or reliability?" and I'll bet you get a different answer. Developing software is always a balancing act between what users want and what is pragmatic. Underscores have continually proved themselves un-pragmatic, and will continue to do so for the life of this project unless we come up w/ a better solution than is currently in place. From srbaker at pobox.com Fri Jul 21 12:48:01 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 21 Jul 2006 09:48:01 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <57c63afe0607210943x1d9610ccl4c776b106970f48@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <57c63afe0607210943x1d9610ccl4c776b106970f48@mail.gmail.com> Message-ID: <24221F4B-A47C-4443-B367-2122D7842F49@pobox.com> > It's what users want based on the question "what do you want, dots or > underscores?" Ask the question "what do you want, underscores or > reliability?" and I'll bet you get a different answer. No, the underscores aren't unreliable. The current implementation of the underscored method sugar has a few oversights that haven't been completely worked around yet. Not a big deal. > Developing software is always a balancing act between what users want > and what is pragmatic. Underscores have continually proved themselves > un-pragmatic, and will continue to do so for the life of this project > unless we come up w/ a better solution than is currently in place. The solution is in the works. At this point, I'm fighting the ceiling of my own understanding of method call order in Ruby. I'm sure this is a simple solution for folks with more metaprogramming-fu. -Steven From aslak.hellesoy at gmail.com Fri Jul 21 12:52:23 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 11:52:23 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> Message-ID: <8d961d900607210952h700fae46uddb60fb800fa733e@mail.gmail.com> On 7/21/06, David Chelimsky wrote: > Yes, except that mine says /Users/david/ ;) > > The same thing was happening to me w/ the failing_examples last week > and I believe you fixed it. > By 'the same thing' do you mean that the build broke, but in a different way than what I described (rails specific) > This brings up, once again, two issues that I think we need to resolve: > > One is that we don't have an automated way to run all of the tests. To > me, ensuring that changes don't break the ability to run the examples, > failing_examples and the rails examples must be part of the commit > process. We need to either agree to do this manually, chopping off the > hands of those who fail to comply, or we need to pursue a CI setup > that includes the execution of these tasks on every commit. > See separate mail > The other is this whole sugar thing. This is like the 5th time it's > come up as a problem w/ changes we're making. I propose that we draw a > line in the sand right now. We're either committed to it, which means > that all changes must be tested to not conflict w/ sugar (which means > there should be tests that are expressed using the _ syntax) or we > should bag the thing. I'm leaning more and more towards bagging it, > but I understand the desires of users to have the more rubyish syntax. > It's just that it makes rspec brittle. Maybe it's just that we need an > implementation that is less ticklish. > > Thoughts? > Steven says he can fix it. If he (or anyone else) can show us the code (either by committing it or submitting a patch) I think we should still try to keep it. Right now the rspec on rails stuff is completely broken, so the underscore bug that happens with rails can't be reproduced until it's fixed. Brian has said he'll try to fix rails - hopefully by using inherit Test::Unit::TestCase and ditching our own fixture code. Let's wait a few days till rails is fixed and see if the underscore bug is still there. Aslak > David > > On 7/21/06, aslak hellesoy wrote: > > I think the recent inherit/include features completely broke the RSpec on Rails. > > > > If I go to the vendor/rspec_on_rails, follow the instructions in the > > README and run rake spec I get: > > > > /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/api/sugar.rb:17:in > > `method_missing': undefined method `fixtures' for Object:Class > > (NoMethodError) > > from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/context_eval.rb:39:in > > `method_missing' > > from ./spec/models/animal_spec.rb:4 > > from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/context.rb:10:in > > `initialize' > > from /Users/aslakhellesoy/scm/rspec/trunk/lib/../lib/spec/runner/kernel_ext.rb:3:in > > `context' > > from ./spec/models/animal_spec.rb:3 > > from /Users/aslakhellesoy/scm/rspec/trunk/bin/spec:13 > > from /Users/aslakhellesoy/scm/rspec/trunk/bin/spec:7 > > > > Can anyone else reproduce this? > > > > Aslak > > _______________________________________________ > > 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 Fri Jul 21 13:06:17 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 12:06:17 -0500 Subject: [Rspec-devel] commit protocol Message-ID: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> Allrighty folks Before you commit (or submit a patch if you are not part of the team), here is the protocol: rake pre_commit This will run all the important stuff, including examples, failing_examples, build the website locally, translate all our tests with test2spec and run them, and finally run the rspec_on_rails' pre_commit rake task (which sanity checks rspec's rails support). If you see "OK TO COMMIT" it's ok to commit. If not, fix what you broke. Since rspec on rails is currently broken (because we didn't have a protocol like this in place) I have added an additional rake task - pre_commit_without rails. We'll use this until our rails stuff is working again, at which point we will delete the task. Aslak From aslak.hellesoy at gmail.com Fri Jul 21 13:10:39 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 12:10:39 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <24221F4B-A47C-4443-B367-2122D7842F49@pobox.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <57c63afe0607210943x1d9610ccl4c776b106970f48@mail.gmail.com> <24221F4B-A47C-4443-B367-2122D7842F49@pobox.com> Message-ID: <8d961d900607211010tb85252es4a74c2dd6f40c041@mail.gmail.com> On 7/21/06, Steven R. Baker wrote: > > It's what users want based on the question "what do you want, dots or > > underscores?" Ask the question "what do you want, underscores or > > reliability?" and I'll bet you get a different answer. > > No, the underscores aren't unreliable. The current implementation of > the underscored method sugar has a few oversights that haven't been > completely worked around yet. Not a big deal. > > > Developing software is always a balancing act between what users want > > and what is pragmatic. Underscores have continually proved themselves > > un-pragmatic, and will continue to do so for the life of this project > > unless we come up w/ a better solution than is currently in place. > > The solution is in the works. At this point, I'm fighting the > ceiling of my own understanding of method call order in Ruby. I'm > sure this is a simple solution for folks with more metaprogramming-fu. > How long do you feel it's acceptable to wait for this to be fixed? Can we set a deadline? Like one month from now or else it's gone? Has anyone had problems with underscores other than in a rails environment? Aslak > -Steven > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From srbaker at pobox.com Fri Jul 21 13:14:10 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 21 Jul 2006 10:14:10 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607211010tb85252es4a74c2dd6f40c041@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <57c63afe0607210943x1d9610ccl4c776b106970f48@mail.gmail.com> <24221F4B-A47C-4443-B367-2122D7842F49@pobox.com> <8d961d900607211010tb85252es4a74c2dd6f40c041@mail.gmail.com> Message-ID: >> >> The solution is in the works. At this point, I'm fighting the >> ceiling of my own understanding of method call order in Ruby. I'm >> sure this is a simple solution for folks with more metaprogramming- >> fu. >> > > How long do you feel it's acceptable to wait for this to be fixed? > Can we set a deadline? Like one month from now or else it's gone? Now that I have my powerbook and am spending more time on this stuff, that's probably reasonable. I've solicited some assistance from folks that have better MetaRuby-fu than I do. I have a personal deadline of approximately 15 September for this, since I have a few things coming up in late September and early October that depend on it. > Has anyone had problems with underscores other than in a rails > environment? It basically breaks anywhere method_missing is overridden by a base class. Namely, ActiveRecord::Base. I'm not aware of any other publicly available software that abuses method_missing quite as wonderfully as we do. ;) -Steven From aslak.hellesoy at gmail.com Fri Jul 21 13:18:36 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 12:18:36 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <57c63afe0607210943x1d9610ccl4c776b106970f48@mail.gmail.com> <24221F4B-A47C-4443-B367-2122D7842F49@pobox.com> <8d961d900607211010tb85252es4a74c2dd6f40c041@mail.gmail.com> Message-ID: <8d961d900607211018q6d321104qa94b832a22dddfb5@mail.gmail.com> On 7/21/06, Steven R. Baker wrote: > >> > >> The solution is in the works. At this point, I'm fighting the > >> ceiling of my own understanding of method call order in Ruby. I'm > >> sure this is a simple solution for folks with more metaprogramming- > >> fu. > >> > > > > How long do you feel it's acceptable to wait for this to be fixed? > > Can we set a deadline? Like one month from now or else it's gone? > > Now that I have my powerbook and am spending more time on this stuff, > that's probably reasonable. Ok, so if underscores still don't work in Rails by the end of August we'll bag it. If someone finds a solution at a later stage, we can always reintroduce it. Aslak > I've solicited some assistance from > folks that have better MetaRuby-fu than I do. I have a personal > deadline of approximately 15 September for this, since I have a few > things coming up in late September and early October that depend on it. > > > Has anyone had problems with underscores other than in a rails > > environment? > > It basically breaks anywhere method_missing is overridden by a base > class. Namely, ActiveRecord::Base. I'm not aware of any other > publicly available software that abuses method_missing quite as > wonderfully as we do. ;) > > -Steven > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From srbaker at pobox.com Fri Jul 21 13:21:26 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 21 Jul 2006 10:21:26 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607211018q6d321104qa94b832a22dddfb5@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <57c63afe0607210943x1d9610ccl4c776b106970f48@mail.gmail.com> <24221F4B-A47C-4443-B367-2122D7842F49@pobox.com> <8d961d900607211010tb85252es4a74c2dd6f40c041@mail.gmail.com> <8d961d900607211018q6d321104qa94b832a22dddfb5@mail.gmail.com> Message-ID: >> >> Now that I have my powerbook and am spending more time on this stuff, >> that's probably reasonable. > > Ok, so if underscores still don't work in Rails by the end of August > we'll bag it. > > If someone finds a solution at a later stage, we can always > reintroduce it. Okay, this is a fair compromise. -Steven From dchelimsky at gmail.com Fri Jul 21 16:46:39 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 21 Jul 2006 15:46:39 -0500 Subject: [Rspec-devel] commit protocol In-Reply-To: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> Message-ID: <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> BRILLIANT! Thanks Aslak, David On 7/21/06, aslak hellesoy wrote: > Allrighty folks > > Before you commit (or submit a patch if you are not part of the team), > here is the protocol: > > rake pre_commit > > This will run all the important stuff, including examples, > failing_examples, build the website locally, translate all our tests > with test2spec and run them, and finally run the rspec_on_rails' > pre_commit rake task (which sanity checks rspec's rails support). > > If you see "OK TO COMMIT" it's ok to commit. If not, fix what you broke. > > Since rspec on rails is currently broken (because we didn't have a > protocol like this in place) I have added an additional rake task - > pre_commit_without rails. We'll use this until our rails stuff is > working again, at which point we will delete the task. > > Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Fri Jul 21 17:35:49 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 21 Jul 2006 16:35:49 -0500 Subject: [Rspec-devel] process for introducing bigger changes Message-ID: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> Fellow rspecers, It has occured to me that a few things have made it into rspec of late that have not really gone through any sort of approval process. I realize that rspec is not yet 1.0, but I've been using it w/ clients and in my own personal pet projects for a while. To that end, I want it to be a bit more stable than it's been. On the other hand, rspec is very early in its evolution, and we want to encourage new ideas and experimentation. To balance the desire for stabilty and vitality (allowing for volitility), I'd like to propose that we get a bit more vigilant about putting big changes into branches (not in the trunk) and getting more feedback from usage before introducing them to the trunk. That should keep releases more stable, but still provide an easy path for experimentation. Thoughts? From dchelimsky at gmail.com Fri Jul 21 17:48:34 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 21 Jul 2006 16:48:34 -0500 Subject: [Rspec-devel] commit protocol In-Reply-To: <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> Message-ID: <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> On 7/21/06, David Chelimsky wrote: > BRILLIANT! OK - not so briliant. I just checked out a fresh copy from the trunk: rake pre_commit (in /Users/david/projects/ruby/rspec-trunk) rm -r doc/output/coverage rm -r doc/output/rdoc rm -r pkg rm -rf doc/output rm -rf spec/translated Loaded suite /usr/local/bin/rcov Started ..................................................................................................................................................................................................................................................................................................................................................................................................... Finished in 0.444527 seconds. 389 tests, 357 assertions, 0 failures, 0 errors Coverage: 96.0% (threshold: 96.3%) rake aborted! Coverage must be at least 96.3% but was 96.0% (See full trace by running task with --trace) DOH! David > > Thanks Aslak, > David > > On 7/21/06, aslak hellesoy wrote: > > Allrighty folks > > > > Before you commit (or submit a patch if you are not part of the team), > > here is the protocol: > > > > rake pre_commit > > > > This will run all the important stuff, including examples, > > failing_examples, build the website locally, translate all our tests > > with test2spec and run them, and finally run the rspec_on_rails' > > pre_commit rake task (which sanity checks rspec's rails support). > > > > If you see "OK TO COMMIT" it's ok to commit. If not, fix what you broke. > > > > Since rspec on rails is currently broken (because we didn't have a > > protocol like this in place) I have added an additional rake task - > > pre_commit_without rails. We'll use this until our rails stuff is > > working again, at which point we will delete the task. > > > > Aslak > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From srbaker at pobox.com Fri Jul 21 18:58:37 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 21 Jul 2006 15:58:37 -0700 Subject: [Rspec-devel] commit protocol In-Reply-To: <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> Message-ID: <7EF9DC76-23F8-4D9B-9068-8D6BE125610E@pobox.com> [snip] > 389 tests, 357 assertions, 0 failures, 0 errors > Coverage: 96.0% (threshold: 96.3%) > rake aborted! > Coverage must be at least 96.3% but was 96.0% [snip] The margin for error in RCov is higher than 4%, so 96% threshold is probably just a little high. In one of the projects at my last job, we had 100% of the lines covered, but RCov only reported 94%. This is due to some bugs in RCov not counting trailing ends, empty newlines, etc. It looks like the margin for error increases with the number of files. -Steven From aslak.hellesoy at gmail.com Fri Jul 21 19:58:06 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 18:58:06 -0500 Subject: [Rspec-devel] commit protocol In-Reply-To: <7EF9DC76-23F8-4D9B-9068-8D6BE125610E@pobox.com> References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> <7EF9DC76-23F8-4D9B-9068-8D6BE125610E@pobox.com> Message-ID: <8d961d900607211658x18e83e08k3ba986cc7de20b66@mail.gmail.com> I have rcov 0.6.0 2006-06-12 what do you have? make sure you have the latest. a On 7/21/06, Steven R. Baker wrote: > [snip] > > > 389 tests, 357 assertions, 0 failures, 0 errors > > Coverage: 96.0% (threshold: 96.3%) > > rake aborted! > > Coverage must be at least 96.3% but was 96.0% > > [snip] > > The margin for error in RCov is higher than 4%, so 96% threshold is > probably just a little high. > > In one of the projects at my last job, we had 100% of the lines > covered, but RCov only reported 94%. This is due to some bugs in > RCov not counting trailing ends, empty newlines, etc. It looks like > the margin for error increases with the number of files. > > -Steven > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Fri Jul 21 19:59:43 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 21 Jul 2006 18:59:43 -0500 Subject: [Rspec-devel] process for introducing bigger changes In-Reply-To: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> References: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> Message-ID: <8d961d900607211659i1beb98c9w3637e04e3e8733ad@mail.gmail.com> On 7/21/06, David Chelimsky wrote: > Fellow rspecers, > > It has occured to me that a few things have made it into rspec of late > that have not really gone through any sort of approval process. I > realize that rspec is not yet 1.0, but I've been using it w/ clients > and in my own personal pet projects for a while. To that end, I want > it to be a bit more stable than it's been. > > On the other hand, rspec is very early in its evolution, and we want > to encourage new ideas and experimentation. > > To balance the desire for stabilty and vitality (allowing for > volitility), I'd like to propose that we get a bit more vigilant about > putting big changes into branches (not in the trunk) and getting more > feedback from usage before introducing them to the trunk. That should > keep releases more stable, but still provide an easy path for > experimentation. > agree. anything big needs to be discussed first. big things are likely to be put on a branch. a > Thoughts? > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From srbaker at pobox.com Fri Jul 21 20:05:42 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 21 Jul 2006 17:05:42 -0700 Subject: [Rspec-devel] process for introducing bigger changes In-Reply-To: <8d961d900607211659i1beb98c9w3637e04e3e8733ad@mail.gmail.com> References: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> <8d961d900607211659i1beb98c9w3637e04e3e8733ad@mail.gmail.com> Message-ID: <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> > agree. anything big needs to be discussed first. big things are likely > to be put on a branch. I think an even better approach is to just put stuff on a branch. No discussion required to create a branch. This stuff is easier to talk about when it's somewhere that we can see. -Steven From brian.takita at gmail.com Sat Jul 22 00:49:53 2006 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 21 Jul 2006 21:49:53 -0700 Subject: [Rspec-devel] process for introducing bigger changes In-Reply-To: <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> References: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> <8d961d900607211659i1beb98c9w3637e04e3e8733ad@mail.gmail.com> <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> Message-ID: <1d7ddd110607212149w31924451o6f2297b77b39dc4d@mail.gmail.com> I agree. On 7/21/06, Steven R. Baker wrote: > > > agree. anything big needs to be discussed first. big things are likely > > to be put on a branch. > > I think an even better approach is to just put stuff on a branch. No > discussion required to create a branch. This stuff is easier to talk > about when it's somewhere that we can see. > > -Steven > _______________________________________________ > 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/20060721/172da114/attachment.html From brian.takita at gmail.com Sat Jul 22 04:27:19 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 22 Jul 2006 01:27:19 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607210952h700fae46uddb60fb800fa733e@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <8d961d900607210952h700fae46uddb60fb800fa733e@mail.gmail.com> Message-ID: <1d7ddd110607220127i7108c263o9a11249d1325c562@mail.gmail.com> > > Brian has said he'll try to fix rails - hopefully by using inherit > Test::Unit::TestCase and ditching our own fixture code. I created a branch that fixes all of the tests except the nil.should error and rcov. svn+ssh://rubyforge.org/var/svn/rspec/branches/rails_plugin_fix The Rails plugin now inherits from Test::Unit::TestCase and uses its fixtures. I also removed fixture_loading.rb. Would somebody like to merge it into trunk or should I? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060722/025c71c7/attachment.html From dchelimsky at gmail.com Sat Jul 22 08:53:54 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 22 Jul 2006 07:53:54 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <1d7ddd110607220127i7108c263o9a11249d1325c562@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <8d961d900607210952h700fae46uddb60fb800fa733e@mail.gmail.com> <1d7ddd110607220127i7108c263o9a11249d1325c562@mail.gmail.com> Message-ID: <57c63afe0607220553n4169370ch8a84f959454b654c@mail.gmail.com> On 7/22/06, Brian Takita wrote: > > Brian has said he'll try to fix rails - hopefully by using inherit > > Test::Unit::TestCase and ditching our own fixture code. > > I created a branch that fixes all of the tests except the nil.should error > and rcov. > svn+ssh://rubyforge.org/var/svn/rspec/branches/rails_plugin_fix > > The Rails plugin now inherits from Test::Unit::TestCase and uses its > fixtures. I also removed fixture_loading.rb. > Would somebody like to merge it into trunk or should I? Can we have a little "burn-in" period? Before we move it into trunk, I think the rest of us should use it for a few days to make sure it's working as we expect. This is what I was talking about in the other thread - the quick jump to get stuff into the trunk. From dastels at daveastels.com Sat Jul 22 10:00:27 2006 From: dastels at daveastels.com (David Astels) Date: Sat, 22 Jul 2006 11:00:27 -0300 Subject: [Rspec-devel] process for introducing bigger changes In-Reply-To: <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> References: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> <8d961d900607211659i1beb98c9w3637e04e3e8733ad@mail.gmail.com> <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> Message-ID: <2828EDF0-4731-4E34-9459-D5F875B38BC8@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21-Jul-06, at 9:05 PM, Steven R. Baker wrote: >> agree. anything big needs to be discussed first. big things are >> likely >> to be put on a branch. > > I think an even better approach is to just put stuff on a branch. No > discussion required to create a branch. This stuff is easier to talk > about when it's somewhere that we can see. +1 Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEwi98auez/L4x7g4RAp5XAJ9JfCnfmifOfoCUy/HswiwleSqAwQCfXWPD PuvQ44gWL5zUyKB3AnhiQ0E= =AKDl -----END PGP SIGNATURE----- From dchelimsky at gmail.com Sat Jul 22 10:04:01 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 22 Jul 2006 09:04:01 -0500 Subject: [Rspec-devel] process for introducing bigger changes In-Reply-To: <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> References: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> <8d961d900607211659i1beb98c9w3637e04e3e8733ad@mail.gmail.com> <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> Message-ID: <57c63afe0607220704k6073a582n8b084cb52bb86d14@mail.gmail.com> On 7/21/06, Steven R. Baker wrote: > > agree. anything big needs to be discussed first. big things are likely > > to be put on a branch. > > I think an even better approach is to just put stuff on a branch. No > discussion required to create a branch. This stuff is easier to talk > about when it's somewhere that we can see. +1 Wish I had thought of that ;) From dastels at daveastels.com Sat Jul 22 10:04:24 2006 From: dastels at daveastels.com (David Astels) Date: Sat, 22 Jul 2006 11:04:24 -0300 Subject: [Rspec-devel] commit protocol In-Reply-To: <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21-Jul-06, at 6:48 PM, David Chelimsky wrote: > On 7/21/06, David Chelimsky wrote: >> BRILLIANT! > > OK - not so briliant. > Coverage: 96.0% (threshold: 96.3%) > rake aborted! > Coverage must be at least 96.3% but was 96.0% IMO failing the build due to a coverage # is a bad idea. David's mentioned this earlier... it should give a warning. Coverage is not a reason to fail the build and prevent a gem from being built. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEwjBpauez/L4x7g4RAuybAJ9/9F+gspHjPL19Q4biAY/NIdnFkwCfcoAC mrNNbuJZDwDAtSsGNwRoviA= =8CPi -----END PGP SIGNATURE----- From dchelimsky at gmail.com Sat Jul 22 10:08:07 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 22 Jul 2006 09:08:07 -0500 Subject: [Rspec-devel] commit protocol In-Reply-To: References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> Message-ID: <57c63afe0607220708i251ecd9y861e9689f8234a85@mail.gmail.com> On 7/22/06, David Astels wrote: > On 21-Jul-06, at 6:48 PM, David Chelimsky wrote: > > > On 7/21/06, David Chelimsky wrote: > >> BRILLIANT! > > > > OK - not so briliant. > > Coverage: 96.0% (threshold: 96.3%) > > rake aborted! > > Coverage must be at least 96.3% but was 96.0% > > IMO failing the build due to a coverage # is a bad idea. > > David's mentioned this earlier... it should give a warning. Coverage > is not a reason to fail the build and prevent a gem from being built. What about a hybrid approach where we warn if it drops, but we fail if it gets below a team-agreed threshold like 90%? From aslak.hellesoy at gmail.com Sat Jul 22 10:17:50 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Jul 2006 09:17:50 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <57c63afe0607220553n4169370ch8a84f959454b654c@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <8d961d900607210952h700fae46uddb60fb800fa733e@mail.gmail.com> <1d7ddd110607220127i7108c263o9a11249d1325c562@mail.gmail.com> <57c63afe0607220553n4169370ch8a84f959454b654c@mail.gmail.com> Message-ID: <8d961d900607220717s4f3d9f83v7a30df383fc1a00b@mail.gmail.com> On 7/22/06, David Chelimsky wrote: > On 7/22/06, Brian Takita wrote: > > > Brian has said he'll try to fix rails - hopefully by using inherit > > > Test::Unit::TestCase and ditching our own fixture code. > > > > I created a branch that fixes all of the tests except the nil.should error > > and rcov. > > svn+ssh://rubyforge.org/var/svn/rspec/branches/rails_plugin_fix > > > > The Rails plugin now inherits from Test::Unit::TestCase and uses its > > fixtures. I also removed fixture_loading.rb. Wicked > > Would somebody like to merge it into trunk or should I? > > Can we have a little "burn-in" period? Before we move it into trunk, I > think the rest of us should use it for a few days to make sure it's > working as we expect. This is what I was talking about in the other > thread - the quick jump to get stuff into the trunk. I'll try it out later today. I have many rails specs, so I should be able to give it a good spin. You can merge it to trunk later, but I agree with David - Let's let it prove its maturity first. Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Jul 22 10:19:53 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Jul 2006 09:19:53 -0500 Subject: [Rspec-devel] process for introducing bigger changes In-Reply-To: <57c63afe0607220704k6073a582n8b084cb52bb86d14@mail.gmail.com> References: <57c63afe0607211435p4f3cc18cjcb99866fba6bd318@mail.gmail.com> <8d961d900607211659i1beb98c9w3637e04e3e8733ad@mail.gmail.com> <61F7104E-E526-4323-B655-7C74239C11C6@pobox.com> <57c63afe0607220704k6073a582n8b084cb52bb86d14@mail.gmail.com> Message-ID: <8d961d900607220719ped6a996w6c4940c3c510e337@mail.gmail.com> On 7/22/06, David Chelimsky wrote: > On 7/21/06, Steven R. Baker wrote: > > > agree. anything big needs to be discussed first. big things are likely > > > to be put on a branch. > > > > I think an even better approach is to just put stuff on a branch. No > > discussion required to create a branch. This stuff is easier to talk > > about when it's somewhere that we can see. > > +1 > > Wish I had thought of that ;) +1 Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Jul 22 10:26:47 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Jul 2006 09:26:47 -0500 Subject: [Rspec-devel] commit protocol In-Reply-To: <57c63afe0607220708i251ecd9y861e9689f8234a85@mail.gmail.com> References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> <57c63afe0607220708i251ecd9y861e9689f8234a85@mail.gmail.com> Message-ID: <8d961d900607220726l604e38b2j10c60e159c6cc8a9@mail.gmail.com> On 7/22/06, David Chelimsky wrote: > On 7/22/06, David Astels wrote: > > On 21-Jul-06, at 6:48 PM, David Chelimsky wrote: > > > > > On 7/21/06, David Chelimsky wrote: > > >> BRILLIANT! > > > > > > OK - not so briliant. > > > Coverage: 96.0% (threshold: 96.3%) > > > rake aborted! > > > Coverage must be at least 96.3% but was 96.0% > > > > IMO failing the build due to a coverage # is a bad idea. > > > > David's mentioned this earlier... it should give a warning. Coverage > > is not a reason to fail the build and prevent a gem from being built. > > What about a hybrid approach where we warn if it drops, but we fail if > it gets below a team-agreed threshold like 90%? You won't see a warning. It will fly by in the middle of the build. And things will deteriorate without anyone noticing. Regressions should be dealt with when they occur. Dealing with it is easy, as you will see below. In fact, I prefer to have the build break if it is not EQUAL to the current threshold. Then you have three choices: 1) The actual coverage was higher than the current threshold. You increase the threshold. (Without a build failure you'll forget to do this). 2) The actual coverage was lower than the current threshold because of sloppiness. You write more tests until it's back to where it was. 3) The actual coverage was lower than the current threshold because you wrote some code that is too hard to test. You lower the threshold to your current coverage. I have been using this on several ThoughtWorks projects and it works well. Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Jul 22 10:28:34 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Jul 2006 09:28:34 -0500 Subject: [Rspec-devel] commit protocol In-Reply-To: <8d961d900607220726l604e38b2j10c60e159c6cc8a9@mail.gmail.com> References: <8d961d900607211006h79ca56a5w2fc13c69970812b8@mail.gmail.com> <57c63afe0607211346s17309970i21b9c2a29dbd452@mail.gmail.com> <57c63afe0607211448g3bd94435vbb0e024ebd54bfa4@mail.gmail.com> <57c63afe0607220708i251ecd9y861e9689f8234a85@mail.gmail.com> <8d961d900607220726l604e38b2j10c60e159c6cc8a9@mail.gmail.com> Message-ID: <8d961d900607220728q3e56fb7bo764360e832400bcb@mail.gmail.com> On 7/22/06, aslak hellesoy wrote: > On 7/22/06, David Chelimsky wrote: > > On 7/22/06, David Astels wrote: > > > On 21-Jul-06, at 6:48 PM, David Chelimsky wrote: > > > > > > > On 7/21/06, David Chelimsky wrote: > > > >> BRILLIANT! > > > > > > > > OK - not so briliant. > > > > Coverage: 96.0% (threshold: 96.3%) > > > > rake aborted! > > > > Coverage must be at least 96.3% but was 96.0% > > > > > > IMO failing the build due to a coverage # is a bad idea. > > > > > > David's mentioned this earlier... it should give a warning. Coverage > > > is not a reason to fail the build and prevent a gem from being built. > > > > What about a hybrid approach where we warn if it drops, but we fail if > > it gets below a team-agreed threshold like 90%? > > You won't see a warning. It will fly by in the middle of the build. To be more clear - if we put in a warning, you're likely to miss it. There is a lot of output on the screen. > And things will deteriorate without anyone noticing. Regressions > should be dealt with when they occur. Dealing with it is easy, as you > will see below. > > In fact, I prefer to have the build break if it is not EQUAL to the > current threshold. Then you have three choices: > > 1) The actual coverage was higher than the current threshold. You > increase the threshold. (Without a build failure you'll forget to do > this). > > 2) The actual coverage was lower than the current threshold because of > sloppiness. You write more tests until it's back to where it was. > > 3) The actual coverage was lower than the current threshold because > you wrote some code that is too hard to test. You lower the threshold > to your current coverage. > > I have been using this on several ThoughtWorks projects and it works well. > > Aslak > > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From brian.takita at gmail.com Sat Jul 22 13:42:57 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 22 Jul 2006 10:42:57 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607220717s4f3d9f83v7a30df383fc1a00b@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <8d961d900607210952h700fae46uddb60fb800fa733e@mail.gmail.com> <1d7ddd110607220127i7108c263o9a11249d1325c562@mail.gmail.com> <57c63afe0607220553n4169370ch8a84f959454b654c@mail.gmail.com> <8d961d900607220717s4f3d9f83v7a30df383fc1a00b@mail.gmail.com> Message-ID: <1d7ddd110607221042s2510c932hd29ced53f1697d5b@mail.gmail.com> > > Can we have a little "burn-in" period? Before we move it into trunk, I > think the rest of us should use it for a few days to make sure it's > working as we expect. That makes sense. I was unsure because the trunk is broken. If the trunk is broken, are we going to allow other checkins, or should the build be fixed first? There are also a couple of failing tests. The rcov test and the spec "should have no name (this fails because of a conflict with sugar's use of method_missing)" in person_spec.rb fails. Until we can fix them, should we let them fail or comment them out? I'll try it out later today. I have many rails specs, so I should be > able to give it a good spin. Sounds great. Is there an open source rails project out there that uses rspec? That project can be a good baseline to test changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060722/16c9e341/attachment.html From aslak.hellesoy at gmail.com Sat Jul 22 13:48:43 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Jul 2006 12:48:43 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <1d7ddd110607221042s2510c932hd29ced53f1697d5b@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <8d961d900607210952h700fae46uddb60fb800fa733e@mail.gmail.com> <1d7ddd110607220127i7108c263o9a11249d1325c562@mail.gmail.com> <57c63afe0607220553n4169370ch8a84f959454b654c@mail.gmail.com> <8d961d900607220717s4f3d9f83v7a30df383fc1a00b@mail.gmail.com> <1d7ddd110607221042s2510c932hd29ced53f1697d5b@mail.gmail.com> Message-ID: <8d961d900607221048o4ea40bci6729e7b28eab230a@mail.gmail.com> On 7/22/06, Brian Takita wrote: > > > Can we have a little "burn-in" period? Before we move it into trunk, I > > think the rest of us should use it for a few days to make sure it's > > working as we expect. > > > That makes sense. I was unsure because the trunk is broken. If the trunk is > broken, are we going to allow other checkins, or should the build be fixed > first? > I think it's ok to work on trunk despite that rails is broken. That's why I added the temporary rake task pre_checkin_without_rails > There are also a couple of failing tests. > The rcov test and the spec "should have no name (this fails because of a > conflict with sugar's use of method_missing)" in person_spec.rb fails. Until > we can fix them, should we let them fail or comment them out? > I'd say we comment it out and log a separate bug (I may have done that already) > > > I'll try it out later today. I have many rails specs, so I should be > > able to give it a good spin. > > > Sounds great. > Is there an open source rails project out there that uses rspec? That > project can be a good baseline to test changes. > I have a closed source one. I have already tried your stuff, and it's working great in our local testapp. However, I have found some problems regarding the packaging of the generator gem and how things (don't) work when installed over a different project. I'm looking into that, but will probably not have anything to commit in a couple of days (busy). I think we should rethink how we package the generator gem. I think we should generate a plugin with all the secondhand generators underneath it. More on this later. Aslak > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From brian.takita at gmail.com Sat Jul 22 16:00:01 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 22 Jul 2006 13:00:01 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> Message-ID: <1d7ddd110607221300k2928e1c1t3cdeafbb5069f65c@mail.gmail.com> I fixed the nil.should_* methods for rspec_on_rails. The fix is in the rails_plugin_fix branch. On 7/21/06, aslak hellesoy wrote: > > On 7/21/06, Steven R. Baker wrote: > > >> The other is this whole sugar thing. This is like the 5th time it's > > >> come up as a problem w/ changes we're making. I propose that we > > >> draw a > > >> line in the sand right now. We're either committed to it, which means > > >> that all changes must be tested to not conflict w/ sugar (which means > > >> there should be tests that are expressed using the _ syntax) or we > > >> should bag the thing. I'm leaning more and more towards bagging it, > > >> but I understand the desires of users to have the more rubyish > > >> syntax. > > >> It's just that it makes rspec brittle. Maybe it's just that we > > >> need an > > >> implementation that is less ticklish. > > >> > > >> Thoughts? > > > > > > Bag it & tag it. > > > > > > > Nope. It's what the users want. It'll be made to work. > > > > Make it work. > Then say nope. > > Not the other way around. > > Aslak > > > > For the trouble it's caused, it doesn't bring much to the table... 0 > > > functionallity. > > > > -Steven > > > > _______________________________________________ > > 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/20060722/284463cc/attachment.html From dchelimsky at gmail.com Sat Jul 22 18:09:09 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 22 Jul 2006 17:09:09 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <1d7ddd110607221300k2928e1c1t3cdeafbb5069f65c@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> <1d7ddd110607221300k2928e1c1t3cdeafbb5069f65c@mail.gmail.com> Message-ID: <57c63afe0607221509s69c610beoc732d3c192607c21@mail.gmail.com> On 7/22/06, Brian Takita wrote: > I fixed the nil.should_* methods for rspec_on_rails. The fix is in the > rails_plugin_fix branch. Thanks Brian. Couple of things: It looks like you mostly copied some sugar code into rspec_on_rails.rb. I'm a little concerned about the duplication. Sugar keeps changing whenever we find a case we forgot to test - now that's going to have to happen in two places. What do you think about just keeping the NilClass patching in sugar.rb? At least then it's all in the same file. Also, when I grabbed the branch and followed the directions in the README file in rspec_on_rails, I got the following: ../../bin/test2spec --template spec/test2spec.erb --specdir spec/models test/unit Writing translated specs to spec/models Creating : spec/models/animal_spec.rb Failed to translate ActionController::IntegrationTest Done So there still seems to be a translation problem. I won't have a chance to look at this for probably a week, so if anyone else has time, please check it out. Thanks, David From aslak.hellesoy at gmail.com Sat Jul 22 22:04:28 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Jul 2006 21:04:28 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <57c63afe0607221509s69c610beoc732d3c192607c21@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> <1d7ddd110607221300k2928e1c1t3cdeafbb5069f65c@mail.gmail.com> <57c63afe0607221509s69c610beoc732d3c192607c21@mail.gmail.com> Message-ID: <8d961d900607221904y5bfec2aep5b73f78a574f962a@mail.gmail.com> On 7/22/06, David Chelimsky wrote: > On 7/22/06, Brian Takita wrote: > > I fixed the nil.should_* methods for rspec_on_rails. The fix is in the > > rails_plugin_fix branch. > > Thanks Brian. > > Couple of things: > > It looks like you mostly copied some sugar code into > rspec_on_rails.rb. I'm a little concerned about the duplication. Sugar > keeps changing whenever we find a case we forgot to test - now that's > going to have to happen in two places. > I'm still getting a nil.should_be error on the rails_plugin_fix branch. It might be because I moved that file from lib to the template dir and merges got lost. (Subversion didn't tell me anything though). The reason I moved it is that the gem's lib directory isn't automatically available, so I moved the runtime code to a plugin instead. (This plugin gets installed by the generator). Anyway, I think the packaging is > What do you think about just keeping the NilClass patching in > sugar.rb? At least then it's all in the same file. > I agree - it's ok to patch core on this branch. > Also, when I grabbed the branch and followed the directions in the > README file in rspec_on_rails, I got the following: > > ../../bin/test2spec --template spec/test2spec.erb --specdir > spec/models test/unit > Writing translated specs to spec/models > Creating : spec/models/animal_spec.rb > Failed to translate ActionController::IntegrationTest > You can run test2spec with --verbose to get more info. Let's focus on the core features of RSpec on Rails for now, and get it back to trunk as soon as the important stuff (i.e. running specs) is ok. We can work on the translation later. Translation of Rails tests should be part of rspec on rails' pre_commit. Aslak > Done > > So there still seems to be a translation problem. I won't have a > chance to look at this for probably a week, so if anyone else has > time, please check it out. > Me neither - I'm heading to Agile2006, as is David. Aslak > Thanks, > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sun Jul 23 17:41:04 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 23 Jul 2006 14:41:04 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <8d961d900607221904y5bfec2aep5b73f78a574f962a@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> <1d7ddd110607221300k2928e1c1t3cdeafbb5069f65c@mail.gmail.com> <57c63afe0607221509s69c610beoc732d3c192607c21@mail.gmail.com> <8d961d900607221904y5bfec2aep5b73f78a574f962a@mail.gmail.com> Message-ID: <1d7ddd110607231441t50379659w19adcf24b3351a7a@mail.gmail.com> > > I'm still getting a nil.should_be error on the rails_plugin_fix > branch. It might be because I moved that file from lib to the template > dir and merges got lost. (Subversion didn't tell me anything though). > It looks like test_helper.rb was not calling require File.expand_path(File.dirname(__FILE__) + "/../vendor/plugins/rspec_on_rails/lib/rspec_on_rails") The reason I moved it is that the gem's lib directory isn't > automatically available, so I moved the runtime code to a plugin > instead. (This plugin gets installed by the generator). > Anyway, I think the packaging is > It looks like you mostly copied some sugar code into > > rspec_on_rails.rb. I'm a little concerned about the duplication. Sugar > > keeps changing whenever we find a case we forgot to test - now that's > > going to have to happen in two places. > > What do you think about just keeping the NilClass patching in > > sugar.rb? At least then it's all in the same file. I created a method named Spec::Api::Sugar.sugarize(klass) that takes a class or module and adds the new method_missing method. Instead of: class Object include Spec::Api::Sugar end one would use: Spec::Api::Sugar.sugarize(Object) Rspec on Rails calls Spec::Api::Sugar.sugarize(NilClass) to fix the bug. I agree - it's ok to patch core on this branch. Does that mean I should merge this branch into the trunk? > Also, when I grabbed the branch and followed the directions in the > > README file in rspec_on_rails, I got the following: > > > > ../../bin/test2spec --template spec/test2spec.erb --specdir > > spec/models test/unit > > Writing translated specs to spec/models > > Creating : spec/models/animal_spec.rb > > Failed to translate ActionController::IntegrationTest > > > > You can run test2spec with --verbose to get more info. > Let's focus on the core features of RSpec on Rails for now, and get it > back to trunk as soon as the important stuff (i.e. running specs) is > ok. We can work on the translation later. Translation of Rails tests > should be part of rspec on rails' pre_commit. Good idea. > > > So there still seems to be a translation problem. I won't have a > > chance to look at this for probably a week, so if anyone else has > > time, please check it out. > > > > Me neither - I'm heading to Agile2006, as is David. > Have a good time. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060723/880b8534/attachment.html From brian.takita at gmail.com Sun Jul 23 18:26:31 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 23 Jul 2006 15:26:31 -0700 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <1d7ddd110607231441t50379659w19adcf24b3351a7a@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> <1d7ddd110607221300k2928e1c1t3cdeafbb5069f65c@mail.gmail.com> <57c63afe0607221509s69c610beoc732d3c192607c21@mail.gmail.com> <8d961d900607221904y5bfec2aep5b73f78a574f962a@mail.gmail.com> <1d7ddd110607231441t50379659w19adcf24b3351a7a@mail.gmail.com> Message-ID: <1d7ddd110607231526k6aa7a150h843831dec81132fb@mail.gmail.com> I refactored the sugarize methods to be on Module objects: E.g. Object.sugarize_for_rspec! and NilClass.sugarize_for_rspec! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060723/c36da1b6/attachment.html From chrisjroos at gmail.com Thu Jul 27 11:44:49 2006 From: chrisjroos at gmail.com (Chris Roos) Date: Thu, 27 Jul 2006 16:44:49 +0100 Subject: [Rspec-devel] Only require diff-lcs in diff_test rather than test_helper Message-ID: <3a5e51050607270844n25d11210kad153e57f30b26c2@mail.gmail.com> I don't have diff-lcs installed but would like to run some of the test suites individually. As diff-lcs is required in test_helper I get errors when trying to run any of the tests. A quick inspection appears to reveal that diff-lcs is only required in diff_test.rb. I wonder if the require (diff-lcs) should be moved from test_helper to diff_test.rb? It seems to work fine having made this change locally. Chris From aslak.hellesoy at gmail.com Fri Jul 28 06:01:53 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 28 Jul 2006 05:01:53 -0500 Subject: [Rspec-devel] Only require diff-lcs in diff_test rather than test_helper In-Reply-To: <3a5e51050607270844n25d11210kad153e57f30b26c2@mail.gmail.com> References: <3a5e51050607270844n25d11210kad153e57f30b26c2@mail.gmail.com> Message-ID: <8d961d900607280301m7e1db885s11c27c4d154a35be@mail.gmail.com> Please file a bug report at rubyforge so we can remember to fix this in a future release. Aslak On 7/27/06, Chris Roos wrote: > I don't have diff-lcs installed but would like to run some of the test > suites individually. As diff-lcs is required in test_helper I get > errors when trying to run any of the tests. > > A quick inspection appears to reveal that diff-lcs is only required in > diff_test.rb. I wonder if the require (diff-lcs) should be moved from > test_helper to diff_test.rb? It seems to work fine having made this > change locally. > > Chris > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From chrisjroos at gmail.com Fri Jul 28 09:41:54 2006 From: chrisjroos at gmail.com (Chris Roos) Date: Fri, 28 Jul 2006 14:41:54 +0100 Subject: [Rspec-devel] Only require diff-lcs in diff_test rather than test_helper In-Reply-To: <8d961d900607280301m7e1db885s11c27c4d154a35be@mail.gmail.com> References: <3a5e51050607270844n25d11210kad153e57f30b26c2@mail.gmail.com> <8d961d900607280301m7e1db885s11c27c4d154a35be@mail.gmail.com> Message-ID: <3a5e51050607280641h754c290bk7a229ef5af40ddc@mail.gmail.com> Added as bug to rubyforge. On 7/28/06, aslak hellesoy wrote: > Please file a bug report at rubyforge so we can remember to fix this > in a future release. > > Aslak > > On 7/27/06, Chris Roos wrote: > > I don't have diff-lcs installed but would like to run some of the test > > suites individually. As diff-lcs is required in test_helper I get > > errors when trying to run any of the tests. > > > > A quick inspection appears to reveal that diff-lcs is only required in > > diff_test.rb. I wonder if the require (diff-lcs) should be moved from > > test_helper to diff_test.rb? It seems to work fine having made this > > change locally. > > > > Chris > > _______________________________________________ > > 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 Mon Jul 31 00:59:25 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 30 Jul 2006 23:59:25 -0500 Subject: [Rspec-devel] rails_plugin_fix merged to trunk Message-ID: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com> Hi all, Brian's great work on branches/rails_plugin_fix has been merged back to trunk. In other words, rake pre_commit now passes (It runs *all* the stuff that can break, including rails stuff). There is a structural change too. We decided to ditch the generator/gem packaging scheme for the rails stuff. It's just a plugin now. We need to update our docs about how to install it since installing a given version of it will now rely on svn tags. There is still some cleanup to do in the rails code, but it's getting a lot cleaner and no longer duplicates *any* of the fixtures stuff thanks to the new inherit method (thanks again Brian). Does everyone still agree that we should lose the "controller/functional test" support and go for integration specs instead? (Using rails' app object). I think this would still make it possible to write specs for controllers, but in a better way. And for view stuff I'd like to try out something like this: http://www.fearoffish.co.uk/articles/2006/07/28/testing_views_with_style Regarding backwards compatibilty of the railsy stuff, I'd say we don't try to keep things BWC. We're only at 0.5.x and it would be too much of a commitment. Let's get it right instead. Aslak From aslak.hellesoy at gmail.com Mon Jul 31 01:02:56 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 31 Jul 2006 00:02:56 -0500 Subject: [Rspec-devel] Rspec on Rails is broken in SVN In-Reply-To: <1d7ddd110607231526k6aa7a150h843831dec81132fb@mail.gmail.com> References: <8d961d900607210604sdcd050ck1f00f984681610d8@mail.gmail.com> <57c63afe0607210747k14f284e2m901931938d5834c8@mail.gmail.com> <959D4720-DA9C-4214-BD96-2B5589EEAD72@pobox.com> <8d961d900607210933h50786ca4o59f85891a3b7a14b@mail.gmail.com> <1d7ddd110607221300k2928e1c1t3cdeafbb5069f65c@mail.gmail.com> <57c63afe0607221509s69c610beoc732d3c192607c21@mail.gmail.com> <8d961d900607221904y5bfec2aep5b73f78a574f962a@mail.gmail.com> <1d7ddd110607231441t50379659w19adcf24b3351a7a@mail.gmail.com> <1d7ddd110607231526k6aa7a150h843831dec81132fb@mail.gmail.com> Message-ID: <8d961d900607302202t24a0bbc3k3d09408de64e9ea3@mail.gmail.com> Allright! The underscore bug should now be fixed. The fix was part of the recent merge to trunk. I think we should keep using underscores as the recommended way to go for now. Let's revisit if it crops up again. Aslak On 7/23/06, Brian Takita wrote: > I refactored the sugarize methods to be on Module objects: > > E.g. > Object.sugarize_for_rspec! > and > NilClass.sugarize_for_rspec! > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Mon Jul 31 05:13:49 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 31 Jul 2006 05:13:49 -0400 Subject: [Rspec-devel] rails_plugin_fix merged to trunk In-Reply-To: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com> References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com> Message-ID: <57c63afe0607310213kb86391ch272b1e871b6f4e08@mail.gmail.com> On 7/31/06, aslak hellesoy wrote: > Hi all, > > Brian's great work on branches/rails_plugin_fix has been merged back > to trunk. In other words, rake pre_commit now passes (It runs *all* > the stuff that can break, including rails stuff). > > There is a structural change too. We decided to ditch the > generator/gem packaging scheme for the rails stuff. It's just a plugin > now. We need to update our docs about how to install it since > installing a given version of it will now rely on svn tags. > > There is still some cleanup to do in the rails code, but it's getting > a lot cleaner and no longer duplicates *any* of the fixtures stuff > thanks to the new inherit method (thanks again Brian). > > Does everyone still agree that we should lose the > "controller/functional test" support and go for integration specs > instead? (Using rails' app object). I want isolated tests for controllers. That's actually why I'm working on the mock framework - to support an acts_as_mock plugin that lets you stub out class level methods like new and find. That way controller specs can avoid the database entirely and specs for model stuff (like validation) can live in the model where it is implemented. > > I think this would still make it possible to write specs for > controllers, but in a better way. > > And for view stuff I'd like to try out something like this: > http://www.fearoffish.co.uk/articles/2006/07/28/testing_views_with_style +1 > Regarding backwards compatibilty of the railsy stuff, I'd say we don't > try to keep things BWC. We're only at 0.5.x and it would be too much > of a commitment. Let's get it right instead. +1 From dchelimsky at gmail.com Mon Jul 31 05:19:55 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 31 Jul 2006 05:19:55 -0400 Subject: [Rspec-devel] a commitment to underscores Message-ID: <57c63afe0607310219t3066e52dg60d18ecaa30c51cb@mail.gmail.com> If we're really committed to underscores, I think we need to draw the line and really commit to it. Right now, there are numerous methods like this: def an self end This is there to support syntax like this: 37.should.be.an.instance.of Fixnum I'd propose that since the only use of "an" is in the context of "an_instance_of" that we could clean up the should helper (and family) a bit by creating underscored methods like an_instance_of and at_least and at_most (rather than at, least and most), etc. This would mean that we officially stop supporting dots, but it also means that we can't accidentally word things like this: collection.should_have_most(3).entries #missing "at" Thoughts? David From aslak.hellesoy at gmail.com Mon Jul 31 07:06:06 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 31 Jul 2006 06:06:06 -0500 Subject: [Rspec-devel] a commitment to underscores In-Reply-To: <57c63afe0607310219t3066e52dg60d18ecaa30c51cb@mail.gmail.com> References: <57c63afe0607310219t3066e52dg60d18ecaa30c51cb@mail.gmail.com> Message-ID: <8d961d900607310406x1cca67d8i47cfb66a991bdc97@mail.gmail.com> On 7/31/06, David Chelimsky wrote: > If we're really committed to underscores, I think we need to draw the > line and really commit to it. Right now, there are numerous methods > like this: > > def an > self > end > > This is there to support syntax like this: > > 37.should.be.an.instance.of Fixnum > > I'd propose that since the only use of "an" is in the context of > "an_instance_of" that we could clean up the should helper (and family) > a bit by creating underscored methods like an_instance_of and at_least > and at_most (rather than at, least and most), etc. > > This would mean that we officially stop supporting dots, but it also > means that we can't accidentally word things like this: > > collection.should_have_most(3).entries #missing "at" > > Thoughts? > +1 if we can reduce some of the magic > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Mon Jul 31 07:12:08 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 31 Jul 2006 06:12:08 -0500 Subject: [Rspec-devel] release 0.5.16 today? Message-ID: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com> Is everyone ok with me releasing 0.5.16 later today? Aslak From dchelimsky at gmail.com Mon Jul 31 07:15:24 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 31 Jul 2006 07:15:24 -0400 Subject: [Rspec-devel] a commitment to underscores In-Reply-To: <8d961d900607310406x1cca67d8i47cfb66a991bdc97@mail.gmail.com> References: <57c63afe0607310219t3066e52dg60d18ecaa30c51cb@mail.gmail.com> <8d961d900607310406x1cca67d8i47cfb66a991bdc97@mail.gmail.com> Message-ID: <57c63afe0607310415n1a56e6d9wa5902e910773ff81@mail.gmail.com> On 7/31/06, aslak hellesoy wrote: > On 7/31/06, David Chelimsky wrote: > > If we're really committed to underscores, I think we need to draw the > > line and really commit to it. Right now, there are numerous methods > > like this: > > > > def an > > self > > end > > > > This is there to support syntax like this: > > > > 37.should.be.an.instance.of Fixnum > > > > I'd propose that since the only use of "an" is in the context of > > "an_instance_of" that we could clean up the should helper (and family) > > a bit by creating underscored methods like an_instance_of and at_least > > and at_most (rather than at, least and most), etc. > > > > This would mean that we officially stop supporting dots, but it also > > means that we can't accidentally word things like this: > > > > collection.should_have_most(3).entries #missing "at" > > > > Thoughts? > > > > +1 if we can reduce some of the magic I think we can trim down the cases that sugar needs to cover - all it should do is look for "should_" and then when it passes control to a should helper it never really needs to get it back. This should make things less error prone as time goes on and new features are added. From dchelimsky at gmail.com Mon Jul 31 07:16:44 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 31 Jul 2006 07:16:44 -0400 Subject: [Rspec-devel] release 0.5.16 today? In-Reply-To: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com> References: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com> Message-ID: <57c63afe0607310416l446d8fd9mc3565861bb9b7faf@mail.gmail.com> On 7/31/06, aslak hellesoy wrote: > Is everyone ok with me releasing 0.5.16 later today? You mentioned in previous email that some docs need updating w/ the material moved into the trunk. As long as that gets done pre-release, it's fine w/ me. From lachiec at gmail.com Mon Jul 31 07:25:24 2006 From: lachiec at gmail.com (Lachie) Date: Mon, 31 Jul 2006 21:25:24 +1000 Subject: [Rspec-devel] release 0.5.16 today? In-Reply-To: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com> References: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com> Message-ID: <2c5e719e0607310425g384ae19ew145361a9ba5a79ec@mail.gmail.com> On 7/31/06, aslak hellesoy wrote: > Is everyone ok with me releasing 0.5.16 later today? +1 from me, I'm back at 0.5.13 atm On the rails front, will this include the move from gem-generator to plugin? Do you intend to published it via the plugin system? Lachie http://lachie.info/ http://www.flickr.com/photos/lachie/ From lachiec at gmail.com Mon Jul 31 07:45:17 2006 From: lachiec at gmail.com (Lachie) Date: Mon, 31 Jul 2006 21:45:17 +1000 Subject: [Rspec-devel] rails_plugin_fix merged to trunk In-Reply-To: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com> References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com> Message-ID: <2c5e719e0607310445r790d269u353324cc493c6075@mail.gmail.com> > Does everyone still agree that we should lose the > "controller/functional test" support and go for integration specs > instead? (Using rails' app object). > > I think this would still make it possible to write specs for > controllers, but in a better way. Perhaps the two approaches could be rolled into separate rails plugins, to be mixed in (and matched) via inherit and/or require. Individual controller specs are still important to me at the moment, but I haven't had the opportunity to try the integration way yet. > And for view stuff I'd like to try out something like this: > http://www.fearoffish.co.uk/articles/2006/07/28/testing_views_with_style +1 though I'd like to see it in a plugin rather than core. For most of the stuff I do, rendering html is the least important thing. Things like rendering yaml or xml, or transmitting a file are more common tasks. I see inherit as a way to start putting novel or niche functionality into rails plugins. This way the core is kept lean and acquiring new functionality is faster and more fine grained. From aslak.hellesoy at gmail.com Mon Jul 31 20:34:12 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 31 Jul 2006 19:34:12 -0500 Subject: [Rspec-devel] release 0.5.16 today? In-Reply-To: <2c5e719e0607310425g384ae19ew145361a9ba5a79ec@mail.gmail.com> References: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com> <2c5e719e0607310425g384ae19ew145361a9ba5a79ec@mail.gmail.com> Message-ID: <8d961d900607311734y267605aey8472e635d7aaec1c@mail.gmail.com> On 7/31/06, Lachie wrote: > On 7/31/06, aslak hellesoy wrote: > > Is everyone ok with me releasing 0.5.16 later today? > > +1 from me, I'm back at 0.5.13 atm > > On the rails front, will this include the move from gem-generator to > plugin? Do you intend to published it via the plugin system? > It's too much hassle with the gem. People can install it via svn:externals or simply exporting it into their project and committing it to their own. Both of these would use an svn tag to get the right code. (Our QRS always creates a tag when we release). It *sould* be installed via the rails plugin system, but I actually recommend not to because the rails plugin system doesn't handle versions that well. I'll update the doco. Aslak > Lachie > http://lachie.info/ > http://www.flickr.com/photos/lachie/ > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Mon Jul 31 20:35:23 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 31 Jul 2006 19:35:23 -0500 Subject: [Rspec-devel] rails_plugin_fix merged to trunk In-Reply-To: <2c5e719e0607310445r790d269u353324cc493c6075@mail.gmail.com> References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com> <2c5e719e0607310445r790d269u353324cc493c6075@mail.gmail.com> Message-ID: <8d961d900607311735h11c40193q943882689b70c3e5@mail.gmail.com> On 7/31/06, Lachie wrote: > > Does everyone still agree that we should lose the > > "controller/functional test" support and go for integration specs > > instead? (Using rails' app object). > > > > I think this would still make it possible to write specs for > > controllers, but in a better way. > > Perhaps the two approaches could be rolled into separate rails > plugins, to be mixed in (and matched) via inherit and/or require. > > Individual controller specs are still important to me at the moment, > but I haven't had the opportunity to try the integration way yet. > > > And for view stuff I'd like to try out something like this: > > http://www.fearoffish.co.uk/articles/2006/07/28/testing_views_with_style > > +1 though I'd like to see it in a plugin rather than core. For most of > the stuff I do, rendering html is the least important thing. Things > like rendering yaml or xml, or transmitting a file are more common > tasks. > > I see inherit as a way to start putting novel or niche functionality > into rails plugins. This way the core is kept lean and acquiring new > functionality is faster and more fine grained. I love that idea. Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dastels at daveastels.com Mon Jul 31 23:21:04 2006 From: dastels at daveastels.com (David Astels) Date: Mon, 31 Jul 2006 23:21:04 -0400 Subject: [Rspec-devel] a commitment to underscores In-Reply-To: <57c63afe0607310219t3066e52dg60d18ecaa30c51cb@mail.gmail.com> References: <57c63afe0607310219t3066e52dg60d18ecaa30c51cb@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31-Jul-06, at 5:19 AM, David Chelimsky wrote: > If we're really committed to underscores, I think we need to draw the > line and really commit to it. ... > > I'd propose that since the only use of "an" is in the context of > "an_instance_of" that we could clean up the should helper (and family) > a bit by creating underscored methods like an_instance_of and at_least > and at_most (rather than at, least and most), etc. > > This would mean that we officially stop supporting dots, but it also > means that we can't accidentally word things like this: > Thoughts? Initially, I balked at the idea... but after thinking about it a bit and chatting with David some.. I like the move. so +1 Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEzsihauez/L4x7g4RArS2AJ9ZnklFj26uSh/6ZCLdTGhb35iGUACaAqCk 2Cmk3RYKL5iv4r5TaNARfag= =MwG/ -----END PGP SIGNATURE----- From aslak.hellesoy at gmail.com Mon Jul 31 23:55:52 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 31 Jul 2006 22:55:52 -0500 Subject: [Rspec-devel] [ANN] 0.5.16 released Message-ID: <8d961d900607312055n2dcbb30uda2c242d8fb0eecd@mail.gmail.com> The biggest change is simplified rails support in a new wrapping. See release notes and website for details: http://rubyforge.org/frs/shownotes.php?release_id=6247 http://rspec.rubyforge.org/tools/rails.html Aslak