Ashley Moran wrote:

I like to view it as a sliding scale...

Pure mock specs                             Pure integration specs
 |--------------------------------------------------------------|
Lead more directly to good OOP          Allow rapid hack-solutions

I think I need to sit down some time and think through more formal strategies to choose when to use mocks.

There's a third alternative: Your sliding scale is really a pyramid with a peak.

The third alternative is you never _need_ to mock, yet both your tests and target code are highly decoupled. _That_ is the goal.

Under TDD, you get that by avoiding a design smell called "expensive setup". Your scale assumes that something actually must be set up - either mocks, or end-to-end class models. The best tests only need a few stubbed objects, each easy to construct.

You avoid the design smell by writing the simplest new test you can think of, and writing simple code to pass the test. And if you don't want that code to be so simplistic, you practice "triangulation".

Triangulation occurs when you have a big bowl of spaghetti, a meatball under it, and two chopsticks. You want to lift the meatball out, so you probe with one chopstick until you feel it, then you probe with the other until you can seize it. The two chopsticks now form a triangle, locating the meatball.

The spaghetti is the design you don't want. The meatball is the design you want. Each chopstick is a simple test, and the angle between the chopsticks represents the _difference_ between the two tests. If each test is simple yet is set up differently, then the simplest code which can pass both simple tests approaches the most elegant design.

Mock abuse just enables runaway dependencies.

--
  Phlip

_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to