David's comments on integration testing is right on. The trick with mocks is to understand when to use them, and what advantages they give you.
Mocks allow you to test the expected interaction between the object you are testing an some other object. This works great in TDD because while you're implementing an object, the object(s) it interacts with doesn't have to exist. You can create them as you need them. What mocks fail to do is test the true interaction of real objects. And that is because they are not intended to do so. They are intended to allow you to achieve a better level of unit testing. If I am testing ObjectA I want to know it works as expected. I don't care about ObjectB, ObjectC or ObjectD in my tests for ObjectA. So integration tests give you the ability to test real objects together. Integration tests are usually at a much higher level (not as detailed as unit tests) and they verify that you can step through your application as expected. If someone renames a database column and they do not update the tests then an integration test will catch it (if a unit test doesn't)l. And after seeing it fail you are reminded that you need to go update your tests for that change. In rspec, controller, model and view specs are just unit tests/specs. Google around for mocks and stubs. I don't think Martin Fowler's page on "Mocks aren't stubs" is a very clear form of explaining mocks, so I'm not going to recommend it with a link. If you happen to read it then that is a plus, but if you're just starting out with mocks it may not be the best starter resource. HTH, Zach Dennis http://www.continuousthinking.com http://www.atomicobject.com On 8/28/07, Priit Tamboom <[EMAIL PROTECTED]> wrote: > Hi! > > I know you must be answering a lot of basic questions, sorry about that :-) > > However I have not get it, how do you keep mocks updated without pain? > > I reached to the point where mocking things for view. I spec > model-controller-view using "correct doc" way mocking-stubbing (plus I > should run integration test to be sure that everything really works > together). > > Now, when I want to change something in model then basically I have to > change mocks so many places, haven't I? It really feels a little too > messy for me as nuby rspecer. Or it's just my worry and you have to be > so good that you don't have to change things too much after specing > them? If so then I know that I should think much more when mocking(== > designing) things. > > When I googled about this topic I have found similar worries out there > and I got two solutions, where David [1] suggest to write integration > tests (what should indicate that mocks are outdated) and Ryan [2] > suggest to fall bact to fixtures. > > I feel I will fall back to fixtures, so no more designing fun with > mocks but things feels more lightweight and practical :-) Or perhaps > it's more up to project size and conditions... I don't know yet. > > Oki, > [EMAIL PROTECTED] > > [1] http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial > "Now the risk here is that you could build a model that doesn't have a > title field in it and your app will blow up! Admittedly, if you only > write isolated, granular specs like this that risk is real. So you > should be doing this in conjunction with integration testing." > > [2] http://railsforum.com/viewtopic.php?id=6528 > "I took the past few hours and removed nearly all mocks from my specs. > I also merged the controller and view specs into one using > "integrate_views" in the controller spec. I am also loading all > fixtures for each controller spec so there's some test data to fill > the views. > > The end result? My specs are shorter, simpler, more consistent, less > rigid, and they test the entire stack together (model, view, > controller) so no bugs can slip through the cracks. > > I'm not saying this is the "right" way for everyone. If your project > requires a very strict spec case then it may not be for you, but in my > case this is worlds better than what I had before using mocks. I still > think stubbing is a good solution in a few spots so I'm still doing > that." > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
