Idea for testing ruvi

[Hal Fulton]

I'd really like to have a vim-like editor scriptable in
Ruby, so I hope to contribute test cases at the very least.

Here's an idea I have.

Suppose we have a "canonical" file, a text file about 2K or so
in length, to use as a starting point.

Then vim can happily read stdin (as can ruvi I guess).

Hmm. Actually I just tried ruvi with stdin and had a problem.
But I'm guessing that's a quick fix.

So anyway, the idea is basically this.

cp testfile test1
cp testfile test2
vim test1 <cmds >/dev/null # edit with vim according to 'cmds'
ruvi test2 <cmds >/dev/null # edit w/ ruvi according to 'cmds'

Then if test1 and test2 are the same, the test passes.

This way, a test simply becomes a block of text, something easy
to communicate back and forth.

Note that this method doesn't work for issues such as syntax
highlighting.

Note also that it might be good to represent this text as a
here-doc or Ruby string, so that characters such as \033 can easily
be embedded.

Thoughts?


Hal

 

[Phil Tomson]

I'd really like to have a vim-like editor scriptable in
Ruby, so I hope to contribute test cases at the very least.

I thought that vim itself was scriptable in Ruby (you have to build it
with some special option, I believe - I haven't tried it). I seem to
recall that there was an article in Linux Magazine or Linux Journal a
year or two ago about this...


Phil

 

[Hal Fulton]

I thought that vim itself was scriptable in Ruby (you have to build it
with some special option, I believe - I haven't tried it). I seem to
recall that there was an article in Linux Magazine or Linux Journal a
year or two ago about this...

I've heard something about it. But
1. I've never seen it myself
2. I don't really want to build vim
3. Someone said the Ruby support wasn't that great (YMMV)


Hal

 

[Gavin Sinclair]

I thought that vim itself was scriptable in Ruby (you have to build it
with some special option, I believe - I haven't tried it). I seem to
recall that there was an article in Linux Magazine or Linux Journal a
year or two ago about this...

Yeah, it's pretty limited, though. It doesn't expose any deep vim
internals, just windows and buffers. So you can insert text, etc.

Ultimately, it's a *little* bit more powerful than an external Ruby
program, I think.

You could probably do something useful with it, but noone seems to be
doing so.

Gavin

 

[Alexander Kellett]

I'd really like to have a vim-like editor scriptable in
Ruby, so I hope to contribute test cases at the very least.

ruvi is already pretty much fully unit tested though (23 tests, ~ 300 asserts)
some areas need quite a bit more testing before i'll be
happy with them.

rendering/syntax highlighting tests have been acomplished
by writing a test-only frontend which allows dumping of the
screen data to an output file. my arch repository holding
ruvi contains a number of important rendering test cases,
however there aren't many as previously i was using yaml
rather than Marshal for the testcasing and it would take
over 3 to 4 seconds per dump, which made large suites of
rendering testcases completely infeasible (admittedly
very large suites are impossible anyway due to the number
of files that would involve, .

my common coding cycle goes like this:
write test for new feature
disable all others, enable this one
code until testcases all work
renable all tests
fix possible interaction bugs
in the case of syntax highlighting:
write test for new case
disable all others, enable this one
while not_done
rm renderings/my_new_test
ruby testcasees.rb # now that renderings output is no longer
# present the testsuite will create it rather
# # than comparing it
display_rendering
my_new_test
end
renable tests and fix interaction bugs

the ability to write test cases and still see the screen
rendering is just awesome its massively improved the speed
at which i can hack something in

if anyone has a key sequence that is missing, please add
it to the page:

http://ruvi.rubyforge.org/wiki/wiki.pl?UnimplementedKeySequences

i'll add the list that various people have already contributed
as soon as i wake up from a quick nap

This way, a test simply becomes a block of text, something easy
to communicate back and forth.

interesting idea but i'm not sure of the need to
involve vim really. the tests can be created with vim
usage in mind but i doubt vim will be very easily
testable in this manner. otoh, it would be nice to
know that all my testcases are correct so some
peer review on this would be really nice

mvg,
Alex

 

[Hal Fulton]

interesting idea but i'm not sure of the need to
involve vim really. the tests can be created with vim
usage in mind but i doubt vim will be very easily
testable in this manner. otoh, it would be nice to
know that all my testcases are correct so some
peer review on this would be really nice

Well, I've done it before. In the days before vim, I wrote
testcases for IBM's vi on AIX. Take a known file, apply
known commands to it, get predictable output.

vi (and vim) will read standard input and run commands
that it finds there. Long ago I used this as a kind of
poor man's macro. Plain vi was (is) not scriptable afaik.

And IMO ruvi should read stdin the same way. It *almost*
works, but it got stuck in an infinite loop on ":wq"
(probably some kind of EOF problem).


Hal

 

[Mauricio Fernández]

I'd really like to have a vim-like editor scriptable in
Ruby, so I hope to contribute test cases at the very least.

Here's an idea I have.

Suppose we have a "canonical" file, a text file about 2K or so
in length, to use as a starting point.

Then vim can happily read stdin (as can ruvi I guess).

Hmm. Actually I just tried ruvi with stdin and had a problem.
But I'm guessing that's a quick fix.

So anyway, the idea is basically this.

cp testfile test1
cp testfile test2
vim test1 <cmds >/dev/null # edit with vim according to 'cmds'
ruvi test2 <cmds >/dev/null # edit w/ ruvi according to 'cmds'

Then if test1 and test2 are the same, the test passes.

Take a look at testcases.rb in the ruvi sources: he's already doing
something like that at a command level, and also verifying cursor
position and in general more state than just the output text.
I think the approach you describe could be a very good acceptance test
(and indeed, those who want an accurate reproduction of the subset of
vim they use could define their own acceptance tests that way), but it
could be less useful for debugging since it might be difficult to infer
what went wrong from the mere comparison of the outputs.

Now, if you manage to dump all the intermediate states in vim, you could
generate a massive amount of test cases in little time, as opposed to
creating them by hand which is what has been done so far.