On 20/02/09 16:03, Charles Campbell wrote:
> Tom Link wrote:
>>> However I've made a different design choice: my plugin acts as a
>>> preprocessor. Thanks to that, I'm able to know the line where an
>>> assertion failure occurred
>>>
>> Cool.
>>
>>
>>> BTW, tAssert provides convenience functions that my script don't (yet?).
>>> At first, I wondered if both plugins should be merged.
>>>
>> IMHO they serve different purposes. Although tassert was initially
>> meant to work as a unit testing framework, I then was more interested
>> in sprinkling the code with assertions that could easily be turned
>> off. But with a DbC-related plugin, you'd always want to load it on
>> startup during (informal) testing. A unit-testing plugin on the other
>> hand, you'd probably want to load only before running the test, I
>> suppose. So, a DbC plugin should load fast, a UT-plugin doesn't
>> necessarily have to. This is also the reason why I'd rather prefer to
>> strip down my tassert plugin and to leave only the TAssert command and
>> some utility functions in it.
>>
>> There is some overlap of course since the utility functions you
>> mentioned are useful in both contexts. Maybe those functions should go
>> in a shared autoload file?
>>
>> One main challenge with a unit testing framework for vim scripts
>> actually is, as Ingo Karkat pointed out, the utility functions it
>> provides. IMHO these functions should not only be able to test for
>> buffer content after a defined series of simulated key presses (via
>> feedkey()) but also something like window layout etc. It would also be
>> interesting to combine such a UT plugin with something like Charles
>> Campbell's PluginKiller[1] to make sure that the results are the same
>> with different sets of option values. I think CC's plugin is quite
>> interesting in this respect but I personally don't think it's very
>> practical to manually simulate all different kinds of user
>> interactions repeatedly with different settings. AFAIK PluginKiller
>> doesn't automate (record& replay) this process, does it?
>>
> I think that one can already do a keystroke recording and playback (qa
> ... q @a, for example),
> so I don't have PK automating that process. What'd be great would be to
> combine that playback
> with the ability to determine if the plugin behaved correctly or not --
> but I don't see any way to
> generically accomplish that. Certainly the notion of TAssert could be
> used to give a partial
> feedback of that sort.
>
> Regards,
> Chip Campbell
Well, at least most of Vim (with the exception, IIUC, of the python
interface) is essentially single-threaded, so unlike developers for some
other applications, Vim developers normally don't get headaches from
race conditions (some of them depending on "how fast you're typing and
how busy is the system") and the sporadic crashes that often go with
them, and even sometimes disappear when you harness the app in a
debugging framework. (Though I have sometimes seen X11 error crashes in
gvim at startup, which spontaneously disappeared when started with the
--sync switch to force synchronous interfacing with the X server.)
Best regards,
Tony.
--
"The Good Ship Enterprise" (to the tune of "The Good Ship Lollipop")
On the good ship Enterprise
Every week there's a new surprise
Where the Romulans lurk
And the Klingons often go berserk.
Yes, the good ship Enterprise
There's excitement anywhere it flies
Where Tribbles play
And Nurse Chapel never gets her way.
See Captain Kirk standing on the bridge,
Mr. Spock is at his side.
The weekly menace, ooh-ooh
It gets fried, scattered far and wide.
It's the good ship Enterprise
Heading out where danger lies
And you live in dread
If you're wearing a shirt that's red.
-- Doris Robin and Karen Trimble of The L.A. Filkharmonics
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
