Thinking out loud; please comment.
In unit testing tangle, I ignored @path directives. The "live" code
uses @path directives plus other elements of the environment (such as
the directory containing the .leo file) and the argument to @root to
to generate an absolute path to the derived file. Thought this code
is mostly shared with other @<file> directives, that testing is rather
light and could use some more exploration of corner cases. I can't
simply put the absolute path name in a result node header because
different developers will locate the unitTest.leo file in different
places. There are two general cases to test: (a) paths relative to
the unitTest.leo file and (b) absolute path names. In case (a), I can
put the file path relative to the unitTest.leo directory in the result
node header and test against the derived full file path as derived by
the code by removing the unitTest.leo directory prefix from the file
name and testing for equality. Tests for (b) can put the fully
specified path in the result node header, and work regardless of the
developer environment, because the file is not actually written, and
the directories in the absolute path do not need to actually exist.
Concerning untangle: the no-external-change case can be tested using
the current test data, by adding untangle testing the to current
runRootFileTest. The next step is to test incorporation of changes
generated by untangle. There will be an @root tree node representing
the before state, an @root tree node representing the after state,
then sibling node pseudo-files (i.e., with header corresponding to the
relative file name and body corresponding to the external file
contents to be untangled). A test will (deep) copy the @ root "before"
tree, untangle pseudo-files into that copy, then compare the copy to
the @root "after" tree using the compareTree() routine.
To restate, testing untangle will need: a "before" @root tree; a copy
of the "before" tree into which we untangle; and an "after" @root
tree, to which we compare the result of the untangle. In the "no
changes expected", the "after" tree can be the same as the "before"
tree. In both cases, we can automatically generate the copy of the
"before" tree into which we untangle.
- Stephen
On Jun 2, 4:50 am, thyrsus <[email protected]> wrote:
> I've just pushed 3108 to the trunk. Some @root unit tests now work
> due to fixes in leGlobals.py and leoTangle.py; some still fail. Much
> more to do.
>
> I've included a (failing) unit test with a fanciful interpretation of
> what multiple @comment directives should do in a single node. I'd
> like to hear opinions on the subject.
>
> I'm going to tackle testing untangle tomorrow if I can crib the time.
>
> - Stephen
>
> On Jun 1, 6:42 pm, thyrsus <[email protected]> wrote:
>
> > I've just pushed changes to the @root testing, removing @root from the
> > responsibility of runAtFileTest and moving it to a new function
> > runRootFileTest. The new routine can handle tests of multiple @root
> > file output. Changes to portions of the tangle code used only during
> > unit testing store the different "file" results in a dict keyed by
> > (non-path affected) file name. Still to do: modify it to test
> > untangle and fix all the other failing @root tests.
>
> > - Stephen
>
> > On May 31, 5:58 pm, thyrsus <[email protected]> wrote:
>
> > > I've just pushed unit tests for some of @root functionality. Most of
> > > them fail. It's not yet clear whether that has more to do with the
> > > test scaffolding or actual @root failures; probably both.
>
> > > Multiple @root directives in a body are currently "untestable", in
> > > that the test scaffolding uses a hack to tangle into a single string,
> > > bypassing file generation. Multiple @root directives will require
> > > something like tangling into a dictionary, keyed by the file names -
> > > or perhaps we can drop the hack and tangle into actual files, then use
> > > file comparisons (against @asis output?).
>
> > > Untangling is completely untested. Since every tangle should have a
> > > successful corresponding untangle, I'm leaning toward modifying
> > > runAtFileTest to test using the same input tree/output data.
>
> > > The work on allowing @root in headlines appears to be well on its way,
> > > if not finished. �...@root in the body remains supported (I'm relieved).
> > > runAtFileTest appears not to support testing of @root in the headline;
> > > I'll see what I can do about that.
--
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.
