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. > 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
