I’m trying to spec a system from outside-in as an excercise in ‘emergent design’ – and so far I love it; it made me think about the design for two days before I even wrote the first spec… :)
My most-outside class seems to be a prime candidate for an #each method. The attached (stripped) spec carrying two of the approaches I came up with passes, and raises the following quesitions – any answer would be most appreciated! 1. A philosophical/kosherness question: In the finished system Decomposer#each will yield Decomposition objects, but as I’m specing from outside-in, the Decomposition class is not yet created. In the attached example I’m using an Array as a poor man’s Decomposition replacement. Is this a sane approach, or should I rather create a skeletal Decomposition#initialize instead? 2. The first spec shows my initial approach, with a variable polling the stuff yielded by #each and then validating its contents, but it seems clumsy… 3. …so I came up with the second, Decomposer.new.to_enum approach, which simply validates the enumrator’s #next objects. Unfortunately, this does not seem to trigger #should_receive(:each) on the *_gen mocks and made me #stub!(:each) on them instead. Is this because I’m using RSpec 1.1.12 with Ruby 1.9.1, or am I missing something on how message expectations work with lazy iterators (and, thus, #should_receive fail properly)? 4. Is there any better or more elegant way to spec an #each (or #next) method? — Shot -- uoıʇɔnɹʇsuoɔ ɹəpun
decomposer_spec.rb
Description: application/ruby
signature.asc
Description: Digital signature
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
