Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
Dear Nathan, What you are sayiing is correct, and in terms of Ruby on Rails, BDD _IS_ View Driven development... or at least it should be IMHO. At the end of the day, the only thing that matters in a Rails App is the Behaviour shown to the user, who has as their only interface, the View. The user can not and should not interact with any models. The user MIGHT interact with a controller... (say, having a file download which doesn't get sent through a view), but really... views ARE the behaviour of a Rails App. I found the same thing as you... started with spec'ing my models, doing great, getting to controllers.. doing OK... getting to views and going Where did I go wrong? Starting with views and working backwards from a Test::Unit point of view has definately opened up a lot of RSpec doors for me. My $0.02. Mikel On 7/29/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/29/07, Nathan Sutton [EMAIL PROTECTED] wrote: I want to do View-Driven-Development by Behavior-Driven-Development, but I'm stumped really where to begin. Ideally I'd like to see a tutorial or something that walks though it, or browse through some projects using RSpec for the views, but I can't seem to find any. Maybe I'm not looking hard enough or I don't know where to look. http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: Dear Nathan, What you are sayiing is correct, and in terms of Ruby on Rails, BDD _IS_ View Driven development... or at least it should be IMHO. At the end of the day, the only thing that matters in a Rails App is the Behaviour shown to the user, who has as their only interface, the View. The user can not and should not interact with any models. The user MIGHT interact with a controller... (say, having a file download which doesn't get sent through a view), but really... views ARE the behaviour of a Rails App. I found the same thing as you... started with spec'ing my models, doing great, getting to controllers.. doing OK... getting to views and going Where did I go wrong? Starting with views and working backwards from a Test::Unit point of view has definately opened up a lot of RSpec doors for me. My $0.02. Mikel I think one thing that would make view first development a really powerful tool with rspec is a way to keep track of erroneous calls to model methods. One thing that I am consistently worried about is specing a method in one place via mocks, a la the view, but forgetting to include that method in the model. The way I get around this at the moment, is when I find a method that I want to have that isn't there yet, I open up the spec for the model and add an it should have method bla so that it shows up in the pending report. Of course this means that I have to have the model spec all setup in the first place kind of defeating the purpose of view first. Well almost. If the view is generated via an rspec generator then all that is setup. What would be fantastic is if mock had an option to report calls to non-existent methods. Something like mock( User, :report_pending_methods = :true ) Is there another way to do this that is already in practice? Cheers Daniel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
I find myself doing the same thing... the, open the model and type in the it shoulds... I ws thinking along the same line... probably all that would be needed is a rake task that hooks into the Mock class and runs all the specs taking not of all the stubs and mocks method calls that are made. Then it could PRODUCE the it shoulds... @model = mock_model(People, :id = 1, :name = Bob) @model.should_receive(:alive?).and_return(true) # rake spec:find_fakes produces: describe People automatically do it should have a name it should respond to alive? end Now... that would be cool Regards Mikel On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: Dear Nathan, What you are sayiing is correct, and in terms of Ruby on Rails, BDD _IS_ View Driven development... or at least it should be IMHO. At the end of the day, the only thing that matters in a Rails App is the Behaviour shown to the user, who has as their only interface, the View. The user can not and should not interact with any models. The user MIGHT interact with a controller... (say, having a file download which doesn't get sent through a view), but really... views ARE the behaviour of a Rails App. I found the same thing as you... started with spec'ing my models, doing great, getting to controllers.. doing OK... getting to views and going Where did I go wrong? Starting with views and working backwards from a Test::Unit point of view has definately opened up a lot of RSpec doors for me. My $0.02. Mikel I think one thing that would make view first development a really powerful tool with rspec is a way to keep track of erroneous calls to model methods. One thing that I am consistently worried about is specing a method in one place via mocks, a la the view, but forgetting to include that method in the model. The way I get around this at the moment, is when I find a method that I want to have that isn't there yet, I open up the spec for the model and add an it should have method bla so that it shows up in the pending report. Of course this means that I have to have the model spec all setup in the first place kind of defeating the purpose of view first. Well almost. If the view is generated via an rspec generator then all that is setup. What would be fantastic is if mock had an option to report calls to non-existent methods. Something like mock( User, :report_pending_methods = :true ) Is there another way to do this that is already in practice? Cheers Daniel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: I find myself doing the same thing... the, open the model and type in the it shoulds... I ws thinking along the same line... probably all that would be needed is a rake task that hooks into the Mock class and runs all the specs taking not of all the stubs and mocks method calls that are made. Then it could PRODUCE the it shoulds... @model = mock_model(People, :id = 1, :name = Bob) @model.should_receive(:alive?).and_return(true) # rake spec:find_fakes produces: describe People automatically do it should have a name it should respond to alive? end Now... that would be cool I would tend to disagree. RSpec is a Behaviour Driven Development tool. The idea is that you write a small example of behaviour FIRST, and use that example to drive the implementation. The reason you use examples to drive implementation comes from the idea in Test Driven Development that it will lead to tighter, more focused and more flexible implementations. If your examples come after the code, whether they are generated or you write them yourself, then you are losing out quite a bit of value of the process with which RSpec is aligned. Secondly, having a name is not behaviour. Using it might be. Or how you set it might be. For example: describe Thing do it should use the first initializer argument as its name do Thing.new(João).name.should == João end it should be alive when first created do Thing.new.should be_alive end end Implicit in these examples are the fact that Thing has a name and responds to alive?, but those are just artifacts in support of the behaviour. That all make sense? In a fairly abstract way. But how do you keep track of what methods have been stubbed or mocked? From the above Thing.new.alive? will need to be defined. This seems to be the spec for Thing, but if in a view I said it should do_stuff if @thing is alive do @thing = mock_model( Thing ) @thing.stub!( :alive? ).and_return( true ) controller.should_receive( :do_stuff ) do_get end How do I run the view first without Thing, If you're using mock_model and the constant Thing, then you have to create Thing to get that example to run. Admittedly, having to create that model class is a distraction from the flow, but it is a very small distraction that has never really bothered me that much. I imagine that we could tweak mock_model to accept a String, or perhaps somebody with stronger TextMate chops than mine could submit a patch to the TextMate bundle that would let you click on Thing and create a Thing model. and also keep track of alive? being decalred on the Thing instance? This is something that has come up on this list and in RFEs a few times. The most promising idea is to have a command line switch that would look at any mock that was passed a class name and ensure that the class responds to any mocked or stubbed methods. But even that would fall apart as soon as you start using any metaprogramming techniques to change the nature of an object at runtime. For me, the answer to keeping track of mocked methods is automated end-to-end tests. Either in browser, or something like Rails' integration tests (assuming Rails), or (soon) rbehave's story runner (which is now being integrated into rspec). Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: I find myself doing the same thing... the, open the model and type in the it shoulds... I ws thinking along the same line... probably all that would be needed is a rake task that hooks into the Mock class and runs all the specs taking not of all the stubs and mocks method calls that are made. Then it could PRODUCE the it shoulds... @model = mock_model(People, :id = 1, :name = Bob) @model.should_receive(:alive?).and_return(true) # rake spec:find_fakes produces: describe People automatically do it should have a name it should respond to alive? end Now... that would be cool I would tend to disagree. RSpec is a Behaviour Driven Development tool. The idea is that you write a small example of behaviour FIRST, and use that example to drive the implementation. The reason you use examples to drive implementation comes from the idea in Test Driven Development that it will lead to tighter, more focused and more flexible implementations. If your examples come after the code, whether they are generated or you write them yourself, then you are losing out quite a bit of value of the process with which RSpec is aligned. Secondly, having a name is not behaviour. Using it might be. Or how you set it might be. For example: describe Thing do it should use the first initializer argument as its name do Thing.new(João).name.should == João end it should be alive when first created do Thing.new.should be_alive end end Implicit in these examples are the fact that Thing has a name and responds to alive?, but those are just artifacts in support of the behaviour. That all make sense? In a fairly abstract way. But how do you keep track of what methods have been stubbed or mocked? From the above Thing.new.alive? will need to be defined. This seems to be the spec for Thing, but if in a view I said it should do_stuff if @thing is alive do @thing = mock_model( Thing ) @thing.stub!( :alive? ).and_return( true ) controller.should_receive( :do_stuff ) do_get end How do I run the view first without Thing, If you're using mock_model and the constant Thing, then you have to create Thing to get that example to run. Admittedly, having to create that model class is a distraction from the flow, but it is a very small distraction that has never really bothered me that much. I imagine that we could tweak mock_model to accept a String, or perhaps somebody with stronger TextMate chops than mine could submit a patch to the TextMate bundle that would let you click on Thing and create a Thing model. and also keep track of alive? being decalred on the Thing instance? This is something that has come up on this list and in RFEs a few times. The most promising idea is to have a command line switch that would look at any mock that was passed a class name and ensure that the class responds to any mocked or stubbed methods. But even that would fall apart as soon as you start using any metaprogramming techniques to change the nature of an object at runtime. David, Is it not possible to check if a mocked model actually responds to a method call at the point of it being called? Then capture any that aren't on the original object and print out warnings similar to the pending notices? Please excuse my ignorance. I'm sure I've oversimplified this dramatically. ;) -Daniel For me, the answer to keeping track of mocked methods is automated end-to-end tests. Either in browser, or something like Rails' integration tests (assuming Rails), or (soon) rbehave's story runner (which is now being integrated into rspec). Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Daniel N [EMAIL PROTECTED] wrote: On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: I find myself doing the same thing... the, open the model and type in the it shoulds... I ws thinking along the same line... probably all that would be needed is a rake task that hooks into the Mock class and runs all the specs taking not of all the stubs and mocks method calls that are made. Then it could PRODUCE the it shoulds... @model = mock_model(People, :id = 1, :name = Bob) @model.should_receive(:alive?).and_return(true) # rake spec:find_fakes produces: describe People automatically do it should have a name it should respond to alive? end Now... that would be cool I would tend to disagree. RSpec is a Behaviour Driven Development tool. The idea is that you write a small example of behaviour FIRST, and use that example to drive the implementation. The reason you use examples to drive implementation comes from the idea in Test Driven Development that it will lead to tighter, more focused and more flexible implementations. If your examples come after the code, whether they are generated or you write them yourself, then you are losing out quite a bit of value of the process with which RSpec is aligned. Secondly, having a name is not behaviour. Using it might be. Or how you set it might be. For example: describe Thing do it should use the first initializer argument as its name do Thing.new(João).name.should == João end it should be alive when first created do Thing.new.should be_alive end end Implicit in these examples are the fact that Thing has a name and responds to alive?, but those are just artifacts in support of the behaviour. That all make sense? In a fairly abstract way. But how do you keep track of what methods have been stubbed or mocked? From the above Thing.new.alive? will need to be defined. This seems to be the spec for Thing, but if in a view I said it should do_stuff if @thing is alive do @thing = mock_model( Thing ) @thing.stub!( :alive? ).and_return( true ) controller.should_receive( :do_stuff ) do_get end How do I run the view first without Thing, If you're using mock_model and the constant Thing, then you have to create Thing to get that example to run. Admittedly, having to create that model class is a distraction from the flow, but it is a very small distraction that has never really bothered me that much. I imagine that we could tweak mock_model to accept a String, or perhaps somebody with stronger TextMate chops than mine could submit a patch to the TextMate bundle that would let you click on Thing and create a Thing model. and also keep track of alive? being decalred on the Thing instance? This is something that has come up on this list and in RFEs a few times. The most promising idea is to have a command line switch that would look at any mock that was passed a class name and ensure that the class responds to any mocked or stubbed methods. But even that would fall apart as soon as you start using any metaprogramming techniques to change the nature of an object at runtime. David, Is it not possible to check if a mocked model actually responds to a method call at the point of it being called? Then capture any that aren't on the original object and print out warnings similar to the pending notices? Please excuse my ignorance. I'm sure I've oversimplified this dramatically. Actually, that doesn't sound ignorant at all. I was thinking about it differently. Wanna take a crack at a patch? Here's the relevant RFE: http://rubyforge.org/tracker/index.php?func=detailaid=5064group_id=797atid=3152 Sure I'll try. I am not at all familiar with Rspec internals though. This is specific to the mocking framework, and should work for any application (rails or not), so you should be able to just focus on that part of the system. ;) -Daniel For me, the answer to keeping track of mocked methods is automated end-to-end tests. Either in browser, or something like Rails' integration tests (assuming Rails), or (soon) rbehave's story runner (which is now being integrated into rspec).
Re: [rspec-users] Stubbing Observers in rails?
On 7/30/07, Doug Cole [EMAIL PROTECTED] wrote: In most of my tests I'd like to be able to stub out the observers for my models, but I'm not sure the best way to do this. I doesn't look like there is a way to stub all instance methods, and I don't seem to be able to stub early enough to stub out the observer as it's instantiated. I can think of several hackish ways to get around it, but I was wondering if anyone could suggest a good solution? Thanks! If you're looking to stub all instances, why not use (what) Rails (calls) mocks? ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec
I tend to work in small, complete vertical slices rather than completing one layer at a time. So rather than doing the whole view first, I'd do one small aspect of it and then push right down to the controller action that supports that aspect of it, then push down to the model, then back up to the next little bit starting from the view. Hmm... great discussion! The way you are talking sounds, actually, like the right way to do it in RSpec... vertical slices That way you are integrating (somewhat) at the same time as describing the behaviour of each layer on the way down. So, really, from one point in the view, you might have four or five vertical slices described on the way down... and that would tend to integrate itself somewhat through the process. Food for thought :) Regards Mikel On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: I would tend to disagree. RSpec is a Behaviour Driven Development tool. The idea is that you write a small example of behaviour FIRST, and use that example to drive the implementation. The reason you use examples to drive implementation comes from the idea in Test Driven Development that it will lead to tighter, more focused and more flexible implementations. That all make sense? Yes, that makes sense. But I am thinking more of on the side of having the situation where you are spec'ing Thing and Thing has to call People or interact with people tracking those interactions and the interfaces used would be something needed... Because those interfaces are the tool we use to get the behaviour out of People. In the present (unless I am missing something) the cycle of action goes something like: I spec out the behaviours of a view (say it is the dashboard on 37signals). This view has a lot of interactions with other Classes.. all over the place. But right _now_ I am doing the view, so I mock out all of the other classes and just focus in on the View that I am working on. Good... all specs pass, the page looks presentable... now what? Well... go code up the controller responsible for the view. That's a no brainer, for the view's controller But then what is the best practice from here for all the other models it talks to? Walk through the view spec line by line finding each mock'd model and taking each one and coding the spec and then the code...? (sounds awfully unDRY ... as, really, you have already specified a behaviour for the model by stubbing or mocking it out) That's an interesting perspective, but I'm not sure that I agree with it. Let's say, for example, that in the view we show one thing if a model is valid, but another if a model is not valid. Not terribly far fetched. Have we specified what it means to be valid? Absolutely not! If anything, what has been specified is a thin picture of an API, just the method names that should be supported. I don't think that is behaviour. Surely this is a good task for a computer which is good at doing the very repetative and manual action of Go find me all the behaviours specified out for this class that other classes need so that they can work. Assuming you went ahead and cleaned up all those views, what is the best way to know you didn't miss a class call? Or am I really just missing the point and all of this is what comes under the umbrella of integration testing? I tend to work in small, complete vertical slices rather than completing one layer at a time. So rather than doing the whole view first, I'd do one small aspect of it and then push right down to the controller action that supports that aspect of it, then push down to the model, then back up to the next little bit starting from the view. And yes, this is all much more sane if you're doing integration testing as well. Automated integration testing, that is - ultimately, running the app in production IS integration testing - but we'd prefer to avoid catching the things we missed in that particular framework. Having said all of the above, I am finding Rails RSpec has totally changed the way I think about coding and designing code... it is wonderful... Glad to hear it. Cheers, David Regards Mikel On 7/30/07, David Chelimsky [EMAIL PROTECTED] wrote: On 7/30/07, Mikel Lindsaar [EMAIL PROTECTED] wrote: I find myself doing the same thing... the, open the model and type in the it shoulds... I ws thinking along the same line... probably all that would be needed is a rake task that hooks into the Mock class and runs all the specs taking not of all the stubs and mocks method calls that are made. Then it could PRODUCE the it shoulds... @model = mock_model(People, :id = 1, :name = Bob) @model.should_receive(:alive?).and_return(true) # rake spec:find_fakes produces: describe
[rspec-users] Any liberally-licensed open source projects out there that make good use of RSpec?
I'm trolling for example RSpec code. Any pointers appreciated. Cheers, Obie ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Any liberally-licensed open source projects out there that make good use of RSpec?
Caboose Sample app --- Courtenay On Jul 30, 2007, at 7:48 PM, Obie Fernandez [EMAIL PROTECTED] wrote: I'm trolling for example RSpec code. Any pointers appreciated. Cheers, Obie ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] helper spec not finding rails core helpers
Hi, My helper specs were going ok until I added a call to a rails DateHelper method in one of my helpers http://api.rubyonrails.com/classes/ActionView/Helpers/ DateHelper.html#M000574 The helper runs fine from my view templates, just dies in the spec test. I boiled my question down to a simple (not too useful) example. I'm not sure what I'm missing. # application_helper.rb module ApplicationHelper def app_foo t = Time.now distance_of_time_in_words( t, t + 50.minutes) return true end end # application_helper_spec.rb require File.dirname(__FILE__) + '/../spec_helper' describe ApplicationHelper do it should find app_foo in application_helpers.rb do app_foo.should be_true end end # error output NoMethodError in 'ApplicationHelper should find app_foo in application_helpers.rb' undefined method `distance_of_time_in_words' for [Dynamically generated class for RSpec example]:#Class:0x32d11c8 ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
