On Jul 2, 8:27 pm, "Edward K. Ream" <[email protected]> wrote:
> The new-sentinels branch now contains an important testing script that > uses the new compareClass class, presently defined in leoAtFile.py. > This is packaged as an @test node for easy running, but it's not > really a proper unit test. Some further notes: 1. This will likely never evolve into a unit test because it would require that Leo continually compare old and new sentinels. This isn't worth doing: eventually the code to write old sentinels will disappear. Naturally, the code to *read* old sentinels must be retained "forever" so that Leo can read old external files. Thus, the code in compareClass is "merely" part of the migration process. The migration process will not be complete until all unit tests pass with the new sentinels, but as I have already explained, unit tests really are not enough. 2. The present code compares normal (non-sentinel) lines and sentinel lines separately. This is a bit slack, because it doesn't check the intermixing of the two kinds of files. Furthermore, it destroys line numbering. So it would be best to test the two files in one pass. I plan to do that today. The complicating factors are @doc (and @space) parts. The new write code does not try to be "helpful" by wrapping lines. As I said earlier, there is no reason to do that now that we have the reformat- paragraph command (and also the fcol, file column, indicator in Leo's status line). That is, users are now in a position to format doc parts explicitly in Leo, so the write code should not override the choice. We don't want to ignore *all* non-sentinel comments, because that would mask real errors, so to be complete the test script must deal with @doc parts as a special case. 3. The present code now defines "run" and "ignore" methods. The run method contains the driver code. The @test node is now simply: c.atFileCommands.compareClass(c).run(). The run method is useful because now all changes to the driver code will appear in leoAtFile.py without me having to up leoPy.leo. The ignore method returns true if a file should be ignored. At present, this returns true for the "leo_xxx.py files". I added leoAtFile.py to this list because it has already passed, and it keeps changing. Anyway leoAtFile.py is going to get a complete workout during the conversion process. 4. At present, only leoColor.py fails compareClass.run. The failure involves +middle sentinels, and I'm just beginning to remember what they are about :-) They handle the case where an organizer node appears between a section reference and the node that defines the section. You can see what is happening by looking at leoColor.py:doNormalState. I'm not yet sure whether this is a real failure (of the read or write code), or merely a special case that compareClass must deal with. Either way, it is unlikely that any unitTest would have caught this situation. This single failure justifies all the work that I have done with this script. Edward -- 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.
