I'm having trouble writing a unit test to check code that communicates via standard in and standard out.  Attached to this post is my a reduced form of my problems.  Can anyone tell me what's going wrong? (The assert in the code fails)

"send" belongs to my test harness and can be changed easily
"receive" belongs to working console I/O code.
  In that code receive = new LineIterator!(char)(Cin.stream)

Jason House wrote:
> I'm having trouble writing a unit test to check code that communicates via
> standard in and standard out.  Attached to this post is my a reduced form
> of my problems.  Can anyone tell me what's going wrong? (The assert in the
> code fails)

You need to rewind the file before starting to read after writing:

fakeConsole.seek(0);

torhu wrote:

> Jason House wrote:
>> I'm having trouble writing a unit test to check code that communicates
>> via
>> standard in and standard out.  Attached to this post is my a reduced form
>> of my problems.  Can anyone tell me what's going wrong? (The assert in
>> the code fails)
> 
> You need to rewind the file before starting to read after writing:
> 
> fakeConsole.seek(0);

I interpret that to mean that writing to the file affects the read stream and reading affects the write stream.  I need to decouple those because reading and writing should be more or less independent of each other.

It sounds like if I open up a file twice, once for writing and once for reading, that I can get independent access into the file.  The real test is multi-threaded with reading and writing done asynchronously.  With independent file classes, will EOF be a problem?  AKA, if a read occurs when a write is in progress.

Jason House wrote:

> torhu wrote:
> 
>> Jason House wrote:
>>> I'm having trouble writing a unit test to check code that communicates
>>> via
>>> standard in and standard out.  Attached to this post is my a reduced
>>> form
>>> of my problems.  Can anyone tell me what's going wrong? (The assert in
>>> the code fails)
>> 
>> You need to rewind the file before starting to read after writing:
>> 
>> fakeConsole.seek(0);
> 
> I interpret that to mean that writing to the file affects the read stream and reading affects the write stream.  I need to decouple those because reading and writing should be more or less independent of each other.

Yes, because your TempFile is a Conduit that provides both the input and output stream.

> 
> It sounds like if I open up a file twice, once for writing and once for reading, that I can get independent access into the file.

Yes.

> The real test
> is
> multi-threaded with reading and writing done asynchronously.  With
> independent file classes, will EOF be a problem?  AKA, if a read occurs
> when a write is in progress.

You should lock your resources (files) while writing.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund Wrote:

> Jason House wrote:
> Yes, because your TempFile is a Conduit that provides both the input and
> output stream.

One of these days, I'll try to figure out all the layers of abstraction int he Tango I/O library...  Both what each piece means and why they (strange?) names were chosen.


> > The real test is
> > multi-threaded with reading and writing done asynchronously.  With
> > independent file classes, will EOF be a problem?  AKA, if a read occurs
> > when a write is in progress.
> 
> You should lock your resources (files) while writing.

What kind of locking mechanism are you talking about?  synchronized(obj)?  This would work to ensure proper behavior when reading from temporary file like in my unit test, but can't be done in a more general asynchronous case...  such as when using pipes for communication, or the console.



> 
> -- 
> Lars Ivar Igesund
> blog at http://larsivi.net
> DSource, #d.tango & #D: larsivi
> Dancing the Tango