Comments on: (Inglês) Explicit intent http://rafanoronha.net/explicit-intent/ closing the gap between business and technology Sat, 10 Jul 2010 16:09:20 -0300 http://wordpress.org/?v=2.8.4 hourly 1 By: rafanoronha http://rafanoronha.net/explicit-intent/comment-page-1/#comment-1493 rafanoronha Mon, 21 Sep 2009 19:37:52 +0000 http://rafanoronha.net/?p=649#comment-1493 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. 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.

]]> By: Patrick Reagan http://rafanoronha.net/explicit-intent/comment-page-1/#comment-1492 Patrick Reagan Mon, 21 Sep 2009 19:03:07 +0000 http://rafanoronha.net/?p=649#comment-1492 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: <code> 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 </code> 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. 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.

]]>