Rafael Noronha

(Inglês) Explicit intent

with 2 comments

2 Responses to '(Inglês) Explicit intent'

Subscribe to comments with RSS or TrackBack to '(Inglês) Explicit intent'.

1. Rafael –

   I don’t think that your suggested refactoring provides the clarity that you were looking for in the original sample you provided. After the refactoring, we’re still left with the original issue – by encapsulating the order’s total inside the helper method it is hidden from each of the specs. I think a better approach would be to just create a more meaningful describe block and embed the setup code there instead of bothering with a separate method as a label for your setup state. After all, that’s what before blocks are for.

   In keeping with the theme of explicit intent, I tweaked your example so that I could provide a meaningful setup state in each of the specs:

   
describe CreditcardPayment do

   def initialize_payment_for_completed_order(order_options)
   total = options[:total]
   payment_total = options[:payment_total]

   order = Order.new
   order.checkout_complete = true
   order.stub!(:total).and_return(total)
   order.stub!(:payment_total).and_return(payment_total)

   payment = CreditcardPayment.new(:order => order)

   payment, order
   end

   describe "when saving" do
   it "should mark the order as paid if payment_total = total" do
   payment, order = initialize_payment_for_completed_order(:total => 100, :payment_total => 100)
   order.should_receive(:pay!)

   payment.save
   end

   it "should mark order as paid if payment_total > total" do
   payment, order = initialize_payment_for_completed_order(:total => 100, :payment_total => 101)
   order.should_recieve(:pay!)

   payment.save
   end

   it "should not mark order as paid if payment_total 100, :payment_total => 99)
   order.should_not_receive(:pay!)

   payment.save
   end
   end

   end


   I’ts the difference in :total and :payment_total that are important in each of these specs, so they should remain where they present the most clarity. I still don’t really like this, but I think the awkwardness of the return values from my helper method hint at a design problem (which is what specs are for!). I would refactor the implementation code to have the Order delegate to the CreditcardPayment class, and then have Order interrogate its associated payments and manage its own state.

   Patrick Reagan

   21 Sep 09 at 16:03
2. Patrick,

   Thx for your reply.
   Your code seems pretty good, you hid the mockering noise in a nice way.

   Despite the provided sample, my purpose was to talk about the importance of clarifying intent while we are writing code.

   And it seems that, like me, you take this technique seriously.

   rafanoronha

   21 Sep 09 at 16:37

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website