> 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? Regards, Thomas. [1] http://www.vim.org/scripts/script.php?script_id=1489 --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
