[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5379] Re: applying unit testing to ruby?

From: Dave Thomas <Dave@...>
Date: 2000-10-10 13:29:11 UTC
List: ruby-talk #5379
schneik@us.ibm.com writes:

> # Mathieu Bouchard <matju@cam.org> writes:
> #
> # > It would be nice to have a number of unit tests for Ruby internals
> # > themselves, so that if I break something hacking with the internals I
> may
> # > know it. Of course this isn't ideal because Ruby unit tests have to
> rely
> # > on Ruby somehow, to be evaluated; but it could be good for catching
> subtle
> # > changes in less fundamental modules/classes, e.g. IO, File, Regex.
> #
> # Funny you should say that...
> #
> # I'm in the middle of completing a set for Ruby 1.6. Right now I have
> # tests for 796 separate functions, with just over 10,000 asserts.
> 
> I have a comment and a question:
> 
> (1) Thanks.
> 
> (2) What's the impetus for doing this on top of all your other work?

I wanted to check for major functionality changes in the
libraries. Because we autogenerate the Ruby output in the book, it
would be easy to have the functionality change and not notice it.

It also helped pin down a couple of bugs during 1.6 development.

Dave

In This Thread

Prev Next