Thanks for all the feedback. Personally, i am working outside in, from views to models, so mocking does have its place. After lots of trialing, I am confident now that a Factory class can satisfy my need for using mocks and real models in different places. I define the characteristics of an intended model in the factory and ask it to return either a mock_model or a real one depending on my specific need. Once I've used in anger, I'll mail details of my implementation and experiences.
Although I have played with story runner, I have yet to decide how I'll fit that into my development process. In fact, I love story runner, it's just I am not sure how much time I can afford to assign to tests on client work whilst I am still getting up to speed. As a note, I recently wrote a functional spec document for a client using the Given, When, Then approach for each use case, and the client loved it! It is a very clear way if writing specs. Andy On 8 Dec 2007, at 02:40, "David Chelimsky" <[EMAIL PROTECTED]> wrote: > On Dec 7, 2007 8:30 PM, Priit Tamboom <[EMAIL PROTECTED]> wrote: >> Hi! >> >>>> This is handy and keeps the view test isolated from changes to your >>>> models, but is that really the point? >> >> I was very confused first as well. It didn't make any point to me and >> I'm not using it at all. As far as I know, I take it as an optional >> tool to go nuts with views when needed. I will use it when some stuff >> in view becomes super important to be there. However as an one-band >> project I haven't feel this need yet. >> >> Second thing is about how you like to develop your stuff. As far as I >> know David start with Story -> Views -> controller -> model. I prefer >> to go this way: Story -> model/controller -> views. So now you might >> guess why specing views are nice thing when you go David's way >> up-to-down. >> >> Anyhow, mocking in controllers (and in views) makes much more sense >> now with story runner in the big picture. General stuff 'does it work >> at all' goes to story runner and specific low level stuff goes to >> spec. So it's up to you if you care about low level stuff in views. >> >> One thing what I still don't like so much is that rspec "force" you >> to >> develop things super vertically or otherwise your mocks will be out >> of >> sync very quickly. Correct me if I'm wrong !!! > > RSpec doesn't force you to anything at all. However, the agile > approach tends to be vertical slices in short iterations. Working > outside-in, using mocks, etc all ties in with that thinking. > > But rspec is certainly not going to throw errors at you if you decide > to write your entire model layer first. > >> >> Oki, >> Priit >> >> PS. somehow autotest does not pick up stories to run. I haven't yet >> investigate it why. > > This is by design. Autotest supports the TDD process - rapid > iterations of red/green/refactor. Having them run your stories too > would slow things down considerably. > >> >> _______________________________________________ >> 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 mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
