On Tue, Jul 15, 2008 at 4:59 AM, Piotr Wlodarek <[EMAIL PROTECTED]> wrote: > At first it seems obvious: one should specify behaviour, not > implementation. > > However, there may be a tremendous overhead and duplication with such > approach. > > Let's assume: > > def a > # lot's of business logic > end > > deb b > # lot's of business logic > end > > def main > a > b > end > > Assuming we do have specs for methods a and b, how the main method > should be specified? > > 1) Full behaviour specification > Problem: it duplicates specification of a and b > > 2) Specify that main should call a, then b > Problem: it specifies implementation, NOT behaviour > > > So, what is the right way?
The right way is to write examples of behaviour BEFORE you write the code so you don't end up with two methods with "lots of business logic" :) If you're writing examples first, then you'd have examples for :main and, as :main grew in complexity, :a and :b would be extracted from :main. If :a and :b are methods intended to be part of the public interface of the class, then perhaps they belong on another object, in which case setting message expectations on a mock is perfectly acceptable for examples of :main. HTH, David _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
