On Sun, Sep 1, 2019 at 9:37 AM vitalije <[email protected]> wrote: I gladly accept the challenge. >
Thank you! > I am not sure what you mean by unit test, but here is how I see it. > In this context, a unit test is simply a script that verifies, in some unspecified way, that exiting code works. It can also be applied to any proposed refactoring/simplification of the code. To do both, the unit test should be self contained. That is, it should not use existing code, but instead work from "first principles", that is, the highest-possible description of what is intended. I think of such tests as a form of double-entry bookkeeping. The script complements Leo's existing unit tests. In my mind, the script should be substantially more ambitious. It should test, as much as possible, all of Leo's settings, verifying that settings work as expected no matter where they are defined. This kind of test might take minutes. I will make a python module with the following functions: > > > - *parse_settings_tree*(*vnode*) - returns a generator of settings in > the subtree of given vnode. Yields tuples (*type*, *value*) > - *make_conf*(filenames) - returns an object with the single method: > - *get*(name, kind) - replacement for c.config.get > - *save_conf*(filename) > - *load_conf*(filename) > - *show_current_settings_tree*(c, p) - this will rebuild settings > outline with all values in effect as a first child of p, so that user can > edit settings and root of this outline will have heading > '@current-settings' > - *update_current_settings_and_close*(c) - finds node > `@current-settings`, process them and updates values in c.config and > perhaps stores them in ~/.leo/config.db > > A unit test then can look something like this: > import mymodule > conf = mymodule.make_conf(['leoSettings.leo', 'myLeoSettings.leo', > 'activeUnitTest.leo']) > > d = c.config.settingsDict > > for name, gs in d.items(): > assert conf.get(name, gs.kind) == gs.val > > > A couple of other tests should prove that save_conf/load_conf work as > expected. > Very good. I'll leave the details to you. If this succeeds then Leo can use this module in the following way. Instead > of editing myLeoSettings.leo, user can execute 'show-current-settings-tree' > which will dynamically show entire tree of settings where user can edit any > setting, and then execute 'update-current-settings-and-close' and this tree > will disappear, but changes will be stored for the next run, with the same > effect as if myLeoSettings.leo was edited. > This is pretty much what I am working on now. We can think about merging our respective code later. > Show current settings tree should generate outline similar to > leoSettings.leo with settings grouped by category. > Right. That's what active-settings-outline does. > Your comments please. > I'm glad we are now thinking in code. This is much better than (necessarily!) vague discussions. This new testing pattern can be applied to any proposed major change to Leo. The application of this pattern will necessarily be creative, and will be unique to any big endeavor. For the first time ever, I am confident that Leo will continue to evolve safely after I am gone. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS1iTN%2BLKK82YVRqRmdAvDYg_kcU%2Bg69%3DqotAbsEmuMD%3DQ%40mail.gmail.com.
