From peter_marklund at fastmail.fm Sat Sep 1 02:52:37 2007 From: peter_marklund at fastmail.fm (Peter Marklund) Date: Sat, 1 Sep 2007 08:52:37 +0200 Subject: [rspec-users] Setting use_transactional_fixtures=false for a single spec - a bad idea? In-Reply-To: <57c63afe0708310818v2ef9405bw5aa399f7c79ffda1@mail.gmail.com> References: <57c63afe0708310818v2ef9405bw5aa399f7c79ffda1@mail.gmail.com> Message-ID: > I'd set up a separate folder for these specs and tweak the rake tasks > to run those specs in a separate process, w/ its own spec_helper that > sets config.use_transactional_fixtures to false. Thanks for the quick reply David! Sounds like your solution would be fairly easy to set up. For now though I'm running all my specs with use_transactional_fixtures=false. Slowed my specs down from about 6 to 12 seconds. Cheers peter From rupert_apsc at rupespad.com Sat Sep 1 04:31:31 2007 From: rupert_apsc at rupespad.com (rupert) Date: Sat, 1 Sep 2007 09:31:31 +0100 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> Message-ID: > I saw in one of Dave C.'s comments to a ticket that "our current plan > is to deprecate the mocking framework." I hadn't heard anything about > that, but then again I haven't paid super close attention to the list. > Are we planning on dumping the mock framework in favor of using Mocha > (or any other framework one might want to plug in?). The idea has been banded around on the dev list recently, see..... http://www.nabble.com/mock-framework-tf4312137.html#a12276473 for the discussion Cheers Rupert From tom at experthuman.com Sat Sep 1 05:04:34 2007 From: tom at experthuman.com (Tom Stuart) Date: Sat, 1 Sep 2007 10:04:34 +0100 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> Message-ID: <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> On 1 Sep 2007, at 09:31, rupert wrote: >> Are we planning on dumping the mock framework in favor of using >> Mocha > The idea has been banded around on the dev list recently This makes me sad, because it means only one thing for the majority of users: more hassle. So now I have to choose a mocking framework too (an arbitrary choice, thus a gamble), or else configure RSpec to keep working the way it used to work, and watch my mocking code slide into obsolescence? Sigh. I agree that it's a big win for the RSpec developers to not have to deal with the distraction of maintaining a mocking framework, but it's vaguely surprising that nobody's mentioned how valuable it is that RSpec is a tidy, coherent, consistent, integrated BDD tool that just works out of the box right now. (And newcomers still find it impenetrable!) It looks like it's inevitable that it'll be broken up, but, yeah, it's a real shame. Cheers, -Tom From peter_marklund at fastmail.fm Sat Sep 1 05:15:25 2007 From: peter_marklund at fastmail.fm (Peter Marklund) Date: Sat, 1 Sep 2007 11:15:25 +0200 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> Message-ID: I understand where you're coming from Tom. But it's currently two script/plugin installs to start using RSpec with Rails, making it be three (the current two plus a mocking framework) is presumably not going to change adoption or the hurdle of using RSpec by much. I currently use Mocha because I can use it both with Test::Unit and RSpec. I have a big legacy of Test::Unit tests and I want to be able to maintain those and use mocking there, with the same syntax as in RSpec. That's why I don't use the built in mocking in RSpec. Peter On Sep 1, 2007, at 11:04 AM, Tom Stuart wrote: > On 1 Sep 2007, at 09:31, rupert wrote: >>> Are we planning on dumping the mock framework in favor of using >>> Mocha >> The idea has been banded around on the dev list recently > > This makes me sad, because it means only one thing for the majority > of users: more hassle. So now I have to choose a mocking framework > too (an arbitrary choice, thus a gamble), or else configure RSpec to > keep working the way it used to work, and watch my mocking code slide > into obsolescence? Sigh. > > I agree that it's a big win for the RSpec developers to not have to > deal with the distraction of maintaining a mocking framework, but > it's vaguely surprising that nobody's mentioned how valuable it is > that RSpec is a tidy, coherent, consistent, integrated BDD tool that > just works out of the box right now. (And newcomers still find it > impenetrable!) It looks like it's inevitable that it'll be broken up, > but, yeah, it's a real shame. > > Cheers, > -Tom > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users ---------------------------- Peter Marklund Garvar Lundins Gr?nd 7 11220 Stockholm Sweden Mobile Phone: +46-(0)70-4164857 Home Phone: +46-(0)8-50091315 Skype: peter_marklund IM: AIM - petermarklund, MSN - peter_marklund at hotmail.com, Yahoo - peter_marklund2002 http://marklunds.com ---------------------------- From pergesu at gmail.com Sat Sep 1 05:38:08 2007 From: pergesu at gmail.com (Pat Maddox) Date: Sat, 1 Sep 2007 02:38:08 -0700 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> Message-ID: <810a540e0709010238v69342956p68e9f299bb91d3e0@mail.gmail.com> On 9/1/07, rupert wrote: > > I saw in one of Dave C.'s comments to a ticket that "our current plan > > is to deprecate the mocking framework." I hadn't heard anything about > > that, but then again I haven't paid super close attention to the list. > > Are we planning on dumping the mock framework in favor of using Mocha > > (or any other framework one might want to plug in?). > > The idea has been banded around on the dev list recently, see..... > > http://www.nabble.com/mock-framework-tf4312137.html#a12276473 > > for the discussion > > Cheers > > Rupert > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > Thanks for the link. Pat From win at wincent.com Sat Sep 1 06:34:28 2007 From: win at wincent.com (Wincent Colaiuta) Date: Sat, 1 Sep 2007 12:34:28 +0200 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> Message-ID: El 1/9/2007, a las 11:15, Peter Marklund escribi?: > I understand where you're coming from Tom. But it's currently two > script/plugin installs to start using RSpec with Rails, making it be > three (the current two plus a mocking framework) is presumably not > going to change adoption or the hurdle of using RSpec by much. I > currently use Mocha because I can use it both with Test::Unit and > RSpec. I have a big legacy of Test::Unit tests and I want to be able > to maintain those and use mocking there, with the same syntax as in > RSpec. That's why I don't use the built in mocking in RSpec. Ouch. I used the built-in RSpec mocking because it was the default and I figured that it would be less likely to have compatibility issues in the future (say when Mocha or any of the others made subtle updates outside the control of the RSpec team). I liked the idea of having one integrated package which just worked. I actually thought the trend was in the opposite direction; to include things in RSpec (isn't RBehave part of trunk now?) rather than pare them down. Luckily, however, I don't have too many mocks yet, and the ones which are there aren't that complex. Could probably convert them over to something else in about a day's work. Cheers, Wincent From rupert_apsc at rupespad.com Sat Sep 1 06:35:19 2007 From: rupert_apsc at rupespad.com (rupert) Date: Sat, 1 Sep 2007 11:35:19 +0100 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> Message-ID: <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> On 1 Sep 2007, at 10:04, Tom Stuart wrote: > On 1 Sep 2007, at 09:31, rupert wrote: >>> Are we planning on dumping the mock framework in favor of using >>> Mocha >> The idea has been banded around on the dev list recently > > This makes me sad, because it means only one thing for the majority > of users: more hassle. So now I have to choose a mocking framework > too (an arbitrary choice, thus a gamble), or else configure RSpec to > keep working the way it used to work, and watch my mocking code slide > into obsolescence? Sigh. It won't be removed, so you'll still be able to use it (as Peter pointed out) . I had exactly the same initial reaction as you (mine was a sort of "nooooo, they can't do that") so I know where you're coming from. But having read through the discussion on the dev list and thought about it, the rspec mocking framework is pretty stable and complete so I don't think depreciating it is going to be too big a problem for those (like me!) that have a bundle of specs that use the rspec mocking framework - I'm going to keep using it for now, but have a look at the alternatives as a background task with the intent to use one of them on a new project as some point in the future. Cheers Rupert From dchelimsky at gmail.com Sat Sep 1 10:10:09 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 1 Sep 2007 09:10:09 -0500 Subject: [rspec-users] How to spec routes for a resource nested in multiples resources? In-Reply-To: References: Message-ID: <57c63afe0709010710r37934f1dw1cc49e5fc3852d03@mail.gmail.com> On 8/31/07, Edgar Gonzalez wrote: > Hi, > > I got the resource "Llamadas" nested in: > - Operadores > - Productos > - Centros > > Here is part of my routes http://pastie.caboo.se/92767 > > I want to spec that the routes for Llamadas, I tried several approachs: > > - route_for(:controller => "llamadas", :action => "exitosas", > :operador_id => 1).should == "/operador/1/llamadas;exitosas" route_for wraps ActionController::Routing::Routes.generate(options), so whatever route_for is producing is what rails actually produces. You may want to ask on the Rails list how people are approaching this w/ test/unit. If you get an answer, please report it back here. Cheers, David > > - controller.send(:operador_exitosas_llamadas_path, at operador).should > == "/operador/22/llamadas;exitosas" > > but nothing works. > > any clue? > > thanks in advance > -- > Edgar Gonz?lez Gonz?lez > E-mail: edgargonzalez at gmail.com > http://www.hasmanydevelopers.com > http://www.rubycorner.com > http://www.to2blogs.com > http://www.lacaraoscura.com > -- > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From rupert_apsc at rupespad.com Sat Sep 1 10:54:47 2007 From: rupert_apsc at rupespad.com (rupert) Date: Sat, 1 Sep 2007 15:54:47 +0100 Subject: [rspec-users] How to spec routes for a resource nested in multiples resources? In-Reply-To: <57c63afe0709010710r37934f1dw1cc49e5fc3852d03@mail.gmail.com> References: <57c63afe0709010710r37934f1dw1cc49e5fc3852d03@mail.gmail.com> Message-ID: <0A234D32-C201-4327-8D91-A4F35C5DB3E8@rupespad.com> > On 8/31/07, Edgar Gonzalez wrote: >> Hi, >> >> I got the resource "Llamadas" nested in: >> - Operadores >> - Productos >> - Centros >> >> Here is part of my routes http://pastie.caboo.se/92767 >> >> I want to spec that the routes for Llamadas, I tried several >> approachs: >> >> - route_for(:controller => "llamadas", :action => "exitosas", >> :operador_id => 1).should == "/operador/1/llamadas;exitosas" > > route_for wraps ActionController::Routing::Routes.generate(options), > so whatever route_for is producing is what rails actually produces. > You may want to ask on the Rails list how people are approaching this > w/ test/unit. If you get an answer, please report it back here. another suggestion... you could take the code from http://pastie.caboo.se/74249 and paste it into a file called (say) routes.rake in your lib/tasks directory then run rake routes to get a listing of all the routes and their mappings in your terminal window. This will show you how the controllers, actions and parameters are mapped to urls and might help you work out what's going on. Cheers Rupert From omen.king at gmail.com Sat Sep 1 13:16:26 2007 From: omen.king at gmail.com (Andrew WC Brown) Date: Sat, 1 Sep 2007 13:16:26 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: My question is what would you recommend for Mocking? Mocha or FlexMock? On 9/1/07, rupert wrote: > > > On 1 Sep 2007, at 10:04, Tom Stuart wrote: > > > On 1 Sep 2007, at 09:31, rupert wrote: > >>> Are we planning on dumping the mock framework in favor of using > >>> Mocha > >> The idea has been banded around on the dev list recently > > > > This makes me sad, because it means only one thing for the majority > > of users: more hassle. So now I have to choose a mocking framework > > too (an arbitrary choice, thus a gamble), or else configure RSpec to > > keep working the way it used to work, and watch my mocking code slide > > into obsolescence? Sigh. > > It won't be removed, so you'll still be able to use it (as Peter > pointed out) . I had exactly the same initial reaction as you (mine > was a sort of "nooooo, they can't do that") so I know where you're > coming from. But having read through the discussion on the dev list > and thought about it, the rspec mocking framework is pretty stable > and complete so I don't think depreciating it is going to be too big > a problem for those (like me!) that have a bundle of specs that use > the rspec mocking framework - I'm going to keep using it for now, but > have a look at the alternatives as a background task with the intent > to use one of them on a new project as some point in the future. > > Cheers > > Rupert > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070901/0ee4ed1b/attachment.html From rupert_apsc at rupespad.com Sat Sep 1 13:31:25 2007 From: rupert_apsc at rupespad.com (rupert) Date: Sat, 1 Sep 2007 18:31:25 +0100 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: On 1 Sep 2007, at 18:16, Andrew WC Brown wrote: > My question is what would you recommend for Mocking? > > Mocha or FlexMock? Personally, I've not got a clue as all I've used to date is the rspec mocking framework. I've had a quick look at Mocha and it seems pretty good, but haven't looked into FlexMock at all yet. +1 to anyone who's used both these can comment on the differences! From omen.king at gmail.com Sat Sep 1 13:35:43 2007 From: omen.king at gmail.com (Andrew WC Brown) Date: Sat, 1 Sep 2007 13:35:43 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: After a quick google search: http://www.slideshare.net/viget/mockfight-flexmock-vs-mocha I have no problem using a external mocking framework but its the choosing. convention over configuration. On 9/1/07, rupert wrote: > > > On 1 Sep 2007, at 18:16, Andrew WC Brown wrote: > > > My question is what would you recommend for Mocking? > > > > Mocha or FlexMock? > > Personally, I've not got a clue as all I've used to date is the rspec > mocking framework. I've had a quick look at Mocha and it seems > pretty good, but haven't looked into FlexMock at all yet. > > +1 to anyone who's used both these can comment on the differences! > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Monsterbox Productions putting small businesses on-line 1319 Victoria Avenue East Thunder Bay, Ontario P7C 1C3 Canada Andrew WC Brown web-developer and owner andrew at monsterboxpro.com P: 807-626-9009 F: 807-624-2705 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070901/7645460f/attachment.html From dchelimsky at gmail.com Sat Sep 1 13:48:00 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 1 Sep 2007 12:48:00 -0500 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: <57c63afe0709011048j681316e6kb94145fc682c6aca@mail.gmail.com> On 9/1/07, Andrew WC Brown wrote: > After a quick google search: > > http://www.slideshare.net/viget/mockfight-flexmock-vs-mocha In fairness - there is something lacking in the slide set - it suggests that mocha supports parameter matchers and flexmock does not. In fact, flexmock does. You can do this: mock.should_receive(:message).with(String).once and it will pass if the mock receives the message w/ a String. In mocha, you have to say: mock.expects(:message).with(kind_of(String)) Flexmock compares args using ===, which is why this works implicitly. Similarly, mocha, flexmock, and rspec can all take an argument matcher - an object that responds to == and gives you the right answer. So, you can do this w/ any of these frameworks: class LessThan def initialize(threshold) @threshold = threshold end def ==(other) other < @threshold end end def less_than(expected) LessThan.new(expected) end mock.expects(:message).with(less_than(3)) mock.should_receive(:message).with(less_than(3)) Cheers, David > > I have no problem using a external mocking framework but its the choosing. > convention over configuration. > > > > On 9/1/07, rupert wrote: > > > > On 1 Sep 2007, at 18:16, Andrew WC Brown wrote: > > > > > My question is what would you recommend for Mocking? > > > > > > Mocha or FlexMock? > > > > Personally, I've not got a clue as all I've used to date is the rspec > > mocking framework. I've had a quick look at Mocha and it seems > > pretty good, but haven't looked into FlexMock at all yet. > > > > +1 to anyone who's used both these can comment on the differences! > > > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > -- > Monsterbox Productions > putting small businesses on-line > > 1319 Victoria Avenue East > Thunder Bay, Ontario P7C 1C3 > Canada > > Andrew WC Brown > web-developer and owner > andrew at monsterboxpro.com > P: 807-626-9009 > F: 807-624-2705 > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From wilsonb at gmail.com Sun Sep 2 02:39:20 2007 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Sun, 2 Sep 2007 02:39:20 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: On 9/1/07, rupert wrote: > > On 1 Sep 2007, at 10:04, Tom Stuart wrote: > > > On 1 Sep 2007, at 09:31, rupert wrote: > >>> Are we planning on dumping the mock framework in favor of using > >>> Mocha > >> The idea has been bandied around on the dev list recently This decision, if it is made in this manner, is suicide for RSpec. I have been a huge RSpec booster, but this will make me drop it like a hot coal. =( From pergesu at gmail.com Sun Sep 2 02:45:28 2007 From: pergesu at gmail.com (Pat Maddox) Date: Sat, 1 Sep 2007 23:45:28 -0700 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> Message-ID: <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> On 8/24/07, David Chelimsky wrote: > On 8/24/07, Pat Maddox wrote: > > On 8/24/07, David Chelimsky wrote: > > > describe Widget, "class" do > > > it "should provide a list of widgets sorted alphabetically" do > > > Widget.should_receive(:find).with(:order => "name ASC") > > > Widget.find_alphabetically > > > end > > > end > > > > > > You're correct that the refactoring requires you to change the > > > object-level examples, and that is something that would be nice to > > > avoid. But also keep in mind that in java and C# people refactor > > > things like that all the time without batting an eye, because the > > > tools make it a one-step activity. Refactoring is changing the design > > > of your *system* without changing its behaviour. That doesn't really > > > fly all the way down to the object level 100% of the time. > > > > > > WDYT? > > > > I think that example is fine up until the model spec. The > > find_alphabetically example should hit the db, imo. With the current > > spec there's no way to know whether find_alphabetically actually works > > or not. You're relying on knowledge of ActiveRecord here, trusting > > that the arguments to find are correct. > > Au contrare! This all starts with an Integration Test. I didn't post > the code but I did mention it. > > > What I've found when I write specs is that I discover new layers of > > services until eventually I get to a layer that actually does > > something. When I get there, it's important to have specs that > > describe what it does, not how it does it. In the case of > > find_alphabetically we care that it returns the items in alphabetical > > order. Not that it makes a certain call to the db. > > I play this both ways and haven't come to a preference, but I'm > leaning towards blocking database access from the rspec examples and > only allowing it my end to end tests (using Rails Integration Tests or > - soon - RSpec's new Story Runner). Now that I've had a chance to play with Story Runner, I want to revisit this topic a bit. Let's say in your example you wanted to refactor find_alphabetically to use enumerable's sort_by to do the sorting. def self.find_alphabetically find(:all).sort_by {|w| w.name } end Your model spec will fail, but your integration test will still pass. I've been thinking about this situation a lot over the last few months. It's been entirely theoretical because I haven't had a suite of integration tests ;) Most XP advocates lean heavily on unit tests when doing refactoring. Mocking tends to get in the way of refactoring though. In the example above, we rely on the integration test to give us confidence while refactoring. In fact I would ignore the unit test (model-level spec) altogether, and rewrite it when the refactoring is complete. Here's how I reconcile this with traditional XP unit testing. First of all our integration tests are relatively light weight. In a web app, a user story consists of making a request and verifying the response. Authentication included, you'll be making at most 3-5 HTTP requests per test. This means that our integration tests still run in just a few seconds. Integration tests in a Rails app are a completely different beast from the integration tests in the Chrysler payroll app that Beck, Jeffries, et al worked on. The second point of reconciliation is that mock objects and refactoring are two distinct tools you use to design your code. When I'm writing greenfield code I'll use mocks to drive the design. When I refactor though, I'm following known steps to improve the design of my existing code. The vast majority of the time I will perform a known refactoring, which means I know the steps and the resulting design. In this situation I'll ignore my model specs because they'll blow up, giving me no information other than I changed the design of my code. I can use the integration tests to ensure that I haven't broken any behavior. At this point I would edit the model specs to use the correct mock calls. As I mentioned, this has been something that's been on my mind for a while. I find mock objects to be very useful, but they seem to clash with most of the existing TDD and XP literature. To summarize, here are the points where I think they clash: * Classical TDD relies on unit tests for confidence in refactoring. BDD relies on integration tests * XP acceptance tests are customer tests, whereas RSpec User Stories are programmer tests. They can serve a dual-purpose because you can easily show them to a customer, but they're programmer tests in the sense that the programmer writes and is responsible for those particular tests. In the end it boils down to getting stuff done. After a bit of experimentation I'm thinking that the process of 1. Write a user story 2. Write detailed specs using mocks to drive design 3. Refactor, using stories to ensure that expected behavior is maintained, ignoring detailed specs 4. Retrofit specs with correct mock expectations is a solid approach. I'd like others to weigh in with their thoughts. Pat From pergesu at gmail.com Sun Sep 2 03:05:59 2007 From: pergesu at gmail.com (Pat Maddox) Date: Sun, 2 Sep 2007 00:05:59 -0700 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: <810a540e0709020005t4a7a04d4jd09fefc46018feb4@mail.gmail.com> On 9/1/07, Wilson Bilkovich wrote: > On 9/1/07, rupert wrote: > > > > On 1 Sep 2007, at 10:04, Tom Stuart wrote: > > > > > On 1 Sep 2007, at 09:31, rupert wrote: > > >>> Are we planning on dumping the mock framework in favor of using > > >>> Mocha > > >> The idea has been bandied around on the dev list recently > > This decision, if it is made in this manner, is suicide for RSpec. > I have been a huge RSpec booster, but this will make me drop it like a hot coal. > =( While I won't drop RSpec ;) I agree that removing the mocking framework is a mistake. With the integration of rbehave, RSpec is a complete BDD framework. It allows for behavior specification at the app-level and at the object-level. I'm sure everyone will agree that mocking is integral to the object specification component of BDD. To paraphrase Aslak, "if you're not using mock objects then it ain't BDD." I can understand not wanting to reinvent the wheel, and there are mock frameworks that sufficiently do the job. However the whole point of RSpec is that we're not satisfied with "sufficient" but instead demand a tool that works the way our brains think. I haven't used Mocha or Flexmock extensively because RSpec's mocking has been great for me...but I remember taking a look at them when Mocha support was first added to RSpec. There were some things that RSpec's framework did better and more clearly than Mocha. I wish I could remember them precisely, but it was quite a while back. The point is, if the mock framework feels off even a little bit, it basically defeats the purpose of RSpec. At the very least, it undermines it to a degree. RSpec should keep its mocking framework because it's the only framework that is designed with the same philosophy as RSpec. In fact I feel insanely strange thinking of them as separate entities. The best scenario, imo, is one where we have a mocking framework tightly coupled to the overall vision of the RSpec project, but that allows people to use something else if they really want. I think it's important that RSpec remain a complete BDD framework with all necessary components working in harmony. Pat From priit.tamboom at eesti.ee Sun Sep 2 03:35:17 2007 From: priit.tamboom at eesti.ee (Priit Tamboom) Date: Sun, 2 Sep 2007 15:35:17 +0800 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: On 9/2/07, Wilson Bilkovich wrote: > On 9/1/07, rupert wrote: > > > > On 1 Sep 2007, at 10:04, Tom Stuart wrote: > > > > > On 1 Sep 2007, at 09:31, rupert wrote: > > >>> Are we planning on dumping the mock framework in favor of using > > >>> Mocha > > >> The idea has been bandied around on the dev list recently > > This decision, if it is made in this manner, is suicide for RSpec. > I have been a huge RSpec booster, but this will make me drop it like a hot coal. > =( > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > Eh! The first reactions :-) However I also have to admit and wonder why rspec dev didn't make this kind of decisions before version 1.0. I hate (as a nuby) that now I have to make decision (mocka or flexmock) at the time where I'm not even a big mock fan yet (now it's even more harder to sell the idea to co-workers as well). For the very first look, I prefer mocka syntax more than flexmock. However I like rspec's clean it 'should' specs (and generating doc from it) so much more compared to test::unit way is. Oki, Priit From dchelimsky at gmail.com Sun Sep 2 03:56:58 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 2 Sep 2007 02:56:58 -0500 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> Message-ID: <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> On 9/2/07, Pat Maddox wrote: > On 8/24/07, David Chelimsky wrote: > > On 8/24/07, Pat Maddox wrote: > > > On 8/24/07, David Chelimsky wrote: > > > > describe Widget, "class" do > > > > it "should provide a list of widgets sorted alphabetically" do > > > > Widget.should_receive(:find).with(:order => "name ASC") > > > > Widget.find_alphabetically > > > > end > > > > end > > > > > > > > You're correct that the refactoring requires you to change the > > > > object-level examples, and that is something that would be nice to > > > > avoid. But also keep in mind that in java and C# people refactor > > > > things like that all the time without batting an eye, because the > > > > tools make it a one-step activity. Refactoring is changing the design > > > > of your *system* without changing its behaviour. That doesn't really > > > > fly all the way down to the object level 100% of the time. > > > > > > > > WDYT? > > > > > > I think that example is fine up until the model spec. The > > > find_alphabetically example should hit the db, imo. With the current > > > spec there's no way to know whether find_alphabetically actually works > > > or not. You're relying on knowledge of ActiveRecord here, trusting > > > that the arguments to find are correct. > > > > Au contrare! This all starts with an Integration Test. I didn't post > > the code but I did mention it. > > > > > What I've found when I write specs is that I discover new layers of > > > services until eventually I get to a layer that actually does > > > something. When I get there, it's important to have specs that > > > describe what it does, not how it does it. In the case of > > > find_alphabetically we care that it returns the items in alphabetical > > > order. Not that it makes a certain call to the db. > > > > I play this both ways and haven't come to a preference, but I'm > > leaning towards blocking database access from the rspec examples and > > only allowing it my end to end tests (using Rails Integration Tests or > > - soon - RSpec's new Story Runner). > > Now that I've had a chance to play with Story Runner, I want to > revisit this topic a bit. > > Let's say in your example you wanted to refactor find_alphabetically > to use enumerable's sort_by to do the sorting. > > def self.find_alphabetically > find(:all).sort_by {|w| w.name } > end > > Your model spec will fail, but your integration test will still pass. > > I've been thinking about this situation a lot over the last few > months. It's been entirely theoretical because I haven't had a suite > of integration tests ;) Most XP advocates lean heavily on unit tests > when doing refactoring. Mocking tends to get in the way of > refactoring though. In the example above, we rely on the integration > test to give us confidence while refactoring. In fact I would ignore > the unit test (model-level spec) altogether, and rewrite it when the > refactoring is complete. > > Here's how I reconcile this with traditional XP unit testing. First > of all our integration tests are relatively light weight. In a web > app, a user story consists of making a request and verifying the > response. Authentication included, you'll be making at most 3-5 HTTP > requests per test. This means that our integration tests still run in > just a few seconds. Integration tests in a Rails app are a completely > different beast from the integration tests in the Chrysler payroll app > that Beck, Jeffries, et al worked on. > > The second point of reconciliation is that mock objects and > refactoring are two distinct tools you use to design your code. When > I'm writing greenfield code I'll use mocks to drive the design. When > I refactor though, I'm following known steps to improve the design of > my existing code. The vast majority of the time I will perform a > known refactoring, which means I know the steps and the resulting > design. In this situation I'll ignore my model specs because they'll > blow up, giving me no information other than I changed the design of > my code. I can use the integration tests to ensure that I haven't > broken any behavior. At this point I would edit the model specs to > use the correct mock calls. > > As I mentioned, this has been something that's been on my mind for a > while. I find mock objects to be very useful, but they seem to clash > with most of the existing TDD and XP literature. To summarize, here > are the points where I think they clash: > > * Classical TDD relies on unit tests for confidence in refactoring. > BDD relies on integration tests > * XP acceptance tests are customer tests, whereas RSpec User Stories > are programmer tests. They can serve a dual-purpose because you can > easily show them to a customer, but they're programmer tests in the > sense that the programmer writes and is responsible for those > particular tests. > > In the end it boils down to getting stuff done. After a bit of > experimentation I'm thinking that the process of > 1. Write a user story > 2. Write detailed specs using mocks to drive design > 3. Refactor, using stories to ensure that expected behavior is > maintained, ignoring detailed specs > 4. Retrofit specs with correct mock expectations > > is a solid approach. I'd like others to weigh in with their thoughts. Hey Pat, I really appreciate that you're thinking about and sharing this as its something that weighs on a lot of people's minds and it's clear that you have some understanding of the XP context in which all of this was born. That said, I see this quite a bit differently. I don't think this has anything to do w/ TDD vs BDD. "Mock Objects" is not a BDD concept. It just feels that way because we talk more about interaction testing, but interaction testing predates BDD by some years. The problem we experience with mocks relates to the fact that we've chosen to live in the beautiful, free, dynamically typed and POORLY TOOLED land of Ruby. When Ruby refactoring tools catch up with those of java and .NET, this pain will all go away. For example - if I'm in IntelliJ in a java project and I have a method like this: model.getName() and I'm using jmock (the old version), which uses Strings for method names: model.expects(once()).method("getName").will(returnValue("stub value")) and I do a Rename Method refactoring on getName(), IntelliJ will ask me if I want to change the strings it finds that match getName as well as the method invocations. In Ruby, we do this now w/ search and replace. Not quite as elegant. But under the hood, that's all IntelliJ is doing. It just makes it feel like an integrated step of an automated refactoring. re: Story Runner. The intent of Story Runner is exactly the same as tools like FIT, etc, that are typically found in the Acceptance Testing space in XP projects. In my experience using FitNesse, it was rare that a customer actually added new tests to a suite. If there were testing folks on board, they would do it (and they would likely be equipped to do it in Story Runner as well), but if not, then the FitNesse tests were at best the result of a collaborative session with the customer and, at worst, our (developers), interpretation of conversations we had had with the customer. I see Story Runner fitting in exactly like that in the short run. I can also see external DSLs emerging that let customers actually write the outputs that Story Runner should produce and run that through a process that writes what we're writing now in Story Runner. But that's probably some time off. I totally agree with your last statement that "it boils down to getting stuff done." And your approach seems to be the approach that I take, given the tools that we have. But I really think its about tools and not process. And I think that BDD is a lot more like what really experienced TDD'ers do out of the gate. We're just choosing different words and structures to make it easier to communicate across roles on a team (customer, developer, tester, etc). FWIW. Cheers, David > > Pat > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From pergesu at gmail.com Sun Sep 2 05:32:40 2007 From: pergesu at gmail.com (Pat Maddox) Date: Sun, 2 Sep 2007 02:32:40 -0700 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> Message-ID: <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> On 9/2/07, David Chelimsky wrote: > On 9/2/07, Pat Maddox wrote: > > On 8/24/07, David Chelimsky wrote: > > > On 8/24/07, Pat Maddox wrote: > > > > On 8/24/07, David Chelimsky wrote: > > > > > describe Widget, "class" do > > > > > it "should provide a list of widgets sorted alphabetically" do > > > > > Widget.should_receive(:find).with(:order => "name ASC") > > > > > Widget.find_alphabetically > > > > > end > > > > > end > > > > > > > > > > You're correct that the refactoring requires you to change the > > > > > object-level examples, and that is something that would be nice to > > > > > avoid. But also keep in mind that in java and C# people refactor > > > > > things like that all the time without batting an eye, because the > > > > > tools make it a one-step activity. Refactoring is changing the design > > > > > of your *system* without changing its behaviour. That doesn't really > > > > > fly all the way down to the object level 100% of the time. > > > > > > > > > > WDYT? > > > > > > > > I think that example is fine up until the model spec. The > > > > find_alphabetically example should hit the db, imo. With the current > > > > spec there's no way to know whether find_alphabetically actually works > > > > or not. You're relying on knowledge of ActiveRecord here, trusting > > > > that the arguments to find are correct. > > > > > > Au contrare! This all starts with an Integration Test. I didn't post > > > the code but I did mention it. > > > > > > > What I've found when I write specs is that I discover new layers of > > > > services until eventually I get to a layer that actually does > > > > something. When I get there, it's important to have specs that > > > > describe what it does, not how it does it. In the case of > > > > find_alphabetically we care that it returns the items in alphabetical > > > > order. Not that it makes a certain call to the db. > > > > > > I play this both ways and haven't come to a preference, but I'm > > > leaning towards blocking database access from the rspec examples and > > > only allowing it my end to end tests (using Rails Integration Tests or > > > - soon - RSpec's new Story Runner). > > > > Now that I've had a chance to play with Story Runner, I want to > > revisit this topic a bit. > > > > Let's say in your example you wanted to refactor find_alphabetically > > to use enumerable's sort_by to do the sorting. > > > > def self.find_alphabetically > > find(:all).sort_by {|w| w.name } > > end > > > > Your model spec will fail, but your integration test will still pass. > > > > I've been thinking about this situation a lot over the last few > > months. It's been entirely theoretical because I haven't had a suite > > of integration tests ;) Most XP advocates lean heavily on unit tests > > when doing refactoring. Mocking tends to get in the way of > > refactoring though. In the example above, we rely on the integration > > test to give us confidence while refactoring. In fact I would ignore > > the unit test (model-level spec) altogether, and rewrite it when the > > refactoring is complete. > > > > Here's how I reconcile this with traditional XP unit testing. First > > of all our integration tests are relatively light weight. In a web > > app, a user story consists of making a request and verifying the > > response. Authentication included, you'll be making at most 3-5 HTTP > > requests per test. This means that our integration tests still run in > > just a few seconds. Integration tests in a Rails app are a completely > > different beast from the integration tests in the Chrysler payroll app > > that Beck, Jeffries, et al worked on. > > > > The second point of reconciliation is that mock objects and > > refactoring are two distinct tools you use to design your code. When > > I'm writing greenfield code I'll use mocks to drive the design. When > > I refactor though, I'm following known steps to improve the design of > > my existing code. The vast majority of the time I will perform a > > known refactoring, which means I know the steps and the resulting > > design. In this situation I'll ignore my model specs because they'll > > blow up, giving me no information other than I changed the design of > > my code. I can use the integration tests to ensure that I haven't > > broken any behavior. At this point I would edit the model specs to > > use the correct mock calls. > > > > As I mentioned, this has been something that's been on my mind for a > > while. I find mock objects to be very useful, but they seem to clash > > with most of the existing TDD and XP literature. To summarize, here > > are the points where I think they clash: > > > > * Classical TDD relies on unit tests for confidence in refactoring. > > BDD relies on integration tests > > * XP acceptance tests are customer tests, whereas RSpec User Stories > > are programmer tests. They can serve a dual-purpose because you can > > easily show them to a customer, but they're programmer tests in the > > sense that the programmer writes and is responsible for those > > particular tests. > > > > In the end it boils down to getting stuff done. After a bit of > > experimentation I'm thinking that the process of > > 1. Write a user story > > 2. Write detailed specs using mocks to drive design > > 3. Refactor, using stories to ensure that expected behavior is > > maintained, ignoring detailed specs > > 4. Retrofit specs with correct mock expectations > > > > is a solid approach. I'd like others to weigh in with their thoughts. > > Hey Pat, > > I really appreciate that you're thinking about and sharing this as its > something that weighs on a lot of people's minds and it's clear that > you have some understanding of the XP context in which all of this was > born. > > That said, I see this quite a bit differently. > > I don't think this has anything to do w/ TDD vs BDD. "Mock Objects" is > not a BDD concept. It just feels that way because we talk more about > interaction testing, but interaction testing predates BDD by some > years. Hi David, Thanks so much for your thoughtful reply. You're right, and I didn't mean to suggest that mock objects were a BDD concept at all. However it seems to me that BDDers embrace mock objects as a very useful design tool, whereas classical TDDers would use them sparsely, when a resource is expensive or difficult to use directly. For example, Beck talks about mocking a database in his book, and that's that. Astels demonstrates mocking the roll of a die. He does briefly use mocks before he's ready to implement the GUI part of the app. Those are the two TDD books with which I'm most familiar. I'm sure a lot has changed in the TDD community since then, and indeed you can see that Astels' mentality has changed somewhat. His "one assertion per test" article [1] parses an address and then verifies it by asserting the getters. His remake, "one expectation per example" [2] is a bit different in that he passes a mocked builder in and uses that to verify that the parsing code works, exposing no getters at all. That to me signifies a fundamental shift in TDD thought. Instead of thinking about objects in isolation and what services they provide, we think of the services an object provides and how it interacts with other objects and uses their services. I'm certain that it's not a new way of thinking, but hopefully you can see why I'd believe it's probably not mainstream. There's one other roadblock to my thinking, and it results from using RSpec almost exclusively within Rails projects. I think it's obvious why you mock models when writing view and controller specs. However less obvious to me is why mock associations in model specs, and I think it has to do with the fact that AR couples business and persistence logic. If we just had domain objects that never hit a database, then we might initially mock interactions but then use concrete instances when we later implemented those classes. When I think of Beck's Money example, or Martin Fowler's video rental list in Refactoring, it seems silly to me to use mocks in those cases. Perhaps you might at the very beginning, but you'd sub real objects in as you implemented them. We don't do this with AR because they're simply too heavy. This culminates in another general idea I've had which is to mock services in a lower layer, and use concrete instances for objects in the same layer when possible. If we were to split AR into domain objects and a data access layer, the domain objects would mock calls to the data access layer but use concrete domain objects in the tests. The unit tests remain fast and simple, and mocks no longer get in the way of refactoring. Of course then you're writing integration tests at a fairly low level I guess, but that's 100% acceptable to me in the interest of getting stuff done rather than being dogmatic. > The problem we experience with mocks relates to the fact that > we've chosen to live in the beautiful, free, dynamically typed and > POORLY TOOLED land of Ruby. When Ruby refactoring tools catch up with > those of java and .NET, this pain will all go away. > > For example - if I'm in IntelliJ in a java project and I have a method > like this: > > model.getName() > > and I'm using jmock (the old version), which uses Strings for method names: > > model.expects(once()).method("getName").will(returnValue("stub value")) > > and I do a Rename Method refactoring on getName(), IntelliJ will ask > me if I want to change the strings it finds that match getName as well > as the method invocations. > > In Ruby, we do this now w/ search and replace. Not quite as elegant. > But under the hood, that's all IntelliJ is doing. It just makes it > feel like an integrated step of an automated refactoring. Agreed. I guess for me it's easier to get the production code right and then fix the tests after the fact. I'd hate to do all the work of changing the production and test code and then find out it was incorrect. Fixing tests after fixing the production code amounts to the same work as doing it all in one step, because as you mentioned it's essentially a manual process. > re: Story Runner. The intent of Story Runner is exactly the same as > tools like FIT, etc, that are typically found in the Acceptance > Testing space in XP projects. In my experience using FitNesse, it was > rare that a customer actually added new tests to a suite. If there > were testing folks on board, they would do it (and they would likely > be equipped to do it in Story Runner as well), but if not, then the > FitNesse tests were at best the result of a collaborative session with > the customer and, at worst, our (developers), interpretation of > conversations we had had with the customer. > > I see Story Runner fitting in exactly like that in the short run. I > can also see external DSLs emerging that let customers actually write > the outputs that Story Runner should produce and run that through a > process that writes what we're writing now in Story Runner. But that's > probably some time off. > > I totally agree with your last statement that "it boils down to > getting stuff done." And your approach seems to be the approach that I > take, given the tools that we have. But I really think its about tools > and not process. And I think that BDD is a lot more like what really > experienced TDD'ers do out of the gate. We're just choosing different > words and structures to make it easier to communicate across roles on > a team (customer, developer, tester, etc). So "ideally," who would write Story Runner stories? I put it in quotes because I think it would differ greatly depending on the work environment, what kind of level of interaction you have with the customer, etc. Using TDD terms, would we consider SR stories to be Customer or Developer tests? I gather from your insight that they're Customer tests. Finally I agree 100% on not focusing on process. I'm trying to figure out the most effective process given the tools currently available, and will be constantly changing it as more/better tools come along. Although I suppose what I should really be spending my energy on is building the tools that will make all our lives better ;) Pat From papipo at gmail.com Sun Sep 2 06:28:27 2007 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Sun, 2 Sep 2007 12:28:27 +0200 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> Message-ID: <6d2bdda0709020328u383598d8rd19cfc80aa610ecc@mail.gmail.com> I have an articleabout this in my blog, with a controller spec example, testing just behaviour and not the code. Please, comment it and tell me what you think. I guess that with the new Story runner, this approach will be even better. Thanks in advance. -- http://papipo.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070902/cda3e993/attachment.html From dchelimsky at gmail.com Sun Sep 2 10:49:33 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 2 Sep 2007 09:49:33 -0500 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <6d2bdda0709020328u383598d8rd19cfc80aa610ecc@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <6d2bdda0709020328u383598d8rd19cfc80aa610ecc@mail.gmail.com> Message-ID: <57c63afe0709020749u52ca0437h8f594ea02b69e344@mail.gmail.com> On 9/2/07, Rodrigo Alvarez Fern?ndez wrote: > I have an article about this in my blog, with a controller spec example, > testing just behaviour and not the code. Please, comment it and tell me what > you think. I added comments on the blog: http://papipo.blogspot.com/2007/08/bdd-isolation-integration.html > I guess that with the new Story runner, this approach will be > even better. Be careful here - Story Runner is not really intended to solve these lower level problems. Not that it can't be used for that, but it's a lot more heavyweight and better suited for high level scenarios that exercise the code end to end (including the DB). Cheers, David > > Thanks in advance. > > -- > http://papipo.blogspot.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From papipo at gmail.com Sun Sep 2 11:18:36 2007 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Sun, 2 Sep 2007 17:18:36 +0200 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <57c63afe0709020749u52ca0437h8f594ea02b69e344@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <6d2bdda0709020328u383598d8rd19cfc80aa610ecc@mail.gmail.com> <57c63afe0709020749u52ca0437h8f594ea02b69e344@mail.gmail.com> Message-ID: <6d2bdda0709020818q71289f5j971238242e5e5afa@mail.gmail.com> On 9/2/07, David Chelimsky wrote: > > On 9/2/07, Rodrigo Alvarez Fern?ndez wrote: > > I have an article about this in my blog, with a controller spec example, > > testing just behaviour and not the code. Please, comment it and tell me > what > > you think. > > I added comments on the blog: > http://papipo.blogspot.com/2007/08/bdd-isolation-integration.html > > > I guess that with the new Story runner, this approach will be > > even better. > > Be careful here - Story Runner is not really intended to solve these > lower level problems. Not that it can't be used for that, but it's a > lot more heavyweight and better suited for high level scenarios that > exercise the code end to end (including the DB). Yes, I meant as integration tests. Cheers, > David > > > > > Thanks in advance. > > > > -- > > http://papipo.blogspot.com > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- http://papipo.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070902/fc52dc6f/attachment.html From dchelimsky at gmail.com Sun Sep 2 12:43:13 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 2 Sep 2007 11:43:13 -0500 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> Message-ID: <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> On 9/2/07, Pat Maddox wrote: > On 9/2/07, David Chelimsky wrote: > > On 9/2/07, Pat Maddox wrote: > > > On 8/24/07, David Chelimsky wrote: > > > > On 8/24/07, Pat Maddox wrote: > > > > > On 8/24/07, David Chelimsky wrote: > > > > > > describe Widget, "class" do > > > > > > it "should provide a list of widgets sorted alphabetically" do > > > > > > Widget.should_receive(:find).with(:order => "name ASC") > > > > > > Widget.find_alphabetically > > > > > > end > > > > > > end > > > > > > > > > > > > You're correct that the refactoring requires you to change the > > > > > > object-level examples, and that is something that would be nice to > > > > > > avoid. But also keep in mind that in java and C# people refactor > > > > > > things like that all the time without batting an eye, because the > > > > > > tools make it a one-step activity. Refactoring is changing the design > > > > > > of your *system* without changing its behaviour. That doesn't really > > > > > > fly all the way down to the object level 100% of the time. > > > > > > > > > > > > WDYT? > > > > > > > > > > I think that example is fine up until the model spec. The > > > > > find_alphabetically example should hit the db, imo. With the current > > > > > spec there's no way to know whether find_alphabetically actually works > > > > > or not. You're relying on knowledge of ActiveRecord here, trusting > > > > > that the arguments to find are correct. > > > > > > > > Au contrare! This all starts with an Integration Test. I didn't post > > > > the code but I did mention it. > > > > > > > > > What I've found when I write specs is that I discover new layers of > > > > > services until eventually I get to a layer that actually does > > > > > something. When I get there, it's important to have specs that > > > > > describe what it does, not how it does it. In the case of > > > > > find_alphabetically we care that it returns the items in alphabetical > > > > > order. Not that it makes a certain call to the db. > > > > > > > > I play this both ways and haven't come to a preference, but I'm > > > > leaning towards blocking database access from the rspec examples and > > > > only allowing it my end to end tests (using Rails Integration Tests or > > > > - soon - RSpec's new Story Runner). > > > > > > Now that I've had a chance to play with Story Runner, I want to > > > revisit this topic a bit. > > > > > > Let's say in your example you wanted to refactor find_alphabetically > > > to use enumerable's sort_by to do the sorting. > > > > > > def self.find_alphabetically > > > find(:all).sort_by {|w| w.name } > > > end > > > > > > Your model spec will fail, but your integration test will still pass. > > > > > > I've been thinking about this situation a lot over the last few > > > months. It's been entirely theoretical because I haven't had a suite > > > of integration tests ;) Most XP advocates lean heavily on unit tests > > > when doing refactoring. Mocking tends to get in the way of > > > refactoring though. In the example above, we rely on the integration > > > test to give us confidence while refactoring. In fact I would ignore > > > the unit test (model-level spec) altogether, and rewrite it when the > > > refactoring is complete. > > > > > > Here's how I reconcile this with traditional XP unit testing. First > > > of all our integration tests are relatively light weight. In a web > > > app, a user story consists of making a request and verifying the > > > response. Authentication included, you'll be making at most 3-5 HTTP > > > requests per test. This means that our integration tests still run in > > > just a few seconds. Integration tests in a Rails app are a completely > > > different beast from the integration tests in the Chrysler payroll app > > > that Beck, Jeffries, et al worked on. > > > > > > The second point of reconciliation is that mock objects and > > > refactoring are two distinct tools you use to design your code. When > > > I'm writing greenfield code I'll use mocks to drive the design. When > > > I refactor though, I'm following known steps to improve the design of > > > my existing code. The vast majority of the time I will perform a > > > known refactoring, which means I know the steps and the resulting > > > design. In this situation I'll ignore my model specs because they'll > > > blow up, giving me no information other than I changed the design of > > > my code. I can use the integration tests to ensure that I haven't > > > broken any behavior. At this point I would edit the model specs to > > > use the correct mock calls. > > > > > > As I mentioned, this has been something that's been on my mind for a > > > while. I find mock objects to be very useful, but they seem to clash > > > with most of the existing TDD and XP literature. To summarize, here > > > are the points where I think they clash: > > > > > > * Classical TDD relies on unit tests for confidence in refactoring. > > > BDD relies on integration tests > > > * XP acceptance tests are customer tests, whereas RSpec User Stories > > > are programmer tests. They can serve a dual-purpose because you can > > > easily show them to a customer, but they're programmer tests in the > > > sense that the programmer writes and is responsible for those > > > particular tests. > > > > > > In the end it boils down to getting stuff done. After a bit of > > > experimentation I'm thinking that the process of > > > 1. Write a user story > > > 2. Write detailed specs using mocks to drive design > > > 3. Refactor, using stories to ensure that expected behavior is > > > maintained, ignoring detailed specs > > > 4. Retrofit specs with correct mock expectations > > > > > > is a solid approach. I'd like others to weigh in with their thoughts. > > > > Hey Pat, > > > > I really appreciate that you're thinking about and sharing this as its > > something that weighs on a lot of people's minds and it's clear that > > you have some understanding of the XP context in which all of this was > > born. > > > > That said, I see this quite a bit differently. > > > > I don't think this has anything to do w/ TDD vs BDD. "Mock Objects" is > > not a BDD concept. It just feels that way because we talk more about > > interaction testing, but interaction testing predates BDD by some > > years. > > Hi David, > > Thanks so much for your thoughtful reply. Thanks for your thought provoking post! > You're right, and I didn't mean to suggest that mock objects were a > BDD concept at all. However it seems to me that BDDers embrace mock > objects as a very useful design tool, whereas classical TDDers would > use them sparsely, when a resource is expensive or difficult to use > directly. This is true to some extent, but the mock objects paper, which introduced the idea of mocks-as-design-tool (http://mockobjects.com/files/mockrolesnotobjects.pdf) was presented at OOPSLA 04, and the thinking that it came from had already been evolving. > For example, Beck talks about mocking a database in his > book, and that's that. Astels demonstrates mocking the roll of a die. > He does briefly use mocks before he's ready to implement the GUI part > of the app. > > Those are the two TDD books with which I'm most familiar. I'm sure a > lot has changed in the TDD community since then, and indeed you can > see that Astels' mentality has changed somewhat. His "one assertion > per test" article [1] parses an address and then verifies it by > asserting the getters. His remake, "one expectation per example" [2] > is a bit different in that he passes a mocked builder in and uses that > to verify that the parsing code works, exposing no getters at all. > That to me signifies a fundamental shift in TDD thought. Instead of > thinking about objects in isolation and what services they provide, we > think of the services an object provides and how it interacts with > other objects and uses their services. > > I'm certain that it's not a new way of thinking, but hopefully you can > see why I'd believe it's probably not mainstream. > > There's one other roadblock to my thinking, and it results from using > RSpec almost exclusively within Rails projects. I think it's obvious > why you mock models when writing view and controller specs. However > less obvious to me is why mock associations in model specs, and I > think it has to do with the fact that AR couples business and > persistence logic. Absolutely! AR presents quite a testing conundrum. It's clear from the testing approach supported by Rails directly that decoupling from the database is simply not of interested to DHH and company. Or at least it wasn't early on. I see mock frameworks starting to appear in the Rails codebase, so perhaps this is changing. And I don't mean to suggest that the Rails core team approach is the wrong approach. It simply does not align with what you've called "classical TDD thinking". > If we just had domain objects that never hit a database, then we might > initially mock interactions but then use concrete instances when we > later implemented those classes. When I think of Beck's Money > example, or Martin Fowler's video rental list in Refactoring, it seems > silly to me to use mocks in those cases. I think you're right. Even if you're going down what I view as the ideal mockists path - mocking everything that you need that doesn't exist yet - I've often used mocks in process, but replaced them w/ the real deal once the real objects existed. Then you're really using mocks for what they're most powerful at: interface discovery. And then disposing of them once they've passed their usefulness in a given situation. In the case of AR, I keep them around to keep from hitting the DB. > Perhaps you might at the > very beginning, but you'd sub real objects in as you implemented them. D'oh! You ARE an ideal mockist! > We don't do this with AR because they're simply too heavy. Funny - I'm tempted to remove what I wrote above - but this is fun - responding as I go and then discovering that you already made the same point. > This culminates in another general idea I've had which is to mock > services in a lower layer, and use concrete instances for objects in > the same layer when possible. If we were to split AR into domain > objects and a data access layer, the domain objects would mock calls > to the data access layer but use concrete domain objects in the tests. > The unit tests remain fast and simple, and mocks no longer get in the > way of refactoring. Ay, there's the rub. The problem we face is that AR promises huge productivity gains for the non TDD-er, and challenges the thinking of the die-hard TDD-er. I've gone back and forth about whether it's OK to test validations like this: it "should validate_presence_of digits" do PhoneNumber.expects(:validates_presence_of).with(:digits) load "#{RAILS_ROOT}/app/models/phone_number.rb" end On the one hand, it looks immediately like we're testing implementation. On the other, we're not really - we're mocking a call to an API. The confusion is that the API is represented in the same object as the one we're testing (at least its class object). I haven't really done this in anger yet, but I'm starting to think it's the right way to go - especially now that we have Story Runner to cover things end to end. WDYT of this approach? > > Of course then you're writing integration tests at a fairly low level > I guess, but that's 100% acceptable to me in the interest of getting > stuff done rather than being dogmatic. + 1 - in the end this is all about getting stuff done and knowing WHEN you're done. > > The problem we experience with mocks relates to the fact that > > we've chosen to live in the beautiful, free, dynamically typed and > > POORLY TOOLED land of Ruby. When Ruby refactoring tools catch up with > > those of java and .NET, this pain will all go away. > > > > For example - if I'm in IntelliJ in a java project and I have a method > > like this: > > > > model.getName() > > > > and I'm using jmock (the old version), which uses Strings for method names: > > > > model.expects(once()).method("getName").will(returnValue("stub value")) > > > > and I do a Rename Method refactoring on getName(), IntelliJ will ask > > me if I want to change the strings it finds that match getName as well > > as the method invocations. > > > > In Ruby, we do this now w/ search and replace. Not quite as elegant. > > But under the hood, that's all IntelliJ is doing. It just makes it > > feel like an integrated step of an automated refactoring. > > Agreed. I guess for me it's easier to get the production code right > and then fix the tests after the fact. I'd hate to do all the work of > changing the production and test code and then find out it was > incorrect. Fixing tests after fixing the production code amounts to > the same work as doing it all in one step, because as you mentioned > it's essentially a manual process. > > > re: Story Runner. The intent of Story Runner is exactly the same as > > tools like FIT, etc, that are typically found in the Acceptance > > Testing space in XP projects. In my experience using FitNesse, it was > > rare that a customer actually added new tests to a suite. If there > > were testing folks on board, they would do it (and they would likely > > be equipped to do it in Story Runner as well), but if not, then the > > FitNesse tests were at best the result of a collaborative session with > > the customer and, at worst, our (developers), interpretation of > > conversations we had had with the customer. > > > > I see Story Runner fitting in exactly like that in the short run. I > > can also see external DSLs emerging that let customers actually write > > the outputs that Story Runner should produce and run that through a > > process that writes what we're writing now in Story Runner. But that's > > probably some time off. > > > > I totally agree with your last statement that "it boils down to > > getting stuff done." And your approach seems to be the approach that I > > take, given the tools that we have. But I really think its about tools > > and not process. And I think that BDD is a lot more like what really > > experienced TDD'ers do out of the gate. We're just choosing different > > words and structures to make it easier to communicate across roles on > > a team (customer, developer, tester, etc). > > So "ideally," who would write Story Runner stories? I put it in > quotes because I think it would differ greatly depending on the work > environment, what kind of level of interaction you have with the > customer, etc. Using TDD terms, would we consider SR stories to be > Customer or Developer tests? I gather from your insight that they're > Customer tests. Yes - in my view they are Customer Tests - but bear in mind that that means "tests created by the person acting in the customer role." On a team of one, that might be the same person as the developer. > Finally I agree 100% on not focusing on process. I'm trying to figure > out the most effective process given the tools currently available, > and will be constantly changing it as more/better tools come along. > Although I suppose what I should really be spending my energy on is > building the tools that will make all our lives better ;) Patches always welcome! Cheers Pat. David > > Pat > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Sun Sep 2 12:55:27 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 2 Sep 2007 11:55:27 -0500 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> Message-ID: <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> On 9/2/07, Wilson Bilkovich wrote: > On 9/1/07, rupert wrote: > > > > On 1 Sep 2007, at 10:04, Tom Stuart wrote: > > > > > On 1 Sep 2007, at 09:31, rupert wrote: > > >>> Are we planning on dumping the mock framework in favor of using > > >>> Mocha > > >> The idea has been bandied around on the dev list recently > > This decision, if it is made in this manner, is suicide for RSpec. I simply don't understand this statement. Why is this such a big deal? RSpec's mock framework offers pretty much ZERO over mocha or flexmock - the only thing is that it saves you from typing 24 or 27 characters in a config file, depending on your preference. 21 if you use RR. After that, the functionality is pretty much the same as the other frameworks. > I have been a huge RSpec booster, but this will make me drop it like a hot coal. Again - I can't understand where you're coming from here. If you start using test/unit or test/spec or any of the other bdd frameworks you'll still need to make a decision about a mock framework. What is the pain that you're perceiving that will come along w/ us dumping the mock framework? Perhaps there's something we can do to minimize that pain once we know what it is. Cheers, David > =( > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From mailing_lists at railsnewbie.com Sun Sep 2 13:36:47 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Sun, 2 Sep 2007 13:36:47 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> Message-ID: <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> On Sep 2, 2007, at 12:55 PM, David Chelimsky wrote: > On 9/2/07, Wilson Bilkovich wrote: >> On 9/1/07, rupert wrote: >>> >>> On 1 Sep 2007, at 10:04, Tom Stuart wrote: >>> >>>> On 1 Sep 2007, at 09:31, rupert wrote: >>>>>> Are we planning on dumping the mock framework in favor of using >>>>>> Mocha >>>>> The idea has been bandied around on the dev list recently >> >> This decision, if it is made in this manner, is suicide for RSpec. > > I simply don't understand this statement. Why is this such a big deal? > RSpec's mock framework offers pretty much ZERO over mocha or flexmock > - the only thing is that it saves you from typing 24 or 27 characters > in a config file, depending on your preference. 21 if you use RR. > > After that, the functionality is pretty much the same as the other > frameworks I'm a little confused about this discussion. Why don't we just do the following: 1. Hand off the mocking/stubbing framework off to someone else. It will be their project 2. Make the mocking/stubbing framework a dependency of the rspec gem 3. Make it the default (as it is now) 4. Provide clear directions for changing mocking frameworks (as we have now). I thought the end goal with refactoring the mocking framework out was not that we shouldn't be using it, but, that we (David, Aslak, Brian, etc) won't have to maintain it. Or am I missing something? Scott From omen.king at gmail.com Sun Sep 2 14:06:03 2007 From: omen.king at gmail.com (Andrew WC Brown) Date: Sun, 2 Sep 2007 14:06:03 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> Message-ID: I think that makes sense. Which do you recommend? Flexmock or Mocha? On 9/2/07, Scott Taylor wrote: > > > On Sep 2, 2007, at 12:55 PM, David Chelimsky wrote: > > > On 9/2/07, Wilson Bilkovich wrote: > >> On 9/1/07, rupert wrote: > >>> > >>> On 1 Sep 2007, at 10:04, Tom Stuart wrote: > >>> > >>>> On 1 Sep 2007, at 09:31, rupert wrote: > >>>>>> Are we planning on dumping the mock framework in favor of using > >>>>>> Mocha > >>>>> The idea has been bandied around on the dev list recently > >> > >> This decision, if it is made in this manner, is suicide for RSpec. > > > > I simply don't understand this statement. Why is this such a big deal? > > RSpec's mock framework offers pretty much ZERO over mocha or flexmock > > - the only thing is that it saves you from typing 24 or 27 characters > > in a config file, depending on your preference. 21 if you use RR. > > > > After that, the functionality is pretty much the same as the other > > frameworks > > I'm a little confused about this discussion. Why don't we just do > the following: > > 1. Hand off the mocking/stubbing framework off to someone else. It > will be their project > > 2. Make the mocking/stubbing framework a dependency of the rspec gem > > 3. Make it the default (as it is now) > > 4. Provide clear directions for changing mocking frameworks (as we > have now). > > I thought the end goal with refactoring the mocking framework out was > not that we shouldn't be using it, but, that we (David, Aslak, Brian, > etc) won't have to maintain it. Or am I missing something? > > Scott > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Monsterbox Productions putting small businesses on-line 1319 Victoria Avenue East Thunder Bay, Ontario P7C 1C3 Canada Andrew WC Brown web-developer and owner andrew at monsterboxpro.com P: 807-626-9009 F: 807-624-2705 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070902/52de5bc4/attachment.html From dchelimsky at gmail.com Sun Sep 2 16:04:07 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 2 Sep 2007 15:04:07 -0500 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> Message-ID: <57c63afe0709021304p2cfebe6ct5fce254eac1309f9@mail.gmail.com> On 9/2/07, Scott Taylor wrote: > > On Sep 2, 2007, at 12:55 PM, David Chelimsky wrote: > > > On 9/2/07, Wilson Bilkovich wrote: > >> On 9/1/07, rupert wrote: > >>> > >>> On 1 Sep 2007, at 10:04, Tom Stuart wrote: > >>> > >>>> On 1 Sep 2007, at 09:31, rupert wrote: > >>>>>> Are we planning on dumping the mock framework in favor of using > >>>>>> Mocha > >>>>> The idea has been bandied around on the dev list recently > >> > >> This decision, if it is made in this manner, is suicide for RSpec. > > > > I simply don't understand this statement. Why is this such a big deal? > > RSpec's mock framework offers pretty much ZERO over mocha or flexmock > > - the only thing is that it saves you from typing 24 or 27 characters > > in a config file, depending on your preference. 21 if you use RR. > > > > After that, the functionality is pretty much the same as the other > > frameworks > > I'm a little confused about this discussion. Why don't we just do > the following: > > 1. Hand off the mocking/stubbing framework off to someone else. It > will be their project > > 2. Make the mocking/stubbing framework a dependency of the rspec gem > > 3. Make it the default (as it is now) > > 4. Provide clear directions for changing mocking frameworks (as we > have now). > > I thought the end goal with refactoring the mocking framework out was > not that we shouldn't be using it, but, that we (David, Aslak, Brian, > etc) won't have to maintain it. Or am I missing something? Well, it's not simply a matter of US maintaining it. It's a matter of it being maintained at all in light of the fact that mocha and flexmock exist. Put simply, there never should have been an rspec mock framework. But here we are. In my view, we either put the thing to sleep or keep it part of rspec and forget the whole deprecation thing. Handling it off to someone else to maintain seems silly to me. FWIW, David > > Scott > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From lists-rspec at shopwatch.org Sun Sep 2 16:35:17 2007 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 02 Sep 2007 16:35:17 -0400 Subject: [rspec-users] How do you keep mocks updated without pain? In-Reply-To: <85d99afe0708291519t4152d755m3700b024f528a4ac@mail.gmail.com> References: <85d99afe0708291519t4152d755m3700b024f528a4ac@mail.gmail.com> Message-ID: <46DB1E85.8040900@shopwatch.org> On 8/29/2007 6:19 PM, Zach Dennis wrote: > In rspec, controller, model and view specs are just unit tests/specs. And that's really the key; in Rails Test::Unit, model tests are unit tests, and controller tests are higher-level "functional" tests. So you never get to unit-test your controllers. On the other hand, in RSpec through 1.0.8, you never get to integration-test anything at all. But that's all changing! Jay From mailing_lists at railsnewbie.com Sun Sep 2 17:20:49 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Sun, 2 Sep 2007 17:20:49 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <57c63afe0709021304p2cfebe6ct5fce254eac1309f9@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <57c63afe0709021304p2cfebe6ct5fce254eac1309f9@mail.gmail.com> Message-ID: <9924D5AE-5EBA-4992-8892-EEC5FFEDD624@railsnewbie.com> > > Well, it's not simply a matter of US maintaining it. It's a matter of > it being maintained at all in light of the fact that mocha and > flexmock exist. Put simply, there never should have been an rspec mock > framework. > > But here we are. > > In my view, we either put the thing to sleep or keep it part of rspec > and forget the whole deprecation thing. Handling it off to someone > else to maintain seems silly to me. > > FWIW, > David Ah. I had no idea. Why was it originally created, then? Were you guys not happy with mocha at the time? I find it hard to believe that you were ignorant about it. Plus - are you going to change all of rspec's specs to use flexmock or mocha? Scott From mailing_lists at railsnewbie.com Sun Sep 2 17:51:53 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Sun, 2 Sep 2007 17:51:53 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <57c63afe0709021304p2cfebe6ct5fce254eac1309f9@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <57c63afe0709021304p2cfebe6ct5fce254eac1309f9@mail.gmail.com> Message-ID: > > Well, it's not simply a matter of US maintaining it. It's a matter of > it being maintained at all in light of the fact that mocha and > flexmock exist. Put simply, there never should have been an rspec mock > framework. > > But here we are. > > In my view, we either put the thing to sleep or keep it part of rspec > and forget the whole deprecation thing. Handling it off to someone > else to maintain seems silly to me. Just to reiterate on my last point: There are some advantages to keeping the framework - namely that we won't have to convert a lot of specs. But there are other advantages, too. New features are easier for us to implement for ourselves. I've already had some ideas for how the mocking framework could become better (i.e. support for anonymous functions). I think if we keep it, we should be looking to implement some of those advantages that the other mocking frameworks don't have. We also have steam, which I don't think mocha and flexmock have (although I could be wrong about this). I just took a look at flexmock - and must say that I don't like the "partial mock" language, because it is confusing to my brain which distinguishes a stub from a mock. And mocha/stubba has an ugly syntax (In my humble, and inexperienced, opinion). If you did "put the thing [rspec's mocking framework] to sleep" - which would you covert to - Mocha, or Flexmock? Scott From lists-rspec at shopwatch.org Sun Sep 2 18:14:53 2007 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 02 Sep 2007 18:14:53 -0400 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> Message-ID: <46DB35DD.2040701@shopwatch.org> On 9/2/2007 12:43 PM, David Chelimsky wrote: > The problem we face is that AR promises huge productivity gains for > the non TDD-er, and challenges the thinking of the die-hard TDD-er. > > I've gone back and forth about whether it's OK to test validations like this: > > it "should validate_presence_of digits" do > PhoneNumber.expects(:validates_presence_of).with(:digits) > load "#{RAILS_ROOT}/app/models/phone_number.rb" > end > > On the one hand, it looks immediately like we're testing > implementation. On the other, we're not really - we're mocking a call > to an API. The confusion is that the API is represented in the same > object as the one we're testing (at least its class object). I haven't > really done this in anger yet, but I'm starting to think it's the > right way to go - especially now that we have Story Runner to cover > things end to end. WDYT of this approach? Personally, I don't much like it. It feels too much like: it "should validate_presence_of digits" do my_model.line(7).should_read "validates_presence_of :digits" end I can write specs like that all day and ensure absolutely nothing about my code. I like to think of specs as a form of N-version programming where N=2 (or maybe N=3 now with Story Runner). By using a different vocabulary to express the specs than the actual code, we are more likely to think of the problem differently, and thus find places where the two versions of our code differ. Sometimes, it means we miswrote the spec; sometimes, it means we miswrote the code. But if all your spec does is guarantee that your code reads a certain way, you've done nothing but protect against accidental edits. And if you're gonna go that way, why not go all the way: it "shouldn't change unless I change the spec too" do MD5.new(my_model).should == "0xDEADBEEF0FFD2FFE4..." end I'd much rather see: it "should prevent me from entering anything but digits" do PhoneNumber.new("800-MATTRESS").should_not be_valid end And then, every time I find an edge case, I add another spec: it "should allow me to enter dashes" do PhoneNumber.new("800-555-1212").should be_valid end it "should only allow 10 digits" do PhoneNumber.new("800-555-12121212").should_not be_valid end etc. Jay Levitt From dchelimsky at gmail.com Sun Sep 2 23:49:20 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 2 Sep 2007 22:49:20 -0500 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <46DB35DD.2040701@shopwatch.org> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> <46DB35DD.2040701@shopwatch.org> Message-ID: <57c63afe0709022049m36acf1ebqee936361a5c9981c@mail.gmail.com> On 9/2/07, Jay Levitt wrote: > On 9/2/2007 12:43 PM, David Chelimsky wrote: > > The problem we face is that AR promises huge productivity gains for > > the non TDD-er, and challenges the thinking of the die-hard TDD-er. > > > > I've gone back and forth about whether it's OK to test validations like this: > > > > it "should validate_presence_of digits" do > > PhoneNumber.expects(:validates_presence_of).with(:digits) > > load "#{RAILS_ROOT}/app/models/phone_number.rb" > > end > > > > On the one hand, it looks immediately like we're testing > > implementation. On the other, we're not really - we're mocking a call > > to an API. The confusion is that the API is represented in the same > > object as the one we're testing (at least its class object). I haven't > > really done this in anger yet, but I'm starting to think it's the > > right way to go - especially now that we have Story Runner to cover > > things end to end. WDYT of this approach? > > Personally, I don't much like it. It feels too much like: > > it "should validate_presence_of digits" do > my_model.line(7).should_read "validates_presence_of :digits" > end > > I can write specs like that all day and ensure absolutely nothing about > my code. > > I like to think of specs as a form of N-version programming where N=2 > (or maybe N=3 now with Story Runner). By using a different vocabulary > to express the specs than the actual code, we are more likely to think > of the problem differently, and thus find places where the two versions > of our code differ. Sometimes, it means we miswrote the spec; > sometimes, it means we miswrote the code. > > But if all your spec does is guarantee that your code reads a certain > way, you've done nothing but protect against accidental edits. And if > you're gonna go that way, why not go all the way: > > it "shouldn't change unless I change the spec too" do > MD5.new(my_model).should == "0xDEADBEEF0FFD2FFE4..." > end > > I'd much rather see: > > it "should prevent me from entering anything but digits" do > PhoneNumber.new("800-MATTRESS").should_not be_valid > end > > And then, every time I find an edge case, I add another spec: > > it "should allow me to enter dashes" do > PhoneNumber.new("800-555-1212").should be_valid > end > > it "should only allow 10 digits" do > PhoneNumber.new("800-555-12121212").should_not be_valid > end A couple of things to consider: There's a very useful guideline in TDD that says "test YOUR code, not everyone elses." The validation library we're testing here is ActiveRecord's. It's already tested (we hope!). Also - there's a difference between the behaviour of a system and the behaviour of an object. The system's job is to validate that the phone number is all digits. So it makes sense to have examples like that in high level examples using Story Runner, rails integration tests, or an in-browser suite like Selenium or Watir. This model object's job is to make sure the input gets validated, not to actually validate it. If the model made a more OO-feeling call out to a message library - something like this: class PhoneNumber def validators @validators ||= [] end def add_validator (validator) validators << validator end def validate(input) validators.each {|v| v.validate (input)} end end Then submitting mock validators via add_validator and setting mock expectations that they get called would be totally par for the course. In AR, the validators are added declaratively. This is a Rails design decision that we have to either live with or write other code around. Choosing to live with it, it seems to me that mocking the call to validates_presence_of :digits is no different than mocking validate on an injected validator. That all make sense? > > etc. > > > Jay Levitt > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From zach.dennis at gmail.com Mon Sep 3 00:08:57 2007 From: zach.dennis at gmail.com (Zach Dennis) Date: Mon, 3 Sep 2007 00:08:57 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> Message-ID: <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> On 9/2/07, Andrew WC Brown wrote: > I think that makes sense. > > Which do you recommend? Flexmock or Mocha? > I wouldn't recommend either of them by themselves, at least the current way they sit. Jim Weirich may be adding globally ordered strict mocks, which if he does then I think Flexmock will be the first mocking library in ruby to cover all mocking needs (as far as I know). Mocha (and RSpec mocks too) don't support globally strict ordered mocks. Hardmock is another mocking library which is just strict mocking (no stubs, no partial mocks). Right now I prefer Mocha + Hardmock, but I'm eagerly awaiting to see if Flexmock gets globally strict ordered mocks. Zach Dennis http://www.continuousthinking.com From pergesu at gmail.com Mon Sep 3 01:43:10 2007 From: pergesu at gmail.com (Pat Maddox) Date: Sun, 2 Sep 2007 22:43:10 -0700 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <57c63afe0709022049m36acf1ebqee936361a5c9981c@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> <46DB35DD.2040701@shopwatch.org> <57c63afe0709022049m36acf1ebqee936361a5c9981c@mail.gmail.com> Message-ID: <810a540e0709022243n39ee7a13t5501f58b5cafa848@mail.gmail.com> On 9/2/07, David Chelimsky wrote: > On 9/2/07, Jay Levitt wrote: > > On 9/2/2007 12:43 PM, David Chelimsky wrote: > > > The problem we face is that AR promises huge productivity gains for > > > the non TDD-er, and challenges the thinking of the die-hard TDD-er. > > > > > > I've gone back and forth about whether it's OK to test validations like this: > > > > > > it "should validate_presence_of digits" do > > > PhoneNumber.expects(:validates_presence_of).with(:digits) > > > load "#{RAILS_ROOT}/app/models/phone_number.rb" > > > end > > > > > > On the one hand, it looks immediately like we're testing > > > implementation. On the other, we're not really - we're mocking a call > > > to an API. The confusion is that the API is represented in the same > > > object as the one we're testing (at least its class object). I haven't > > > really done this in anger yet, but I'm starting to think it's the > > > right way to go - especially now that we have Story Runner to cover > > > things end to end. WDYT of this approach? > > > > Personally, I don't much like it. It feels too much like: > > > > it "should validate_presence_of digits" do > > my_model.line(7).should_read "validates_presence_of :digits" > > end > > > > I can write specs like that all day and ensure absolutely nothing about > > my code. > > > > I like to think of specs as a form of N-version programming where N=2 > > (or maybe N=3 now with Story Runner). By using a different vocabulary > > to express the specs than the actual code, we are more likely to think > > of the problem differently, and thus find places where the two versions > > of our code differ. Sometimes, it means we miswrote the spec; > > sometimes, it means we miswrote the code. > > > > But if all your spec does is guarantee that your code reads a certain > > way, you've done nothing but protect against accidental edits. And if > > you're gonna go that way, why not go all the way: > > > > it "shouldn't change unless I change the spec too" do > > MD5.new(my_model).should == "0xDEADBEEF0FFD2FFE4..." > > end > > > > I'd much rather see: > > > > it "should prevent me from entering anything but digits" do > > PhoneNumber.new("800-MATTRESS").should_not be_valid > > end > > > > And then, every time I find an edge case, I add another spec: > > > > it "should allow me to enter dashes" do > > PhoneNumber.new("800-555-1212").should be_valid > > end > > > > it "should only allow 10 digits" do > > PhoneNumber.new("800-555-12121212").should_not be_valid > > end > > A couple of things to consider: > > There's a very useful guideline in TDD that says "test YOUR code, not > everyone elses." The validation library we're testing here is > ActiveRecord's. It's already tested (we hope!). > > Also - there's a difference between the behaviour of a system and the > behaviour of an object. The system's job is to validate that the phone > number is all digits. So it makes sense to have examples like that in > high level examples using Story Runner, rails integration tests, or an > in-browser suite like Selenium or Watir. > > This model object's job is to make sure the input gets validated, not > to actually validate it. If the model made a more OO-feeling call out > to a message library - something like this: > > class PhoneNumber > def validators > @validators ||= [] > end > > def add_validator (validator) > validators << validator > end > > def validate(input) > validators.each {|v| v.validate (input)} > end > end > > Then submitting mock validators via add_validator and setting mock > expectations that they get called would be totally par for the course. > > In AR, the validators are added declaratively. This is a Rails design > decision that we have to either live with or write other code around. > Choosing to live with it, it seems to me that mocking the call to > validates_presence_of :digits is no different than mocking validate on > an injected validator. > > That all make sense? There's nothing technically *wrong* with it, and logically it holds weight. It just doesn't feel right. Your key point is that we're making an API call, which I agree with. We also agree that AR probably does too much, and I think this is a situation where we should go with the flow. We call my_record.valid? and end up with my_record.errors if it's not valid. An AR object is in fact responsible for its own validation (even if you feel it's too much responsibility). It makes sense to specify the object's behavior in the same way. Personally I can't find a strong argument either way. I'm sure it's a matter of taste here. I would prefer to look at a spec and get as much info on how to use an object as possible. In that case, creating an object, calling valid?, and inspecting errors is probably more helpful. But after giving this a lot of thought, I'm not sure it warrants a ton of thought :) Pat From dchelimsky at gmail.com Mon Sep 3 01:53:42 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 3 Sep 2007 00:53:42 -0500 Subject: [rspec-users] blog post on story runner Message-ID: <57c63afe0709022253x15a3b07ev19168560a1636990@mail.gmail.com> Here's an excellent blog post on Story Runner, which will be part of the next release and is undergoing active development in trunk: http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner From pergesu at gmail.com Mon Sep 3 02:29:24 2007 From: pergesu at gmail.com (Pat Maddox) Date: Sun, 2 Sep 2007 23:29:24 -0700 Subject: [rspec-users] blog post on story runner In-Reply-To: <57c63afe0709022253x15a3b07ev19168560a1636990@mail.gmail.com> References: <57c63afe0709022253x15a3b07ev19168560a1636990@mail.gmail.com> Message-ID: <810a540e0709022329i470f66ebrcae5652c53ba35a4@mail.gmail.com> On 9/2/07, David Chelimsky wrote: > Here's an excellent blog post on Story Runner, which will be part of > the next release and is undergoing active development in trunk: > > http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > I've updated it to include the output from the integration test and Story Runner. Pat From peter_marklund at fastmail.fm Mon Sep 3 03:07:59 2007 From: peter_marklund at fastmail.fm (Peter Marklund) Date: Mon, 3 Sep 2007 09:07:59 +0200 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <57c63afe0709022049m36acf1ebqee936361a5c9981c@mail.gmail.com> References: <12309322.post@talk.nabble.com> <57c63afe0708240659y1ea3668qc2065333f199a7bb@mail.gmail.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> <46DB35DD.2040701@shopwatch.org> <57c63afe0709022049m36acf1ebqee936361a5c9981c@mail.gmail.com> Message-ID: <83B5CE48-0AFC-414D-8609-1E7FAAA35EDC@fastmail.fm> > There's a very useful guideline in TDD that says "test YOUR code, not > everyone elses." The validation library we're testing here is > ActiveRecord's. It's already tested (we hope!). Personally, I don't have the courage to assume Rails code is always working. I know from experience it doesn't always work although it is quite solid in general. The Rails code has been tested but not in conjunction with my particular apps. I also want to test my assumptions of how the Rails API works, maybe it doesn't work as I think. Having tests/specs that cover Rails interaction with my app, which higher level tests of course naturally do (system/integration tests), gives me much more courage to upgrade Rails as well. Peter From pergesu at gmail.com Mon Sep 3 03:48:02 2007 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 3 Sep 2007 00:48:02 -0700 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <83B5CE48-0AFC-414D-8609-1E7FAAA35EDC@fastmail.fm> References: <12309322.post@talk.nabble.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> <46DB35DD.2040701@shopwatch.org> <57c63afe0709022049m36acf1ebqee936361a5c9981c@mail.gmail.com> <83B5CE48-0AFC-414D-8609-1E7FAAA35EDC@fastmail.fm> Message-ID: <810a540e0709030048s162c9ecbqc1d731011e1bf8ac@mail.gmail.com> On 9/3/07, Peter Marklund wrote: > > There's a very useful guideline in TDD that says "test YOUR code, not > > everyone elses." The validation library we're testing here is > > ActiveRecord's. It's already tested (we hope!). > > Personally, I don't have the courage to assume Rails code is always > working. I know from experience it doesn't always work although it is > quite solid in general. The Rails code has been tested but not in > conjunction with my particular apps. I also want to test my > assumptions of how the Rails API works, maybe it doesn't work as I > think. Having tests/specs that cover Rails interaction with my app, > which higher level tests of course naturally do (system/integration > tests), gives me much more courage to upgrade Rails as well. > > Peter That's a good point. Having specs in place that demonstrate how you expect the code to behave will alert when a newer version of Rails behaves a bit differently. Granted, in the validates_presence_of example that probably won't be an issue, but you get the idea. I think it was Kevin Clark who said it's a good idea to learn Ruby by writing specs...then whenever you upgrade Ruby or install new libraries, your spec suite will make it clear when your assumptions about the language need to change. Pat From mailing_lists at railsnewbie.com Mon Sep 3 03:59:28 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Mon, 3 Sep 2007 03:59:28 -0400 Subject: [rspec-users] testing behaviour or testing code? In-Reply-To: <810a540e0709030048s162c9ecbqc1d731011e1bf8ac@mail.gmail.com> References: <12309322.post@talk.nabble.com> <810a540e0708241006m23118ed7k9248705c13c2678a@mail.gmail.com> <57c63afe0708241012o6c5bf76bib536656bf69ee323@mail.gmail.com> <810a540e0709012345t5aba354ai6f2f7414fe5a5ea@mail.gmail.com> <57c63afe0709020056y26081df7labe53761f20fa90a@mail.gmail.com> <810a540e0709020232g1a8bc555h129dbbbc0be5d6a7@mail.gmail.com> <57c63afe0709020943o1a9e4783x65390eb7ad44c87a@mail.gmail.com> <46DB35DD.2040701@shopwatch.org> <57c63afe0709022049m36acf1ebqee936361a5c9981c@mail.gmail.com> <83B5CE48-0AFC-414D-8609-1E7FAAA35EDC@fastmail.fm> <810a540e0709030048s162c9ecbqc1d731011e1bf8ac@mail.gmail.com> Message-ID: <2403B620-59D3-4B78-9583-EB1B0E5ECFFD@railsnewbie.com> On Sep 3, 2007, at 3:48 AM, Pat Maddox wrote: > On 9/3/07, Peter Marklund wrote: >>> There's a very useful guideline in TDD that says "test YOUR code, >>> not >>> everyone elses." The validation library we're testing here is >>> ActiveRecord's. It's already tested (we hope!). >> >> Personally, I don't have the courage to assume Rails code is always >> working. I know from experience it doesn't always work although it is >> quite solid in general. I think there are also a lot of leaky abstractions when it comes to rails code. It's tempting to think that rails is just doing a bunch of stuff automatically for you (and it is) - but there are edge cases, and unless you know *exactly* what rails is doing under the cover, testing the behaviour seems to be a good idea. I've already run into one bug in the last week (when doing something rather dynamic in a model class) which I wouldn't have expected. Scott From papipo at gmail.com Mon Sep 3 05:19:35 2007 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Mon, 3 Sep 2007 11:19:35 +0200 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> Message-ID: <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> I would like to know if the mock framework will be deprecated, since I have a pair of feature requests, and I don't know where to request them: 1) Alternative expectations: mock.should_receive(:save). and_return(false). or_receive(:save!). and_raise(ActiveRecord::RecordNotSaved) 2) Chained stubs/expectations mock.stub!(:valid?).and_return(false) mock.stub!(:valid?).and_return(true).after_receiving(:save).and_return(true) I'm sure that this needs no more explanation :) On 9/3/07, Zach Dennis wrote: > On 9/2/07, Andrew WC Brown wrote: > > I think that makes sense. > > > > Which do you recommend? Flexmock or Mocha? > > > > I wouldn't recommend either of them by themselves, at least the > current way they sit. > > Jim Weirich may be adding globally ordered strict mocks, which if he > does then I think Flexmock will be the first mocking library in ruby > to cover all mocking needs (as far as I know). > > Mocha (and RSpec mocks too) don't support globally strict ordered > mocks. Hardmock is another mocking library which is just strict > mocking (no stubs, no partial mocks). Right now I prefer Mocha + > Hardmock, but I'm eagerly awaiting to see if Flexmock gets globally > strict ordered mocks. > > Zach Dennis > http://www.continuousthinking.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- http://papipo.blogspot.com From peter_marklund at fastmail.fm Mon Sep 3 05:41:08 2007 From: peter_marklund at fastmail.fm (Peter Marklund) Date: Mon, 3 Sep 2007 11:41:08 +0200 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> Message-ID: <8C3C084F-3BFE-4BEC-A5ED-0F3EBA82F222@fastmail.fm> > 2) Chained stubs/expectations > > mock.stub!(:valid?).and_return(false) > mock.stub!(:valid?).and_return(true).after_receiving > (:save).and_return(true) On first look, that last line is pretty hard to read. I think I understand the intention now, but I'm not sure it harmonizes with the "Clarity over Cleverness" motto. Peter From papipo at gmail.com Mon Sep 3 05:45:53 2007 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Mon, 3 Sep 2007 11:45:53 +0200 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <8C3C084F-3BFE-4BEC-A5ED-0F3EBA82F222@fastmail.fm> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> <8C3C084F-3BFE-4BEC-A5ED-0F3EBA82F222@fastmail.fm> Message-ID: <6d2bdda0709030245j7315e4eak58d59260ad25eddf@mail.gmail.com> On 9/3/07, Peter Marklund wrote: > > 2) Chained stubs/expectations > > > > mock.stub!(:valid?).and_return(false) > > mock.stub!(:valid?).and_return(true).after_receiving > > (:save).and_return(true) > > On first look, that last line is pretty hard to read. I think I > understand the intention now, but I'm not sure it harmonizes with the > "Clarity over Cleverness" motto. > I understand that there are maybe too many method calls there, but it would be a nice feature. Another approach could be using blocks: mock.stub?(:save).and_return(true) do |saved_mock| saved_mock.stub!(:valid?).and_return(true) end WDYT? -- http://papipo.blogspot.com From pergesu at gmail.com Mon Sep 3 06:01:36 2007 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 3 Sep 2007 03:01:36 -0700 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <6d2bdda0709030245j7315e4eak58d59260ad25eddf@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> <8C3C084F-3BFE-4BEC-A5ED-0F3EBA82F222@fastmail.fm> <6d2bdda0709030245j7315e4eak58d59260ad25eddf@mail.gmail.com> Message-ID: <810a540e0709030301l71ecd577l37f3a201296ea53d@mail.gmail.com> On 9/3/07, Rodrigo Alvarez Fern?ndez wrote: > On 9/3/07, Peter Marklund wrote: > > > 2) Chained stubs/expectations > > > > > > mock.stub!(:valid?).and_return(false) > > > mock.stub!(:valid?).and_return(true).after_receiving > > > (:save).and_return(true) > > > > On first look, that last line is pretty hard to read. I think I > > understand the intention now, but I'm not sure it harmonizes with the > > "Clarity over Cleverness" motto. > > > I understand that there are maybe too many method calls there, but it > would be a nice feature. > > Another approach could be using blocks: > > mock.stub?(:save).and_return(true) do |saved_mock| > saved_mock.stub!(:valid?).and_return(true) > end > > WDYT? This seems kind of funky. If an AR object can be saved then it's going to be valid anyway. In other words my_object.valid? # false my_object.save # true my_object.valid? # true is a super weird sequence. What context is this in? At first glance (i.e. with no context) I don't think that's a good use for mocks. You're introducing behavior and state into the mock ("when save is called, change my valid state to true") which is getting a bit clever and mixing concerns imo. The mocks created via the framework should be pretty stupid and just respond how you want them to. If you do need some actual behavior then I suggest you code up another object that behaves as you need. However as I said that's just a strange sequence anyway, which suggests that maybe your design is a bit off. Pat From papipo at gmail.com Mon Sep 3 06:04:50 2007 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Mon, 3 Sep 2007 12:04:50 +0200 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <810a540e0709030301l71ecd577l37f3a201296ea53d@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> <8C3C084F-3BFE-4BEC-A5ED-0F3EBA82F222@fastmail.fm> <6d2bdda0709030245j7315e4eak58d59260ad25eddf@mail.gmail.com> <810a540e0709030301l71ecd577l37f3a201296ea53d@mail.gmail.com> Message-ID: <6d2bdda0709030304v65c43ce6xd648b40770416f6@mail.gmail.com> On 9/3/07, Pat Maddox wrote: > On 9/3/07, Rodrigo Alvarez Fern?ndez wrote: > > On 9/3/07, Peter Marklund wrote: > > > > 2) Chained stubs/expectations > > > > > > > > mock.stub!(:valid?).and_return(false) > > > > mock.stub!(:valid?).and_return(true).after_receiving > > > > (:save).and_return(true) > > > > > > On first look, that last line is pretty hard to read. I think I > > > understand the intention now, but I'm not sure it harmonizes with the > > > "Clarity over Cleverness" motto. > > > > > I understand that there are maybe too many method calls there, but it > > would be a nice feature. > > > > Another approach could be using blocks: > > > > mock.stub?(:save).and_return(true) do |saved_mock| > > saved_mock.stub!(:valid?).and_return(true) > > end > > > > WDYT? > > This seems kind of funky. If an AR object can be saved then it's > going to be valid anyway. In other words > > my_object.valid? # false > my_object.save # true > my_object.valid? # true > > is a super weird sequence. What context is this in? Ok, I meant new_record? instead of valid? ;-) I think that now it makes sense, doesn't it? > > At first glance (i.e. with no context) I don't think that's a good use > for mocks. You're introducing behavior and state into the mock ("when > save is called, change my valid state to true") which is getting a bit > clever and mixing concerns imo. The mocks created via the framework > should be pretty stupid and just respond how you want them to. If you > do need some actual behavior then I suggest you code up another object > that behaves as you need. > > However as I said that's just a strange sequence anyway, which > suggests that maybe your design is a bit off. > > Pat > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- http://papipo.blogspot.com From mailing_lists at railsnewbie.com Mon Sep 3 06:28:28 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Mon, 3 Sep 2007 06:28:28 -0400 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> Message-ID: <1A8C5D26-889A-4904-877E-EFAAA79B3014@railsnewbie.com> On Sep 3, 2007, at 5:19 AM, Rodrigo Alvarez Fern?ndez wrote: > I would like to know if the mock framework will be deprecated, since I > have a pair of feature requests, and I don't know where to request > them: > > 1) Alternative expectations: > > mock.should_receive(:save). > and_return(false). > or_receive(:save!). > and_raise(ActiveRecord::RecordNotSaved) > > 2) Chained stubs/expectations > > mock.stub!(:valid?).and_return(false) > mock.stub!(:valid?).and_return(true).after_receiving > (:save).and_return(true) > > I'm sure that this needs no more explanation :) Or we could do as flexmock does (and which I find much more readable): mock.stub!("method1.method2.method3").and_return(true) Scott From papipo at gmail.com Mon Sep 3 07:12:21 2007 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Mon, 3 Sep 2007 13:12:21 +0200 Subject: [rspec-users] Deprecating the mocking framework? In-Reply-To: <1A8C5D26-889A-4904-877E-EFAAA79B3014@railsnewbie.com> References: <810a540e0708311617r7a85a9d8wf013add5f3647f10@mail.gmail.com> <9918842A-2A10-4620-9A07-8B0E3E465126@experthuman.com> <6E64948B-5A57-49D3-9F76-48FBF9864F56@rupespad.com> <57c63afe0709020955u4d63d43fha984929a7a0c93b2@mail.gmail.com> <26853B78-59DA-4EE7-83DE-68D5C3400AD1@railsnewbie.com> <85d99afe0709022108s33017e53k1ff49aa80b253fd2@mail.gmail.com> <6d2bdda0709030219s658dae1dv4dddae6747185606@mail.gmail.com> <1A8C5D26-889A-4904-877E-EFAAA79B3014@railsnewbie.com> Message-ID: <6d2bdda0709030412x7e72aed9u3085485a091b40a3@mail.gmail.com> On 9/3/07, Scott Taylor wrote: > > On Sep 3, 2007, at 5:19 AM, Rodrigo Alvarez Fern?ndez wrote: > > > I would like to know if the mock framework will be deprecated, since I > > have a pair of feature requests, and I don't know where to request > > them: > > > > 1) Alternative expectations: > > > > mock.should_receive(:save). > > and_return(false). > > or_receive(:save!). > > and_raise(ActiveRecord::RecordNotSaved) > > > > 2) Chained stubs/expectations > > > > mock.stub!(:valid?).and_return(false) > > mock.stub!(:valid?).and_return(true).after_receiving > > (:save).and_return(true) > > Maybe this can be accomplished with ordered stubs. rSpec mocks support only ordered expectations, doesn't it? > > I'm sure that this needs no more explanation :) > > Or we could do as flexmock does (and which I find much more readable): > > mock.stub!("method1.method2.method3").and_return(true) > > Scott > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- http://papipo.blogspot.com From work at ashleymoran.me.uk Mon Sep 3 07:59:10 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Mon, 3 Sep 2007 12:59:10 +0100 Subject: [rspec-users] Reason for _spec.rb convention Message-ID: <32F9D508-B834-4DE6-8560-A4059CA4767E@ashleymoran.me.uk> Hi Easy one - I just wondered why all spec files for rspec_on_rails end "_spec.rb" instead of just ".rb"? They are all inside the spec folder so surely the fact they are specs is implicit? Ashley From win at wincent.com Mon Sep 3 08:47:56 2007 From: win at wincent.com (Wincent Colaiuta) Date: Mon, 3 Sep 2007 14:47:56 +0200 Subject: [rspec-users] Reason for _spec.rb convention In-Reply-To: <32F9D508-B834-4DE6-8560-A4059CA4767E@ashleymoran.me.uk> References: <32F9D508-B834-4DE6-8560-A4059CA4767E@ashleymoran.me.uk> Message-ID: El 3/9/2007, a las 13:59, Ashley Moran escribi?: > Hi > > Easy one - I just wondered why all spec files for rspec_on_rails end > "_spec.rb" instead of just ".rb"? They are all inside the spec > folder so surely the fact they are specs is implicit? > > Ashley I know it's very application-specific, but one good reason for this is that it makes finding files in TextMate much easier when you hit Command-T; you type a few characters and at a glance can distinguish between sp