Hello RSpec mailing list,
I have a question which I’m sure someone here has a “duh!” answer to. 
A lot of the Ruby programming I do is around installing servers and
automating various tasks. The pattern I use goes as follows, I’m sure
you’ll see where the gap is.
Write a failing test. Write enough Ruby code to make it pass. Continue
until I have a class (or set of classes) that solve my problem. So far,
so good.
I then need to put this code into a script so I can run it as part of
everyday automation. My approach so far has been to take green-light
code and plug it into the script so that when the script gets run, it
takes the arguments to the scripts and passes it to my tested code. The
script runs and does what its supposed to do; all is well.
Now – there’s a bug in my code somewhere, or I need to add something to
the code I’ve written to improve it. No problem initially. First, run
all tests. Green light, good. Write a failing test. Write enough Ruby
code to make it pass. Happy, happy.
Problem: the code in my script is not fixed! Running my spec suite does
not catch the fact that there’s client code in my script using bad code.
So, my question is: how can I make sure that when I run my spec suite
that all the code in my scripts gets tested as well? I thought about
adding “–test” option to all my scripts, but that seems, well…just
not the right way to do it.
Anyone have any words of wisdom they’d like to share? Have I walked into
an antipattern here?
Thanks much!
Sebastian
On Tue, Mar 3, 2009 at 11:35 PM, Sebastian W. [email protected]
wrote:
Problem: the code in my script is not fixed! Running my spec suite does
not catch the fact that there’s client code in my script using bad code.
So, my question is: how can I make sure that when I run my spec suite
that all the code in my scripts gets tested as well? I thought about
adding “–test” option to all my scripts, but that seems, well…just
not the right way to do it.
Anyone have any words of wisdom they’d like to share? Have I walked into
an antipattern here?
BDD means (among other things) driving development from the
outside-in. It sounds like you’re working in the opposite direction
here.
The approach we’d take with RSpec and Cucumber, would be to write
Cucumber features with scenarios that drive the scripts, and then work
your way down to RSpec code examples that drive the smaller bits.
In case this is new to you, the Cucumber scenarios will fail until you
get all of the RSpec code examples to pass. If you get to the point
where all of the scenarios are passing, but you feel like you want to
drive out more code in the underlying objects, take a step back and
think of a new failing scenario you can add to the Cucumber features
first.
This approach should help you refine the work you’re doing on the
objects, as well as build confidence that deploying the scripts will
work.
HTH,
David
Hi David,
I think I see what you’re saying, but I admit I’m still a bit confused.
Maybe I’m missing something here, but I can’t think of how I would drive
the scripts (even through Cucumber) without actually invoking them, thus
kicking off processes that I don’t want.
Real code to illustrate my thought process:
#test.rb
class Test
def test
true
end
end
#test_spec.rb
describe Test
it “should test”
Test.new.test.should be(true)
end
end
#my_script_using_test.rb
require ‘test’
Test.new.test
Even if I invoke my “script” through Cucumber, it’s still going to fire,
no? I think perhaps I am just missing the point altogether. 
Thank you,
Sebastian
