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.
Eero S. 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
robertRobert K. wrote:
Eero S. 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 
Kind regards
robert
Eero S. wrote:
Robert K. wrote:
Eero S. 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).
Kind regards
robert
On 28.08.2006 00:20, Eero S. 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.
Kind regards
robertRobert K. wrote:
On 28.08.2006 00:20, Eero S. 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.
Kind regards
robert
Eero S. 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 V.
David V. wrote:
Eero S. 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?
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.
David V.
On 8/28/06, David V. [email protected] wrote:
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 V.
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
–
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs