lumiera_/tests/46node.tests

TESTING "Component Test Suite: Render Engine parts" ./test-suite --group=node


PLANNED "Proc Node basics" NodeBasic_test <<END
END


PLANNED "Proc Node creation" NodeBuilder_test <<END
END


TEST "Proc Node test support" NodeDevel_test <<END
END


PLANNED "Proc Node fabrication" NodeFactory_test <<END
END


PLANNED "Proc Node connectivity" NodeLinkage_test <<END
END


PLANNED "Proc Node input reading" NodeInput_test <<END
END


PLANNED "Proc Node operation modes" NodeOperation_test <<END
END
Dispatcher-Pipeline: prepare test for the new NodeGraphAttachment It turns out that the real (not mocked) implementation of JobTicket creation is already required now for this planned (mock)Dispatcher setup; moreover, this real implementation turns out to be almost identical to the mock implementation written recently -- just nested structure of prerequiste JobTickets need to be changed into a similar structur of ExitNodes -- as an aside: rearrange various tests to be more in-line with the envisioned architecture of playback and engine 2023-06-07 04:03:00 +02:00			`TESTING "Component Test Suite: Render Engine parts" ./test-suite --group=node`



			`PLANNED "Proc Node basics" NodeBasic_test <<END`
			`END`


Invocation: establish a concept how to handle parameter data This was an extended digression into architecture planning, which became necessary in order to suitably map out the role for the `TurnoutSystem` — which can now be defined as ''mediator'' to connect and forward control- and parameter data while specific render invocation proceeds through the render node network. 2024-12-05 23:58:22 +01:00			`PLANNED "Proc Node creation" NodeBuilder_test <<END`
			`END`


Invocation: develop more complex text data manipulations The overall goal is eventually to arrive at something akin to a ''»Dummy Media-processing Library«'' * this will offer some „Functionality“ * it will work on different ''kinds'' or ''flavours'' of data * it should provide operations that can be packaged into ''Nodes'' However — at the moment I have no clue how to get there... And thus I'll start out with some rather obvious basic data manipulation functions, and then try to give them meaningful names and descriptors. This in turn will allow to build some multi-step processing netwaorks — which actually is the near-term goal for the ''main effort'' (which is after all, to get the Render Node code into some sufficient state of completion)... 2024-11-28 02:15:59 +01:00			`TEST "Proc Node test support" NodeDevel_test <<END`
Dispatcher-Pipeline: prepare test for the new NodeGraphAttachment It turns out that the real (not mocked) implementation of JobTicket creation is already required now for this planned (mock)Dispatcher setup; moreover, this real implementation turns out to be almost identical to the mock implementation written recently -- just nested structure of prerequiste JobTickets need to be changed into a similar structur of ExitNodes -- as an aside: rearrange various tests to be more in-line with the envisioned architecture of playback and engine 2023-06-07 04:03:00 +02:00			`END`


Invocation: forge a path for integration Facing quite some difficulties here, since there are (at least) two abandoned past efforts towards building a render node network in the code base; the structure and architecture decisions from these previous attempts seem largely valid still, yet on a technical level, the style of construction evolved considerably in the meantime. Moreover, these old fragments of code, written during the early stages of the project, were lacking clear goals and anchor points at places; the situation is quite different now in this respect. Sticking to well proven practice, the rework will be driven by a test setup, and will progress over three steps with increasing levels of integration. 2024-04-22 23:13:55 +02:00			`PLANNED "Proc Node fabrication" NodeFactory_test <<END`
			`END`


			`PLANNED "Proc Node connectivity" NodeLinkage_test <<END`
Dispatcher-Pipeline: prepare test for the new NodeGraphAttachment It turns out that the real (not mocked) implementation of JobTicket creation is already required now for this planned (mock)Dispatcher setup; moreover, this real implementation turns out to be almost identical to the mock implementation written recently -- just nested structure of prerequiste JobTickets need to be changed into a similar structur of ExitNodes -- as an aside: rearrange various tests to be more in-line with the envisioned architecture of playback and engine 2023-06-07 04:03:00 +02:00			`END`


Invocation: forge a path for integration Facing quite some difficulties here, since there are (at least) two abandoned past efforts towards building a render node network in the code base; the structure and architecture decisions from these previous attempts seem largely valid still, yet on a technical level, the style of construction evolved considerably in the meantime. Moreover, these old fragments of code, written during the early stages of the project, were lacking clear goals and anchor points at places; the situation is quite different now in this respect. Sticking to well proven practice, the rework will be driven by a test setup, and will progress over three steps with increasing levels of integration. 2024-04-22 23:13:55 +02:00			`PLANNED "Proc Node input reading" NodeInput_test <<END`
			`END`


			`PLANNED "Proc Node operation modes" NodeOperation_test <<END`
Dispatcher-Pipeline: prepare test for the new NodeGraphAttachment It turns out that the real (not mocked) implementation of JobTicket creation is already required now for this planned (mock)Dispatcher setup; moreover, this real implementation turns out to be almost identical to the mock implementation written recently -- just nested structure of prerequiste JobTickets need to be changed into a similar structur of ExitNodes -- as an aside: rearrange various tests to be more in-line with the envisioned architecture of playback and engine 2023-06-07 04:03:00 +02:00			`END`