\nThat kind of round trip testing is what I've been doing to test tangle/untangle in @root. I followed along with an earlier decistion to "pollute" the code with a dependency on g.unitTesting to put the test result from/to an in-memory dict instead of an actual external fille; the advantange is that one doesn't have to deal with all the externalities created by the OS file system; the disadvantage is that one doesn't test dependencies introduced by the OS filesystem.
We each have our threshhold for acceptable corruption ;-). I'm sure we'll need to fix the kind of code duplication mentioned (if a node contains "i++\n" and turns into "i++\ni++\n", I don't think anyone's going to be happy - although the functional programmers might be immune - all 0.001% of them :-}). On the other hand, my code to remove @language and @comment directives from the generated file and then reintroduce them after an untangle changes the section part definition can leave spurious blank lines. At the moment, I'm too concerned with other issues to deal with it. On Jul 1, 8:40 am, "Edward K. Ream" <[email protected]> wrote: > The new sentinels code has past its first major milestone. The > following round-trip test passes: > > - Set new_write to True in the working copy of leoPy.leo. > - Start a test copy of LeoPy.leo. Write leoAtFile.py, thereby > generating new sentinels. > - Restart the test copy of LeoPy.leo. Writing leoAtFile.py leaves > the file unchanged. > > This is just the start of rigorous testing. At least two problems > remain: > > 1. In some cases, not yet fully understood, clones can caused body > text to be duplicated. Amusingly, this does not cause apparent harm: > some nodes become something like: > > def foo(): > body > def foo(): > body > > Python is fine with the duplication, though pylint would complain :-) > > 2. Text following section references, like: > > if ( <<condition>> ): > > becomes, after round-tripping: > > if ( << condition >> > ): > > BTW, the parens are required, because the expansion of << condition >> > will take several lines. I forget how this case was handled with old > sentinels--something similar will be needed with new sentinels. > > Edward > > P.S. The works has had quite an ad-hoc flavor to it. It's not > entirely clear how to put it on a more sold basis. Unit tests might > help, but it's a bit hard to see how to make them easy enough to > create to be really useful. More thought is needed on this topic. > > Perhaps a more useful approach would be to automate round-trip > testing. This would involve a script that creates and compares the > first and second generations of leoPy.leo and all of Leo's core files. > > EKR -- 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.
