On Tue, Mar 4, 2008 at 8:13 AM, David Chelimsky <[EMAIL PROTECTED]> wrote: > On Tue, Mar 4, 2008 at 7:13 AM, Matthijs Langenberg > <[EMAIL PROTECTED]> wrote: > > I really would like to know how people are using the Story and Example > > runner to write their software. > > It would be great to get some direction on it, because I think I'm missing > > some points. > > > > Taking the outside-in approach in thought: > > > > At first we write a high-level customer-facing story, this story fails. > > Then we start using mocks at object level to use them as a design tool, > > and so we implement the different layers of the system. > > After implementing the inner layer, the story should pass. > > When that happens we could remove the mocks and replace it with calls to > the > > real code, > > I do this sometimes - removing the mocks - as long as the objects are > trivial to set up and they don't have dependencies that I don't want > to expose. There's no one way to do this, and I'll sometimes remove > mocks and reintroduce them over the life of a project. > > > > making the suite less brittle > > What brittle means is a bit subjective here. Just a lengthy > conversation about this in irc last night. The guy with whom I was > chatting prefers to not use mocks because he'd rather see a change > cause a bunch of lower level examples to fail than stories. From what > I can tell, he doesn't like to use mocks even temporarily, in process. > > His approach has the benefit that you learn about side effects of your > changes faster, and the cost that it means you sometimes have more > "red bar" to wade through while you get things right. > > My approach has the benefit that you can address side effects of your > changes with a green bar helping you know that the smaller bits > (objects and methods) are functioning, and the cost that you sometimes > don't learn about side effects until you run your stories (or > integration suite). > > Neither solution is perfect. You just have to pick your poison. > > > > (except for calls to external > > services/databases/file systems). > > This is a funny thing about ruby, specifically rails. > > One of the hallmarks of OO is a high level of decoupling - especially > decoupling your code from 3rd party code through adapters. There are a > couple of reasons for this. > > One is that having an adapter lets you write exactly the code that you > want to write throughout most of your system, rather than being > subject to the naming conventions of the 3rd party library that might > clash with those in your system or even with your domain. > > The other is that if you decide to switch to a different library, > you're pretty well hosed unless you have adapters. If you look at the > competitors to ActiveRecord, like Og and Datamapper, they are all VERY > similar syntactically. Why? Two reasons I think. One is that AR got a > lot of things right from a domain perspective. The other is that calls > to AR internals have leaked out to a lot of controllers and even > views: > > Person.find(:all, :conditions => ['active = ?', true]) > > In spite of guidelines all over the web that say that this should be > wrapped in a #find_active method in the model, these sorts of things > pop up all over the place anyhow.
Finishing up that thought - find_active is an adapter - just at the method level instead of the object level. > > So if the story passes all acceptance tests, why is there a need for > > examples at a lower level? > > So that you can get things working one step at a time, and then change > things as needed one step at a time, with green bars keeping you sane, > stress free, and even happy all the way through. > > HTH, > David > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
