I prefer the mantra "mock roles, not objects", in other words, mock things that have behaviour (services, components, resources, whatever your preferred term is) rather than stubbing out domain objects themselves. If you have to mock domain objects it's usually a smell that your domain implementation is too tightly coupled to some infrastructure.
The rails community is the first place I've encountered stubbing domain objects as a norm (and in fact as an encouraged "best practice"). It seems to be a consequence of how tightly coupled the model classes are to the database. I don't use rails in anger, and in the other technologies and frameworks I use (in Java, .Net or Ruby) I never mock the domain model. It seems unwieldy and overly verbose to me to have to stub properties on a model class. I usually use a builder pattern: cheese = CheeseBuilder.to_cheese # with suitable default values for testing The builder has lots of methods that start "with_" and return the builder instance, so you can train-wreck the properties: another_cheese = CheeseBuilder.with_type (:edam).with_flavour(:mild).to_cheese toastie = ToastieBuilder.with_cheese(cheese).to_toastie # composing domain objects In applications with a database, I then have a very thin suite of low level integration tests that use "real" domain objects, wired up to a real database to verify the behaviour at that level. Of course this is both slow and highly dependent on infrastructure, so I am careful to keep the integration examples separate from the interaction-based ones that I can isolate. Maybe it's the way rails encourages you to write apps - where it's mostly about getting data from a screen to a database and back again - that people are more tolerant of such highly-coupled tests. For myself, I use builders for domain objects and mocks for service dependencies whenever I can, and have a minimal suite of integration tests that require everything to be wired together. Using fixtures and database setup for regular behavioural examples smacks of data-oriented programming to me, and stubbing domain objects feels like solving the wrong problem. Cheers, Dan On Dec 8, 2007 9:20 AM, Andy Goundry <[EMAIL PROTECTED]> wrote: > 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 >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
