On Tue, Dec 26, 2023 at 8:44 PM HaveF HaveF <[email protected]> wrote:
My intuitive thought is that there are two types of tests in Leo,
>
>
> 1. Testing of common Python function script nodes,
>
>
> 2. Tests that require a Leo context, such as g, c, p, etc.
>
LeoPyRef.leo contains two direct children of the top-level "Code" node:
- *Testing*
- *leo/unittests*
Like Thomas says, the second node contains all of Leo's unit tests.
The first node contains a single node, *@file leoTest2.py*, whose children
are:
- << leoTest2 imports & annotations >>
- function.create_app
- class LeoUnitTest(unittest.TestCase)
The *LeoUnitTest* class invokes the magic that supports c, g, and p in
Leo's unit test. Its top-level node defines the *setUpClass *method:
@classmethod
def setUpClass(cls: Any) -> None:
create_app(gui_name='null')
In other words, any subclass of LeoUnitTest will call *create_app* before
running any unit test.
So create_app is the source of the magic. This function creates a complete
Leo *application* running with a null gui. It's similar to code in Leo's
bridge.
As you can see, the test classes in leo/unittests are all subclasses
(directly or indirectly) of LeoUnitTest. Some classes override their
*setUpClass
*or *setUp *methods.
*Summary*
The starting point for any question about how Leo works is LeoPyRef.leo.
I'm always willing to answer questions about LeoPyRef.leo.
How many times must I say this?
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/CAMF8tS3CSJYcqEP8CmvhBsdbQHjm%3DMtkRi_gtcByqs2eS-HZEQ%40mail.gmail.com.
