Innovation almost happens without a juicy problem. The problem that inspired these thoughts was this: how can we associate unit tests with (the code in) a Leo node?
One thought was to put one or more unit tests for node p in p.u, p's user data. Clearly that's possible. Moreover, a script could discover and run such unit tests. So p.u becomes another dimension of the outline. That is, p.u is *another* outline, "orthogonal" to the original outline. We've been here before, with the notion of colored links with Leo outline. The conclusion then (and spoiler alert, now) is that the concept isn't that useful. However, I would like to discuss this (dubious) idea in a bit more detail, just for fun. *Outlines all the way down* If p's user data can contain *another* outline, then any node p-prime in the new outline could contain yet another outline, contained in p-prime's user data. And so on... This has little or no appeal :-) *Gui problems* I have not been able to make sense of this idea in terms of screen elements, even if we stop at one additional level. We would need *another* pane to show the user data, and there would likely have to be various representations of the user data depending on what the various parts of the user data are. It would be like the VR pane, but showing p.u rather than p.b. Just as with the VR pane, we would need distinct code for each different kind of user data. But user data can contain (almost) anything, so the new pane could never be "complete". Furthermore, the new pane, say the *user data pane*, would likely take a lot of screen real estate to show the user data. Most of the time that space would be wasted (almost useless). How could the user data pane show yet another outline? Does that second outline need yet another VR pane or another user data pane? It seems like the most complex thing that could possibly work :-) *A simpler way* Let's go back to the original problem: we want a way to associate unit tests with code. Links are the obvious way to do that. Leo already has unl's (uniform node locators). There is nothing to prevent two-way unl's between code and unit tests. Each node (containing code to be tested) could contain a link to a tree containing zero or more unit tests. Each unit test could optionally contain a link back to the node being tested. So there is a (benign) many-to-one relationship between the links. I noted above that the user data pane could never show all possible user data (in a friendly format). However, *particular* data could be shown using special case code. Terry's todo and backlink plugins are examples of specialized views of data. We could consider showing graphs of links, if that would be useful. *Other considerations* Links could take many forms besides unl's, including tags, or even file names (of the code to be tested). Unit tests of outline-oriented code benefit from being included in unitTest.leo. That way the unit tests can use Leo's outline-oriented capabilities. The unit tests for leoAst.py were a great fit for pytest because they *didn't* need those outline-oriented features. *Summary* Associating code with unit tests would be useful, but putting tests in p.u is about the most complicated thing that might work :-) 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/aba20320-18dc-41a3-bb40-c31051859ccc%40googlegroups.com.
