Puts behaviour

Ruby
1

I have a number of “puts” in my testcase file. When I run my test
harness using ruby -w test/testcase.rb the first “puts” in the second
method prefixes the output string with a ‘.’ I cannot seem to locate
any reference to this behaviour. Under what circumstances does “puts”
without any argument produce ‘.’ as output?

Regards,
Jim

2

James B. wrote:

I have a number of “puts” in my testcase file. When I run my test
harness using ruby -w test/testcase.rb the first “puts” in the second
method prefixes the output string with a ‘.’ I cannot seem to locate
any reference to this behaviour. Under what circumstances does “puts”
without any argument produce ‘.’ as output?

If you are running this as part of the standard Test::Unit test case
runner, then it is probably Test::Unit printing the “.”. It prints one
period for each test case run.

–
– Jim W.

3

Jim W. wrote:

If you are running this as part of the standard Test::Unit test case
runner, then it is probably Test::Unit printing the “.”. It prints one
period for each test case run.

Are these '.'s pushed onto some sort of string variable in TestUnit
wherein ‘puts’ is redefined so that the string is prefaced to any
argument passed to puts and then cleared?

Regards,
Jim

4

On Feb 23, 2006, at 7:29 PM, James B. wrote:

Are these '.'s pushed onto some sort of string variable in TestUnit
wherein ‘puts’ is redefined so that the string is prefaced to any
argument passed to puts and then cleared?

I don’t quite know what you are asking, but –

If you do not want buffered output, set $stdout.sync = true (or
$stderr). If $stdout.sync is false (and it is by default), the line
will not be flushed until a newline. You could also just call IO#flush.

– Daniel

5

James B. wrote:

Daniel H. wrote:

I don’t quite know what you are asking, but –

If you do not want buffered output, set $stdout.sync = true (or
$stderr). If $stdout.sync is false (and it is by default), the line
will not be flushed until a newline. You could also just call IO#flush.

– Daniel

Without examining the code, which is probably the next step, I speculate
that these '.'s are set by Test::Unit to provide support for some sort
of progress status bar. I am not sufficently well versed in Ruby (I
wrote my first non trival program in it last week) to have encountered
things like $stdout.sync and IO.flush. However, having this new
information combined with my previous experience with the mysterous '.'s
leads me to the inference above.

This is no more than an inquiry as to why these things appeared
unexpectedly in my output, which happened to be directory strings
wherein a prefix of . has rather profound implications.

Right, no, the ‘.’ is just a progress indicator, one for each
successful test_* method in your test case (you will see an ‘F’
for each failure and an ‘E’ for each error). The dots are output
using #print rather than #puts, so they are not followed by newlines
which means that your string will appear immediately after one.
There should be a newline after your string, though (if not, then
the framework strips those–I do not have access to test right now).

Thanks for the information. It clarifies a few items of confusion.

Regards,
Jim

E

6

Daniel H. wrote:

I don’t quite know what you are asking, but –

If you do not want buffered output, set $stdout.sync = true (or
$stderr). If $stdout.sync is false (and it is by default), the line
will not be flushed until a newline. You could also just call IO#flush.

– Daniel

Without examining the code, which is probably the next step, I speculate
that these '.'s are set by Test::Unit to provide support for some sort
of progress status bar. I am not sufficently well versed in Ruby (I
wrote my first non trival program in it last week) to have encountered
things like $stdout.sync and IO.flush. However, having this new
information combined with my previous experience with the mysterous '.'s
leads me to the inference above.

This is no more than an inquiry as to why these things appeared
unexpectedly in my output, which happened to be directory strings
wherein a prefix of . has rather profound implications.

Thanks for the information. It clarifies a few items of confusion.

Regards,
Jim