Re: [rspec-users] client first, top down, outside in, etc with rails
Another approach to what Pat mentioned is would be to use a presenter approach. We use presenters to encapsulate view logic and they often hide (or delegate) functionality to one or more models based on the UI component you're focusing on. This route doesn't muck up your models with things that may come in the future. When they do come you can refactor your presenter to delegate to your model, when and if your model is the object that is going to do the job. Right now it's all view implementation anyways and the way we use presenters encapsulate the requirements of the view. Here's some info on how we use presenters: http://spin.atomicobject.com/2008/01/27/the-exceptional-presenter/ The way we use presenter's is different then Jay Fields, so if you think you know what a presenter is and how to use them based on Jay Fields talks or blogs, then you should really read the above as its a different take on presenters with different goals in mind. Zach On Jan 29, 2008 1:34 AM, Pat Maddox [EMAIL PROTECTED] wrote: On Jan 28, 2008 3:24 PM, Jay Donnell [EMAIL PROTECTED] wrote: I guess I can use dummy methods in my models that simply return some canned result. Maybe even name it 'my_method_dummy' so I can easily track down the dummy methods. The stubbing syntax is so clean In rspec that I was hoping I could define a bunch of mocks in a single place, environment.rb maybe, and be able to easily glance to see what is still being mocked. We also have different people working on the views vs the models and would like for the views to progress separately from the models. We can do this by spec'ing the views in isolation but it would be nice to see the views integrated into a functioning page as well. hrm...well if you want it all in one place, I'd stick it in some mocked_methods.rb file and require that. You can open the classes you want there User.class_eval do def full_name Johnny Tsunami end end That way it's easy to see where they all are. You really don't need to introduce RSpec dependencies into your production code. Just define methods on the class you want, or use OpenStruct and return canned values, or write your own simple stub class. If I was doing this a bunch (I never would, of course :) then I might write a macro that defines these stubs for me and includes some diagnostic info, like a logger.warn(*** dude this is a stubbed method ***) and maybe the caller information as well. Then I could just do User.stub_method(:full_name, Johnny Tsunami) Going that route would let you collect info about how many times they're called, blah blah blah. Or you could just implement your code :) Pat ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -- Zach Dennis http://www.continuousthinking.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] client first, top down, outside in, etc with rails
I'm starting a new project and I want to try writing the client first. I.e. I want to write my 'views' first and I would like to mock out all the models in such a way that I can run the site and browse it with the mocked out models. Is it easy to use rspec's mocking for this sort of thing and has anyone done it before? Does anyone know of a tutorial out there for doing something like this? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] client first, top down, outside in, etc with rails
awesome Nathan Sutton [EMAIL PROTECTED] rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 28, 2008, at 5:24 PM, Jay Donnell wrote: I apologize, I oversimplified for the sake of brevity. We have most of the models written but there are some pieces than aren't and won't be written in the near future. I wanted to mock them out in some form so we can implement those portions of the views. Things like certain features of the sidebar, etc. I don't want to make place holder methods in the actual models because they will be worked on at some point and I want the views to continue working until those pieces are complete. I guess I can use dummy methods in my models that simply return some canned result. Maybe even name it 'my_method_dummy' so I can easily track down the dummy methods. The stubbing syntax is so clean In rspec that I was hoping I could define a bunch of mocks in a single place, environment.rb maybe, and be able to easily glance to see what is still being mocked. We also have different people working on the views vs the models and would like for the views to progress separately from the models. We can do this by spec'ing the views in isolation but it would be nice to see the views integrated into a functioning page as well. you end up doing a lot of dev work before you find out if the feature you've built is acceptable (that's where stories come in as well, defining acceptance criteria). I've used my approach with success using flex and web services. I created web services that returned canned data and developed the UI in flex before developing the back-end. I feel this methods works well and lead to less dev work because we didn't implement models only to find out that we didn't really want it to work that way. We fleshed out the way we wanted the site to work with a functioning front-end before doing the heavy dev work on the back-end. jay That's not really what mocks are for. Mocks are a testing tool that help you discover the interactions between objects in your code. ... It would probably be a bad idea to implement the site backed by mocks, because you end up going top-down instead of outside-in. There's a big difference. Top-down is implementing a layer for the entire application, then moving to the layer it depends on, all the way down until the app runs. The problem with that is that the feedback loop is very wide, both in a development and business sense. In a development sense, you don't really know that your app works until you type that final character that brings the whole thing together. In a business sense, you end up doing a lot of dev work before you find out if the feature you've built is acceptable (that's where stories come in as well, defining acceptance criteria). Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ 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] client first, top down, outside in, etc with rails
I apologize, I oversimplified for the sake of brevity. We have most of the models written but there are some pieces than aren't and won't be written in the near future. I wanted to mock them out in some form so we can implement those portions of the views. Things like certain features of the sidebar, etc. I don't want to make place holder methods in the actual models because they will be worked on at some point and I want the views to continue working until those pieces are complete. I guess I can use dummy methods in my models that simply return some canned result. Maybe even name it 'my_method_dummy' so I can easily track down the dummy methods. The stubbing syntax is so clean In rspec that I was hoping I could define a bunch of mocks in a single place, environment.rb maybe, and be able to easily glance to see what is still being mocked. We also have different people working on the views vs the models and would like for the views to progress separately from the models. We can do this by spec'ing the views in isolation but it would be nice to see the views integrated into a functioning page as well. you end up doing a lot of dev work before you find out if the feature you've built is acceptable (that's where stories come in as well, defining acceptance criteria). I've used my approach with success using flex and web services. I created web services that returned canned data and developed the UI in flex before developing the back-end. I feel this methods works well and lead to less dev work because we didn't implement models only to find out that we didn't really want it to work that way. We fleshed out the way we wanted the site to work with a functioning front-end before doing the heavy dev work on the back-end. jay That's not really what mocks are for. Mocks are a testing tool that help you discover the interactions between objects in your code. ... It would probably be a bad idea to implement the site backed by mocks, because you end up going top-down instead of outside-in. There's a big difference. Top-down is implementing a layer for the entire application, then moving to the layer it depends on, all the way down until the app runs. The problem with that is that the feedback loop is very wide, both in a development and business sense. In a development sense, you don't really know that your app works until you type that final character that brings the whole thing together. In a business sense, you end up doing a lot of dev work before you find out if the feature you've built is acceptable (that's where stories come in as well, defining acceptance criteria). Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] client first, top down, outside in, etc with rails
On Jan 28, 2008 12:01 PM, Jay Donnell [EMAIL PROTECTED] wrote: I'm starting a new project and I want to try writing the client first. I.e. I want to write my 'views' first and I would like to mock out all the models in such a way that I can run the site and browse it with the mocked out models. Is it easy to use rspec's mocking for this sort of thing and has anyone done it before? Does anyone know of a tutorial out there for doing something like this? That's not really what mocks are for. Mocks are a testing tool that help you discover the interactions between objects in your code. I'd say the best way is to develop in small iterations. Write a story that represents a very small, but useful bit of functionality. Implement it, going outside-in, and then when the story is completed you've got something. Then work on the next story. It would probably be a bad idea to implement the site backed by mocks, because you end up going top-down instead of outside-in. There's a big difference. Top-down is implementing a layer for the entire application, then moving to the layer it depends on, all the way down until the app runs. The problem with that is that the feedback loop is very wide, both in a development and business sense. In a development sense, you don't really know that your app works until you type that final character that brings the whole thing together. In a business sense, you end up doing a lot of dev work before you find out if the feature you've built is acceptable (that's where stories come in as well, defining acceptance criteria). It *is* a good idea to sometimes work on the interaction flow before writing a bunch of Rails code, but that should really be done with plain HTML wireframes, no application coding. Pat ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] client first, top down, outside in, etc with rails
sorry about that, I have no idea how that happened. It looked fine in yahoo mail before I sent it :/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
