Readline and StringIO

[Eero Saynatkari]

It is currently not possible to substitute $stdout or
$stdin with a StringIO when using the Readline library
($stderr seems to be fine) due to a T_FILE check in
readline.c.

Can someone come up with a reason why this might be
required before I change it and submit a patch?

While I am at it, I suppose I will try to provide an
additional method for getting the full line of input.

 

[Robert Klemme]

It is currently not possible to substitute $stdout or
$stdin with a StringIO when using the Readline library
($stderr seems to be fine) due to a T_FILE check in
readline.c.

Can someone come up with a reason why this might be
required before I change it and submit a patch?

While I am at it, I suppose I will try to provide an
additional method for getting the full line of input.

Um, I don't understand why you would want to do that. You are talking
about GNU readline, aren't you? AFAIK this lib is for interactive
editing input - something you cannot do with a StringIO anyway. Did I
miss something?

Kind regards

robert

 

[Eero Saynatkari]

Um, I don't understand why you would want to do that. You are talking
about GNU readline, aren't you? AFAIK this lib is for interactive
editing input - something you cannot do with a StringIO anyway. Did I
miss something?

Unit-testing a program that is supposed to be
interactive. StringIO can would be a fairly simple
way of providing specific input and being able to
predict the output. This is possible with files as
well, if a bit less wieldy

 

[Eero Saynatkari]

Unit-testing a program that is supposed to be
interactive. StringIO can would be a fairly simple
way of providing specific input and being able to
predict the output. This is possible with files as
well, if a bit less wieldy

Come to think of it, might make such input redirection
possible in irb also (if using --readline).

 

[Robert Klemme]

Come to think of it, might make such input redirection
possible in irb also (if using --readline).

You can use fork with a temporary file that is used as input. Even more
appropriate for testing interactive applications might be something like
expect or the Ruby version of it.

Kind regards

robert

 

[Eero Saynatkari]

You can use fork with a temporary file that is used as input. Even more
appropriate for testing interactive applications might be something like
expect or the Ruby version of it.

Not sure if expect will work on output streams (though
I will take a look) and yes, I am aware that this can
be done with files (which is what I am doing currently).

I was merely wondering if there is any reason for the
T_FILE check in Readline (as opposed to a more permissive
one) since that would be the easier solution.

 

[David Vallner]

I was merely wondering if there is any reason for the
T_FILE check in Readline (as opposed to a more permissive
one) since that would be the easier solution.

Change the check and see if there is a reason?

Personally, I'd avoid unit-testing with simulating interactive input.
Unless you're unit-testing the readline library / binding. Maybe you're
missing an abstraction layer between user input and your program logic?

At least I thought unit testing was supposed to test the core logic
modules, where you can just feed them with your specific data or
environment. Testing at the interface level doesn't seem like
unit-testing to me, and you probably want tools like expect to get
decent coverage from that approach.

David Vallner

 

[Eero Saynatkari]

Change the check and see if there is a reason?

Personally, I'd avoid unit-testing with simulating interactive input.
Unless you're unit-testing the readline library / binding. Maybe you're
missing an abstraction layer between user input and your program logic?

I am actually trying to test output which is also not possible.

At least I thought unit testing was supposed to test the core logic
modules, where you can just feed them with your specific data or
environment. Testing at the interface level doesn't seem like
unit-testing to me, and you probably want tools like expect to get
decent coverage from that approach.

I dunno, I see nothing wrong with testing with correct/incorrect
IO for those parts which access the streams directly. The alternative
would be using some type of mocking but, well, that would not work
either.