Add tests.

[Oliver Caldwell]

Some sort of VSpec? Not sure what the best approach would be or even if it's worth it.

[Andrew Radev]

For testing, I use my own vimrunner gem. The tests are standard RSpec tests, which should be familiar to ruby developers. Here's an example. The way it works, it spawns a Vim instance and then sends commands to it through Vim's --remote interface.

Of course, if you're not a ruby developer, this is probably not a good option. Vroom is something that works in pretty much the same way as Vimrunner, except it uses a simple format to describe the interaction. It's also implemented in python, so if you're a python person, you might find it easier to debug it if something goes wrong.

VSpec is something I haven't used, but I've heard good things about it. I think it just runs Vim and then executes commands through it directly, so it probably avoids some of the weirdnesses of the --remote interace. Personally, I like the remote Vim approach, since I feel it replicates user interaction well, but this may also depend a lot on what exactly you're testing.

Whether it's worth it is hard to say :). It wouldn't be a terrible idea to wait and see if you make many changes to the code. It might work fine as-is and you never need to hack on it in the future, in which case tests would probably not help you much. Unlike most software, Vim plugins don't bitrot a lot for various reasons, so it's not uncommon to use something that was last touched in 2006, for example. That said, I'd still recommend trying to write tests for learning purposes at least :).

[Oliver Caldwell]

I'll have a look at both (which have been discussed at Vim London in the past I think) and probably add a few rudimentary tests in one, just to get started. I sort of agree that there isn't really a need to test yet, but it would make me feel better about myself. If I do it, it'll probably be a learning exercise, but there's certainly more things I want to add, and tests before then would be a good idea.

Thanks for the insightful reply, it's just what I was looking for by creating this issue ahead of time!

[Jason Imison]

Give vader.vim a try. It seems the simplest out of them all.

[Oliver Caldwell]

I'm going to give vader a go and hook it into TravisCI for v1.1.0, this should be fun.

[Oliver Caldwell]

Things that need testing:

• :EnMasseVersion prints the version number, or at least a plain string. (RegExp check)
• :EnMasse with no quickfix list displays an error.
• :EnMasse with a quickfix list creates a buffer.
• The buffer contains the matching lines from the quickfix list.
• Duplicate lines are joined together.
• CursorMoved triggers an echo of the original line.
• Joined lines echo both of their messages separated by a pipe.
• If a line is too long to echo on one line, it is truncated.
• Writing causes changes to be written to the file.
• Does not write if there are no changes.
• If an extra line is added or one is removed, it will not let you write and it will echo an error.
• Writing to a file that is open prompts you to load the changes.
• Pressing <CR> opens the line under the cursor just like a quickfix list. (not quite there yet, so should also fail)

Better get cracking.