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 --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---