[#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:5377] Re: Unit testing network code?

From: "Glen Stampoultzis" <trinexus@...>
Date: 2000-10-10 11:18:27 UTC
List: ruby-talk #5377
> > I think maybe one would test each end on its own first, faking the
> > communication between them, then start up both ends together and cause
> > them to interact.  That seems fair enough but when the network is not
> > reliable (UDP for example), how does one isolate the different problems
> > introduced by a lossy network from each other and from the property
being
> > tested?
>
> This seems to be heavily architecture-dependent. Maybe there could be an
> alternate version of the inet loopback (lo.o ?) module in Linux that could
> do that... when the address matches a certain pattern (127.1.*.*) it would
> drop packets according to a certain characteristic. Maybe you could
> suggest the idea on the Linux kernel mailing-list.
>
> Otherwise, a simple UDP/TCP emulator/filter could be written in Ruby, and
> you would add rules of packet-dropping in it. This would be less universal
> (Ruby only, and must be used explicitly) but much easier to write.

You could run everything in the one process and use mock objects to simular
the transport layer.  This would give you finer control over your testing.

http://www.connextra.com/site/all_about_us/xp/mockobjects.pdf

Regards,

    Glen


In This Thread