Hi, I've got a stalled development plug-in that I've just went back to and want to fix up and release. Put of my problem with it is that it keeps expanding as I realized that it actually has two levels of use, not the one I originally saw, (and had close to working code for). Trying to allow for this second level of use just exploded the number of functions and cases and left everything a non-working mess.
I'd been writing, utility functions, codition-testing functions and "action" function then using them in a script to support the plug-in purpose --supporting incremental programing. I'd written simple tests for each but them quickly got too hard to manage and run to keep thing validate as they soon started calling each other and where hard to get known to the interpreter just through button activated scripts. So I need more robust testing and figured the @test facilities might be the way to go. Delving into the test/unitest stuff, I see that in unitest usage, you are writing a file that that imports your code module(s) and the unitest module and populate it with an unitest object instance that contains methods that test the code of your module. That is all well and good, but my code exists only in a leo outline, and gets called via a button, (at least until it gets packaged into a true plug-in), so I need a way to support testing in this, "non- modularized" usage. Leo itself uses unitest, but here the test code is contained in test.leo and works on Leo which is already loaded. Any hints on using this for my use case? Tom --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
