Test::Unit output

[Charles Comstock]

I was curious if there are other test modes on test::unit which are more
descriptive of the progress through each file of testing. I think this
would be particularly useful for running test cases like those in the
ruby interpreter. If the interpreter segfaults in the middle of running
tests, and all you have are a bunch of .'s and E's how are you supposed
to tell what it failed on? Also while the .'s are alright for a short
set, it would seem as if some sort of progress description over each
test file would be more descriptive of the progress while testing.

Has this been gone over before? Any particular reason for the choice of
the dotted output?

Charles Comstock

 

[Gavin Sinclair]

I was curious if there are other test modes on test::unit which are more
descriptive of the progress through each file of testing. I think this
would be particularly useful for running test cases like those in the
ruby interpreter. If the interpreter segfaults in the middle of running
tests, and all you have are a bunch of .'s and E's how are you supposed
to tell what it failed on? Also while the .'s are alright for a short
set, it would seem as if some sort of progress description over each
test file would be more descriptive of the progress while testing.

Once or twice I've written my own test runner that executes each test
class in turn, so when it goes ..........E...F...., you know right
away which file is causing trouble. That makes sense for a large test
suite.

In general, though, I usually restrict the test run to the file that's
relevant to what I'm working on. Saves time.

Has this been gone over before?

Not that I know of.

Any particular reason for the choice of the dotted output?

A premium on simplicity of output, I think. In the common case (all
tests work), you don't want lots of crap filling up the screen.

Cheers,
Gavin

 

[Nathaniel Talbott]

I was curious if there are other test modes on test::unit which are
more descriptive of the progress through each file of testing. I
think this would be particularly useful for running test cases like
those in the ruby interpreter. If the interpreter segfaults in the
middle of running tests, and all you have are a bunch of .'s and E's
how are you supposed to tell what it failed on? Also while the .'s
are alright for a short set, it would seem as if some sort of progress
description over each test file would be more descriptive of the
progress while testing.

Has this been gone over before? Any particular reason for the choice
of the dotted output?

Did you try passing your test --help on the commandline? I think
--verbose is what you're looking for:

ntalbott@jacob:~/tmp$ cat t.rb
require 'test/unit'

class T < Test::Unit::TestCase
def test1
end

def test2
end
end

ntalbott@jacob:~/tmp$ ruby t.rb
Loaded suite t
Started
..
Finished in 0.005947 seconds.

2 tests, 0 assertions, 0 failures, 0 errors
ntalbott@jacob:~/tmp$ ruby t.rb --verbose
Loaded suite t
Started
test1(T): .
test2(T): .

Finished in 0.009733 seconds.

2 tests, 0 assertions, 0 failures, 0 errors

HTH,


Nathaniel
Terralien, Inc.

<(><

 

[Charles Comstock]

Did you try passing your test --help on the commandline? I think
--verbose is what you're looking for:

ntalbott@jacob:~/tmp$ cat t.rb
require 'test/unit'

class T < Test::Unit::TestCase
def test1
end

def test2
end
end

ntalbott@jacob:~/tmp$ ruby t.rb
Loaded suite t
Started
..
Finished in 0.005947 seconds.

2 tests, 0 assertions, 0 failures, 0 errors
ntalbott@jacob:~/tmp$ ruby t.rb --verbose
Loaded suite t
Started
test1(T): .
test2(T): .

Finished in 0.009733 seconds.

2 tests, 0 assertions, 0 failures, 0 errors

HTH,


Nathaniel
Terralien, Inc.

<(><

Right that's per test listing, I was more looking for per file listing
or something like that. Hate to mention the p language, but I had to
install something from cpan last night to run someone elses code and I
was reminded of how nice there test ouput was. They seemed to follow
the general format of:
t/testfilename test#/ofTotal (cycling through number complete and then
outputing ok when done)

If it's just one file I don't really think you need to necessarily know
test by test, above would be useful to find it in a specific file
though. Anyway I was impressed by there format I guess. Particularly
haven been bitten for a while with a segfault running the test suite
bundled with the interpreter in ruby. I found out later what was
killing with it, but after a hundred of those dots go by it's kinda hard
to keep track of what test you might be on.

Hmm maybe i'll write my own test-suite formatter or something.

Charlie

 

[Nathaniel Talbott]

Right that's per test listing, I was more looking for per file listing
or something like that. Hate to mention the p language, but I had to
install something from cpan last night to run someone elses code and I
was reminded of how nice there test ouput was. They seemed to follow
the general format of:
t/testfilename test#/ofTotal (cycling through number complete and then
outputing ok when done)

If it's just one file I don't really think you need to necessarily
know test by test, above would be useful to find it in a specific file
though. Anyway I was impressed by there format I guess. Particularly
haven been bitten for a while with a segfault running the test suite
bundled with the interpreter in ruby. I found out later what was
killing with it, but after a hundred of those dots go by it's kinda
hard to keep track of what test you might be on.

Can you give an example of the P language output?


Nathaniel
Terralien, Inc.

<(><

 

[Zachary P. Landau]

--Wtrm9ATX0sn6fFKv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I was curious if there are other test modes on test::unit which are more= =20
descriptive of the progress through each file of testing. I think this= =20
would be particularly useful for running test cases like those in the=20
ruby interpreter. If the interpreter segfaults in the middle of running= =20
tests, and all you have are a bunch of .'s and E's how are you supposed= =20
to tell what it failed on? Also while the .'s are alright for a short=20
set, it would seem as if some sort of progress description over each=20
test file would be more descriptive of the progress while testing.
=20
Has this been gone over before? Any particular reason for the choice of= =20
the dotted output?

I just came across these CUnit screenshots today[1]. They seem to do a
pretty good job of keeping the output nice and clear. I don't have any
major issues with the current Test::Unit output, but I figured I'd show
these.

[1] http://gethos.net/opensource/cunit_screenshots.php

--
Zachary P. Landau <[email protected]>
GPG: gpg --recv-key 0x24E5AD99 | http://kapheine.hypa.net/kapheine.asc

--Wtrm9ATX0sn6fFKv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBHkv1CwWyMCTlrZkRAu/3AJ0b4NoM7Gel7xgHz/fRwRYsyICr0wCfbheJ
dj9TYnR+/5wdxT1Dul8AVlM=
=liQg
-----END PGP SIGNATURE-----

--Wtrm9ATX0sn6fFKv--