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.
--
Posted via http://www.ruby-forum.com/.
Eero Saynatkari wrote:
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
Robert Klemme wrote:
Eero Saynatkari wrote:
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?
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 wrote:
Robert Klemme wrote:
Eero Saynatkari wrote:
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?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).
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
On 28.08.2006 00:20, Eero Saynatkari wrote:
Eero Saynatkari wrote:
Robert Klemme wrote:
Eero Saynatkari wrote:
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?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 wieldyCome to think of it, might make such input redirection
possible in irb also (if using --readline).
Robert Klemme wrote:
well, if a bit less wieldy
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.
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.
On 28.08.2006 00:20, Eero Saynatkari wrote:
Kind regards
robert
--
Posted via http://www.ruby-forum.com/\.
Eero Saynatkari wrote:
> 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
David Vallner wrote:
Eero Saynatkari wrote:
> I was merely wondering if there is any reason for theT_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?
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.
I am afraid that this comes from the difficulties to automate testing at
that level ( and OP is just fighting with one of the many problems to
solve),
but certainly interactive input treatement is a very worthy unit to test.
Cheers
Robert
On 8/28/06, David Vallner <david@vallner.net> wrote:
Eero Saynatkari wrote:
> 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
--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.
- Albert Einstein