Ashley Moran: > On Nov 07, 2008, at 5:24 pm, Shot (Piotr Szotkowski) wrote:
>> Right, that’s why I suggested I could Kernel#eval the binary’s contents >> in the current process instead. This would require tricking Trollop, but >> I assume I could trick it by hand-crafting ARGV. > You might find Rick Bradley's talk[1] on regression testing flog > useful here. He starts by speccing the binary at a Ruby level. Heh – I brought exactly this talk up twice when talking about specing binaries here (it was what pointed me in the direction that it would be actually good to spec/test them, actually). :) > Note, however, that later in the talk he admits he made a mistake in > not writing end-to-end tests soon enough. I think he should have run > the binary as a black box and just pushed binary code into lib sooner. Right. I think I agree that’s the best (and most elegant) way to test binaries. In my case, asfter some specing and some coding, it turns out I can’t really do this the way I wanted; most of the cases I need to test for are triggered with input that makes the binary run a long time (it’s the code behind my PhD thesis, so tons of computations). As I’m testing a black box with Kernel#`, I can’t mock/stub anything out. Seeing as my binary grew to over 80 lines, I guess my best bet is to pull out the gist of it into a separate Runner class, spec it (with mocks/stubs/fixtures) so it runs in a sane time and then only create a think binary wrapper around it (which will basically parse the options, set the config and then run the runner). Thanks a lot for the nice Cucumber example! It was most informative. -- Shot -- As the Slashdot distributed brain engine has observed, the ultimate test of any piece of equipment is to build a Beowulf cluster of it. -- Peter Seebach
pgpJg4jWrvShH.pgp
Description: PGP signature
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
