≡ Menu

Small quirk in RubyFit

If you are working with FitNesse and Ruby, you’ve no doubt run into RubyFit. Installable by gem, it’s a great way to get up and running with Ruby in FitNesse.

Last week on the main FitNesse list, we found a small quirk. A poster was trying to get running with it, but was only seeing the error message when running their tests. Clicking on the Error logs, he only saw a listing of warnings – mainly around @verbose not being initialized in fit_server.rb.

I spun up a quick instance and was able to reproduce the issue. Upon digging into the fit_server.rb code, I saw the following line for initializing @verbose:

if arg_count == 4 and arg_list.shift == '-v'
   @verbose = true

In other words, when you specify your COMMAND_PATTERN, if -v isn’t the last thing in the pattern, you won’t turn on verbose mode. So it needs to look something like:

!define COMMAND_PATTERN {ruby -I %p -I
/var/lib/gems/1.8/gems/fit-1.1/lib/
/var/lib/gems/1.8/gems/fit-1.1/bin/FitServer.rb -v}

I’ll be filing a bug hopefully this week to change fit_server.rb.

Update (1/15/08): Bug Filed

Comments on this entry are closed.

  • gpiancastelli December 28, 2008, 2:19 am

    I think that the check on the order of parameters is done to ensure uniform behaviour amongst FitServer implementations that can be called from the command line. If you look at:

    http://fitnesse.org/FitNesse.FitServerProtocol

    you will find something like:

    Command Line Arguments:
    Java usage: java fit.FitServer [-v] host port socketTicket

    So, when activating the server from c.l., the verbose option must always be in that specific position. I believe that other FitServer implementations are bound to respect that very same order, and w.r.t. Ruby some tests in test/fit_server_test.rb seem to confirm that (see test_args, test_args_with_verbose, test_bad_args). The check on arg_count should be another hint.

    I don’t know what’s the relationship between command line usage and COMMAND_PATTERN usage, but I don’t think it would be feasible to break c.l. usage uniformity to gain… well, indeed, to gain what, exactly?

    I’m still leaving the bug report open, though, with a Postponed resolution
    and a lower priority.