LUMIERA.clone/tests/51-gui-model.tests

TESTING "Component Test Suite: GUI Model Parts" ./test-suite --group=gui


TEST "Self-check: testing GUI backbone parts" TestGui_test <<END
return: 0
END


TEST "the abstracted tangible UI element" AbstractTangible_test <<END
return: 0
END


PLANNED "building block of the UI-Bus" BusTerm_test <<END
return: 0
END


TEST "storage record for captured UI state" StateMapGroupingStorage_test <<END
return: 0
END


PLANNED "Concept demonstration: retrieve session contents" SessionStructureMapping_test <<END
return: 0
END


PLANNED "Concept demonstration: update hierarchical elements" TangibleUpdate_test <<END
return: 0
END
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely. 2013-01-07 05:43:01 +01:00			`TESTING "Component Test Suite: GUI Model Parts" ./test-suite --group=gui`
Add GUI/model tests fixtures 2010-12-24 03:51:57 +01:00
enable special unit-tests to link against the gui 2014-10-18 04:27:07 +02:00

			`TEST "Self-check: testing GUI backbone parts" TestGui_test <<END`
			`return: 0`
Add GUI/model tests fixtures 2010-12-24 03:51:57 +01:00			`END`

WIP: pondering diff representation variants Actually I arried at the conclusion, that the receiving of a diff representation is actually a typical double-dispatch situation. This leads to the attempt to come up with a specialised visitor as standard pattern to handle and apply a diff. Obviously, we do not want the classical GoF-Visitor, but (yes, we had that discussion allready) -- well in terms of runtime cost, we have to deal with at least two indirections anyway; so now I'm exploring the idea to implement one of these indirections through a functor object, which at the same time acts as "Tag" in the diff representation language (instead of using an enum as tag) 2014-11-10 04:00:39 +01:00
Finish AbstractTangible_test and the basic UI-Element protocol closes #975 and #992 2016-10-04 03:50:44 +02:00			`TEST "the abstracted tangible UI element" AbstractTangible_test <<END`
WIP: pondering diff representation variants Actually I arried at the conclusion, that the receiving of a diff representation is actually a typical double-dispatch situation. This leads to the attempt to come up with a specialised visitor as standard pattern to handle and apply a diff. Obviously, we do not want the classical GoF-Visitor, but (yes, we had that discussion allready) -- well in terms of runtime cost, we have to deal with at least two indirections anyway; so now I'm exploring the idea to implement one of these indirections through a functor object, which at the same time acts as "Tag" in the diff representation language (instead of using an enum as tag) 2014-11-10 04:00:39 +01:00			`return: 0`
			`END`

extended planning to define the operation of UI-Bus and model update this includes a decision about the tree diff representation and handling format 2015-01-17 16:08:56 +01:00
test driven planning next steps will be to invent a mock UI element and then to wire and operat this mock through the UI-Bus 2015-11-26 22:23:43 +01:00			`PLANNED "building block of the UI-Bus" BusTerm_test <<END`
extended planning to define the operation of UI-Bus and model update this includes a decision about the tree diff representation and handling format 2015-01-17 16:08:56 +01:00			`return: 0`
			`END`


state manager storage implemented and covered by unit test sigh. If you want to feel slick and cool, never dare to write any unit test.... 2016-02-13 22:54:41 +01:00			`TEST "storage record for captured UI state" StateMapGroupingStorage_test <<END`
			`return: 0`
			`END`


test driven planning next steps will be to invent a mock UI element and then to wire and operat this mock through the UI-Bus 2015-11-26 22:23:43 +01:00			`PLANNED "Concept demonstration: retrieve session contents" SessionStructureMapping_test <<END`
			`return: 0`
Add GUI/model tests fixtures 2010-12-24 03:51:57 +01:00			`END`


test driven planning next steps will be to invent a mock UI element and then to wire and operat this mock through the UI-Bus 2015-11-26 22:23:43 +01:00			`PLANNED "Concept demonstration: update hierarchical elements" TangibleUpdate_test <<END`
			`return: 0`
Add GUI/model tests fixtures 2010-12-24 03:51:57 +01:00			`END`