From brian.takita at gmail.com Fri Sep 1 18:26:20 2006 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 1 Sep 2006 15:26:20 -0700 Subject: [Rspec-devel] RSpec style in Scriptaculous' unittest.js In-Reply-To: <8d961d900608310300x4af50af6pfceec46fb29b034b@mail.gmail.com> References: <8d961d900608310300x4af50af6pfceec46fb29b034b@mail.gmail.com> Message-ID: <1d7ddd110609011526s516f580cg5852c9c9c336f09c@mail.gmail.com> Oh sweet. I've been stuck in JS land for a while. I like it. :) On 8/31/06, aslak hellesoy wrote: > > Doing Javascript? > > Looks like Scriptaculous' *excellent* unittest.js has got some BDD love: > > > http://ajaxian.com/archives/scriptaculous-behaviour-driven-development-testing > > Aslak > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060901/94170a90/attachment.html From dchelimsky at gmail.com Sat Sep 2 12:59:05 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 2 Sep 2006 11:59:05 -0500 Subject: [Rspec-devel] mocks with blocks Message-ID: <57c63afe0609020959o5e861e92s5a0bbfb73c60f1f0@mail.gmail.com> A pet peeve of mine is having to maintain two ways to do the same thing - especially when one is far simpler to understand than the other. The following syntax is currently supported for defining expected arguments and return values in a block: @mock.should_receive(:random_call) do | a, b | a.should_equal "a" b.should_equal "b" "booh" end Given the above, this passes: assert_equal("booh", @mock.random_call("a", "b")) But you could just as easily do this: @mock.should_receive(:random_call).with("a","b").and_return("booh") which is far more clear IMO. Admittedly, the block syntax is a bit more flexible, as it allows you to provide custom matching like this: @mock.should_receive(:msg) do |val| val.should_be_close 0.25, 0.001 end But I'm not convinced that anyone is actually using it and I'd like to kill it as the supporting code is just gumming up the works. Are any of you using it? David From dastels at daveastels.com Sat Sep 2 18:37:43 2006 From: dastels at daveastels.com (David Astels) Date: Sat, 2 Sep 2006 19:37:43 -0300 Subject: [Rspec-devel] mocks with blocks In-Reply-To: <57c63afe0609020959o5e861e92s5a0bbfb73c60f1f0@mail.gmail.com> References: <57c63afe0609020959o5e861e92s5a0bbfb73c60f1f0@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2-Sep-06, at 1:59 PM, David Chelimsky wrote: > ... > > Admittedly, the block syntax is a bit more flexible, as it allows you > to provide custom matching like this: > > @mock.should_receive(:msg) do |val| > val.should_be_close 0.25, 0.001 > end > > But I'm not convinced that anyone is actually using it and I'd like to > kill it as the supporting code is just gumming up the works. Are any > of you using it? I haven't had need for it yet Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE+ge+auez/L4x7g4RAu7QAKDdOTVj8UWxXetYtn5ALjVi12QBogCggO03 8HZDY3AwvSJpwLXh3uZu7jw= =qFOB -----END PGP SIGNATURE----- From lists-rspec at shopwatch.org Sat Sep 2 22:05:37 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sat, 02 Sep 2006 22:05:37 -0400 Subject: [Rspec-devel] controller_mixin broken w/EdgeRails Message-ID: <44FA3871.70303@jay.fm> When I try to run a controller spec using edge rails, I get errors like: NameError in 'The MyController should have no current_user if Vlad provides the wrong password' uninitialized constant MyController I presume this is because MyController now needs to be explicitly loaded. The following line added to controller_name *seems* to work, but I'm intentionally not providing it in patch form because I have no idea if it's the right solution: require "#{@controller_name}_controller" Jay Levitt From lists-rspec at shopwatch.org Sat Sep 2 22:43:36 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sat, 02 Sep 2006 22:43:36 -0400 Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc. In-Reply-To: <44F57017.8050001@dr-siemssen.de> References: <44F38766.7080805@shopwatch.org> <8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com> <44F424EF.3060203@dr-siemssen.de> <44F433E1.5080502@rubyforge.org> <8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com> <44F43D52.8020508@rubyforge.org> <8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com> <44F4483F.5070002@rubyforge.org> <44F45738.2080601@dr-siemssen.de> <44F459B5.7010601@rubyforge.org> <44F4687A.2070203@dr-siemssen.de> <44F47BFC.1090605@rubyforge.org> <44F57017.8050001@dr-siemssen.de> Message-ID: <44FA4158.6080805@rubyforge.org> Daniel Siemssen wrote: > As you see conventions haven't changed. But now all classes that are > loaded automatically can be reloaded and not only those that descend > from a class that includes the Reloadable module. > > Take a look at activesupport/lib/active_support/dependencies.rb if you > want to know more and please correct me if I'm wrong. One note: due to some recent changes in trunk, you'll need to set config.load_once_paths = [] in environment.rb to get a plugin to reload. And that probably breaks a bunch of other plugins. Still, it's semi-useful for plugin development. Sadly, there's no way to put that into test.rb - it has to be in environment.rb. Jay From lists-rspec at shopwatch.org Mon Sep 4 15:41:56 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 04 Sep 2006 15:41:56 -0400 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> Message-ID: <44FC8184.6030501@rubyforge.org> David Astels wrote: > On 27-Aug-06, at 4:51 PM, David Chelimsky wrote: >> I also >> have yet to see a case where using partial mocks is a better >> decision than improving the decoupling in the system under test. > I agree. Partial mocks can get very confusing, very easily. OK, but what about partial stubs? It's particularly handy to stub out Time.now, f'rinstance, so that all your expectations run at a particular "now", matching up with timestamps in fixtures, etc. There's no way to do that via an API that requires you to create new instance objects for your mocks. And I don't imagine you're suggesting that I decouple an app by asking for "time_handler" at startup... Also, FWIW, it sounds like Mocha is likely to become included in (or at least used by) Rails core: http://rubyforge.org/pipermail/mocha-developer/2006-September/000017.html I guess, depending on your viewpoint, that's either good for, bad for, or irrelevant to this discussion and rspec in general. Jay Levitt From dchelimsky at gmail.com Mon Sep 4 17:38:15 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 4 Sep 2006 16:38:15 -0500 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <44FC8184.6030501@rubyforge.org> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> Message-ID: <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> On 9/4/06, Jay Levitt wrote: > David Astels wrote: > > On 27-Aug-06, at 4:51 PM, David Chelimsky wrote: > >> I also > >> have yet to see a case where using partial mocks is a better > >> decision than improving the decoupling in the system under test. > > I agree. Partial mocks can get very confusing, very easily. > > OK, but what about partial stubs? It's particularly handy to stub out > Time.now, f'rinstance, so that all your expectations run at a particular > "now", matching up with timestamps in fixtures, etc. There's no way to > do that via an API that requires you to create new instance objects for > your mocks. And I don't imagine you're suggesting that I decouple an > app by asking for "time_handler" at startup... There's a balance here. With something that's part of Ruby I tend to think it preferable to use the class directly. Third party stuff should get wrapped though, so you're not bound to it. > Also, FWIW, it sounds like Mocha is likely to become included in (or at > least used by) Rails core: > > http://rubyforge.org/pipermail/mocha-developer/2006-September/000017.html Cool! > I guess, depending on your viewpoint, that's either good for, bad for, > or irrelevant to this discussion and rspec in general. I think it is very relevant. I've been playing around w/ using Mocha and Stubba from rspec. Haven't gotten it to work the way I want to yet, but if we can tap into a solid mock framework that someone else is maintaining, why not? The catch would be that the syntax for mocha is slightly different - using "expects" instead of "should_receive". But a simple search and replace should fix that - no? There are a couple of others, like "returns" instead of "and_return", etc. The other side of that is that mock.should_receive(:msg).and_return(value) sounds a lot more like subject.should_equal(value). Its more like the rest of rspec. What is important to me is that whatever mock framework we use is seamlessly integrated, auto-verified, etc. If mocha works its way into rails, it will implicitly become somewhat of a standard. And while rspec's expectation API and context/specify DSL offer something that feels different from test/unit, the mock framework really doesn't offer anything worthy of maintaining yet another framework. Any other opinions? David From lists-rspec at shopwatch.org Mon Sep 4 18:23:05 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 04 Sep 2006 18:23:05 -0400 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> Message-ID: <44FCA749.8040904@rubyforge.org> David Chelimsky wrote: >> Also, FWIW, it sounds like Mocha is likely to become included in (or at >> least used by) Rails core: >> >> http://rubyforge.org/pipermail/mocha-developer/2006-September/000017.html > I think it is very relevant. I've been playing around w/ using Mocha > and Stubba from rspec. Haven't gotten it to work the way I want to > yet, but if we can tap into a solid mock framework that someone else > is maintaining, why not? The catch would be that the syntax for mocha > is slightly different - using "expects" instead of "should_receive". > But a simple search and replace should fix that - no? There are a > couple of others, like "returns" instead of "and_return", etc. So would you propose wrapping and aliasing the mocha methods, or trying to convice James to include those aliases for rspec use? > What is important to me is that whatever mock framework we use is > seamlessly integrated, auto-verified, etc. If mocha works its way into > rails, it will implicitly become somewhat of a standard. And while > rspec's expectation API and context/specify DSL offer something that > feels different from test/unit, the mock framework really doesn't > offer anything worthy of maintaining yet another framework. I completely agree. I'd rather see rspec stick to the things that make it unique. But then, I almost always wish people working on a library would simply merge it with that other library, and that so rarely happens... I'm a big fan of integration. Personally, I think that while mocha may not have picked the verbs you'd pick for rspec, the overall syntax blends nicely with rspec, and I'd rather see rspec's mocks be cut-and-paste compatible with the many examples of mocking that are likely to pop up if it gets included in core. And I am simply loving: setup do Time.stubs(:now).returns(Time.at(1)) Jay > > Any other opinions? > > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From lists-rspec at shopwatch.org Mon Sep 4 18:45:44 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 04 Sep 2006 18:45:44 -0400 Subject: [Rspec-devel] controller_mixin broken w/EdgeRails In-Reply-To: <44FA3871.70303@jay.fm> References: <44FA3871.70303@jay.fm> Message-ID: <44FCAC98.4000609@rubyforge.org> Jay Levitt wrote: I presume this is because MyController now needs to be explicitly > loaded. The following line added to controller_name *seems* to work, > but I'm intentionally not providing it in patch form because I have no > idea if it's the right solution: > > require "#{@controller_name}_controller" Correction: I now have no idea if THIS is the right solution for line 13 of controller_mixin.rb: require_dependency "#{@controller_name}_controller" > > Jay Levitt > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From lists-rspec at shopwatch.org Mon Sep 4 18:55:19 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 04 Sep 2006 18:55:19 -0400 Subject: [Rspec-devel] Inspecting deprecated structures in EdgeRails Message-ID: <44FCAED7.5020807@shopwatch.org> I don't entirely understand how inspect_for_expectation_not_met_error works in should_base.rb, but with Edge Rails I'm now getting things like: @params is deprecated! Call params.inspect instead of @params.inspect. Args: [] (inspect_for_expectation_not_met_error at /usr/lib/ruby/gems/1.8/gems/rspec-0.6.2/lib/spec/api/helper/should_base.rb:10) when I use response.should_be_redirect. In the process of doing its inspection, it's looking at things like response. at params, which in this one instance is perfectly normal to look at... There's an ActiveSupport::Deprecation::silence method that takes a block. Should the rails helper override should_base and wrap it in silence? Jay Levitt From dchelimsky at gmail.com Mon Sep 4 19:03:09 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 4 Sep 2006 18:03:09 -0500 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <44FCA749.8040904@rubyforge.org> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> <44FCA749.8040904@rubyforge.org> Message-ID: <57c63afe0609041603l389b4bd6j8e176d3c1d24bd8a@mail.gmail.com> On 9/4/06, Jay Levitt wrote: > David Chelimsky wrote: > >> Also, FWIW, it sounds like Mocha is likely to become included in (or at > >> least used by) Rails core: > >> > >> http://rubyforge.org/pipermail/mocha-developer/2006-September/000017.html > > I think it is very relevant. I've been playing around w/ using Mocha > > and Stubba from rspec. Haven't gotten it to work the way I want to > > yet, but if we can tap into a solid mock framework that someone else > > is maintaining, why not? The catch would be that the syntax for mocha > > is slightly different - using "expects" instead of "should_receive". > > But a simple search and replace should fix that - no? There are a > > couple of others, like "returns" instead of "and_return", etc. > > So would you propose wrapping and aliasing the mocha methods, or trying > to convice James to include those aliases for rspec use? I'm more inclined to deprecate rspec's mocking framework. We'd keep it alive, but frozen, for some time to avoid forcing transition - but if we're going to plug in other frameworks then I see little value in wrapping them. > > What is important to me is that whatever mock framework we use is > > seamlessly integrated, auto-verified, etc. If mocha works its way into > > rails, it will implicitly become somewhat of a standard. And while > > rspec's expectation API and context/specify DSL offer something that > > feels different from test/unit, the mock framework really doesn't > > offer anything worthy of maintaining yet another framework. > > I completely agree. I'd rather see rspec stick to the things that make > it unique. But then, I almost always wish people working on a library > would simply merge it with that other library, and that so rarely > happens... I'm a big fan of integration. > > Personally, I think that while mocha may not have picked the verbs you'd > pick for rspec, the overall syntax blends nicely with rspec, and I'd > rather see rspec's mocks be cut-and-paste compatible with the many > examples of mocking that are likely to pop up if it gets included in core. I agree. > > And I am simply loving: > > setup do > Time.stubs(:now).returns(Time.at(1)) Yeah, yeah, yeah. OK. David > > > Jay > > > > > Any other opinions? > > > > David > > _______________________________________________ > > 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 dastels at daveastels.com Mon Sep 4 19:49:34 2006 From: dastels at daveastels.com (David Astels) Date: Mon, 4 Sep 2006 20:49:34 -0300 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> Message-ID: <88409F99-F9F7-412F-98EA-A2A2D073B020@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-Sep-06, at 6:38 PM, David Chelimsky wrote: > What is important to me is that whatever mock framework we use is > seamlessly integrated, auto-verified, etc. If mocha works its way into > rails, it will implicitly become somewhat of a standard. And while > rspec's expectation API and context/specify DSL offer something that > feels different from test/unit, the mock framework really doesn't > offer anything worthy of maintaining yet another framework. > > Any other opinions? I will be looking hard at mocha/stubba tonight, but they look like a good way to go. I'm quite happy to have us depricate rSpec's mock framework in favour of mocha/stubba. They seem to be rapidly gaining popularity with the rails community. Interestingly, Ben Grifftths was the author of Schmock which I based rSpecs initial mock framework on. He's also one of the developer of Mocha/Stubba. It would seem that rSpec Mocks and Mocha are siblings. Pending us finding glaring problems.. I'd say switching to Mocha is a great idea. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD4DBQFE/LuPauez/L4x7g4RAnk+AJiuAMCmWXXAJNQDO5f2oU8RWY7BAKDgr9WD RZFSktou1QvcKP+eLaJhYA== =mh0B -----END PGP SIGNATURE----- From dastels at daveastels.com Mon Sep 4 20:10:37 2006 From: dastels at daveastels.com (David Astels) Date: Mon, 4 Sep 2006 21:10:37 -0300 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <88409F99-F9F7-412F-98EA-A2A2D073B020@daveastels.com> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> <88409F99-F9F7-412F-98EA-A2A2D073B020@daveastels.com> Message-ID: <8D739720-2B34-4D55-8CA5-2AC43C1EFCF2@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-Sep-06, at 8:49 PM, David Astels wrote: > I will be looking hard at mocha/stubba tonight, but they look like a > good way to go. I'm quite happy to have us depricate rSpec's mock > framework in favour of mocha/stubba. Well.. on first glance Mocha seems significantly inferior to rSpec mocks. No support for consecutive calls, primitive argument matching, no ordering, and a rather clunky syntax. I have an alternative suggestion. We make the mocking framework pluggable. There are two points on integration to worry about: creating a mock and verifying all created mocks. A single require in your spec file to override the builting mocks with mocha would do it. Or something less intrusive... a small mock plugin file that rspec requires... install the appropriate one for the mock framework of choice. No reason we couldn't directly support flexmock in this way as well. Then we could extract our mock framework as a standalone piece.. a separate project even. Then anyone could install rspec, their mock framework of choice, and the small piece to bind them together. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE/MB9auez/L4x7g4RAm7GAKCoztPcBXTbbWfxHrQSl4egp78bewCgpcfm ewwz2YW145GK+tSeGD0O3dM= =D8Fk -----END PGP SIGNATURE----- From lists-rspec at shopwatch.org Mon Sep 4 20:37:05 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 04 Sep 2006 20:37:05 -0400 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <8D739720-2B34-4D55-8CA5-2AC43C1EFCF2@daveastels.com> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> <88409F99-F9F7-412F-98EA-A2A2D073B020@daveastels.com> <8D739720-2B34-4D55-8CA5-2AC43C1EFCF2@daveastels.com> Message-ID: <44FCC6B1.1010003@rubyforge.org> David Astels wrote: > On 4-Sep-06, at 8:49 PM, David Astels wrote: > >> I will be looking hard at mocha/stubba tonight, but they look like a >> good way to go. I'm quite happy to have us depricate rSpec's mock >> framework in favour of mocha/stubba. > > Well.. on first glance Mocha seems significantly inferior to rSpec > mocks. No support for consecutive calls, primitive argument > matching, no ordering, and a rather clunky syntax. Is that inherent to Mocha's structure, though, or just a function of the fact that Mocha's all of 45 days old? I wonder if contributing these features to Mocha isn't better than creating a pluggable-framework-framework. In fact, I think I can argue that in either case: If these features are inherent to the mock object, then there's no way a pluggable framework could support such verifications on Mocha objects. If, however, they're inherent to the verification layer, then there's no reason they can't be contributed to Mocha, thus getting rspec out of the mock business. Jay From dastels at daveastels.com Mon Sep 4 21:08:57 2006 From: dastels at daveastels.com (David Astels) Date: Mon, 4 Sep 2006 22:08:57 -0300 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <44FCC6B1.1010003@rubyforge.org> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> <88409F99-F9F7-412F-98EA-A2A2D073B020@daveastels.com> <8D739720-2B34-4D55-8CA5-2AC43C1EFCF2@daveastels.com> <44FCC6B1.1010003@rubyforge.org> Message-ID: <428795B1-D3F8-4F79-9988-EFC53C576169@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-Sep-06, at 9:37 PM, Jay Levitt wrote: > David Astels wrote: >> On 4-Sep-06, at 8:49 PM, David Astels wrote: >> >>> I will be looking hard at mocha/stubba tonight, but they look like a >>> good way to go. I'm quite happy to have us depricate rSpec's mock >>> framework in favour of mocha/stubba. >> >> Well.. on first glance Mocha seems significantly inferior to rSpec >> mocks. No support for consecutive calls, primitive argument >> matching, no ordering, and a rather clunky syntax. > > Is that inherent to Mocha's structure, though, or just a function > of the > fact that Mocha's all of 45 days old? I wonder if contributing these > features to Mocha isn't better than creating a > pluggable-framework-framework. In fact, I think I can argue that in > either case: > Probably. Both mocha and rspec-mock are built partly on the same base (Schmock)... it should be easy to add these capabilities to Mocha. > If these features are inherent to the mock object, then there's no > way a > pluggable framework could support such verifications on Mocha objects. > If, however, they're inherent to the verification layer, then > there's no > reason they can't be contributed to Mocha, thus getting rspec out > of the > mock business. Verification is internal to the mock and it's expectations. The call to verify the mock is exposed to the outer framework (test/unit or rspec). Either way is fine with me. I do wonder what's better for the community... a single, common mock framework... or some selection/ variation? I generally tend to favour the latter. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE/M4qauez/L4x7g4RAmX1AKCQU+Gy7gMYJLvG3iyRx+TGcePO8wCgzFoD HoRDo1L2k6LZhbipQ5kl9Pc= =DNnF -----END PGP SIGNATURE----- From lists-rspec at shopwatch.org Mon Sep 4 21:20:13 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 04 Sep 2006 21:20:13 -0400 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <428795B1-D3F8-4F79-9988-EFC53C576169@daveastels.com> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> <88409F99-F9F7-412F-98EA-A2A2D073B020@daveastels.com> <8D739720-2B34-4D55-8CA5-2AC43C1EFCF2@daveastels.com> <44FCC6B1.1010003@rubyforge.org> <428795B1-D3F8-4F79-9988-EFC53C576169@daveastels.com> Message-ID: <44FCD0CD.1060006@rubyforge.org> David Astels wrote: > Either way is fine with me. I do wonder what's better for the > community... a single, common mock framework... or some selection/ > variation? > > I generally tend to favour the latter. I guess I favor selection/variation when the libraries have different goals - e.g. rspec vs. Test::Unit. But I don't see rspec's mocks and Mocha's mocks having different goals, just coincidentally different feature sets. That's why I'd favor integration. But I'll shut up about that now... Jay From dchelimsky at gmail.com Mon Sep 4 22:20:31 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 4 Sep 2006 21:20:31 -0500 Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with In-Reply-To: <8D739720-2B34-4D55-8CA5-2AC43C1EFCF2@daveastels.com> References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com> <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com> <44FC8184.6030501@rubyforge.org> <57c63afe0609041438i41da3d36u2b576b52e89aa6af@mail.gmail.com> <88409F99-F9F7-412F-98EA-A2A2D073B020@daveastels.com> <8D739720-2B34-4D55-8CA5-2AC43C1EFCF2@daveastels.com> Message-ID: <57c63afe0609041920w33e7375fr57b11c8dc272cdc0@mail.gmail.com> On 9/4/06, David Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 4-Sep-06, at 8:49 PM, David Astels wrote: > > > I will be looking hard at mocha/stubba tonight, but they look like a > > good way to go. I'm quite happy to have us depricate rSpec's mock > > framework in favour of mocha/stubba. > > Well.. on first glance Mocha seems significantly inferior to rSpec > mocks. No support for consecutive calls, primitive argument > matching, no ordering, and a rather clunky syntax. > > I have an alternative suggestion. We make the mocking framework > pluggable. There are two points on integration to worry about: > creating a mock and verifying all created mocks. A single require in > your spec file to override the builting mocks with mocha would do > it. This is what Aslak and I were talking about - but not an override. Start by requiring the require explicitly: require 'rspec' require 'rspec/mock' Then the latter could be replaced w/ mocha, flexmock, whatever anyone wishes. As long as the framework in question provides the hooks we need to register an instance on creation and verify at the end of a spec. > Or something less intrusive... a small mock plugin file that > rspec requires... install the appropriate one for the mock framework > of choice. No reason we couldn't directly support flexmock in this > way as well. Then we could extract our mock framework as a > standalone piece.. a separate project even. Then anyone could > install rspec, their mock framework of choice, and the small piece to > bind them together. > > Dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFE/MB9auez/L4x7g4RAm7GAKCoztPcBXTbbWfxHrQSl4egp78bewCgpcfm > ewwz2YW145GK+tSeGD0O3dM= > =D8Fk > -----END PGP SIGNATURE----- > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Sep 4 22:29:25 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 4 Sep 2006 21:29:25 -0500 Subject: [Rspec-devel] separation of components Message-ID: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> I'd like to separate the pieces of rspec. By default you get the current pieces: require 'spec' Or you could ask for individual pieces: require 'spec/context' require 'spec/expectation' require 'spec/mock' This would free us up to: - incorporate other mock frameworks - support alternate APIs (given/then/when) - expose the expectation API to test/unit users Thoughts? From dastels at daveastels.com Mon Sep 4 22:45:38 2006 From: dastels at daveastels.com (David Astels) Date: Mon, 4 Sep 2006 23:45:38 -0300 Subject: [Rspec-devel] separation of components In-Reply-To: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-Sep-06, at 11:29 PM, David Chelimsky wrote: > I'd like to separate the pieces of rspec. By default you get the > current pieces: > > require 'spec' > > Or you could ask for individual pieces: > > require 'spec/context' > require 'spec/expectation' > require 'spec/mock' > > This would free us up to: > - incorporate other mock frameworks > - support alternate APIs (given/then/when) > - expose the expectation API to test/unit users > > Thoughts? Big +1 Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE/OTTauez/L4x7g4RAhRkAKC+2WJ0LFGcqsC7hFRbBxftoyp8JwCguvdF WnJICj7FOl4EC5+gTKPD74Y= =vAQD -----END PGP SIGNATURE----- From dchelimsky at gmail.com Tue Sep 5 03:15:25 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 02:15:25 -0500 Subject: [Rspec-devel] separation of components In-Reply-To: References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> Message-ID: <57c63afe0609050015h124e4270u1afe69c41ae917a5@mail.gmail.com> On 9/4/06, David Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 4-Sep-06, at 11:29 PM, David Chelimsky wrote: > > > I'd like to separate the pieces of rspec. By default you get the > > current pieces: > > > > require 'spec' > > > > Or you could ask for individual pieces: > > > > require 'spec/context' > > require 'spec/expectation' > > require 'spec/mock' > > > > This would free us up to: > > - incorporate other mock frameworks > > - support alternate APIs (given/then/when) > > - expose the expectation API to test/unit users > > > > Thoughts? > > Big +1 Played w/ this tonight. Currently everything is in Spec::Api. I'd want that to change to Spec::Expectations, Spec::Runner and Spec::Mocks. Would that hurt anybody? Shouldn't if you're just using rspec as documented. David From aslak.hellesoy at gmail.com Tue Sep 5 03:25:42 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 5 Sep 2006 09:25:42 +0200 Subject: [Rspec-devel] separation of components In-Reply-To: <57c63afe0609050015h124e4270u1afe69c41ae917a5@mail.gmail.com> References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> <57c63afe0609050015h124e4270u1afe69c41ae917a5@mail.gmail.com> Message-ID: <8d961d900609050025l2379c5a4wc44b7ca0d270ac31@mail.gmail.com> On 9/5/06, David Chelimsky wrote: > On 9/4/06, David Astels wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > On 4-Sep-06, at 11:29 PM, David Chelimsky wrote: > > > > > I'd like to separate the pieces of rspec. By default you get the > > > current pieces: > > > > > > require 'spec' > > > > > > Or you could ask for individual pieces: > > > > > > require 'spec/context' > > > require 'spec/expectation' > > > require 'spec/mock' > > > > > > This would free us up to: > > > - incorporate other mock frameworks > > > - support alternate APIs (given/then/when) > > > - expose the expectation API to test/unit users > > > > > > Thoughts? > > > > Big +1 > +1 > Played w/ this tonight. Currently everything is in Spec::Api. I'd want > that to change to Spec::Expectations, Spec::Runner and Spec::Mocks. > Would that hurt anybody? Shouldn't if you're just using rspec as > documented. > These are internal changes. Go for it. But perhaps on a branch? Aslak > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue Sep 5 03:38:59 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 02:38:59 -0500 Subject: [Rspec-devel] separation of components In-Reply-To: <8d961d900609050025l2379c5a4wc44b7ca0d270ac31@mail.gmail.com> References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> <57c63afe0609050015h124e4270u1afe69c41ae917a5@mail.gmail.com> <8d961d900609050025l2379c5a4wc44b7ca0d270ac31@mail.gmail.com> Message-ID: <57c63afe0609050038q413b4a9dk57767b9d14747642@mail.gmail.com> On 9/5/06, aslak hellesoy wrote: > On 9/5/06, David Chelimsky wrote: > > On 9/4/06, David Astels wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > > > > On 4-Sep-06, at 11:29 PM, David Chelimsky wrote: > > > > > > > I'd like to separate the pieces of rspec. By default you get the > > > > current pieces: > > > > > > > > require 'spec' > > > > > > > > Or you could ask for individual pieces: > > > > > > > > require 'spec/context' > > > > require 'spec/expectation' > > > > require 'spec/mock' > > > > > > > > This would free us up to: > > > > - incorporate other mock frameworks > > > > - support alternate APIs (given/then/when) > > > > - expose the expectation API to test/unit users > > > > > > > > Thoughts? > > > > > > Big +1 > > > > +1 > > > Played w/ this tonight. Currently everything is in Spec::Api. I'd want > > that to change to Spec::Expectations, Spec::Runner and Spec::Mocks. > > Would that hurt anybody? Shouldn't if you're just using rspec as > > documented. > > > > These are internal changes. Go for it. > But perhaps on a branch? Fair enough - ~/branches/modularized. I'll check something in tomorrow. David From dchelimsky at gmail.com Tue Sep 5 09:05:31 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 08:05:31 -0500 Subject: [Rspec-devel] volunteers to prove out experiment Message-ID: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> All, I've created a branch with the modules and directories restructured to reflect three distinct modules: Spec::Expectations Spec::Mocks Spec::Runner Will the brave among you (with a little time on your hands - just a little) please check out the branch, build and install the gem and let me know if you run into any problems? svn co svn://rubyforge.org/var/svn/rspec/branches/modularized cd modularized rake gem gem install pkg/rspec-0.6.4.gem I'd like to merge this to the trunk as soon as possible to minimize the merge pain, but I want to make sure I'm not missing anything glariing. Thanks, David From jim.weirich at gmail.com Tue Sep 5 09:09:03 2006 From: jim.weirich at gmail.com (Jim Weirich) Date: Tue, 5 Sep 2006 09:09:03 -0400 Subject: [Rspec-devel] separation of components In-Reply-To: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> Message-ID: On 9/4/06, David Chelimsky wrote: [...] > This would free us up to: > - incorporate other mock frameworks I've been thinking about adapting FlexMock to work with RSpec (as well as Test::Unit). Is there any interest in this? I think the FlexMock interface is already pretty similar to what you are currently using. -- -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060905/9c11086f/attachment.html From dchelimsky at gmail.com Tue Sep 5 09:18:14 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 08:18:14 -0500 Subject: [Rspec-devel] separation of components In-Reply-To: References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> Message-ID: <57c63afe0609050618w4b85ec4ds5393773df043ae28@mail.gmail.com> On 9/5/06, Jim Weirich wrote: > > > On 9/4/06, David Chelimsky wrote: > [...] > > > This would free us up to: > > - incorporate other mock frameworks > > > I've been thinking about adapting FlexMock to work with RSpec (as well as > Test::Unit). Is there any interest in this? I think the FlexMock interface > is already pretty similar to what you are currently using. Definitely. We've actually been talking internally about providing adapters for Flexmock and Mocha. That way the integration is seamless, and we're in control of the integration points (therefore free to change them). Once we've proved out the integration concept, it would be a simple matter for anyone else who wishes to plug in a different framework to do so by providing their own adapters. Do you have any thoughts about this? > > -- > -- > -- Jim Weirich jim at weirichhouse.org http://onestepback.org > ----------------------------------------------------------------- > "Beware of bugs in the above code; I have only proved it correct, > not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From jim.weirich at gmail.com Tue Sep 5 11:12:25 2006 From: jim.weirich at gmail.com (Jim Weirich) Date: Tue, 5 Sep 2006 11:12:25 -0400 Subject: [Rspec-devel] separation of components In-Reply-To: <57c63afe0609050618w4b85ec4ds5393773df043ae28@mail.gmail.com> References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> <57c63afe0609050618w4b85ec4ds5393773df043ae28@mail.gmail.com> Message-ID: On 9/5/06, David Chelimsky wrote: > > > Definitely. We've actually been talking internally about providing > adapters for Flexmock and Mocha. Great! Do you have any thoughts about this? Here are some thoughts off the top of my head. * I will need a way to tie into test teardown to handle mock verification. With Test::Unit, I include FlexMock::TestCase which overrides the teardown method with my own. Its a bit fragile, for if the user defined a test specific teardown and doesn't invoke "super", my teardown code will be missed. * I use assert_xxx in several places in FlexMock. This won't work with RSpec (obviously), but I think it could easily be abstracted into a bridge that asserts properly in either RSpec or Test::Unit. * I also rescue (and rethrow) Test::Unit::AssertionFailedError to add extra information to the generic Test::Unit assertion failed message ( e.g. the name of the mock that failed). I would probably need to do something similar in RSpec. That's all I can think of at the moment. Right now, flexmock is pretty tightly in bed with Test::Unit, but I wouldn't mind shaking it loose a bit. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060905/23997bf2/attachment-0001.html From dchelimsky at gmail.com Tue Sep 5 11:29:54 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 10:29:54 -0500 Subject: [Rspec-devel] separation of components In-Reply-To: References: <57c63afe0609041929r4328c355kf12f3544c5fbc3ab@mail.gmail.com> <57c63afe0609050618w4b85ec4ds5393773df043ae28@mail.gmail.com> Message-ID: <57c63afe0609050829g2438b7cco7a106d1fcd5441ea@mail.gmail.com> On 9/5/06, Jim Weirich wrote: > On 9/5/06, David Chelimsky wrote: > > > > > > Definitely. We've actually been talking internally about providing > > adapters for Flexmock and Mocha. > > > Great! > > > > Do you have any thoughts about this? > > > Here are some thoughts off the top of my head. > > * I will need a way to tie into test teardown to handle mock verification. > With Test::Unit, I include FlexMock::TestCase which overrides the teardown > method with my own. Its a bit fragile, for if the user defined a test > specific teardown and doesn't invoke "super", my teardown code will be > missed. > > * I use assert_xxx in several places in FlexMock. This won't work with > RSpec (obviously), but I think it could easily be abstracted into a bridge > that asserts properly in either RSpec or Test::Unit. > > * I also rescue (and rethrow) > Test::Unit::AssertionFailedError to add extra information > to the generic Test::Unit assertion failed message ( e.g. the name of the > mock that failed). I would probably need to do something similar in RSpec. > > That's all I can think of at the moment. Right now, flexmock is pretty > tightly in bed with Test::Unit, but I wouldn't mind shaking it loose a bit. Ah - I hadn't considered the messaging. I was thinking the only issues would be capturing creation of new mocks and being able to explicitly control verification. I'm in the process of creating a clean separation between the rspec mock framework and the rest of rspec. This should provide some insight as to how we'd like to see this work. I'll let you know how that progresses. Thanks, David > > -- > > -- Jim Weirich jim at weirichhouse.org http://onestepback.org > ----------------------------------------------------------------- > "Beware of bugs in the above code; I have only proved it correct, > not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From lists-rspec at shopwatch.org Tue Sep 5 12:02:50 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Tue, 05 Sep 2006 12:02:50 -0400 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> Message-ID: <44FD9FAA.7040609@shopwatch.org> David Chelimsky wrote: > Will the brave among you (with a little time on your hands - just a > little) please check out the branch, build and install the gem and let > me know if you run into any problems? > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized svn: Connection closed unexpectedly Sigh. Jay From dchelimsky at gmail.com Tue Sep 5 12:13:48 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 11:13:48 -0500 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <44FD9FAA.7040609@shopwatch.org> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> <44FD9FAA.7040609@shopwatch.org> Message-ID: <57c63afe0609050913p53d0e731r77dd751933219d4f@mail.gmail.com> On 9/5/06, Jay Levitt wrote: > David Chelimsky wrote: > > Will the brave among you (with a little time on your hands - just a > > little) please check out the branch, build and install the gem and let > > me know if you run into any problems? > > > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized > svn: Connection closed unexpectedly > Bummer. I was able to do it, but then not. They must be having a bad day. > Sigh. > > Jay > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue Sep 5 12:14:48 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 11:14:48 -0500 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <57c63afe0609050913p53d0e731r77dd751933219d4f@mail.gmail.com> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> <44FD9FAA.7040609@shopwatch.org> <57c63afe0609050913p53d0e731r77dd751933219d4f@mail.gmail.com> Message-ID: <57c63afe0609050914q67d964b4tb0b68f216eca7a4@mail.gmail.com> On 9/5/06, David Chelimsky wrote: > On 9/5/06, Jay Levitt wrote: > > David Chelimsky wrote: > > > Will the brave among you (with a little time on your hands - just a > > > little) please check out the branch, build and install the gem and let > > > me know if you run into any problems? > > > > > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized > > svn: Connection closed unexpectedly > > > > Bummer. I was able to do it, but then not. They must be having a bad day. I seem to able to do it now. Try again, pls. > > > > > Sigh. > > > > Jay > > > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From lists-rspec at shopwatch.org Tue Sep 5 12:45:41 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Tue, 05 Sep 2006 12:45:41 -0400 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> Message-ID: <44FDA9B5.2060706@shopwatch.org> David Chelimsky wrote: > > Will the brave among you (with a little time on your hands - just a > little) please check out the branch, build and install the gem and let > me know if you run into any problems? This runs my meager, existing specs with no problem... Jay From smartgpx at gmail.com Tue Sep 5 17:24:05 2006 From: smartgpx at gmail.com (DeeJay) Date: Tue, 5 Sep 2006 22:24:05 +0100 Subject: [Rspec-devel] volunteers to prove out experiment Message-ID: <533048b70609051424p2ebb8f96wbd4db1f54779f4fa@mail.gmail.com> "please check out the branch, build and install the gem and let me know if you run into any problems?" Sorry - problems building on Windows I think. (But it's late, I'll take a fresh look tomorrow.) I *think* that on a WinXPproSP2 system earlier, with 1.8.4 (OCI 184-19) the rake gem step was clean and the 0.6.4 gem got built. At the moment, on a WinXPhomeSP1 system with 1.8.5 (OCI 185-21) the build looks 'noisy', and the run of spec against the failing examples does indeed fail with 11 failures, so rake aborts and the gem isn't built. I'll give this more attention if needed and clarify what I am seeing. DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060905/6dcbf406/attachment.html From aslak.hellesoy at gmail.com Tue Sep 5 18:09:19 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 6 Sep 2006 00:09:19 +0200 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <533048b70609051424p2ebb8f96wbd4db1f54779f4fa@mail.gmail.com> References: <533048b70609051424p2ebb8f96wbd4db1f54779f4fa@mail.gmail.com> Message-ID: <8d961d900609051509o64c75f58u1d3e3113bbca77a3@mail.gmail.com> On 9/5/06, DeeJay wrote: > > > "please check out the branch, build and install the gem and let > me know if you run into any problems?" > > Sorry - problems building on Windows I think. (But it's late, I'll take a > fresh look tomorrow.) > rake # 339 tests, 323 assertions, 0 failures, 0 errors (some warnings but that's ok) rake gem gem install pkg\rspec-0.6.4.gem spec examples all of this works fine on WinXPProSP2 + ruby 1.8.4 (2006-04-14) [i386-mswin32] > I *think* that on a WinXPproSP2 system earlier, with 1.8.4 (OCI 184-19) the > rake gem step was clean and the 0.6.4 gem got built. > what's OCI? > At the moment, on a WinXPhomeSP1 system with 1.8.5 (OCI 185-21) the > build looks 'noisy', and the run of spec against the failing examples does > indeed fail with 11 failures, so rake aborts and the gem isn't built. > The failing_examples are supposed to fail and the rake script is supposed to account for it and continue. However, this is a little tricky and no effort has been put in to make this work on windows. What exact command are you running and what errors do you see? (Run Rake with -v -t) > I'll give this more attention if needed and clarify what I am seeing. > It all looks good to me. pre_commit doesn't pass, but that's the same as on trunk. It's related to windows things, not the rspec code. I think it's ok to merge the branch to trunk. Aslak > > DeeJay > > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Tue Sep 5 18:24:47 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 17:24:47 -0500 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <8d961d900609051509o64c75f58u1d3e3113bbca77a3@mail.gmail.com> References: <533048b70609051424p2ebb8f96wbd4db1f54779f4fa@mail.gmail.com> <8d961d900609051509o64c75f58u1d3e3113bbca77a3@mail.gmail.com> Message-ID: <57c63afe0609051524n3bf0de90ufc5be03318f6e9f7@mail.gmail.com> On 9/5/06, aslak hellesoy wrote: > On 9/5/06, DeeJay wrote: > > > > > > "please check out the branch, build and install the gem and let > > me know if you run into any problems?" > > > > Sorry - problems building on Windows I think. (But it's late, I'll take a > > fresh look tomorrow.) > > > > rake # 339 tests, 323 assertions, 0 failures, 0 errors (some warnings > but that's ok) > rake gem > gem install pkg\rspec-0.6.4.gem > spec examples > > all of this works fine on WinXPProSP2 + ruby 1.8.4 (2006-04-14) [i386-mswin32] > > > I *think* that on a WinXPproSP2 system earlier, with 1.8.4 (OCI 184-19) the > > rake gem step was clean and the 0.6.4 gem got built. > > > > what's OCI? > > > At the moment, on a WinXPhomeSP1 system with 1.8.5 (OCI 185-21) the > > build looks 'noisy', and the run of spec against the failing examples does > > indeed fail with 11 failures, so rake aborts and the gem isn't built. > > > > The failing_examples are supposed to fail and the rake script is > supposed to account for it and continue. However, this is a little > tricky and no effort has been put in to make this work on windows. > > What exact command are you running and what errors do you see? (Run > Rake with -v -t) > > > I'll give this more attention if needed and clarify what I am seeing. > > > > It all looks good to me. pre_commit doesn't pass, but that's the same > as on trunk. It's related to windows things, not the rspec code. > > I think it's ok to merge the branch to trunk. Done > > Aslak > > > > > DeeJay > > > > > > > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue Sep 5 18:30:18 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 6 Sep 2006 00:30:18 +0200 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> Message-ID: <8d961d900609051530o6ea80741ob2f8859f1449d050@mail.gmail.com> On 9/5/06, David Chelimsky wrote: > All, > > I've created a branch with the modules and directories restructured to > reflect three distinct modules: > > Spec::Expectations > Spec::Mocks > Spec::Runner > > Will the brave among you (with a little time on your hands - just a > little) please check out the branch, build and install the gem and let > me know if you run into any problems? > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized > cd modularized > rake gem > gem install pkg/rspec-0.6.4.gem > > I'd like to merge this to the trunk as soon as possible to minimize > the merge pain, but I want to make sure I'm not missing anything > glariing. > As mentioned in a separate mail, I think it's fine to merge this back to trunk. There is still some work to be done though. First, I'd love to see module/class names be modified to reflect the file structure. We can do this once back on trunk. Second, we should modify the build so that the tests for each sub library is run individually, to ensure there are no hidden cyclic dependencies. I assume: (see this in monospaced font) Runner->Mocks->Expectations | ^ | | +-----------------+ Again, this can be done on trunk. We should even consider having separate Rakefiles for each sub project. That would be the cleanest. We should package these as 3 independent gems, possibly with independent versioning schemes similar to the way it's done in Rails. I'm thinking 3 gems for now, possibly 4 when we start writing a more gwt style runner: Runner becomes rspec.gem Mocks becomes rspec-mocks.gem (which we may EOL later) Expectations becomes rspec-expectations.gem A new gwt runner could become rbehave(?).gem or rspec-gwt.gem Thoughts? Aslak > Thanks, > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue Sep 5 18:58:36 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 5 Sep 2006 17:58:36 -0500 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <8d961d900609051530o6ea80741ob2f8859f1449d050@mail.gmail.com> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> <8d961d900609051530o6ea80741ob2f8859f1449d050@mail.gmail.com> Message-ID: <57c63afe0609051558r75e87e3er98b6a75ef9e49baf@mail.gmail.com> On 9/5/06, aslak hellesoy wrote: > On 9/5/06, David Chelimsky wrote: > > All, > > > > I've created a branch with the modules and directories restructured to > > reflect three distinct modules: > > > > Spec::Expectations > > Spec::Mocks > > Spec::Runner > > > > Will the brave among you (with a little time on your hands - just a > > little) please check out the branch, build and install the gem and let > > me know if you run into any problems? > > > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized > > cd modularized > > rake gem > > gem install pkg/rspec-0.6.4.gem > > > > I'd like to merge this to the trunk as soon as possible to minimize > > the merge pain, but I want to make sure I'm not missing anything > > glariing. > > > > As mentioned in a separate mail, I think it's fine to merge this back to trunk. > > There is still some work to be done though. > > First, I'd love to see module/class names be modified to reflect the > file structure. We can do this once back on trunk. This is already done to some extent. There are now three separate modules as described above. What else did you have in mind? > Second, we should modify the build so that the tests for each sub > library is run individually, to ensure there are no hidden cyclic > dependencies. I assume: > > (see this in monospaced font) > Runner->Mocks->Expectations > | ^ > | | > +-----------------+ Why should there be even these dependencies? The specs will rely on all three, but I think they can be completely independent with the exception that if you just "require 'spec'" you'll get all three included. > > Again, this can be done on trunk. We should even consider having > separate Rakefiles for each sub project. That would be the cleanest. That would be OK as long as we can have a single Rakefile that will spawn all three. I don't want to have to build all three separately every time. > We should package these as 3 independent gems, possibly with > independent versioning schemes similar to the way it's done in Rails. > I'm thinking 3 gems for now, possibly 4 when we start writing a more > gwt style runner: > > Runner becomes rspec.gem > Mocks becomes rspec-mocks.gem (which we may EOL later) > Expectations becomes rspec-expectations.gem > A new gwt runner could become rbehave(?).gem or rspec-gwt.gem If Dan is on board for rbehave, I think we should use that. I'll see where he is on his own rbehave project. David > > Thoughts? > > Aslak > > > Thanks, > > David > > _______________________________________________ > > 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 Sep 6 01:53:05 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 6 Sep 2006 07:53:05 +0200 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <57c63afe0609051558r75e87e3er98b6a75ef9e49baf@mail.gmail.com> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> <8d961d900609051530o6ea80741ob2f8859f1449d050@mail.gmail.com> <57c63afe0609051558r75e87e3er98b6a75ef9e49baf@mail.gmail.com> Message-ID: <8d961d900609052253w4bf0f2a2w4507ffac74daf0cb@mail.gmail.com> On 9/6/06, David Chelimsky wrote: > On 9/5/06, aslak hellesoy wrote: > > On 9/5/06, David Chelimsky wrote: > > > All, > > > > > > I've created a branch with the modules and directories restructured to > > > reflect three distinct modules: > > > > > > Spec::Expectations > > > Spec::Mocks > > > Spec::Runner > > > > > > Will the brave among you (with a little time on your hands - just a > > > little) please check out the branch, build and install the gem and let > > > me know if you run into any problems? > > > > > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized > > > cd modularized > > > rake gem > > > gem install pkg/rspec-0.6.4.gem > > > > > > I'd like to merge this to the trunk as soon as possible to minimize > > > the merge pain, but I want to make sure I'm not missing anything > > > glariing. > > > > > > > As mentioned in a separate mail, I think it's fine to merge this back to trunk. > > > > There is still some work to be done though. > > > > First, I'd love to see module/class names be modified to reflect the > > file structure. We can do this once back on trunk. > > This is already done to some extent. There are now three separate > modules as described above. What else did you have in mind? > spec/expectations/helper/have_helper.rb contains class Spec::HaveHelper. They don't match. It's very deep. We could move the file one up and change the module hierarchy so we get: spec/expectations/have_helper.rb contains class Spec::Expectations::HaveHelper. This is still kind of deep. Now that things are split and will stand on their own feet perhaps we should think of real standalone names for these libraries? That would allow one more shortening of depth. Example: should/have_helper.rb contains class Should::HaveHelper. The expectations project could be called should(!). -Both the gem and the namespace. Just an idea. > > Second, we should modify the build so that the tests for each sub > > library is run individually, to ensure there are no hidden cyclic > > dependencies. I assume: > > > > (see this in monospaced font) > > Runner->Mocks->Expectations > > | ^ > > | | > > +-----------------+ > > Why should there be even these dependencies? The specs will rely on > all three, but I think they can be completely independent with the > exception that if you just "require 'spec'" you'll get all three > included. > > > > > Again, this can be done on trunk. We should even consider having > > separate Rakefiles for each sub project. That would be the cleanest. > > That would be OK as long as we can have a single Rakefile that will > spawn all three. I don't want to have to build all three separately > every time. > Sure. > > We should package these as 3 independent gems, possibly with > > independent versioning schemes similar to the way it's done in Rails. > > I'm thinking 3 gems for now, possibly 4 when we start writing a more > > gwt style runner: > > > > Runner becomes rspec.gem > > Mocks becomes rspec-mocks.gem (which we may EOL later) > > Expectations becomes rspec-expectations.gem > > A new gwt runner could become rbehave(?).gem or rspec-gwt.gem > > If Dan is on board for rbehave, I think we should use that. I'll see > where he is on his own rbehave project. > > David > > > > > Thoughts? > > > > Aslak > > > > > Thanks, > > > David > > > _______________________________________________ > > > 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 smartgpx at gmail.com Wed Sep 6 02:23:10 2006 From: smartgpx at gmail.com (DeeJay) Date: Wed, 6 Sep 2006 07:23:10 +0100 Subject: [Rspec-devel] volunteers to prove out experiment Message-ID: <533048b70609052323o384518a5hd84bf76fe4b62410@mail.gmail.com> Since this is now in trunk this feedback is of academic interest only. "what's OCI?" One Click Installer. The de-facto standard distribution of ruby for Windows. Apologies for throwing in an undefined TLA - I thought it was commonplace. " The failing_examples are supposed to fail and the rake script is supposed to account for it and continue. However, this is a little tricky and no effort has been put in to make this work on windows. " Setting FAIL_ON_ERROR false in the spec task for the failing examples allows rake to continue and generate the .gem desc "Run all failing examples" Spec::Rake::SpecTask.new('failing_examples') do |t| t.spec_files = FileList['failing_examples/**/*_spec.rb'] t.fail_on_error = false # DJR end " What exact command are you running and what errors do you see? (Run Rake with -v -t) " Literal answer is "rake gem", just as you asked! Sensible answer is that the output from rake -v -t gem is probably more verbose than a mailing list wants. I'll mail it privately if it might be of any value. Some highlights are: ** Execute test C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/diff-lcs-1.1.2 /lib/diff/lcs/hunk.rb: 69: warning: method redefined; discarding old flag_context= ./test/spec/expectations/sugar_test.rb:41: warning: method redefined; discarding old test_should_allow_underscored_anys_on_mocks ./test/spec/runner/../../test_helper.rb:16: warning: method redefined; discardin g old verify_sexp_equal ./test/spec/runner/../../test_helper.rb:22: warning: method redefined; discardin g old my_pp ./test/spec/runner/formatter/../../../test_helper.rb:16: warning: method redefin ed; discarding old verify_sexp_equal ./test/spec/runner/formatter/../../../test_helper.rb:22: warning: method redefin ed; discarding old my_pp ./test/spec/mocks/../../test_helper.rb:16: warning: method redefined; discarding old verify_sexp_equal ./test/spec/mocks/../../test_helper.rb:22: warning: method redefined; discarding old my_pp ./test/spec/mocks/mock_test.rb:7: warning: method redefined; discarding old setu p Loaded suite C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1 /lib/rake/rak e_test_loader Started (eval):2: warning: method redefined; discarding old message (eval):2: warning: method redefined; discarding old random_call (eval):2: warning: method redefined; discarding old random_call (eval):2: warning: method redefined; discarding old spec_failed ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................... Finished in 0.375 seconds. 339 tests, 323 assertions, 0 failures, 0 errors C:/OneClickRuby/ruby/bin/ruby -I"G:/RubyPackages/rSpec_repository/branches/modul arized/lib" "G:/RubyPackages/rSpec_repository/branches/modularized/bin/spec" "f ailing_examples/empty_stack_spec.rb" "failing_examples/stack_spec.rb" "failing_e xamples/team_spec.rb" "failing_examples/big_string_spec.rb" "failing_examples/mo cking_spec.rb" "failing_examples/spec_framework_spec.rb" "failing_examples/airpo rt_spec.rb" ** Invoke doc (first_time, not_needed) ** Invoke lib (first_time, not_needed) ** Invoke failing_examples (first_time) ** Execute failing_examples ...FF.....F......FF.F.FFFF...F 1) NoMethodError in 'A stack with one item should return top when sent top' undefined method `top_should_be' for # G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/suga C:/OneClickRuby/ruby/bin/ruby -I"G:/RubyPackages/rSpec_repository/branches/modul arized/lib" "G:/RubyPackages/rSpec_repository/branches/modularized/bin/spec" "e xamples/stack_spec.rb" "examples/bdd_framework_spec.rb" "examples/io_processor_s pec.rb" "examples/mocking_spec.rb" "examples/custom_method_spec.rb" "examples/te st_case_spec.rb" "examples/airport_spec.rb" "examples/file_accessor_spec.rb" "ex amples/sugar_spec.rb" r.rb:16:in `call' G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/suga r.rb:16:in `_method_missing' G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/suga r.rb:12:in `method_missing' ./failing_examples/stack_spec.rb:16:in `should return top when sent top' [ other detailed failures suppressed... DJR ] 11) Spec::Expectations::ExpectationNotMetError in 'Airport at home should not need e lectricity' Airport # should not need electricity G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/help er/should_base.rb:27:in `fail_with_message' G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/help er/should_negator.rb:66:in `method_missing' G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/suga r.rb:27:in `__send__' G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/suga r.rb:27:in `_method_missing' G:/RubyPackages/rSpec_repository/branches/modularized/lib/spec/expectations/suga r.rb:12:in `method_missing' ./failing_examples/airport_spec.rb:28:in `should not need electricity' Finished in 0.031 seconds 30 specifications, 11 failures Let me know if you want any more input on this. I'll checkout trunk before I try again. DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060906/f7cabbee/attachment.html From smartgpx at gmail.com Wed Sep 6 06:04:43 2006 From: smartgpx at gmail.com (DeeJay) Date: Wed, 6 Sep 2006 11:04:43 +0100 Subject: [Rspec-devel] volunteers to prove out experiment Message-ID: <533048b70609060304r1a7830e1wd30a0e3d3e60b40d@mail.gmail.com> Still working with the code checked out from branches/modularized yesterday, I can confirm that the rspec-0.6.4.gem built from that revision can be installed on and run from a Windows ruby-1.8.5 system, and that it correctly runs the examples generated as a result of following Dave Astels Mastermind project. This exercises the spec runner, expectations, the mocks, and the SpecTask including its interface to rcov. DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060906/564b5cf7/attachment.html From dchelimsky at gmail.com Wed Sep 6 06:32:31 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 6 Sep 2006 05:32:31 -0500 Subject: [Rspec-devel] volunteers to prove out experiment In-Reply-To: <8d961d900609052253w4bf0f2a2w4507ffac74daf0cb@mail.gmail.com> References: <57c63afe0609050605p1a727577ma42e02db25ebe327@mail.gmail.com> <8d961d900609051530o6ea80741ob2f8859f1449d050@mail.gmail.com> <57c63afe0609051558r75e87e3er98b6a75ef9e49baf@mail.gmail.com> <8d961d900609052253w4bf0f2a2w4507ffac74daf0cb@mail.gmail.com> Message-ID: <57c63afe0609060332v123f42fbw2f0cfef8f9f36629@mail.gmail.com> On 9/6/06, aslak hellesoy wrote: > On 9/6/06, David Chelimsky wrote: > > On 9/5/06, aslak hellesoy wrote: > > > On 9/5/06, David Chelimsky wrote: > > > > All, > > > > > > > > I've created a branch with the modules and directories restructured to > > > > reflect three distinct modules: > > > > > > > > Spec::Expectations > > > > Spec::Mocks > > > > Spec::Runner > > > > > > > > Will the brave among you (with a little time on your hands - just a > > > > little) please check out the branch, build and install the gem and let > > > > me know if you run into any problems? > > > > > > > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized > > > > cd modularized > > > > rake gem > > > > gem install pkg/rspec-0.6.4.gem > > > > > > > > I'd like to merge this to the trunk as soon as possible to minimize > > > > the merge pain, but I want to make sure I'm not missing anything > > > > glariing. > > > > > > > > > > As mentioned in a separate mail, I think it's fine to merge this back to trunk. > > > > > > There is still some work to be done though. > > > > > > First, I'd love to see module/class names be modified to reflect the > > > file structure. We can do this once back on trunk. > > > > This is already done to some extent. There are now three separate > > modules as described above. What else did you have in mind? > > > > spec/expectations/helper/have_helper.rb contains class Spec::HaveHelper. > > They don't match. It's very deep. We could move the file one up and > change the module hierarchy so we get: > > spec/expectations/have_helper.rb contains class Spec::Expectations::HaveHelper. > > This is still kind of deep. Now that things are split and will stand > on their own feet perhaps we should think of real standalone names for > these libraries? That would allow one more shortening of depth. > Example: > > should/have_helper.rb contains class Should::HaveHelper. > > The expectations project could be called should(!). -Both the gem and > the namespace. Just an idea. I hadn't ventured into every file - just searched for Api and replaced that. In general, I agree w/ where you're headed w/ this. The lack of cohesion between the directory structure and the module names bugged me at first. Then I forgot about it :) Part of why I let go of it was because I wasn't sure if the little voice in my head saying "these should line up" was my inner-java-developer (who I was trying to supress) or just plain common sense. As for Should::HaveHelper vs Spec::Expectations::Helpers::HaveHelper, I think flattening the hierarchy is a no-brainer. I also like the idea of should.gem as opposed to spec-expectations.gem. So we'd have rspec.gem, should.gem, and spec-mocks.gem with Spec, Should and Spec::Mocks modules respectively (at the top levels of each). Make sense? > > > > Second, we should modify the build so that the tests for each sub > > > library is run individually, to ensure there are no hidden cyclic > > > dependencies. I assume: > > > > > > (see this in monospaced font) > > > Runner->Mocks->Expectations > > > | ^ > > > | | > > > +-----------------+ > > > > Why should there be even these dependencies? The specs will rely on > > all three, but I think they can be completely independent with the > > exception that if you just "require 'spec'" you'll get all three > > included. > > > > > > > > Again, this can be done on trunk. We should even consider having > > > separate Rakefiles for each sub project. That would be the cleanest. > > > > That would be OK as long as we can have a single Rakefile that will > > spawn all three. I don't want to have to build all three separately > > every time. > > > > Sure. > > > > We should package these as 3 independent gems, possibly with > > > independent versioning schemes similar to the way it's done in Rails. > > > I'm thinking 3 gems for now, possibly 4 when we start writing a more > > > gwt style runner: > > > > > > Runner becomes rspec.gem > > > Mocks becomes rspec-mocks.gem (which we may EOL later) > > > Expectations becomes rspec-expectations.gem > > > A new gwt runner could become rbehave(?).gem or rspec-gwt.gem > > > > If Dan is on board for rbehave, I think we should use that. I'll see > > where he is on his own rbehave project. > > > > David > > > > > > > > Thoughts? > > > > > > Aslak > > > > > > > Thanks, > > > > David > > > > _______________________________________________ > > > > Rspec-devel mailing list > > > > Rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > Rspec-devel mailing list > > > Rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Wed Sep 6 10:06:07 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 6 Sep 2006 16:06:07 +0200 Subject: [Rspec-devel] RSpec and Watir Message-ID: <8d961d900609060706h29ab680egd908a18321dffbe2@mail.gmail.com> Hi all, (Sorry for cross-posting - please reply to only one list, preferrably wtr-general) I just started on a project where it looks like we might start using Watir. I just whipped up a little example and some doco about how to (and why) use RSpec with Watir. It's in RSpec's subversion under trunk/vendor/watir http://rubyforge.org/scm/?group_id=797 http://rubyforge.org/plugins/scmsvn/viewcvs.php/trunk/vendor/watir/?root=rspec There is a README where I try explain some of the benefits of the RSpec/Watir combo - from a user/qa/tester perspective. RSpec's specdoc feature, documentation and communication is key here. Please take a look and give some feedback. I'd like to put this up on RSpec's web page soon. Aslak From dchelimsky at gmail.com Wed Sep 6 10:52:55 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 6 Sep 2006 09:52:55 -0500 Subject: [Rspec-devel] support for arbitrary comparisons Message-ID: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> Mike Williams contributed a patch to support arbitrary comparisons. This is now in the trunk and will be part of the next release. So you will now be able to do this: result.should_be < 5 result.should_be >= 7 It also supports alternate syntax for should_be, should_match result.should == 3 result.should =~ /regex/ Personally, I prefer should_be and should_match in these cases, as I think they read better. Anyone else have opinions about that? This patch also supports using methods that are not formatted like predicates but act like them: def whatever true end subject.should_be_whatever I really object to this on philosophical grounds. Ruby predicates are a beautiful construct, and I personally feel that if you're writing methods like that you are violating a ruby aesthetic. If you agree with that, then you have to agree that supporting them in rspec also violates the same aesthetic. To that end, even though they work, they will not be offically supported at this point (i.e. you can use them, but they may go away some day). I'm curious to hear thoughts on this as well. Thanks again to Mike Williams for supporting arbitrary comparisons. It's really a great addition. Cheers, David From lists-rspec at shopwatch.org Wed Sep 6 11:16:55 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Wed, 06 Sep 2006 11:16:55 -0400 Subject: [Rspec-devel] support for arbitrary comparisons In-Reply-To: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> References: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> Message-ID: <44FEE667.5060403@shopwatch.org> David Chelimsky wrote: > Mike Williams contributed a patch to support arbitrary comparisons. > This is now in the trunk and will be part of the next release. So you > will now be able to do this: > > result.should_be < 5 > result.should_be >= 7 This rocks. > It also supports alternate syntax for should_be, should_match > > result.should == 3 > result.should =~ /regex/ > > Personally, I prefer should_be and should_match in these cases, as I > think they read better. Anyone else have opinions about that? I agree. I don't mind should =~ so much (though I probably wouldn't use it myself), but "should ==" reads "should_equal" to me, which is different than "should_be". > This patch also supports using methods that are not formatted like > predicates but act like them: > > def whatever > true > end > > subject.should_be_whatever > > I really object to this on philosophical grounds. This is so simple that I don't understand it... how/why would I use that in a real spec? Jay From dchelimsky at gmail.com Wed Sep 6 11:23:58 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 6 Sep 2006 10:23:58 -0500 Subject: [Rspec-devel] support for arbitrary comparisons In-Reply-To: <44FEE667.5060403@shopwatch.org> References: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> <44FEE667.5060403@shopwatch.org> Message-ID: <57c63afe0609060823q53b4e97ew85e6d90a695eff3e@mail.gmail.com> On 9/6/06, Jay Levitt wrote: > David Chelimsky wrote: > > This patch also supports using methods that are not formatted like > > predicates but act like them: > > > > def whatever > > true > > end > > > > subject.should_be_whatever > > > > I really object to this on philosophical grounds. > > This is so simple that I don't understand it... how/why would I use that > in a real spec? RSpec supports arbitrary predicates - any ruby method formatted with a "?" at the end that returns boolean. I use this for things like: collection.should_be_empty I do use that periodically, and I think that it is nicer than this: collection.empty?.should_be true David > > Jay > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Wed Sep 6 11:47:16 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 6 Sep 2006 17:47:16 +0200 Subject: [Rspec-devel] support for arbitrary comparisons In-Reply-To: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> References: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> Message-ID: <8d961d900609060847p53a9ac03n2053c9745771bbca@mail.gmail.com> On 9/6/06, David Chelimsky wrote: > Mike Williams contributed a patch to support arbitrary comparisons. > This is now in the trunk and will be part of the next release. So you > will now be able to do this: > > result.should_be < 5 > result.should_be >= 7 > > It also supports alternate syntax for should_be, should_match > > result.should == 3 > result.should =~ /regex/ > > Personally, I prefer should_be and should_match in these cases, as I > think they read better. Anyone else have opinions about that? > I prefer should_match and should_equal too, but I don't expect everyone to feel the same. I think it's great to support both. I don't see a problem with making this official now and add it to the website documentation. Dave's cheatsheet (which is not in svn - grr) should be updated too. > This patch also supports using methods that are not formatted like > predicates but act like them: > > def whatever > true > end > > subject.should_be_whatever > > I really object to this on philosophical grounds. Ruby predicates are > a beautiful construct, and I personally feel that if you're writing > methods like that you are violating a ruby aesthetic. If you agree > with that, then you have to agree that supporting them in rspec also > violates the same aesthetic. To that end, even though they work, they > will not be offically supported at this point (i.e. you can use them, > but they may go away some day). > I agree we shouldn't support non-questionmark "predicates". Let's make the day support for it goes away be today ;-) > I'm curious to hear thoughts on this as well. > > Thanks again to Mike Williams for supporting arbitrary comparisons. > It's really a great addition. > > Cheers, > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed Sep 6 11:51:31 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 6 Sep 2006 10:51:31 -0500 Subject: [Rspec-devel] support for arbitrary comparisons In-Reply-To: <8d961d900609060847p53a9ac03n2053c9745771bbca@mail.gmail.com> References: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> <8d961d900609060847p53a9ac03n2053c9745771bbca@mail.gmail.com> Message-ID: <57c63afe0609060851i14d81e30lbf06fa6af373b97e@mail.gmail.com> On 9/6/06, aslak hellesoy wrote: > On 9/6/06, David Chelimsky wrote: > > Mike Williams contributed a patch to support arbitrary comparisons. > > This is now in the trunk and will be part of the next release. So you > > will now be able to do this: > > > > result.should_be < 5 > > result.should_be >= 7 > > > > It also supports alternate syntax for should_be, should_match > > > > result.should == 3 > > result.should =~ /regex/ > > > > Personally, I prefer should_be and should_match in these cases, as I > > think they read better. Anyone else have opinions about that? > > > > I prefer should_match and should_equal too, but I don't expect > everyone to feel the same. I think it's great to support both. Fair enough. > I don't see a problem with making this official now and add it to the > website documentation. Dave's cheatsheet (which is not in svn - grr) > should be updated too. In the process of doing so (not on the cheatsheet). > > This patch also supports using methods that are not formatted like > > predicates but act like them: > > > > def whatever > > true > > end > > > > subject.should_be_whatever > > > > I really object to this on philosophical grounds. Ruby predicates are > > a beautiful construct, and I personally feel that if you're writing > > methods like that you are violating a ruby aesthetic. If you agree > > with that, then you have to agree that supporting them in rspec also > > violates the same aesthetic. To that end, even though they work, they > > will not be offically supported at this point (i.e. you can use them, > > but they may go away some day). > > > > I agree we shouldn't support non-questionmark "predicates". Let's make > the day support for it goes away be today ;-) The only problem with explicitly not supporting them (i.e. not letting them work at all) is that it gums up the rspec code which is currently quite general. My thinking is that if it is in the docs, it is supported. Otherwise you're on your own. What do you think? > > > I'm curious to hear thoughts on this as well. > > > > Thanks again to Mike Williams for supporting arbitrary comparisons. > > It's really a great addition. > > > > Cheers, > > David > > _______________________________________________ > > 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 Sep 6 11:56:53 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 6 Sep 2006 17:56:53 +0200 Subject: [Rspec-devel] support for arbitrary comparisons In-Reply-To: <57c63afe0609060851i14d81e30lbf06fa6af373b97e@mail.gmail.com> References: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> <8d961d900609060847p53a9ac03n2053c9745771bbca@mail.gmail.com> <57c63afe0609060851i14d81e30lbf06fa6af373b97e@mail.gmail.com> Message-ID: <8d961d900609060856n13360d09j5c80043542317f8e@mail.gmail.com> On 9/6/06, David Chelimsky wrote: > On 9/6/06, aslak hellesoy wrote: > > On 9/6/06, David Chelimsky wrote: > > > Mike Williams contributed a patch to support arbitrary comparisons. > > > This is now in the trunk and will be part of the next release. So you > > > will now be able to do this: > > > > > > result.should_be < 5 > > > result.should_be >= 7 > > > > > > It also supports alternate syntax for should_be, should_match > > > > > > result.should == 3 > > > result.should =~ /regex/ > > > > > > Personally, I prefer should_be and should_match in these cases, as I > > > think they read better. Anyone else have opinions about that? > > > > > > > I prefer should_match and should_equal too, but I don't expect > > everyone to feel the same. I think it's great to support both. > > Fair enough. > > > I don't see a problem with making this official now and add it to the > > website documentation. Dave's cheatsheet (which is not in svn - grr) > > should be updated too. > > In the process of doing so (not on the cheatsheet). > > > > This patch also supports using methods that are not formatted like > > > predicates but act like them: > > > > > > def whatever > > > true > > > end > > > > > > subject.should_be_whatever > > > > > > I really object to this on philosophical grounds. Ruby predicates are > > > a beautiful construct, and I personally feel that if you're writing > > > methods like that you are violating a ruby aesthetic. If you agree > > > with that, then you have to agree that supporting them in rspec also > > > violates the same aesthetic. To that end, even though they work, they > > > will not be offically supported at this point (i.e. you can use them, > > > but they may go away some day). > > > > > > > I agree we shouldn't support non-questionmark "predicates". Let's make > > the day support for it goes away be today ;-) > > The only problem with explicitly not supporting them (i.e. not letting > them work at all) is that it gums up the rspec code which is currently > quite general. My thinking is that if it is in the docs, it is > supported. Otherwise you're on your own. > > What do you think? Fair enough. A non-documented feature is a non-feature. Aslak > > > > > > I'm curious to hear thoughts on this as well. > > > > > > Thanks again to Mike Williams for supporting arbitrary comparisons. > > > It's really a great addition. > > > > > > Cheers, > > > David > > > _______________________________________________ > > > 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 dastels at daveastels.com Wed Sep 6 12:06:14 2006 From: dastels at daveastels.com (David Astels) Date: Wed, 6 Sep 2006 13:06:14 -0300 Subject: [Rspec-devel] support for arbitrary comparisons In-Reply-To: <8d961d900609060847p53a9ac03n2053c9745771bbca@mail.gmail.com> References: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> <8d961d900609060847p53a9ac03n2053c9745771bbca@mail.gmail.com> Message-ID: <2F34FA88-EA57-4664-8C71-17B4FAEBB021@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6-Sep-06, at 12:47 PM, aslak hellesoy wrote: > Dave's cheatsheet (which is not in svn - grr) OK.. done. I was waiting for a resolution to the great underscore war.. and it got pushed to the back burner. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE/vH3auez/L4x7g4RAiWPAJ9HAfLfk9+m9amrHOEGn20271Ga1ACbBtdY 9EkTn6ITJBmO9V45Jx52BSQ= =oHhS -----END PGP SIGNATURE----- From dchelimsky at gmail.com Wed Sep 6 12:28:04 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 6 Sep 2006 11:28:04 -0500 Subject: [Rspec-devel] support for arbitrary comparisons In-Reply-To: <8d961d900609060856n13360d09j5c80043542317f8e@mail.gmail.com> References: <57c63afe0609060752q1e18edf9pd16ddf518a2f2191@mail.gmail.com> <8d961d900609060847p53a9ac03n2053c9745771bbca@mail.gmail.com> <57c63afe0609060851i14d81e30lbf06fa6af373b97e@mail.gmail.com> <8d961d900609060856n13360d09j5c80043542317f8e@mail.gmail.com> Message-ID: <57c63afe0609060928p2855b123r4ec151071d17ca08@mail.gmail.com> On 9/6/06, aslak hellesoy wrote: > On 9/6/06, David Chelimsky wrote: > > On 9/6/06, aslak hellesoy wrote: > > > On 9/6/06, David Chelimsky wrote: > > > > Mike Williams contributed a patch to support arbitrary comparisons. > > > > This is now in the trunk and will be part of the next release. So you > > > > will now be able to do this: > > > > > > > > result.should_be < 5 > > > > result.should_be >= 7 > > > > > > > > It also supports alternate syntax for should_be, should_match > > > > > > > > result.should == 3 > > > > result.should =~ /regex/ > > > > > > > > Personally, I prefer should_be and should_match in these cases, as I > > > > think they read better. Anyone else have opinions about that? > > > > > > > > > > I prefer should_match and should_equal too, but I don't expect > > > everyone to feel the same. I think it's great to support both. > > > > Fair enough. > > > > > I don't see a problem with making this official now and add it to the > > > website documentation. Dave's cheatsheet (which is not in svn - grr) > > > should be updated too. > > > > In the process of doing so (not on the cheatsheet). > > > > > > This patch also supports using methods that are not formatted like > > > > predicates but act like them: > > > > > > > > def whatever > > > > true > > > > end > > > > > > > > subject.should_be_whatever > > > > > > > > I really object to this on philosophical grounds. Ruby predicates are > > > > a beautiful construct, and I personally feel that if you're writing > > > > methods like that you are violating a ruby aesthetic. If you agree > > > > with that, then you have to agree that supporting them in rspec also > > > > violates the same aesthetic. To that end, even though they work, they > > > > will not be offically supported at this point (i.e. you can use them, > > > > but they may go away some day). > > > > > > > > > > I agree we shouldn't support non-questionmark "predicates". Let's make > > > the day support for it goes away be today ;-) > > > > The only problem with explicitly not supporting them (i.e. not letting > > them work at all) is that it gums up the rspec code which is currently > > quite general. My thinking is that if it is in the docs, it is > > supported. Otherwise you're on your own. > > > > What do you think? > > Fair enough. A non-documented feature is a non-feature. Changed my mind. It was way too simple to add the non-support and clarify what is supported directly in the code. So I've checked in the non-support for non-predicates. You can still do this: target.non_predicate.should_be true (or false) Cheers, David From aslak.hellesoy at gmail.com Thu Sep 7 05:43:52 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 7 Sep 2006 11:43:52 +0200 Subject: [Rspec-devel] Dead easy Watir AND Selenium Message-ID: <8d961d900609070243k5ac8e877p5333ced152e47874@mail.gmail.com> Yesterday I added some Watir examples to RSpec's svn. Today I added some Selenium (actually - Selenium Remote Control) examples. It's dead easy to use both, and the Ruby code you end up writing is actually quite similar. Here's a taste: == Watir == require File.dirname(__FILE__) + '/rspec_watir' context "Google's search page" do setup do @browser.goto('http://www.google.com') end specify "should find rspec's home page" do @browser.text_field(:name, "q").set("rspec") @browser.button(:name, "btnG").click @browser.contains_text("rspec.rubyforge.org").should_be(true) end specify "should not find Ali G when I search for rspec" do @browser.text_field(:name, "q").set("rspec") @browser.button(:name, "btnG").click @browser.contains_text("Ali G").should_be(false) end end == Selenium == require File.dirname(__FILE__) + '/rspec_selenium' context "Google's search page" do setup do @browser = Selenium::SeleneseInterpreter.new("localhost", 4444, "*firefox", "http://www.google.no", 10000) @browser.start @browser.open('http://www.google.no') end specify "should find rspec's home page" do @browser.type "name=q", "rspec" @browser.click_and_wait "name=btnG" @browser.is_text_present("rspec.rubyforge.org").should_be(true) end specify "should not find Ali G when I search for rspec" do @browser.type "name=q", "rspec" @browser.click_and_wait "name=btnG" @browser.is_text_present("Ali G").should_be(false) end end From dchelimsky at gmail.com Thu Sep 7 09:02:47 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 7 Sep 2006 08:02:47 -0500 Subject: [Rspec-devel] Dead easy Watir AND Selenium In-Reply-To: <8d961d900609070243k5ac8e877p5333ced152e47874@mail.gmail.com> References: <8d961d900609070243k5ac8e877p5333ced152e47874@mail.gmail.com> Message-ID: <57c63afe0609070602w7bd6c948o310fc9dbe1b20da3@mail.gmail.com> On 9/7/06, aslak hellesoy wrote: > Yesterday I added some Watir examples to RSpec's svn. Have you tried this w/ firewatir? > Today I added some Selenium (actually - Selenium Remote Control) examples. > > It's dead easy to use both, and the Ruby code you end up writing is > actually quite similar. Here's a taste: > > == Watir == > require File.dirname(__FILE__) + '/rspec_watir' > > context "Google's search page" do > > setup do > @browser.goto('http://www.google.com') > end > > specify "should find rspec's home page" do > @browser.text_field(:name, "q").set("rspec") > @browser.button(:name, "btnG").click > @browser.contains_text("rspec.rubyforge.org").should_be(true) > end > > specify "should not find Ali G when I search for rspec" do > @browser.text_field(:name, "q").set("rspec") > @browser.button(:name, "btnG").click > @browser.contains_text("Ali G").should_be(false) > end > > end > > == Selenium == > require File.dirname(__FILE__) + '/rspec_selenium' > > context "Google's search page" do > > setup do > @browser = Selenium::SeleneseInterpreter.new("localhost", 4444, > "*firefox", "http://www.google.no", 10000) > @browser.start > @browser.open('http://www.google.no') > end > > specify "should find rspec's home page" do > @browser.type "name=q", "rspec" > @browser.click_and_wait "name=btnG" > @browser.is_text_present("rspec.rubyforge.org").should_be(true) > end > > specify "should not find Ali G when I search for rspec" do > @browser.type "name=q", "rspec" > @browser.click_and_wait "name=btnG" > @browser.is_text_present("Ali G").should_be(false) > end > > end > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Thu Sep 7 10:59:33 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 7 Sep 2006 16:59:33 +0200 Subject: [Rspec-devel] Dead easy Watir AND Selenium In-Reply-To: <57c63afe0609070602w7bd6c948o310fc9dbe1b20da3@mail.gmail.com> References: <8d961d900609070243k5ac8e877p5333ced152e47874@mail.gmail.com> <57c63afe0609070602w7bd6c948o310fc9dbe1b20da3@mail.gmail.com> Message-ID: <8d961d900609070759y7528fb14o85c48d12c58f402a@mail.gmail.com> On 9/7/06, David Chelimsky wrote: > On 9/7/06, aslak hellesoy wrote: > > Yesterday I added some Watir examples to RSpec's svn. > > Have you tried this w/ firewatir? > No > > Today I added some Selenium (actually - Selenium Remote Control) examples. > > > > It's dead easy to use both, and the Ruby code you end up writing is > > actually quite similar. Here's a taste: > > > > == Watir == > > require File.dirname(__FILE__) + '/rspec_watir' > > > > context "Google's search page" do > > > > setup do > > @browser.goto('http://www.google.com') > > end > > > > specify "should find rspec's home page" do > > @browser.text_field(:name, "q").set("rspec") > > @browser.button(:name, "btnG").click > > @browser.contains_text("rspec.rubyforge.org").should_be(true) > > end > > > > specify "should not find Ali G when I search for rspec" do > > @browser.text_field(:name, "q").set("rspec") > > @browser.button(:name, "btnG").click > > @browser.contains_text("Ali G").should_be(false) > > end > > > > end > > > > == Selenium == > > require File.dirname(__FILE__) + '/rspec_selenium' > > > > context "Google's search page" do > > > > setup do > > @browser = Selenium::SeleneseInterpreter.new("localhost", 4444, > > "*firefox", "http://www.google.no", 10000) > > @browser.start > > @browser.open('http://www.google.no') > > end > > > > specify "should find rspec's home page" do > > @browser.type "name=q", "rspec" > > @browser.click_and_wait "name=btnG" > > @browser.is_text_present("rspec.rubyforge.org").should_be(true) > > end > > > > specify "should not find Ali G when I search for rspec" do > > @browser.type "name=q", "rspec" > > @browser.click_and_wait "name=btnG" > > @browser.is_text_present("Ali G").should_be(false) > > end > > > > 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 aslak.hellesoy at gmail.com Thu Sep 7 16:32:45 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 7 Sep 2006 22:32:45 +0200 Subject: [Rspec-devel] --colour Message-ID: <8d961d900609071332m271cddb8sfc81f3b4a9afff8@mail.gmail.com> Inspired from http://on-ruby.blogspot.com/2006/05/red-and-green-for-ruby.html I just committed support for a new option: -c, --colour, --color It will output the summary in red or green. Until we make a release, you can see it in the svn code with: ruby -Ilib bin/spec examples -c Cheers, Aslak From smartgpx at gmail.com Thu Sep 7 18:38:05 2006 From: smartgpx at gmail.com (DeeJay) Date: Thu, 7 Sep 2006 23:38:05 +0100 Subject: [Rspec-devel] --colour Message-ID: <533048b70609071538w2a56018ah891b16c461fb4963@mail.gmail.com> " I just committed support for a new option: -c, --colour, --color It will output the summary in red or green. " Hey, support in both languages, English and American! :-) I haven't looked or tried yet, so being lazy but hopeful... have you taken Windows users into account, given that cmd and command don't natively have support for colour terminals? regards DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060907/debe8f2c/attachment.html From aslak.hellesoy at gmail.com Thu Sep 7 19:15:00 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 8 Sep 2006 01:15:00 +0200 Subject: [Rspec-devel] --colour In-Reply-To: <533048b70609071538w2a56018ah891b16c461fb4963@mail.gmail.com> References: <533048b70609071538w2a56018ah891b16c461fb4963@mail.gmail.com> Message-ID: <8d961d900609071615sd13b398q496d47f68f8027f5@mail.gmail.com> On 9/8/06, DeeJay wrote: > > " I just committed support for a new option: -c, --colour, --color > It will output the summary in red or green. " > > Hey, support in both languages, English and American! :-) > > I haven't looked or tried yet, so being lazy but hopeful... have you taken > Windows users into account, given that cmd and command don't natively have > support for colour terminals? > If windows shells don't support colours, how would we take windows users into account? What can we do for them? Aslak > regards > > > DeeJay > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Thu Sep 7 19:32:32 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 7 Sep 2006 18:32:32 -0500 Subject: [Rspec-devel] --colour In-Reply-To: <8d961d900609071615sd13b398q496d47f68f8027f5@mail.gmail.com> References: <533048b70609071538w2a56018ah891b16c461fb4963@mail.gmail.com> <8d961d900609071615sd13b398q496d47f68f8027f5@mail.gmail.com> Message-ID: <57c63afe0609071632n78d4daddva1e73a9eded22ee7@mail.gmail.com> On 9/7/06, aslak hellesoy wrote: > On 9/8/06, DeeJay wrote: > > > > " I just committed support for a new option: -c, --colour, --color > > It will output the summary in red or green. " > > > > Hey, support in both languages, English and American! :-) > > > > I haven't looked or tried yet, so being lazy but hopeful... have you taken > > Windows users into account, given that cmd and command don't natively have > > support for colour terminals? > > > > If windows shells don't support colours, how would we take windows > users into account? What can we do for them? Advise them to use cygwin! > > Aslak > > > regards > > > > > > DeeJay > > _______________________________________________ > > 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 smartgpx at gmail.com Fri Sep 8 02:33:20 2006 From: smartgpx at gmail.com (DeeJay) Date: Fri, 8 Sep 2006 07:33:20 +0100 Subject: [Rspec-devel] --colour Message-ID: <533048b70609072333t3aba5399nfcc7a0ad9373087f@mail.gmail.com> " If windows shells don't support colours, how would we take windows users into account? " >From a later blog entry " http://on-ruby.blogspot.com/2006/06/more-fun-with-redgreen.html" in the same series... As a pre-requisite: gem install win32console Then in the code: require 'Win32/Console/ANSI' if PLATFORM =~ /win32/ DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060908/0d756169/attachment.html From smartgpx at gmail.com Fri Sep 8 07:06:18 2006 From: smartgpx at gmail.com (DeeJay) Date: Fri, 8 Sep 2006 12:06:18 +0100 Subject: [Rspec-devel] --colour : Windows complications Message-ID: <533048b70609080406p4f7e291dve96ec8ef99c0586d@mail.gmail.com> Actually, the code presently in trunk doesn't only 'not support' Windows users, but positively 'breaks' the screen presentation. [If --colour is given as an option, so the easy workaround is to leave it out! :-) ] Like this - J:\TryBZR>spec specs -c ............................ Finished in 0.265 seconds ?[32m28 specifications, 0 failures?[0m [ Those " <-[#m " sequences are the ansi controls not being interpreted by Windows.] Trying to reproduce ansi-terminal functionality with win32console works OK with a simple 'puts "\e[32m" ', but breaks somewhere in rspec's Formatter and Reporter classes, because putting @output << "\e[32m" in the formatter's dump methods does not have the desired effect DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060908/248d7cda/attachment.html From aslak.hellesoy at gmail.com Fri Sep 8 09:25:26 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 8 Sep 2006 15:25:26 +0200 Subject: [Rspec-devel] --colour : Windows complications In-Reply-To: <533048b70609080406p4f7e291dve96ec8ef99c0586d@mail.gmail.com> References: <533048b70609080406p4f7e291dve96ec8ef99c0586d@mail.gmail.com> Message-ID: <8d961d900609080625u4e0aac22iccf3e3eeccb06d53@mail.gmail.com> On 9/8/06, DeeJay wrote: > > > Actually, the code presently in trunk doesn't only 'not support' Windows > users, but positively 'breaks' the screen presentation. [If --colour is > given as an option, so the easy workaround is to leave it out! :-) ] > > Like this - > > > J:\TryBZR>spec specs -c > > ............................ > > Finished in 0.265 seconds > > ?[32m28 specifications, 0 failures?[0m > > [ Those " <-[#m " sequences are the ansi controls not being interpreted by > Windows.] > > > > Trying to reproduce ansi-terminal functionality with win32console works OK > with a simple 'puts "\e[32m" ', but breaks somewhere in rspec's Formatter > and Reporter classes, because putting @output << "\e[32m" in the > formatter's dump methods does not have the desired effect > It looks like STDOUT.puts and puts Don't behave the same way with win32console . I'll work something out. Aslak > DeeJay > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From smartgpx at gmail.com Fri Sep 8 09:57:22 2006 From: smartgpx at gmail.com (DeeJay) Date: Fri, 8 Sep 2006 14:57:22 +0100 Subject: [Rspec-devel] --colour : Windows complications Message-ID: <533048b70609080657o2022b980na3fd01196daecd15@mail.gmail.com> " It looks like STDOUT.puts and puts Don't behave the same way with win32console . " I'm slower on the uptake, but had reached a similar conclusion, demonstrated here - === require 'Win32/Console/ANSI' @works = $stdout @works << "\e[31m" << "RED" << "\e[32m" << "GREEN" << "\e[0m" << "normal" << "\n" @fails = STDOUT @fails << "\e[31m" << "RED" << "\e[32m" << "GREEN" << "\e[0m" << "normal" << "\n" === Changing the default output stream from STDOUT to $stdout breaks other things, but doesn't fix this. Looking in the win32console library, at the end of ../Win32/Console/ANSI.rb, it is a new $stdout that gets returned, which is an IO with its own 'write' method. So it seems STDOUT << 'string' doesn't go through win32console at all. DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060908/52f08d84/attachment-0001.html From aslak.hellesoy at gmail.com Fri Sep 8 10:11:53 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 8 Sep 2006 16:11:53 +0200 Subject: [Rspec-devel] --colour : Windows complications In-Reply-To: <533048b70609080657o2022b980na3fd01196daecd15@mail.gmail.com> References: <533048b70609080657o2022b980na3fd01196daecd15@mail.gmail.com> Message-ID: <8d961d900609080711t7d4eee3ao6972a45b060bbb5e@mail.gmail.com> On 9/8/06, DeeJay wrote: > > " It looks like > > STDOUT.puts > and > puts > > Don't behave the same way with win32console . " > > I'm slower on the uptake, but had reached a similar conclusion, demonstrated > here - > > === > > > > require 'Win32/Console/ANSI' > > @works = $stdout > @works << "\e[31m" << "RED" << "\e[32m" << "GREEN" << "\e[0m" << "normal" << > "\n" > @fails = STDOUT > @fails << "\e[31m" << "RED" << "\e[32m" << "GREEN" << "\e[0m" << "normal" << > "\n" > > > === > > > Changing the default output stream from STDOUT to $stdout breaks other > things, but doesn't fix this. > > Looking in the win32console library, at the end of ../Win32/Console/ANSI.rb, > it is a new $stdout that > gets returned, which is an IO with its own 'write' method. So it seems > STDOUT << 'string' doesn't > go through win32console at all. > I just committed a fix so this should now work on windows (I hope I didn't break native support on osx/linux). It's a hack in base_text_formatter.rb. A little ugly but it works. Aslak > > DeeJay > > > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Fri Sep 8 10:22:20 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 8 Sep 2006 09:22:20 -0500 Subject: [Rspec-devel] --colour : Windows complications In-Reply-To: <8d961d900609080711t7d4eee3ao6972a45b060bbb5e@mail.gmail.com> References: <533048b70609080657o2022b980na3fd01196daecd15@mail.gmail.com> <8d961d900609080711t7d4eee3ao6972a45b060bbb5e@mail.gmail.com> Message-ID: <57c63afe0609080722i17f2177aqe99af77e854a54b@mail.gmail.com> On 9/8/06, aslak hellesoy wrote: > On 9/8/06, DeeJay wrote: > > > > " It looks like > > > > STDOUT.puts > > and > > puts > > > > Don't behave the same way with win32console . " > > > > I'm slower on the uptake, but had reached a similar conclusion, demonstrated > > here - > > > > === > > > > > > > > require 'Win32/Console/ANSI' > > > > @works = $stdout > > @works << "\e[31m" << "RED" << "\e[32m" << "GREEN" << "\e[0m" << "normal" << > > "\n" > > @fails = STDOUT > > @fails << "\e[31m" << "RED" << "\e[32m" << "GREEN" << "\e[0m" << "normal" << > > "\n" > > > > > > === > > > > > > Changing the default output stream from STDOUT to $stdout breaks other > > things, but doesn't fix this. > > > > Looking in the win32console library, at the end of ../Win32/Console/ANSI.rb, > > it is a new $stdout that > > gets returned, which is an IO with its own 'write' method. So it seems > > STDOUT << 'string' doesn't > > go through win32console at all. > > > > I just committed a fix so this should now work on windows (I hope I > didn't break native support on osx/linux). It's a hack in > base_text_formatter.rb. A little ugly but it works. Works on OS X fine. Hack is hack-ish - but it's a text formatter class that deals generally w/ console output, so it's as good a place for it as any. Nice work on this Aslak. David > > Aslak > > > > > DeeJay > > > > > > > > _______________________________________________ > > 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 smartgpx at gmail.com Fri Sep 8 11:05:59 2006 From: smartgpx at gmail.com (DeeJay) Date: Fri, 8 Sep 2006 16:05:59 +0100 Subject: [Rspec-devel] --colour : Windows OK Message-ID: <533048b70609080805t3db108deqe45b9976c9089c25@mail.gmail.com> Aslak At rev 761, looks fine on Windows with ruby 1.8.4 (2006-04-14) [i386-mswin32] from OneClickInstaller184-19. Thanks for your efforts and rapid response. DeeJay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060908/70b9dff5/attachment.html From maillist at steelskies.com Fri Sep 8 11:23:24 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Fri, 8 Sep 2006 16:23:24 +0100 Subject: [Rspec-devel] Rails controller testing questions Message-ID: <44E0F5E9-7262-4FD7-9260-701E3AD2741C@steelskies.com> I'm fine with model specs, but for some reason I'm struggling a bit making controller specs feel right. I'd love to see some more examples if anyone has any they're willing to share. Also, I have a few questions... -- Is there any difference between should_have_tag 'input', :attributes => {:id => 'asset_name'} and response.body.should_have_tag 'input', :attributes => {:id => 'asset_name'} ? Both styles are used on http://rspec.rubyforge.org/tools/rails.html -- Is it possible to get route recognition testing to work in rspec? eg - assert_recognizes({:controller => 'assets', :action => 'new'}, {:path => "/assets/new", :method => :get}) -- How about named urls? Being able to use get assets_url would be fairly handy -- Finally, is it just me, or is rspec controller testing missing a bunch of useful functionality? For example, in rails functional tests there's assert_redirect_to :action => 'index' and I'm struggling to find an equivalent in rspec. The closest thing I can find is response.redirect_url.should_be 'http://test.host/assets' which is liable to break if, say, your default controller in routes.rb is AssetsController. I really want to like rspec for controller testing, but I keep on running into little annoyances like the above. Am I the only one? Jon From aslak.hellesoy at gmail.com Fri Sep 8 11:43:32 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 8 Sep 2006 17:43:32 +0200 Subject: [Rspec-devel] Rails controller testing questions In-Reply-To: <44E0F5E9-7262-4FD7-9260-701E3AD2741C@steelskies.com> References: <44E0F5E9-7262-4FD7-9260-701E3AD2741C@steelskies.com> Message-ID: <8d961d900609080843r614728bdy67d42f782c88ae60@mail.gmail.com> On 9/8/06, Jonathan del Strother wrote: > I'm fine with model specs, but for some reason I'm struggling a bit > making controller specs feel right. I'd love to see some more > examples if anyone has any they're willing to share. > > Also, I have a few questions... > > -- > > Is there any difference between > > should_have_tag 'input', :attributes => {:id => 'asset_name'} > > and > > response.body.should_have_tag 'input', :attributes => {:id => > 'asset_name'} > > ? > > Both styles are used on http://rspec.rubyforge.org/tools/rails.html > > -- > > Is it possible to get route recognition testing to work in rspec? eg - > assert_recognizes({:controller => 'assets', :action => 'new'}, > {:path => "/assets/new", :method => :get}) > > > -- > > How about named urls? Being able to use > get assets_url > would be fairly handy > > > -- > > Finally, is it just me, or is rspec controller testing missing a > bunch of useful functionality? For example, in rails functional > tests there's > assert_redirect_to :action => 'index' > and I'm struggling to find an equivalent in rspec. The closest thing > I can find is > response.redirect_url.should_be 'http://test.host/assets' > which is liable to break if, say, your default controller in > routes.rb is AssetsController. > > > I really want to like rspec for controller testing, but I keep on > running into little annoyances like the above. Am I the only one? > The controller part definitely needs more love. Who's up for improving it? Plugin code or examples. Or even blog entries. My wishlist: * Show how to decouple controllers from models usgin Mocha/Stubba * Show how to use CSS selectors to verify views (scrapi, hpricot) * Implement rspec equivalents for Rails' assert_foo stuff that applies to controllers. Aslak > > Jon > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Fri Sep 8 12:18:39 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 8 Sep 2006 11:18:39 -0500 Subject: [Rspec-devel] Rails controller testing questions In-Reply-To: <44E0F5E9-7262-4FD7-9260-701E3AD2741C@steelskies.com> References: <44E0F5E9-7262-4FD7-9260-701E3AD2741C@steelskies.com> Message-ID: <57c63afe0609080918q782208eam4f2f3d9ad3a5c75@mail.gmail.com> On 9/8/06, Jonathan del Strother wrote: > I'm fine with model specs, but for some reason I'm struggling a bit > making controller specs feel right. I'd love to see some more > examples if anyone has any they're willing to share. > > Also, I have a few questions... > > -- > > Is there any difference between > > should_have_tag 'input', :attributes => {:id => 'asset_name'} > > and > > response.body.should_have_tag 'input', :attributes => {:id => > 'asset_name'} Ironically, the first one didn't work - it only failed to fail (don't know why). However, I've just gotten it to work and committed it. So you should use this: should_have_tag 'input', :attributes => {:id => 'asset_name'} Though the other won't break, it will be deprectated. > > ? > > Both styles are used on http://rspec.rubyforge.org/tools/rails.html > > -- > > Is it possible to get route recognition testing to work in rspec? eg - > assert_recognizes({:controller => 'assets', :action => 'new'}, > {:path => "/assets/new", :method => :get}) > > > -- > > How about named urls? Being able to use > get assets_url > would be fairly handy > > > -- > > Finally, is it just me, or is rspec controller testing missing a > bunch of useful functionality? For example, in rails functional > tests there's > assert_redirect_to :action => 'index' > and I'm struggling to find an equivalent in rspec. The closest thing > I can find is > response.redirect_url.should_be 'http://test.host/assets' > which is liable to break if, say, your default controller in > routes.rb is AssetsController. > > > I really want to like rspec for controller testing, but I keep on > running into little annoyances like the above. Am I the only one? Hi Jon. No, you are definitely not the only one. rspec_on_rails is a work in progress. That said, would you please check the existing RFEs and add any that you feel are missing from both rspec and the existing backlog? http://rubyforge.org/tracker/?atid=3152&group_id=797&func=browse Thanks, David > > > Jon > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From jamesmead44 at gmail.com Tue Sep 12 04:57:53 2006 From: jamesmead44 at gmail.com (James Mead) Date: Tue, 12 Sep 2006 09:57:53 +0100 Subject: [Rspec-devel] Mocha and TestCase#add_assertion Message-ID: <1db558f00609120157w1ea8396dte4ed34a165a99127@mail.gmail.com> I had a query on the Mocha mailing list this morning from someone who is using RSpec and Mocha plugins. He was seeing an error which looks to be down to RSpec raising an exception when add_assertion is called. Mocha uses add_assertion to include verified expectations in the assertion count. My colleague Chris Roos gives the following tests as an illustration of the problem. # normal test, no errors def test_abc add_assertion end # rspec spec, raises nil.add_assertion spec "should blah" do add_assertion end I haven't looked into it any further, but does anyone have any ideas? I suggested he patched his version of Mocha to rescue the exception, but told him I wasn't sure of the ramifications on the RSpec side. -- James. http://blog.floehopper.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060912/2b6130f0/attachment.html From maillist at steelskies.com Tue Sep 12 05:24:13 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Tue, 12 Sep 2006 10:24:13 +0100 Subject: [Rspec-devel] Mocha and TestCase#add_assertion In-Reply-To: <1db558f00609120157w1ea8396dte4ed34a165a99127@mail.gmail.com> References: <1db558f00609120157w1ea8396dte4ed34a165a99127@mail.gmail.com> Message-ID: On 12 Sep 2006, at 09:57, James Mead wrote: > I had a query on the Mocha mailing list this morning from someone > who is using RSpec and Mocha plugins. He was seeing an error which > looks to be down to RSpec raising an exception when add_assertion > is called. Mocha uses add_assertion to include verified > expectations in the assertion count. My colleague Chris Roos gives > the following tests as an illustration of the problem. > > # normal test, no errors > def test_abc > add_assertion > end > > # rspec spec, raises nil.add_assertion > spec "should blah" do > add_assertion > end > > I haven't looked into it any further, but does anyone have any > ideas? I suggested he patched his version of Mocha to rescue the > exception, but told him I wasn't sure of the ramifications on the > RSpec side. Just FWIW, add_assertion expects a @_result object. I needed to call assert_redirected_to, and was running into similar problems. You could set it up before each call to assert (@_result = Test::Unit::TestResult.new), though this adds a dependency on Test:Unit which may or may not be desirable. You could set up a fake object with an add_assertion method, and assign that to @_result. ...however, these are all hacks that are just there as a workaround, and I'm guessing there's a much better way of doing this. From dchelimsky at gmail.com Tue Sep 12 09:15:15 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 12 Sep 2006 09:15:15 -0400 Subject: [Rspec-devel] Mocha and TestCase#add_assertion In-Reply-To: References: <1db558f00609120157w1ea8396dte4ed34a165a99127@mail.gmail.com> Message-ID: <57c63afe0609120615u28555bbap6a74422dd62720e0@mail.gmail.com> On 9/12/06, Jonathan del Strother wrote: > On 12 Sep 2006, at 09:57, James Mead wrote: > > > I had a query on the Mocha mailing list this morning from someone > > who is using RSpec and Mocha plugins. He was seeing an error which > > looks to be down to RSpec raising an exception when add_assertion > > is called. Mocha uses add_assertion to include verified > > expectations in the assertion count. My colleague Chris Roos gives > > the following tests as an illustration of the problem. > > > > # normal test, no errors > > def test_abc > > add_assertion > > end > > > > # rspec spec, raises nil.add_assertion > > spec "should blah" do > > add_assertion > > end > > > > I haven't looked into it any further, but does anyone have any > > ideas? I suggested he patched his version of Mocha to rescue the > > exception, but told him I wasn't sure of the ramifications on the > > RSpec side. > > Just FWIW, add_assertion expects a @_result object. I needed to call > assert_redirected_to, and was running into similar problems. You > could set it up before each call to assert (@_result = > Test::Unit::TestResult.new), though this adds a dependency on > Test:Unit which may or may not be desirable. You must be using this in the rails environment. The reason you can use "assert_redirected_to" is because we're inheriting from Test::Unit::TestCase already. > You could set up a fake > object with an add_assertion method, and assign that to @_result. > > ...however, these are all hacks that are just there as a workaround, > and I'm guessing there's a much better way of doing this. Agreed, but the fact that we're inheriting from test/unit is a hack, in my view, to begin with. In the long run, I'd like to see rspec_on_rails running on its own legs but that is some time off. David From aslak.hellesoy at gmail.com Tue Sep 12 10:21:26 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 12 Sep 2006 16:21:26 +0200 Subject: [Rspec-devel] Mocha and TestCase#add_assertion In-Reply-To: <57c63afe0609120615u28555bbap6a74422dd62720e0@mail.gmail.com> References: <1db558f00609120157w1ea8396dte4ed34a165a99127@mail.gmail.com> <57c63afe0609120615u28555bbap6a74422dd62720e0@mail.gmail.com> Message-ID: <8d961d900609120721k43934cegd30f7f8baa195a74@mail.gmail.com> On 9/12/06, David Chelimsky wrote: > On 9/12/06, Jonathan del Strother wrote: > > On 12 Sep 2006, at 09:57, James Mead wrote: > > > > > I had a query on the Mocha mailing list this morning from someone > > > who is using RSpec and Mocha plugins. He was seeing an error which > > > looks to be down to RSpec raising an exception when add_assertion > > > is called. Mocha uses add_assertion to include verified > > > expectations in the assertion count. My colleague Chris Roos gives > > > the following tests as an illustration of the problem. > > > > > > # normal test, no errors > > > def test_abc > > > add_assertion > > > end > > > > > > # rspec spec, raises nil.add_assertion > > > spec "should blah" do > > > add_assertion > > > end > > > > > > I haven't looked into it any further, but does anyone have any > > > ideas? I suggested he patched his version of Mocha to rescue the > > > exception, but told him I wasn't sure of the ramifications on the > > > RSpec side. > > > > Just FWIW, add_assertion expects a @_result object. I needed to call > > assert_redirected_to, and was running into similar problems. You > > could set it up before each call to assert (@_result = > > Test::Unit::TestResult.new), though this adds a dependency on > > Test:Unit which may or may not be desirable. > > You must be using this in the rails environment. The reason you can > use "assert_redirected_to" is because we're inheriting from > Test::Unit::TestCase already. > > > You could set up a fake > > object with an add_assertion method, and assign that to @_result. > > > > ...however, these are all hacks that are just there as a workaround, > > and I'm guessing there's a much better way of doing this. > > Agreed, but the fact that we're inheriting from test/unit is a hack, > in my view, to begin with. In the long run, I'd like to see > rspec_on_rails running on its own legs but that is some time off. > That's where we started, and we had to reimplement tons of code - especially the fixtures stuff. When we got the inherit support in RSpec we could throw away a lot of our own code and reuse more from Rails. This is a Good Thing. It would be great if we could reuse without also getting the Test::Unit baggage, but I'm not sure that's going to happen. It's a major refactoring in Rails, and I'm not sure if anyone is willing to undertake that effort, even less sure it will get applied if someone does. And I don't see how the extra Test::Unit baggage is really hurting us. A > David > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Wed Sep 13 16:45:43 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 13 Sep 2006 15:45:43 -0500 Subject: [Rspec-devel] RSpec and autotest Message-ID: Hi RSpec'ers, I cobbled this [1] together yesterday. Does this seem appropriate to add to RSpec on Rails? It could probably use a little polishing too, so please try it out and let me know. Cheers, /Nick [1]: http://blog.nicksieger.com/articles/2006/09/13/auto-rspec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060913/84314127/attachment.html From aslak.hellesoy at gmail.com Wed Sep 13 17:39:52 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 13 Sep 2006 23:39:52 +0200 Subject: [Rspec-devel] RSpec and autotest In-Reply-To: References: Message-ID: <8d961d900609131439l1eecedava53e4ad3500331e8@mail.gmail.com> On 9/13/06, Nick Sieger wrote: > Hi RSpec'ers, > > I cobbled this [1] together yesterday. Does this seem appropriate to add to > RSpec on Rails? It could probably use a little polishing too, so please try > it out and let me know. > I haven't had time to try it yet - just glossed over the code. I'm interested in adding this to RSpec on Rails. I haven't really used autotest, but from what I know it runs your tests/specs in the background while you're hacking away right? I'll try it out next week (too busy till Sunday) and let you know more. My main concern is that anything we add to RSpec should have a regular maintainer and avoid the risk of things stopping to work when autotest/rails/rspec changes. We'd need a regular maintainer (you?) of this stuff. Cheers, Aslak > Cheers, > /Nick > > [1]: > http://blog.nicksieger.com/articles/2006/09/13/auto-rspec > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From nicksieger at gmail.com Wed Sep 13 17:57:15 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 13 Sep 2006 16:57:15 -0500 Subject: [Rspec-devel] RSpec and autotest In-Reply-To: <8d961d900609131439l1eecedava53e4ad3500331e8@mail.gmail.com> References: <8d961d900609131439l1eecedava53e4ad3500331e8@mail.gmail.com> Message-ID: On 9/13/06, aslak hellesoy wrote: > > I haven't really used autotest, but from what I know it runs your > tests/specs in the background while you're hacking away right? Yes, every time it saves a file. It runs individual failing specs until they succeed (the idea being that the change you just made that broke them will still be really fresh in your mind), and then once the tests succeed it re-runs all, and repeats. I haven't been using it very long but so far it sure beats switching to a console and typing "rake" all the time. Guess I'm just lazy :). My main concern is that anything we add to RSpec should have a > regular maintainer and avoid the risk of things stopping to work when > autotest/rails/rspec changes. We'd need a regular maintainer (you?) of > this stuff. No problem. I'd be fine with maintaining it, and I also certainly don't expect you to take every load of crap I throw at you guys :). I'm also interested to see how the ZenTest guys respond to it, as the code is brittle right now, not taking of intentional extension points in autotest. It's probably not appropriate to release with RSpec on Rails in it's current form. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060913/0b18be2c/attachment.html From nicksieger at gmail.com Wed Sep 13 17:58:53 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 13 Sep 2006 16:58:53 -0500 Subject: [Rspec-devel] RSpec and autotest In-Reply-To: References: <8d961d900609131439l1eecedava53e4ad3500331e8@mail.gmail.com> Message-ID: On 9/13/06, Nick Sieger wrote: > > > you just made that broke them will still be really fresh in your mind), > and then once the tests succeed it re-runs all, > s/tests/specs/ -- Old habits die hard ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060913/40be35a9/attachment.html From mikkel at shatteredruby.com Mon Sep 11 04:54:19 2006 From: mikkel at shatteredruby.com (Mikkel Garcia) Date: Mon, 11 Sep 2006 02:54:19 -0600 Subject: [Rspec-devel] RSpec mock ideas/bugs Message-ID: <2519B883-074A-4F98-A97B-E45C2FA3E582@shatteredruby.com> Hey guys, I'm a big fan of what y'all are trying to do. I've been running into a few issues with it, in the form of bugs(non-conformity) and ideas. Conformity - mock objects Mocks have a .nil? function context "A mock" do specify "should have no responses to any events" do @object = mock(:object) @object.nil? #Will not raise a mock unexpected message event @object.object_id #Will raise a mock unexpected message event end end Mocks returned by mocks expect an :instance_of call context "A mock returning a mock" do specify "should not receive instance_of message" do player = mock(:player) arch_enemy = mock(:arch_enemy) player.should_receive(:most_hated_enemy).and_return(arch_enemy) player.most_hated_enemy # This mock fails with: Mock 'enemy' received unexpected message 'instance_of?' with [] end end Ideas Mocks being substituted for real objects - True integration tests for free ? Alot of the specs we are writing separate responsibilities among tightly coupled classes. We are testing the individuality, but if we wanted to test the true integration of those classes we would probably have to create new specs. How about, instead, creating mock objects from classes themselves and having a rake spec:integrate task. This task would substitute the real classes for the mocks, which brings me to: Mocks/stubs syntax Let's say I have a Level object, and that is responsible for reading my map into the game. I have an object in that map I want to test (err...spec). Would something like this be feasible? @level = Level.mock or @level = Level.mock(:null_object => true) Or maybe I have a class that has a GUI portion, and I want to stub that function. @level = Level.stub #Keeps all the Level functionality and lets you stub things out @level.should_receive(:draw).and_return(true) That way, if you do something like: spec -integrate level_spec.rb it could turn all mocks and stubs into real objects. I'm really excited about the implications this has towards simplifying game design, and I'm hoping that it works well enough to replace Test::Unit for our 3d game framework, Shattered. Thanks, -Mikkel Garcia http://shatteredruby.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060911/9ac7fd0e/attachment.html From evgeny.zislis at gmail.com Thu Sep 14 04:58:49 2006 From: evgeny.zislis at gmail.com (Evgeny) Date: Thu, 14 Sep 2006 11:58:49 +0300 Subject: [Rspec-devel] RSpec and autotest In-Reply-To: References: <8d961d900609131439l1eecedava53e4ad3500331e8@mail.gmail.com> Message-ID: I usually use the "watch" command to run rake every 1-2 seconds, and after each change I glance at the other terminal to see if it failed. It also highlight changes -- which is very comfortable and the "new" error gets noticed. Doing it with recognition of file chages is better - but highlighting the changes is very nice. (i didnt test your auto-spec yet) just my 2cc Regards, Evgeny On 9/14/06, Nick Sieger wrote: > > On 9/13/06, aslak hellesoy wrote: > > > I haven't really used autotest, but from what I know it runs your > > tests/specs in the background while you're hacking away right? > > > Yes, every time it saves a file. It runs individual failing specs until > they succeed (the idea being that the change you just made that broke them > will still be really fresh in your mind), and then once the tests succeed it > re-runs all, and repeats. I haven't been using it very long but so far it > sure beats switching to a console and typing "rake" all the time. Guess I'm > just lazy :). > > My main concern is that anything we add to RSpec should have a > > regular maintainer and avoid the risk of things stopping to work when > > autotest/rails/rspec changes. We'd need a regular maintainer (you?) of > > this stuff. > > > No problem. I'd be fine with maintaining it, and I also certainly don't > expect you to take every load of crap I throw at you guys :). I'm also > interested to see how the ZenTest guys respond to it, as the code is brittle > right now, not taking of intentional extension points in autotest. It's > probably not appropriate to release with RSpec on Rails in it's current > form. > > /Nick > > _______________________________________________ > 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/20060914/ca5f86d2/attachment-0001.html From hughes.james at gmail.com Thu Sep 14 17:36:14 2006 From: hughes.james at gmail.com (James Hughes) Date: Thu, 14 Sep 2006 14:36:14 -0700 Subject: [Rspec-devel] RSpec and autotest In-Reply-To: References: Message-ID: <765a2c230609141436rf5e5976y214da06c43d2f4db@mail.gmail.com> On 9/13/06, Nick Sieger wrote: > Hi RSpec'ers, > > I cobbled this [1] together yesterday. Does this seem appropriate to add to > RSpec on Rails? It could probably use a little polishing too, so please try > it out and let me know. > Hey, I've been using this for a couple hours now and it seems to be working very well. Autotest was one thing I was missing from the Test::Unit world; really nice to have the beginnings of an implementation for rspec. jh -- James Hughes Web application developer Vancouver, BC "Developing a coherent political analysis is in many respects contingent upon an ability to connect one context to another, a process not dissimilar to playing the kid's game of dot-to-dot." - Ward Churchill, from '"A Government of Laws"?' From dchelimsky at gmail.com Mon Sep 18 00:18:25 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 18 Sep 2006 00:18:25 -0400 Subject: [rspec-devel] [Rspec-devel] RSpec mock ideas/bugs In-Reply-To: <2519B883-074A-4F98-A97B-E45C2FA3E582@shatteredruby.com> References: <2519B883-074A-4F98-A97B-E45C2FA3E582@shatteredruby.com> Message-ID: <57c63afe0609172118q6a74e596raab1dc33ff0fba28@mail.gmail.com> On 9/11/06, Mikkel Garcia wrote: > > Hey guys, > I'm a big fan of what y'all are trying to do. I've been running into a few > issues with it, in the form of bugs(non-conformity) and ideas. > > Conformity - mock objects > Mocks have a .nil? function > context "A mock" do > specify "should have no responses to any events" do > @object = mock(:object) > @object.nil? #Will not raise a mock unexpected message event > @object.object_id #Will raise a mock unexpected message event > end > end > > Mocks returned by mocks expect an :instance_of call > context "A mock returning a mock" do > specify "should not receive instance_of message" do > player = mock(:player) > arch_enemy = mock(:arch_enemy) > > player.should_receive(:most_hated_enemy).and_return(arch_enemy) > player.most_hated_enemy > # This mock fails with: Mock 'enemy' received unexpected message > 'instance_of?' with [] > end > end Please submit these at http://rubyforge.org/tracker/?group_id=797 > > > Ideas > Mocks being substituted for real objects - True integration tests for free ? > Alot of the specs we are writing separate responsibilities among tightly > coupled classes. We are testing the individuality, but if we wanted to test > the true integration of those classes we would probably have to create new > specs. How about, instead, creating mock objects from classes themselves > and having a rake spec:integrate task. This task would substitute the real > classes for the mocks, which brings me to: > > Mocks/stubs syntax > Let's say I have a Level object, and that is responsible for reading my map > into the game. I have an object in that map I want to test(err...spec). > Would something like this be feasible? > @level = Level.mock > or > @level = Level.mock(:null_object => true) > > Or maybe I have a class that has a GUI portion, and I want to stub that > function. > @level = Level.stub #Keeps all the Level functionality and lets you stub > things out > @level.should_receive(:draw).and_return(true) > > That way, if you do something like: > spec -integrate level_spec.rb > it could turn all mocks and stubs into real objects. I think this would add a bunch of unwanted complexity to the rspec code-base itself, as well as the specs that you'd have to write. You would probably have to, for example, have two different setups - one to set up the mock object and one to set up the real object. Feel free to add this one as a feature request at rubyforge as well, and we can continue the discussion in that forum. > > I'm really excited about the implications this has towards simplifying game > design, and I'm hoping that it works well enough to replace Test::Unit for > our 3d game framework, Shattered. > > Thanks, > -Mikkel Garcia > http://shatteredruby.com > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From brian.takita at gmail.com Fri Sep 22 03:53:04 2006 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 22 Sep 2006 00:53:04 -0700 Subject: [rspec-devel] Stub patch Message-ID: <1d7ddd110609220053o356f0f36r8793c38d3c67bd58@mail.gmail.com> Hello, I added a patch that adds stubbing support to rspec. http://rubyforge.org/tracker/index.php?func=detail&aid=5844&group_id=797&atid=3151 context "A consumer of a stub" do specify "should be able to stub objects" do obj = Object.new stub(obj).method(:foobar).with {:return_value} obj.foobar.should_equal :return_value end end It also resets the object to its prestubb state after the spec is finished. This would allow stubbing of class methods like Stubby or flexstub. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060922/29b6776c/attachment.html From dchelimsky at gmail.com Fri Sep 22 07:50:48 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 22 Sep 2006 06:50:48 -0500 Subject: [rspec-devel] Stub patch In-Reply-To: <1d7ddd110609220053o356f0f36r8793c38d3c67bd58@mail.gmail.com> References: <1d7ddd110609220053o356f0f36r8793c38d3c67bd58@mail.gmail.com> Message-ID: <57c63afe0609220450s66a25e36hc3a7a8f5b4180389@mail.gmail.com> On 9/22/06, Brian Takita wrote: > Hello, > > I added a patch that adds stubbing support to rspec. > > http://rubyforge.org/tracker/index.php?func=detail&aid=5844&group_id=797&atid=3151 > > context "A consumer of a stub" do > > specify "should be able to stub objects" do > obj = Object.new > stub(obj).method(:foobar).with {:return_value} > obj.foobar.should_equal :return_value > end > > end > > It also resets the object to its prestubb state after the spec is finished. > This would allow stubbing of class methods like Stubby or flexstub. This is beautiful. Thanks Brian. I started to commit it but there are a bunch of new warnings and coverage went down to by 3%. If you can eliminate the warnings and address the coverage issues and get "rake pre_commit" to run, feel free to commit this. Otherwise I'll look at it as time allows, but that won't likely be for a couple of days. Thanks again. This is great. David > > Brian > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Fri Sep 22 08:11:19 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 22 Sep 2006 07:11:19 -0500 Subject: [rspec-devel] Stub patch In-Reply-To: <57c63afe0609220450s66a25e36hc3a7a8f5b4180389@mail.gmail.com> References: <1d7ddd110609220053o356f0f36r8793c38d3c67bd58@mail.gmail.com> <57c63afe0609220450s66a25e36hc3a7a8f5b4180389@mail.gmail.com> Message-ID: <57c63afe0609220511i1afa831akdbe401498855ba0b@mail.gmail.com> On 9/22/06, David Chelimsky wrote: > On 9/22/06, Brian Takita wrote: > > Hello, > > > > I added a patch that adds stubbing support to rspec. > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=5844&group_id=797&atid=3151 > > > > context "A consumer of a stub" do > > > > specify "should be able to stub objects" do > > obj = Object.new > > stub(obj).method(:foobar).with {:return_value} > > obj.foobar.should_equal :return_value > > end > > > > end > > > > It also resets the object to its prestubb state after the spec is finished. > > This would allow stubbing of class methods like Stubby or flexstub. > > This is beautiful. Thanks Brian. I started to commit it but there are > a bunch of new warnings and coverage went down to by 3%. If you can > eliminate the warnings and address the coverage issues and get "rake > pre_commit" to run, feel free to commit this. Otherwise I'll look at > it as time allows, but that won't likely be for a couple of days. Well, I found the time. It wasn't much. I just don't know how to use patch properly, so for some reason all code in the new files appeared twice, hence the warnings and the coverage. I've committed this and you can all experience the love if you check out the trunk. Brian, before we do a release I want to get this documented. Do you want to take a crack at it? Release coming no later than 2 weeks (very busy until that time frame) but possibly sooner. Cheers, David > > Thanks again. This is great. > > David > > > > > Brian > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > From brian.takita at gmail.com Fri Sep 22 16:55:52 2006 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 22 Sep 2006 13:55:52 -0700 Subject: [rspec-devel] Stub patch In-Reply-To: <57c63afe0609220511i1afa831akdbe401498855ba0b@mail.gmail.com> References: <1d7ddd110609220053o356f0f36r8793c38d3c67bd58@mail.gmail.com> <57c63afe0609220450s66a25e36hc3a7a8f5b4180389@mail.gmail.com> <57c63afe0609220511i1afa831akdbe401498855ba0b@mail.gmail.com> Message-ID: <1d7ddd110609221355k24af4e13td2bc1f9ca1f726f3@mail.gmail.com> > > Brian, before we do a release I want to get this documented. Do you want > to take a crack at it? > Sure. On 9/22/06, David Chelimsky wrote: > > On 9/22/06, David Chelimsky wrote: > > On 9/22/06, Brian Takita wrote: > > > Hello, > > > > > > I added a patch that adds stubbing support to rspec. > > > > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=5844&group_id=797&atid=3151 > > > > > > context "A consumer of a stub" do > > > > > > specify "should be able to stub objects" do > > > obj = Object.new > > > stub(obj).method(:foobar).with {:return_value} > > > obj.foobar.should_equal :return_value > > > end > > > > > > end > > > > > > It also resets the object to its prestubb state after the spec is > finished. > > > This would allow stubbing of class methods like Stubby or flexstub. > > > > This is beautiful. Thanks Brian. I started to commit it but there are > > a bunch of new warnings and coverage went down to by 3%. If you can > > eliminate the warnings and address the coverage issues and get "rake > > pre_commit" to run, feel free to commit this. Otherwise I'll look at > > it as time allows, but that won't likely be for a couple of days. > > Well, I found the time. It wasn't much. I just don't know how to use > patch properly, so for some reason all code in the new files appeared > twice, hence the warnings and the coverage. > > I've committed this and you can all experience the love if you check > out the trunk. > > Brian, before we do a release I want to get this documented. Do you > want to take a crack at it? > > Release coming no later than 2 weeks (very busy until that time frame) > but possibly sooner. > > Cheers, > David > > > > > > > Thanks again. This is great. > > > > David > > > > > > > > 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/20060922/3c9f61e5/attachment.html From jake.howerton at gmail.com Fri Sep 22 17:57:00 2006 From: jake.howerton at gmail.com (Jake Howerton) Date: Fri, 22 Sep 2006 17:57:00 -0400 Subject: [rspec-devel] ARTS on RSpec on Rails Message-ID: <218a05e40609221457neb9b476kb78d2536f98282a6@mail.gmail.com> Hello Everyone.. Over the past day or so I hacked Kevin Clark's ARTS(http://glu.ttono.us/articles/2006/09/15/arts-0-5-released) RJS testing library into RSpec. You can now do things like specify "replace_html in 'mydiv'" do response.rjs.should :replace_html, 'mydiv' end And anything else you can do with ARTS(hopefully) ... I have not tested everything in it, and have only been testing it by creating specs for an existing application and running them through it, so if you need this please bang away on it and let me know if it works or doesnt. Also, the magic should_helper.rb in RSpec was making my head spin, so I danced around it in some spots. If this is really ugly I apologize, but for now it works. Attached are diff's for 0.6.3 plugin and trunk plugin... I also noticed there was a change with how things get loaded in 0.6.3 vs the way it was in 0.6.0 (init.rb)... how are things for the rails plugin loaded now and do I need to add anything to get the new lib/arts.rb file loaded? Also I check http://geekonomics.blogspot.com/2006/09/arts-on-rspec-on-rails.html for longer example/updates if I have any. Cheers Jake Howerton -------------- next part -------------- A non-text attachment was scrubbed... Name: arts_on_rspec_0_6_3.diff Type: application/octet-stream Size: 4224 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060922/8b42318d/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: arts_on_rspec_trunk.diff Type: application/octet-stream Size: 4224 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060922/8b42318d/attachment-0003.obj From dchelimsky at gmail.com Fri Sep 22 23:58:14 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 22 Sep 2006 22:58:14 -0500 Subject: [rspec-devel] ARTS on RSpec on Rails In-Reply-To: <218a05e40609221457neb9b476kb78d2536f98282a6@mail.gmail.com> References: <218a05e40609221457neb9b476kb78d2536f98282a6@mail.gmail.com> Message-ID: <57c63afe0609222058y52efe6fcp8cd13afdf5bf1333@mail.gmail.com> On 9/22/06, Jake Howerton wrote: > Hello Everyone.. > > Over the past day or so I hacked Kevin Clark's > ARTS(http://glu.ttono.us/articles/2006/09/15/arts-0-5-released) RJS > testing library into RSpec. > > You can now do things like > > specify "replace_html in 'mydiv'" do > response.rjs.should :replace_html, 'mydiv' > end > > And anything else you can do with ARTS(hopefully) ... I have not > tested everything in it, and have only been testing it by creating > specs for an existing application and running them through it, so if > you need this please bang away on it and let me know if it works or > doesnt. > > Also, the magic should_helper.rb in RSpec was making my head spin, so > I danced around it in some spots. If this is really ugly I apologize, > but for now it works. > > Attached are diff's for 0.6.3 plugin and trunk plugin... I also > noticed there was a change with how things get loaded in 0.6.3 vs the > way it was in 0.6.0 (init.rb)... how are things for the rails plugin > loaded now and do I need to add anything to get the new lib/arts.rb > file loaded? > > Also I check http://geekonomics.blogspot.com/2006/09/arts-on-rspec-on-rails.html > for longer example/updates if I have any. Hey Jake - why don't you go ahead and submit this at rubyforge: http://rubyforge.org/tracker/?atid=3151&group_id=797&func=browse Looking forward to checking this out. Thanks, David > > Cheers > > Jake Howerton > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From jake.howerton at gmail.com Sun Sep 24 03:02:19 2006 From: jake.howerton at gmail.com (Jake Howerton) Date: Sun, 24 Sep 2006 03:02:19 -0400 Subject: [rspec-devel] ARTS on RSpec on Rails In-Reply-To: <57c63afe0609222058y52efe6fcp8cd13afdf5bf1333@mail.gmail.com> References: <218a05e40609221457neb9b476kb78d2536f98282a6@mail.gmail.com> <57c63afe0609222058y52efe6fcp8cd13afdf5bf1333@mail.gmail.com> Message-ID: <218a05e40609240002m7925bf68m9371fe7015467851@mail.gmail.com> Hi David, On 9/22/06, David Chelimsky wrote: > > Hey Jake - why don't you go ahead and submit this at rubyforge: > I have submitted a new patch at rubyforge http://rubyforge.org/tracker/index.php?func=detail&aid=5873&group_id=797&atid=3151 There was one change (adding require 'arts' to spec_helper.rb)... RE: your comment on my blog. I played around with the style you suggested response.rjs.should_replace_html 'mydiv'; but that was when my head started to spin in should_helper.rb.... :) If you are willing to poke around the way that I did it and maybe the original ARTS code also... the main trouble spot I was bumping into is that ARTS doesnt have a method for every single RJS effect.... so for something like should_show, there is no show method to delegate to. Jake Howerton From dchelimsky at gmail.com Sun Sep 24 10:05:16 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 24 Sep 2006 09:05:16 -0500 Subject: [rspec-devel] ARTS on RSpec on Rails In-Reply-To: <218a05e40609240002m7925bf68m9371fe7015467851@mail.gmail.com> References: <218a05e40609221457neb9b476kb78d2536f98282a6@mail.gmail.com> <57c63afe0609222058y52efe6fcp8cd13afdf5bf1333@mail.gmail.com> <218a05e40609240002m7925bf68m9371fe7015467851@mail.gmail.com> Message-ID: <57c63afe0609240705l7c6d830p852fdade58be6978@mail.gmail.com> On 9/24/06, Jake Howerton wrote: > Hi David, > > > On 9/22/06, David Chelimsky wrote: > > > > Hey Jake - why don't you go ahead and submit this at rubyforge: > > > > I have submitted a new patch at rubyforge > > http://rubyforge.org/tracker/index.php?func=detail&aid=5873&group_id=797&atid=3151 Great. Thanks. > > There was one change (adding require 'arts' to spec_helper.rb)... > > RE: your comment on my blog. > > I played around with the style you suggested > response.rjs.should_replace_html 'mydiv'; but that was when my head > started to spin in should_helper.rb.... :) > > If you are willing to poke around the way that I did it and maybe the > original ARTS code also... the main trouble spot I was bumping into is > that ARTS doesnt have a method for every single RJS effect.... so > for something like should_show, there is no show method to delegate > to. I am most willing. I looked at it briefly and believe that I see the path. I may not have much time this week, but I most certainly will the following week. I really want to get this support in, but I really don't want to add it without it feeling more like rspec. Thanks again Jake. David > > Jake Howerton > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Sep 25 00:50:12 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 25 Sep 2006 00:50:12 -0400 Subject: [rspec-devel] ARTS on RSpec on Rails In-Reply-To: <57c63afe0609240705l7c6d830p852fdade58be6978@mail.gmail.com> References: <218a05e40609221457neb9b476kb78d2536f98282a6@mail.gmail.com> <57c63afe0609222058y52efe6fcp8cd13afdf5bf1333@mail.gmail.com> <218a05e40609240002m7925bf68m9371fe7015467851@mail.gmail.com> <57c63afe0609240705l7c6d830p852fdade58be6978@mail.gmail.com> Message-ID: <57c63afe0609242150j792eced7ke8297e2157a46417@mail.gmail.com> On 9/24/06, David Chelimsky wrote: > On 9/24/06, Jake Howerton wrote: > > Hi David, > > > > > > On 9/22/06, David Chelimsky wrote: > > > > > > Hey Jake - why don't you go ahead and submit this at rubyforge: > > > > > > > I have submitted a new patch at rubyforge > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=5873&group_id=797&atid=3151 I've been playing around w/ this a bit and came up w/ syntax that works a little better for all of the different rjs expectations: response.should_have_rjs :replace_html, 'replaceable_div', "This goes inside the div" response.should_have_rjs :sortable, 'sortable_div' etc I've got this basically working and will try to commit something tomorrow night. Related to this, the upcoming release will support the following as well: response.should_have_tag :div, :context => "this goes in the div" This gives response.should_have_rjs and response.should_have_tag a nice symmetry. Cheers, David From jake.howerton at gmail.com Mon Sep 25 11:15:54 2006 From: jake.howerton at gmail.com (Jake Howerton) Date: Mon, 25 Sep 2006 11:15:54 -0400 Subject: [rspec-devel] ARTS on RSpec on Rails In-Reply-To: <57c63afe0609242150j792eced7ke8297e2157a46417@mail.gmail.com> References: <218a05e40609221457neb9b476kb78d2536f98282a6@mail.gmail.com> <57c63afe0609222058y52efe6fcp8cd13afdf5bf1333@mail.gmail.com> <218a05e40609240002m7925bf68m9371fe7015467851@mail.gmail.com> <57c63afe0609240705l7c6d830p852fdade58be6978@mail.gmail.com> <57c63afe0609242150j792eced7ke8297e2157a46417@mail.gmail.com> Message-ID: <218a05e40609250815v96b1926i2ebf3075c66757e0@mail.gmail.com> Hey David, On 9/25/06, David Chelimsky wrote: > I've been playing around w/ this a bit and came up w/ syntax that > works a little better for all of the different rjs expectations: > > response.should_have_rjs :replace_html, 'replaceable_div', "This goes > inside the div" > response.should_have_rjs :sortable, 'sortable_div' > etc Yes I was playing around with it for a bit this way as well. One thing that is good about doing it this way is that it is more inline with the original ARTS API. However when I was playing with it I just had it written as response.should_rjs :replace_html, 'replaceable_div', which does not read very well.... the 'have' in there helps out alot. To me the ultimate goal would be response.rjs.should_replace_html 'replaceable_div' ..... read aloud as "RJS should replace html in 'replaceable_div'" It doesnt work so well for sortable though now does it. :) Let me know what you think... either way I am very happy to have this in RSpec and I suspect there are others who will be as well. Jake P.S. with your way it can be read nicely as well... "Response should have RJS (call to) replace_html for 'replaceable_div' From aslak.hellesoy at gmail.com Tue Sep 26 04:36:34 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 26 Sep 2006 10:36:34 +0200 Subject: [rspec-devel] Underscored predicates Message-ID: <8d961d900609260136k3fbbc68fqe612e056d6c7d530@mail.gmail.com> Don't work.... I just added http://rubyforge.org/tracker/index.php?func=detail&aid=5909&group_id=797&atid=3152 But somewhere in the back of my head I have a recollection of someone having fixed this with a patch or something. Did it get lost in the wool? Aslak From aslak.hellesoy at gmail.com Tue Sep 26 18:17:39 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 27 Sep 2006 00:17:39 +0200 Subject: [rspec-devel] Keeping things tidy Message-ID: <8d961d900609261517x514dd5fr151c6d5d133b64bb@mail.gmail.com> Hi folks, It's great to see the ARTS stuff go in. There was quite a bit of duplication in the code, and I have refactored away the biggest dupes. I have a couple of comments about our tidiness in general... 1) Every time we get apply a patch from someone, make sure they get the kudos they deserve on the team page (doc/src/core_team.page) 2) RSpec on Rails now has both a 'spec' and a 'specs' folder. What's with that? Even worse - the 'spec' foder specs weren't even being run as part of RSpec on Rails' pre_commit. I fixed that in the Rakefile, but there are still two folders. Intentional or glitch? 3) Shouldn't http://rubyforge.org/tracker/index.php?func=detail&aid=5873&group_id=797&atid=3151 be closed? Any objections if I do a rake release tonight? It's been a while and there is lots of new stuff... Cheers, Aslak From aslak.hellesoy at gmail.com Tue Sep 26 19:39:37 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 27 Sep 2006 01:39:37 +0200 Subject: [rspec-devel] Keeping things tidy In-Reply-To: <8d961d900609261517x514dd5fr151c6d5d133b64bb@mail.gmail.com> References: <8d961d900609261517x514dd5fr151c6d5d133b64bb@mail.gmail.com> Message-ID: <8d961d900609261639u5083871cn610032dbfb8b1c32@mail.gmail.com> On 9/27/06, aslak hellesoy wrote: > Hi folks, > > It's great to see the ARTS stuff go in. There was quite a bit of > duplication in the code, and I have refactored away the biggest dupes. > I have a couple of comments about our tidiness in general... > > 1) Every time we get apply a patch from someone, make sure they get > the kudos they deserve on the team page (doc/src/core_team.page) > > 2) RSpec on Rails now has both a 'spec' and a 'specs' folder. What's > with that? Even worse - the 'spec' foder specs weren't even being run > as part of RSpec on Rails' pre_commit. I fixed that in the Rakefile, > but there are still two folders. Intentional or glitch? > My bad. I overlooked the first line in bootstrap_rspec.rake, which runs :spec, which is handled by the plugin. I have reverted my "fix". > 3) Shouldn't http://rubyforge.org/tracker/index.php?func=detail&aid=5873&group_id=797&atid=3151 > be closed? > Let's wait till the doco is in. There is quite a bit to document. Maybe it's time to split up the RSpec on Rails doco to several pages? > Any objections if I do a rake release tonight? It's been a while and > there is lots of new stuff... > I'll hold for the missing doco of the new features. And sorry if I sounded snotty in the last mail. It wasn't intentional :-) All the new stuff is good stuff. Aslak > Cheers, > Aslak > From dchelimsky at gmail.com Tue Sep 26 23:06:39 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 26 Sep 2006 23:06:39 -0400 Subject: [rspec-devel] rspec stubbing Message-ID: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> Hi everyone, Brian contributed a patch with some kick-ass stubbing capability last week. I've been playing w/ the syntax a bit, with an eye to making it more rspec like: Story.stub!(:new).with(value) I was able to get this to work, but it wasn't exactly what I think we need from rspec. I think what we really need is class level mocking - just like the existing mocking framework: Story.should_receive(:new).and_return(value) Person.should_receive(:find).with("1").and_return(value) etc. Right now there are a ton of other features that we're waiting to release until this gets settled. What I'd like to do is to yank the stubbing from the trunk so we can release and then add it to a branch in which we can play w/ syntax and functionality, moving towards including it an 0.6.5 release. That work for everyone? David From dastels at daveastels.com Wed Sep 27 01:40:55 2006 From: dastels at daveastels.com (Dave Astels) Date: Wed, 27 Sep 2006 02:40:55 -0300 Subject: [rspec-devel] rspec stubbing In-Reply-To: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> References: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> Message-ID: <0DD3EA25-25D6-4933-86E9-86FEAFC98697@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27-Sep-06, at 12:06 AM, David Chelimsky wrote: > Right now there are a ton of other features that we're waiting to > release until this gets settled. What I'd like to do is to yank the > stubbing from the trunk so we can release and then add it to a branch > in which we can play w/ syntax and functionality, moving towards > including it an 0.6.5 release. > > That work for everyone? +1 Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFGg7oauez/L4x7g4RAmM8AJ45zVFXjr9sL6ucHs+7CYQC4JezDwCeMPoN Zyaepocs7ossLcBBaPupDBY= =/kmK -----END PGP SIGNATURE----- From aslak.hellesoy at gmail.com Wed Sep 27 09:35:19 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 27 Sep 2006 15:35:19 +0200 Subject: [rspec-devel] rspec stubbing In-Reply-To: <0DD3EA25-25D6-4933-86E9-86FEAFC98697@daveastels.com> References: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> <0DD3EA25-25D6-4933-86E9-86FEAFC98697@daveastels.com> Message-ID: <8d961d900609270635s21a0d6c4hd28c82dd2a9ac43c@mail.gmail.com> On 9/27/06, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 27-Sep-06, at 12:06 AM, David Chelimsky wrote: > > > Right now there are a ton of other features that we're waiting to > > release until this gets settled. What I'd like to do is to yank the > > stubbing from the trunk so we can release and then add it to a branch > > in which we can play w/ syntax and functionality, moving towards > > including it an 0.6.5 release. > > > > That work for everyone? > > +1 +1 > > Dave > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFFGg7oauez/L4x7g4RAmM8AJ45zVFXjr9sL6ucHs+7CYQC4JezDwCeMPoN > Zyaepocs7ossLcBBaPupDBY= > =/kmK > -----END PGP SIGNATURE----- > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed Sep 27 12:49:45 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 27 Sep 2006 12:49:45 -0400 Subject: [rspec-devel] rspec stubbing In-Reply-To: <8d961d900609270635s21a0d6c4hd28c82dd2a9ac43c@mail.gmail.com> References: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> <0DD3EA25-25D6-4933-86E9-86FEAFC98697@daveastels.com> <8d961d900609270635s21a0d6c4hd28c82dd2a9ac43c@mail.gmail.com> Message-ID: <57c63afe0609270949n10a70bd9i1689a735096e2632@mail.gmail.com> On 9/27/06, aslak hellesoy wrote: > On 9/27/06, Dave Astels wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > On 27-Sep-06, at 12:06 AM, David Chelimsky wrote: > > > > > Right now there are a ton of other features that we're waiting to > > > release until this gets settled. What I'd like to do is to yank the > > > stubbing from the trunk so we can release and then add it to a branch > > > in which we can play w/ syntax and functionality, moving towards > > > including it an 0.6.5 release. > > > > > > That work for everyone? > > > > +1 > > +1 Cool. I won't have time to do that today. Aslak, if you feel so inclined, feel free to create a 'stubs' branch from the current trunk and then yank the stub material from the trunk and do a release. If not, I'll be able to get to it in the next few days. From dastels at daveastels.com Wed Sep 27 20:22:15 2006 From: dastels at daveastels.com (Dave Astels) Date: Wed, 27 Sep 2006 21:22:15 -0300 Subject: [rspec-devel] rspec stubbing In-Reply-To: <57c63afe0609270949n10a70bd9i1689a735096e2632@mail.gmail.com> References: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> <0DD3EA25-25D6-4933-86E9-86FEAFC98697@daveastels.com> <8d961d900609270635s21a0d6c4hd28c82dd2a9ac43c@mail.gmail.com> <57c63afe0609270949n10a70bd9i1689a735096e2632@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We need to integrate something like this into RSpec: http://zentest.rubyforge.org/classes/Test/Rails/ViewTestCase.html Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFGxW3auez/L4x7g4RAl0aAJ9LbtLEo2I4l7RQStB3RMQ7M/LQLgCfQrCA lv6NWZrAbmBfrn70R8Tz+O0= =ogu0 -----END PGP SIGNATURE----- From dchelimsky at gmail.com Wed Sep 27 23:18:07 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 27 Sep 2006 23:18:07 -0400 Subject: [rspec-devel] view specs (was 'rspec stubbing') Message-ID: <57c63afe0609272018h4ddba688h5bb0f354f7be1637@mail.gmail.com> On 9/27/06, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We need to integrate something like this into RSpec: > > http://zentest.rubyforge.org/classes/Test/Rails/ViewTestCase.html That's more or less where we're already headed w/ view specs. Right now (in the trunk), when you do this: script/generate rspec_controller Person list new create edit update You get, in addition to the appropriate production files, specs for: spec/controllers/person_controller_spec.rb spec/views/person_list_view_spec.rb spec/views/person_list_new_spec.rb spec/views/person_list_create_spec.rb spec/views/person_list_edit_spec.rb spec/views/person_list_update_spec.rb You can then use these expectations response.should_have_tag response.should_have_rjs to spec anything that goes in a view. We have some work to do on this, like some more useful expectations. But we're on the right path i believe. Cheers, David From aslak.hellesoy at gmail.com Thu Sep 28 03:56:54 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 28 Sep 2006 09:56:54 +0200 Subject: [rspec-devel] view specs (was 'rspec stubbing') In-Reply-To: <57c63afe0609272018h4ddba688h5bb0f354f7be1637@mail.gmail.com> References: <57c63afe0609272018h4ddba688h5bb0f354f7be1637@mail.gmail.com> Message-ID: <8d961d900609280056i182458a1nd80e29614029a61f@mail.gmail.com> On 9/28/06, David Chelimsky wrote: > On 9/27/06, Dave Astels wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > We need to integrate something like this into RSpec: > > > > http://zentest.rubyforge.org/classes/Test/Rails/ViewTestCase.html > This allows a view to be verified without going through a controller. They're just setting variables in the same way a controller would and then saying render. > That's more or less where we're already headed w/ view specs. Is it really? I thought we had to go through a controller in order to verify a view. > Right > now (in the trunk), when you do this: > > script/generate rspec_controller Person list new create edit update > > You get, in addition to the appropriate production files, specs for: > > spec/controllers/person_controller_spec.rb > spec/views/person_list_view_spec.rb > spec/views/person_list_new_spec.rb > spec/views/person_list_create_spec.rb > spec/views/person_list_edit_spec.rb > spec/views/person_list_update_spec.rb > > You can then use these expectations > > response.should_have_tag > response.should_have_rjs > > to spec anything that goes in a view. > > We have some work to do on this, like some more useful expectations. > But we're on the right path i believe. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Thu Sep 28 04:11:47 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 28 Sep 2006 01:11:47 -0700 Subject: [rspec-devel] New Stub API Implemented Message-ID: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> Hello, I checked in the latest stub framework with the agreed upon API. object.stub!(:method).with {:value} I still need to write the documentation however. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060928/dac43947/attachment.html From brian.takita at gmail.com Thu Sep 28 04:21:32 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 28 Sep 2006 01:21:32 -0700 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> Message-ID: <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> Whoops, I didn't read the rspec stubbing thread. I did commit to the stub branch though. At least my changes also include some refactorings that clean up the implementation. On 9/28/06, Brian Takita wrote: > > Hello, > > I checked in the latest stub framework with the agreed upon API. > object.stub!(:method).with {:value} > > I still need to write the documentation however. > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060928/b3f00c3f/attachment.html From lachiec at gmail.com Thu Sep 28 05:43:00 2006 From: lachiec at gmail.com (Lachie) Date: Thu, 28 Sep 2006 09:43:00 +0000 Subject: [rspec-devel] rspec stubbing In-Reply-To: References: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> <0DD3EA25-25D6-4933-86E9-86FEAFC98697@daveastels.com> <8d961d900609270635s21a0d6c4hd28c82dd2a9ac43c@mail.gmail.com> <57c63afe0609270949n10a70bd9i1689a735096e2632@mail.gmail.com> Message-ID: <2c5e719e0609280243mdd85c2dk9928b22580ced44c@mail.gmail.com> On 9/28/06, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We need to integrate something like this into RSpec: > > http://zentest.rubyforge.org/classes/Test/Rails/ViewTestCase.html +1 That's what I've been mixing in to do my view testing > > Dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFFGxW3auez/L4x7g4RAl0aAJ9LbtLEo2I4l7RQStB3RMQ7M/LQLgCfQrCA > lv6NWZrAbmBfrn70R8Tz+O0= > =ogu0 > -----END PGP SIGNATURE----- > _______________________________________________ > 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 luke at agileevolved.com Thu Sep 28 05:52:42 2006 From: luke at agileevolved.com (Luke Redpath) Date: Thu, 28 Sep 2006 10:52:42 +0100 Subject: [rspec-devel] rspec stubbing In-Reply-To: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> References: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> Message-ID: +1 for waiting and branching. -1 for the partial mocking - I much prefer the stubbing functionality. I love using Stubba but thats currently broken with the latest RSpec release - I would be one very happy man if RSpec rolled in its own Stubba-like functionality. I'd have no objections to both though! As well as being able to stub a method to return a value, it would be nice to be able to stub a method with a routine as well: Foo.stub!(:bar) do # do something here! end Cheers Luke On 27 Sep 2006, at 04:06, David Chelimsky wrote: > Hi everyone, > > Brian contributed a patch with some kick-ass stubbing capability last > week. I've been playing w/ the syntax a bit, with an eye to making it > more rspec like: > > Story.stub!(:new).with(value) > > I was able to get this to work, but it wasn't exactly what I think we > need from rspec. I think what we really need is class level mocking - > just like the existing mocking framework: > > Story.should_receive(:new).and_return(value) > Person.should_receive(:find).with("1").and_return(value) > etc. > > Right now there are a ton of other features that we're waiting to > release until this gets settled. What I'd like to do is to yank the > stubbing from the trunk so we can release and then add it to a branch > in which we can play w/ syntax and functionality, moving towards > including it an 0.6.5 release. > > That work for everyone? > > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Thu Sep 28 07:46:06 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 28 Sep 2006 07:46:06 -0400 Subject: [rspec-devel] view specs (was 'rspec stubbing') In-Reply-To: <8d961d900609280056i182458a1nd80e29614029a61f@mail.gmail.com> References: <57c63afe0609272018h4ddba688h5bb0f354f7be1637@mail.gmail.com> <8d961d900609280056i182458a1nd80e29614029a61f@mail.gmail.com> Message-ID: <57c63afe0609280446q232938d4h69f21d79a3341df2@mail.gmail.com> On 9/28/06, aslak hellesoy wrote: > On 9/28/06, David Chelimsky wrote: > > On 9/27/06, Dave Astels wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > We need to integrate something like this into RSpec: > > > > > > http://zentest.rubyforge.org/classes/Test/Rails/ViewTestCase.html > > > > This allows a view to be verified without going through a controller. > They're just setting variables in the same way a controller would and > then saying render. > > > That's more or less where we're already headed w/ view specs. > > Is it really? I thought we had to go through a controller in order to > verify a view. Man, you're impatient. Sometimes, when you're on a road, you start at the beginning of the road. Separating out the view specs is the first step. The next step is devise some mojo to get at the views. I hadn't considered helper specs or partials. That would be even cooler. From dchelimsky at gmail.com Thu Sep 28 07:59:20 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 28 Sep 2006 07:59:20 -0400 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> Message-ID: <57c63afe0609280459o12d81d44h505aacc78b590427@mail.gmail.com> On 9/28/06, Brian Takita wrote: > Whoops, I didn't read the rspec stubbing thread. I did commit to the stub > branch though. > At least my changes also include some refactorings that clean up the > implementation. I think we should keep the stub facility in addition to the class level mocking I'm interested in. For me, stubbing is useful for that 'other' class the class under spec is using and won't run without, but not for dealing w/ values that are important to the spec itself. For example, if an ATM won't respond to messages you send it without a Display or a Dispenser, I'd stub out the Dispay for the specs that deal w/ how the ATM interacts w/ the Dispenser, but I'd MOCK the Dispenser itself. And vice versa. That said, I already use the existing mock framework for stubs and name them accordingly. mock_dispenser = mock("dispenser") mock_dispenser.should_receive(:etc, etc, etc) stub_display = mock("display") mock_dispenser.should_receive(:etc, etc, etc) Being able to do this instead: mock_dispenser = mock("dispenser") mock_dispenser.should_receive(:etc, etc, etc) stub_display = Object.new mock_dispenser.stub!(:etc, etc, etc) ... makes the spec much more clear. Brian, if you want to take a look at the class level mocking please feel free.It strikes me that there's probably already some duplication between the mock and stub implementations, so perhaps a single framework w/ both facilities is the way to go. Just let me know if you plan to, in which case I'll coordinate w/ you before I take any stabs at it. Cheers, David From dchelimsky at gmail.com Thu Sep 28 08:02:29 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 28 Sep 2006 08:02:29 -0400 Subject: [rspec-devel] rspec stubbing In-Reply-To: References: <57c63afe0609262006j590d34a0t72f5dc6370aa8c3@mail.gmail.com> Message-ID: <57c63afe0609280502v78ebc790le201ca23e1b6c2c2@mail.gmail.com> On 9/28/06, Luke Redpath wrote: > +1 for waiting and branching. > > -1 for the partial mocking - I much prefer the stubbing > functionality. I love using Stubba but thats currently broken with > the latest RSpec release - I would be one very happy man if RSpec > rolled in its own Stubba-like functionality. I'd have no objections > to both though! > > As well as being able to stub a method to return a value, it would be > nice to be able to stub a method with a routine as well: > > Foo.stub!(:bar) do > # do something here! > end I haven't looked at Brian's re-implementation yet (in branches/stubs), but the first implementation did this already. Look for this as part of the next-next release (0.6.5). Just some kinks to work out. Cheers, David > > Cheers > Luke > > On 27 Sep 2006, at 04:06, David Chelimsky wrote: > > > Hi everyone, > > > > Brian contributed a patch with some kick-ass stubbing capability last > > week. I've been playing w/ the syntax a bit, with an eye to making it > > more rspec like: > > > > Story.stub!(:new).with(value) > > > > I was able to get this to work, but it wasn't exactly what I think we > > need from rspec. I think what we really need is class level mocking - > > just like the existing mocking framework: > > > > Story.should_receive(:new).and_return(value) > > Person.should_receive(:find).with("1").and_return(value) > > etc. > > > > Right now there are a ton of other features that we're waiting to > > release until this gets settled. What I'd like to do is to yank the > > stubbing from the trunk so we can release and then add it to a branch > > in which we can play w/ syntax and functionality, moving towards > > including it an 0.6.5 release. > > > > That work for everyone? > > > > David > > _______________________________________________ > > 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 Thu Sep 28 09:05:38 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 28 Sep 2006 15:05:38 +0200 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> Message-ID: <8d961d900609280605o12d707a4q9296dbebcf84f061@mail.gmail.com> When I reverted the stubbing logic on trunk (after creating the stubs branch) I discovered that there were a bunch of disabled tests. I think it was in the specification test. (def xtest_) Can you make sure that gets fixed on the branch before we merge it back to the trunk? Cheers, Aslak On 9/28/06, Brian Takita wrote: > Whoops, I didn't read the rspec stubbing thread. I did commit to the stub > branch though. > At least my changes also include some refactorings that clean up the > implementation. > > > On 9/28/06, Brian Takita wrote: > > Hello, > > > > I checked in the latest stub framework with the agreed upon API. > > object.stub!(:method).with {:value} > > > > I still need to write the documentation however. > > > > Brian > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From brian.takita at gmail.com Thu Sep 28 23:53:56 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 28 Sep 2006 20:53:56 -0700 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <57c63afe0609280459o12d81d44h505aacc78b590427@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> <57c63afe0609280459o12d81d44h505aacc78b590427@mail.gmail.com> Message-ID: <1d7ddd110609282053u2f905ec4uc288de10c99d7da5@mail.gmail.com> > > Brian, if you want to take a look at the class level mocking please > feel free.It strikes me that there's probably already some duplication > between the mock and stub implementations, so perhaps a single > framework w/ both facilities is the way to go. > Yes, I think they can be integrated, particularly with the partial mocking objects. I'm thinking about adding the should_receive method to Object. On 9/28/06, David Chelimsky wrote: > > On 9/28/06, Brian Takita wrote: > > Whoops, I didn't read the rspec stubbing thread. I did commit to the > stub > > branch though. > > At least my changes also include some refactorings that clean up the > > implementation. > > I think we should keep the stub facility in addition to the class > level mocking I'm interested in. > For me, stubbing is useful for that 'other' class the class under spec > is using and won't run without, but not for dealing w/ values that are > important to the spec itself. For example, if an ATM won't respond to > messages you send it without a Display or a Dispenser, I'd stub out > the Dispay for the specs that deal w/ how the ATM interacts w/ the > Dispenser, but I'd MOCK the Dispenser itself. And vice versa. > > That said, I already use the existing mock framework for stubs and > name them accordingly. > > mock_dispenser = mock("dispenser") > mock_dispenser.should_receive(:etc, etc, etc) > stub_display = mock("display") > mock_dispenser.should_receive(:etc, etc, etc) > > Being able to do this instead: > > mock_dispenser = mock("dispenser") > mock_dispenser.should_receive(:etc, etc, etc) > stub_display = Object.new > mock_dispenser.stub!(:etc, etc, etc) > > ... makes the spec much more clear. > > Brian, if you want to take a look at the class level mocking please > feel free.It strikes me that there's probably already some duplication > between the mock and stub implementations, so perhaps a single > framework w/ both facilities is the way to go. Just let me know if you > plan to, in which case I'll coordinate w/ you before I take any stabs > at it. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060928/9ac21326/attachment.html From brian.takita at gmail.com Fri Sep 29 02:05:17 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 28 Sep 2006 23:05:17 -0700 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <8d961d900609280605o12d707a4q9296dbebcf84f061@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> <8d961d900609280605o12d707a4q9296dbebcf84f061@mail.gmail.com> Message-ID: <1d7ddd110609282305j5bae1082p96769ed3100f00a7@mail.gmail.com> I fixed it. Sorry about that. On 9/28/06, aslak hellesoy wrote: > > When I reverted the stubbing logic on trunk (after creating the stubs > branch) I discovered that there were a bunch of disabled tests. I > think it was in the specification test. (def xtest_) > > Can you make sure that gets fixed on the branch before we merge it > back to the trunk? > > Cheers, > Aslak > > On 9/28/06, Brian Takita wrote: > > Whoops, I didn't read the rspec stubbing thread. I did commit to the > stub > > branch though. > > At least my changes also include some refactorings that clean up the > > implementation. > > > > > > On 9/28/06, Brian Takita wrote: > > > Hello, > > > > > > I checked in the latest stub framework with the agreed upon API. > > > object.stub!(:method).with {:value} > > > > > > I still need to write the documentation however. > > > > > > 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/20060928/112c4810/attachment.html From jamesmead44 at gmail.com Fri Sep 29 05:52:57 2006 From: jamesmead44 at gmail.com (James Mead) Date: Fri, 29 Sep 2006 10:52:57 +0100 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <1d7ddd110609282305j5bae1082p96769ed3100f00a7@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> <8d961d900609280605o12d707a4q9296dbebcf84f061@mail.gmail.com> <1d7ddd110609282305j5bae1082p96769ed3100f00a7@mail.gmail.com> Message-ID: <1db558f00609290252j4f4e24c0lb8b02818b49cc102@mail.gmail.com> I've now had requests from several people for a way of using Mocha (& Stubba) without a dependency on Test::Unit so it can interoperate with other testing frameworks. Given that this is the reason the current versions of Mocha and RSpec don't play together, I thought you might be interested to know I'm in the middle of making the necessary (relatively minor) changes to make this possible. -- James. http://blog.floehopper.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060929/61e9e613/attachment.html From dchelimsky at gmail.com Fri Sep 29 08:06:07 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 29 Sep 2006 08:06:07 -0400 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <1db558f00609290252j4f4e24c0lb8b02818b49cc102@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> <8d961d900609280605o12d707a4q9296dbebcf84f061@mail.gmail.com> <1d7ddd110609282305j5bae1082p96769ed3100f00a7@mail.gmail.com> <1db558f00609290252j4f4e24c0lb8b02818b49cc102@mail.gmail.com> Message-ID: <57c63afe0609290506o37d2ae6cu98f6aa609f0b70bd@mail.gmail.com> On 9/29/06, James Mead wrote: > I've now had requests from several people for a way of using Mocha (& > Stubba) without a dependency on Test::Unit so it can interoperate with other > testing frameworks. Given that this is the reason the current versions of > Mocha and RSpec don't play together, I thought you might be interested to > know I'm in the middle of making the necessary (relatively minor) changes to > make this possible. James, That's awesome news. Thanks. Our plan here is to continue to have an integrated stubbing/mocking framework that is invoked by default, but allow other frameworks to be plugged in. To make that work most effectively, rspec needs some hook into Mocha/Stubba (and vice versa) so that the verification of mocks and resetting of stubs is seamless. Here's my current thinking: rspec would support a runtime configuration bit that allows users to choose a mock framework. Something like this: Spec::Mock.plugin = 'mocha' In each specification, RSpec includes a module named Spec::Mock::Plugin (or something like that) provided by mocha. This would provide spec writers access to mocha's API. The plugin would have to support two methods for rspec: one to assign a mock registry and one to verify a mock. Something like this: module Spec module Mock module Plugin attr_writer :mock_registry def verify mock #do whatever mocha does to verify the mock #raise an exception if verification fails end include XXX #module w/ mock creation methods, etc end end end It would then be mocha's job to call "mock_registry.register mock" as each mock is created and rspec's job to call verify(mock) at the end of each specification. Is this too complex? The thing I like about it is that rspec can make a few changes and any framework can offer itself up as a plugin w/ little effort. Thoughts? David From brian.takita at gmail.com Fri Sep 29 22:52:31 2006 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 29 Sep 2006 19:52:31 -0700 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <57c63afe0609290506o37d2ae6cu98f6aa609f0b70bd@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> <8d961d900609280605o12d707a4q9296dbebcf84f061@mail.gmail.com> <1d7ddd110609282305j5bae1082p96769ed3100f00a7@mail.gmail.com> <1db558f00609290252j4f4e24c0lb8b02818b49cc102@mail.gmail.com> <57c63afe0609290506o37d2ae6cu98f6aa609f0b70bd@mail.gmail.com> Message-ID: <1d7ddd110609291952g5f0900bdobbe349e39eb8dfd3@mail.gmail.com> What about having listeners on setup and teardown? For example, a plugin of any nature can register on the setup and teardown events for each spec. On 9/29/06, David Chelimsky wrote: > > On 9/29/06, James Mead wrote: > > I've now had requests from several people for a way of using Mocha (& > > Stubba) without a dependency on Test::Unit so it can interoperate with > other > > testing frameworks. Given that this is the reason the current versions > of > > Mocha and RSpec don't play together, I thought you might be interested > to > > know I'm in the middle of making the necessary (relatively minor) > changes to > > make this possible. > > James, > > That's awesome news. Thanks. > > Our plan here is to continue to have an integrated stubbing/mocking > framework that is invoked by default, but allow other frameworks to be > plugged in. To make that work most effectively, rspec needs some hook > into Mocha/Stubba (and vice versa) so that the verification of mocks > and resetting of stubs is seamless. Here's my current thinking: > > rspec would support a runtime configuration bit that allows users to > choose a mock framework. Something like this: > > Spec::Mock.plugin = 'mocha' > > In each specification, RSpec includes a module named > Spec::Mock::Plugin (or something like that) provided by mocha. This > would provide spec writers access to mocha's API. > > The plugin would have to support two methods for rspec: one to assign > a mock registry and one to verify a mock. Something like this: > > module Spec > module Mock > module Plugin > attr_writer :mock_registry > def verify mock > #do whatever mocha does to verify the mock > #raise an exception if verification fails > end > include XXX #module w/ mock creation methods, etc > end > end > end > > It would then be mocha's job to call "mock_registry.register mock" as > each mock is created and rspec's job to call verify(mock) at the end > of each specification. > > Is this too complex? The thing I like about it is that rspec can make > a few changes and any framework can offer itself up as a plugin w/ > little effort. > > Thoughts? > > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060929/8fbd62e0/attachment-0001.html From brian.takita at gmail.com Sat Sep 30 02:19:40 2006 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 29 Sep 2006 23:19:40 -0700 Subject: [rspec-devel] Issues with ParseTree Message-ID: <1d7ddd110609292319l4641e56dkb27c4d8e13a25172@mail.gmail.com> Has anybody been having issues with ParseTree? First, I couldnt even get the library to parse due to an "error: extra tokens at end of #endif directive" error. I filed a bug report: http://rubyforge.org/tracker/index.php?func=detail&aid=5970&group_id=439&atid=1778 and a hack that fixes the issue for me: http://rubyforge.org/tracker/index.php?func=detail&aid=5971&group_id=439&atid=1780 So now I can load ParseTree but now the SexpTransformerTests are failing. Does anybody know what's going on? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060929/10e6f908/attachment.html From dchelimsky at gmail.com Sat Sep 30 08:51:17 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 30 Sep 2006 08:51:17 -0400 Subject: [rspec-devel] New Stub API Implemented In-Reply-To: <1d7ddd110609291952g5f0900bdobbe349e39eb8dfd3@mail.gmail.com> References: <1d7ddd110609280111u354f5b7m5fb502528862529b@mail.gmail.com> <1d7ddd110609280121o75134f8cnc5269890cbff28ca@mail.gmail.com> <8d961d900609280605o12d707a4q9296dbebcf84f061@mail.gmail.com> <1d7ddd110609282305j5bae1082p96769ed3100f00a7@mail.gmail.com> <1db558f00609290252j4f4e24c0lb8b02818b49cc102@mail.gmail.com> <57c63afe0609290506o37d2ae6cu98f6aa609f0b70bd@mail.gmail.com> <1d7ddd110609291952g5f0900bdobbe349e39eb8dfd3@mail.gmail.com> Message-ID: <57c63afe0609300551t49105bacj791597ea357e42cc@mail.gmail.com> On 9/29/06, Brian Takita wrote: > What about having listeners on setup and teardown? > For example, a plugin of any nature can register on the setup and teardown > events for each spec. That's a great idea in terms of the events themselves. Frees up each framework to plug in on its own terms. In fact, that's a great way for any other sort of plugin to work. The only other requirement would be that the plugin would have to make its methods available within the Specification. I guess they could just do Spec::Runner::Specification.include. I'm thinking we should tweak our own framework to plug in in this way. That will teach us a lot about how well it works before we publish a plugin mechanism. I'll take a crack at that over the next few days. Cheers, David > On 9/29/06, David Chelimsky wrote: > > > > On 9/29/06, James Mead wrote: > > > I've now had requests from several people for a way of using Mocha (& > > > Stubba) without a dependency on Test::Unit so it can interoperate with > other > > > testing frameworks. Given that this is the reason the current versions > of > > > Mocha and RSpec don't play together, I thought you might be interested > to > > > know I'm in the middle of making the necessary (relatively minor) > changes to > > > make this possible. > > > > James, > > > > That's awesome news. Thanks. > > > > Our plan here is to continue to have an integrated stubbing/mocking > > framework that is invoked by default, but allow other frameworks to be > > plugged in. To make that work most effectively, rspec needs some hook > > into Mocha/Stubba (and vice versa) so that the verification of mocks > > and resetting of stubs is seamless. Here's my current thinking: > > > > rspec would support a runtime configuration bit that allows users to > > choose a mock framework. Something like this: > > > > Spec::Mock.plugin = 'mocha' > > > > In each specification, RSpec includes a module named > > Spec::Mock::Plugin (or something like that) provided by mocha. This > > would provide spec writers access to mocha's API. > > > > The plugin would have to support two methods for rspec: one to assign > > a mock registry and one to verify a mock. Something like this: > > > > module Spec > > module Mock > > module Plugin > > attr_writer :mock_registry > > def verify mock > > #do whatever mocha does to verify the mock > > #raise an exception if verification fails > > end > > include XXX #module w/ mock creation methods, etc > > end > > end > > end > > > > It would then be mocha's job to call "mock_registry.register mock" as > > each mock is created and rspec's job to call verify(mock) at the end > > of each specification. > > > > Is this too complex? The thing I like about it is that rspec can make > > a few changes and any framework can offer itself up as a plugin w/ > > little effort. > > > > Thoughts? > > > > David From brian.takita at gmail.com Sat Sep 30 23:07:40 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 30 Sep 2006 20:07:40 -0700 Subject: [rspec-devel] Partial Mocks Message-ID: <1d7ddd110609302007o1d8aca12s36ab74108840eb25@mail.gmail.com> I added Partial Mocking, aka Class Level Mocking. For now, I added should_receive and should_not_receive to Object, but it can be moved to Class and/or its own module. I understand the Partial Mocking is controversial and dangerous if used incorrectly, but I've been finding myself using them with success. I'd advocate that Partial Mocking is a "sharp knife" that, if used correctly, can be a nice tool that simplifies tests/specs. Of course when used incorrectly, it can "slice through bone". Anyways, here is an example. It is committed inside of the stubs branch. How should we proceed? require File.dirname(__FILE__) + '/../lib/spec' class MockableClass def self.find id return :original_return end end context "A partial mock" do specify "should be able to stub objects" do obj = Object.new obj.should_receive(:foobar).and_return {:return_value} obj.foobar.should_equal :return_value end specify "should work at the class level" do MockableClass.should_receive(:find).and_return {:stub_return} MockableClass.find(1).should_equal :stub_return end specify "should revert to the original after each spec" do MockableClass.find(1).should_equal :original_return end end Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060930/e55048bf/attachment.html From noreply at rubyforge.org Tue Sep 19 22:08:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 19 Sep 2006 22:08:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5815 ] active_record_subclass.should_have(3).records Message-ID: <20060920020818.7EE325241964@rubyforge.org> Feature Requests item #5815, was opened at 2006-09-20 02:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5815&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Dave Astels (dastels) Summary: active_record_subclass.should_have(3).records Initial Comment: active_record_subclass.should_have(3).find(:all) already works, but it sucks for readability. active_record_subclass.should_have(3).records Now THAT is nice ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5815&group_id=797 From noreply at rubyforge.org Wed Sep 20 01:16:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 20 Sep 2006 01:16:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5815 ] active_record_subclass.should_have(3).records Message-ID: <20060920051649.85771A970018@rubyforge.org> Feature Requests item #5815, was opened at 2006-09-20 02:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5815&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Dave Astels (dastels) Summary: active_record_subclass.should_have(3).records Initial Comment: active_record_subclass.should_have(3).find(:all) already works, but it sucks for readability. active_record_subclass.should_have(3).records Now THAT is nice ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-09-20 05:16 Message: Dave Astels committed this ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5815&group_id=797 From noreply at rubyforge.org Fri Sep 22 03:50:55 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 22 Sep 2006 03:50:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-5844 ] Stub method Message-ID: <20060922075055.A5AD15240B99@rubyforge.org> Patches item #5844, was opened at 2006-09-22 00:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Stub method Initial Comment: This patch allows objects to be stubbed. It also reverts the object to its unstubbed state after the spec is finished executing. For example: require File.dirname(__FILE__) + '/../lib/spec' context "A consumer of a stub" do specify "should be able to stub objects" do obj = Object.new stub(obj).method(:foobar).with {:return_value} obj.foobar.should_equal :return_value end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 From noreply at rubyforge.org Fri Sep 22 08:53:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 22 Sep 2006 08:53:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-5844 ] Stub method Message-ID: <20060922125314.077075240BDC@rubyforge.org> Patches item #5844, was opened at 2006-09-22 07:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: Brian Takita (btakita) Summary: Stub method Initial Comment: This patch allows objects to be stubbed. It also reverts the object to its unstubbed state after the spec is finished executing. For example: require File.dirname(__FILE__) + '/../lib/spec' context "A consumer of a stub" do specify "should be able to stub objects" do obj = Object.new stub(obj).method(:foobar).with {:return_value} obj.foobar.should_equal :return_value end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-09-22 12:53 Message: Committed in revision 786 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 From noreply at rubyforge.org Sat Sep 23 15:42:53 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 23 Sep 2006 15:42:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5801 ] QuickRef.pdf should say RSpec, not rSpec Message-ID: <20060923194253.6F882A970003@rubyforge.org> Feature Requests item #5801, was opened at 2006-09-18 17:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5801&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Dave Astels (dastels) Summary: QuickRef.pdf should say RSpec, not rSpec Initial Comment: RSpec is the name that is most widely used, so the PDF should follow the convention. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-23 15:42 Message: Looks like Dave fixed this ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5801&group_id=797 From noreply at rubyforge.org Sun Sep 24 02:53:51 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 24 Sep 2006 02:53:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-5873 ] ARTS on RSpec on Rails Message-ID: <20060924065351.D37F25240C67@rubyforge.org> Patches item #5873, was opened at 2006-09-24 02:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5873&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: ARTS on RSpec on Rails Initial Comment: Here is my patchfile for adding ARTS support to the rails plugin as mentioned in the mailing list and on my blog. I made one modification ( add require 'arts' to spec_helper) Jake ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5873&group_id=797 From noreply at rubyforge.org Mon Sep 25 01:29:15 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 25 Sep 2006 01:29:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5890 ] Can't set expectation on predicate method whose name has underscores Message-ID: <20060925052915.4074852409C4@rubyforge.org> Bugs item #5890, was opened at 2006-09-25 01:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5890&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Can't set expectation on predicate method whose name has underscores Initial Comment: Using rspec 0.6.3, 0.6.2 and 0.6.1, I was unable to set an expectation on a predicate method whose name has underscores. I realize that there is more readable syntax than what I used in the attached example, but I think there is a problem nevertheless. In brief, I can't do this @order.should_needs_payment for a method needs_payment? on a class Order. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5890&group_id=797 From noreply at rubyforge.org Tue Sep 26 04:31:09 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 26 Sep 2006 04:31:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5909 ] Underscored predicates don't work Message-ID: <20060926083109.A6C825240C7E@rubyforge.org> Feature Requests item #5909, was opened at 2006-09-26 04:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 Category: None Group: None Status: Open Priority: 5 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Underscored predicates don't work Initial Comment: The following fails: class Bottle def contain_milk? true end end context "A new bottle" do specify "should contain milk" do Bottle.new.should_contain_milk end end It fails with: NoMethodError in 'A new bottle should contain milk' undefined method `contain?' for # ./failing_examples\bottle_spec.rb:11:in `should contain milk' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 From noreply at rubyforge.org Tue Sep 26 06:54:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 26 Sep 2006 06:54:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5909 ] Underscored predicates don't work Message-ID: <20060926105411.4A45A5240D6D@rubyforge.org> Feature Requests item #5909, was opened at 2006-09-26 08:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 Category: None Group: None Status: Open Priority: 5 Submitted By: Aslak Hellesoy (aslak_hellesoy) >Assigned to: David Chelimsky (dchelimsky) Summary: Underscored predicates don't work Initial Comment: The following fails: class Bottle def contain_milk? true end end context "A new bottle" do specify "should contain milk" do Bottle.new.should_contain_milk end end It fails with: NoMethodError in 'A new bottle should contain milk' undefined method `contain?' for # ./failing_examples\bottle_spec.rb:11:in `should contain milk' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-09-26 10:54 Message: Turns out that it depends on the form. The following works: target.should_multi_word_predicate but these fail: target.should_be_multi_word_predicate target.should_not_multi_word_predicate target.should_not_be_multi_word_predicate IIRC, this was working correctly at one point. I've added tests to ensure that it keeps working once I've gotten the fix (in progress). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 From noreply at rubyforge.org Tue Sep 26 18:23:56 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 26 Sep 2006 18:23:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5909 ] Underscored predicates don't work Message-ID: <20060926222356.18A62A970034@rubyforge.org> Feature Requests item #5909, was opened at 2006-09-26 04:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 Category: None Group: None Status: Open Priority: 5 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: Underscored predicates don't work Initial Comment: The following fails: class Bottle def contain_milk? true end end context "A new bottle" do specify "should contain milk" do Bottle.new.should_contain_milk end end It fails with: NoMethodError in 'A new bottle should contain milk' undefined method `contain?' for # ./failing_examples\bottle_spec.rb:11:in `should contain milk' ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-26 06:54 Message: Turns out that it depends on the form. The following works: target.should_multi_word_predicate but these fail: target.should_be_multi_word_predicate target.should_not_multi_word_predicate target.should_not_be_multi_word_predicate IIRC, this was working correctly at one point. I've added tests to ensure that it keeps working once I've gotten the fix (in progress). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 From noreply at rubyforge.org Tue Sep 26 18:24:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 26 Sep 2006 18:24:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5909 ] Underscored predicates don't work Message-ID: <20060926222434.B1FCAA97002E@rubyforge.org> Feature Requests item #5909, was opened at 2006-09-26 04:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 Category: None Group: None Status: Open Priority: 5 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: Underscored predicates don't work Initial Comment: The following fails: class Bottle def contain_milk? true end end context "A new bottle" do specify "should contain milk" do Bottle.new.should_contain_milk end end It fails with: NoMethodError in 'A new bottle should contain milk' undefined method `contain?' for # ./failing_examples\bottle_spec.rb:11:in `should contain milk' ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-26 06:54 Message: Turns out that it depends on the form. The following works: target.should_multi_word_predicate but these fail: target.should_be_multi_word_predicate target.should_not_multi_word_predicate target.should_not_be_multi_word_predicate IIRC, this was working correctly at one point. I've added tests to ensure that it keeps working once I've gotten the fix (in progress). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 From noreply at rubyforge.org Tue Sep 26 18:25:52 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 26 Sep 2006 18:25:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5890 ] Can't set expectation on predicate method whose name has underscores Message-ID: <20060926222552.E9ECAA970037@rubyforge.org> Bugs item #5890, was opened at 2006-09-25 01:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5890&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Can't set expectation on predicate method whose name has underscores Initial Comment: Using rspec 0.6.3, 0.6.2 and 0.6.1, I was unable to set an expectation on a predicate method whose name has underscores. I realize that there is more readable syntax than what I used in the attached example, but I think there is a problem nevertheless. In brief, I can't do this @order.should_needs_payment for a method needs_payment? on a class Order. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-26 18:25 Message: Duplicate of http://rubyforge.org/tracker/index.php?group_id=797&atid=3152 (which should have been filed as a bug instead of an RFE) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5890&group_id=797 From noreply at rubyforge.org Tue Sep 26 19:02:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 26 Sep 2006 19:02:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5909 ] Underscored predicates don't work Message-ID: <20060926230213.4494BA970019@rubyforge.org> Feature Requests item #5909, was opened at 2006-09-26 08:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: David Chelimsky (dchelimsky) Summary: Underscored predicates don't work Initial Comment: The following fails: class Bottle def contain_milk? true end end context "A new bottle" do specify "should contain milk" do Bottle.new.should_contain_milk end end It fails with: NoMethodError in 'A new bottle should contain milk' undefined method `contain?' for # ./failing_examples\bottle_spec.rb:11:in `should contain milk' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-09-26 23:02 Message: Fixed. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-26 10:54 Message: Turns out that it depends on the form. The following works: target.should_multi_word_predicate but these fail: target.should_be_multi_word_predicate target.should_not_multi_word_predicate target.should_not_be_multi_word_predicate IIRC, this was working correctly at one point. I've added tests to ensure that it keeps working once I've gotten the fix (in progress). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5909&group_id=797 From noreply at rubyforge.org Wed Sep 27 15:59:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 27 Sep 2006 15:59:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-5844 ] Stub method Message-ID: <20060927195926.C7EEAA97005F@rubyforge.org> Patches item #5844, was opened at 2006-09-22 03:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 Category: None Group: None >Status: Open Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Stub method Initial Comment: This patch allows objects to be stubbed. It also reverts the object to its unstubbed state after the spec is finished executing. For example: require File.dirname(__FILE__) + '/../lib/spec' context "A consumer of a stub" do specify "should be able to stub objects" do obj = Object.new stub(obj).method(:foobar).with {:return_value} obj.foobar.should_equal :return_value end end ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-27 15:59 Message: I'm reopening this since it's reverted from trunk and now lives in branches/stubs until we're happy with the API and docs are written. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-22 08:53 Message: Committed in revision 786 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 From noreply at rubyforge.org Wed Sep 27 23:28:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 27 Sep 2006 23:28:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5932 ] rspec_on_rails tied to gem Message-ID: <20060928032827.D0D37A970013@rubyforge.org> Bugs item #5932, was opened at 2006-09-28 03:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5932&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec_on_rails tied to gem Initial Comment: This is mostly for the dev team. stand in the root and do the following: cd vendor/rspec_on_rails rake pre_commit gem uninstall rspec (sudo if necessary, remove all versions) rake pre_commit What's happening is that pre_commit is bound to the spec command that is installed with the gem. With the gem uninstalled, these don't run. This means that whenever we're developing rspec_on_rails, we're developing against the last version of the gem we installed on our systems, not the current source. I'm just guessing, but I think that is bad! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5932&group_id=797 From noreply at rubyforge.org Fri Sep 29 03:37:23 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 29 Sep 2006 03:37:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5947 ] script/rails_spec_runner doesn't work on Windows Message-ID: <20060929073723.510EF5240BA9@rubyforge.org> Bugs item #5947, was opened at 2006-09-29 10:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5947&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: script/rails_spec_runner doesn't work on Windows Initial Comment: rails_spec_runner doesn't work on Windows. C:\my_project>ruby script/rails_spec_runner Loading Rails environment script/rails_spec_runner:45:in `trap': unsupported signal SIGUSR2 (ArgumentError) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5947&group_id=797 From noreply at rubyforge.org Fri Sep 29 03:39:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 29 Sep 2006 03:39:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5948 ] rails_spec_runner called rails_spec_server in documentation Message-ID: <20060929073942.CC1A35240E51@rubyforge.org> Bugs item #5948, was opened at 2006-09-29 10:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5948&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: rails_spec_runner called rails_spec_server in documentation Initial Comment: In http://rspec.rubyforge.org/tools/rails.html: [...] Running specs faster with rails_spec Loading the entire Rails environment every time a spec is executed is quite slow. We have therefore made a little tool that allows you to load the rails environment once for all. In a separate shell, run: script/rails_spec_server [...] Shouldn't this be script/rails_spec_runner ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5948&group_id=797