ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/gui
History
Ichthyostega 20ecc3f0d0 DI: allow to trigger the lazy instantiation of a mock service instance directly 
Basically the mocking mechanism just switches the configuration
and then waits for the service to be accessed in order to cause acutual
instantiation of the mock service implementation. But sometimes we want
to prepare and rig the mock instance prior to the first invocation;
in such cases it can be handy just to trigger the lazy creating process
2018-04-08 18:43:27 +02:00
..
ctrl DI: allow to trigger the lazy instantiation of a mock service instance directly 2018-04-08 18:43:27 +02:00
interact ElementAccess: initial brainstorming about the interface mechanics 2018-04-07 02:28:29 +02:00
test ElementAccess: draft simple lookup interface 2018-04-08 18:43:27 +02:00
abstract-tangible-test.cpp Modernise Unknown Exception handler and Exception messages 2018-04-02 01:48:51 +02:00
bus-term-test.cpp Library: replace boost::noncopyable by our own library solution 2018-03-24 05:35:13 +01:00
gen-node-location-query.hpp ElementAccess: initial brainstorming about the interface mechanics 2018-04-07 02:28:29 +02:00
README enable special unit-tests to link against the gui 2014-10-18 04:27:07 +02:00
session-structure-mapping-test.cpp DockAccess: analysis continued... 2017-09-08 03:53:52 +02:00
test-gui-test.cpp Doxygen: magically insert a reference to the test class 2017-02-22 03:17:18 +01:00

README 

GUI backbone tests

The tests in this subtree are a bit special: they cover the generic and
backbone internals of the Lumiera GTK GUI. They are linked against the
complete GUI-module (gui plugin), and thus may use all related ABIs.

Yet these tests are *deliberately* compiled without any GTK, GTKmm or SigC
includes. This effectively rules out the use, even indirectly, of any GTK
widgets and APIs -- forcing the covered GUI backbone entities to stay
clean and generic at API level.

This is a decision done on purpose. The concrete GUI framework technology
shall be treated as an implementation detail. There is no point in writing
tests which click buttons in the GUI -- better delegate any significant
logic or functionality to GUI agnostic components. GUI is meant to be
a presentation layer and must not develop intelligence on its own.