AbstractTangible_test Class Reference

Description

Test:

cover the basic operations of any tangible UI element, with the help of a mock UI element.

• creation
• destruction
• command invocation
• state mark
• state mark replay
• message casting
• error state indication
• structural changes by MutationMessage

This test documents a generic interaction protocol supported by all "tangible" elements of the Lumiera GTK UI. This works by connecting any such element to a messaging backbone, the UI-Bus. By sending messages according to this protocol, typical state changes can be detected and later be replayed on elements addressed by ID. Moreover, the preconfigured commands offered by the session can be invoked via bus message, and it is possible to populate and change UI elements by sending a tree diff message

Note

the actions in this test are verified with the help of an EventLog built into the mock UI element and the mock UI-Bus counterpart. Additionally, each test case dumps those log contents to STDOUT, which hopefully helps to understand the interactions in detail.

See also

BusTerm_test

DiffTreeApplication_test

tangible.hpp

ui-bus.hpp

Definition at line 173 of file abstract-tangible-test.cpp.

Private Member Functions
void	invokeCommand ()
void	markState ()
void	mutate ()
void	notify ()
void	revealer ()
virtual void	run (Arg)
void	verify_mockManipulation ()

Static Private Member Functions
static string	memLocation (Tangible &uiElm)

Member Function Documentation

verify_mockManipulation()

void verify_mockManipulation ( )

inlineprivate

Test:

verify the UI widget unit test support framework.

The generic backbone of the Lumiera UI offers a mock UI element, with the ability to stand-in for actual elements present in the real GUI. This allows us to rig an emulated test user interface to cover interactions involving some communication from or to interface elements. After setting up a mock UI-element with a suitable name / ID, we're able to operate this element programmatically and to send messages and responses from the core "up" to this mocked interface. And since this mock element embodies an event log, the unit test code can verify the occurrence of expected events, invocations and responses.

connectivity

Any mock element will automatically connect against the Test-Nexus, so to be suitably rigged for unit testing. This means, there is no live connection to the session, but any command- or other messages will be captured and can be retrieved or verified from the test code. Since lifecycle and robustness in "post mortem" situations tend to be tricky for UI code, we provide a dedicated stage::test::TestNexus::zombificatezombification" feature": a MockElm can be turned into an almost dead state, while still hanging around. It will be detached from the "living" Test-Nexus and re-wired to some special, hidden "Zombie Nexus", causing any further messaging activity to be logged and ignored.

Definition at line 211 of file abstract-tangible-test.cpp.

References EventMatch::arg(), EventMatch::before(), MARK_TEST_FUN, and EventLog::verify().

Here is the call graph for this function:

markState()

void markState ( )

inlineprivate

Test:

mark interface state.

This test case performs an elementary UI operation, namely to expand / collapse an element, to verify both directions of state marking. Here »state marking« is a mechanism, where UI state changes get recorded at some central StateManager, to be able to restore interface state later. Thus, when we'll expand and collapse the mock, we expect the corresponding "state mark" notifications to appear at the UI-Bus.

The second part of this test replays such a state mark, which causes thedoMark() operation on the UI element to be invoked.

Note

this test does not cover or even emulate the operation of the "state manager", since the goal is to cover the UI element protocol. We'll just listen at the bus and replay messages.

Definition at line 371 of file abstract-tangible-test.cpp.

References EventMatch::arg(), EventMatch::beforeCall(), EventMatch::beforeEvent(), MARK_TEST_FUN, Tangible::slotCollapse(), Tangible::slotExpand(), Nexus::testUI(), and MockElm::verifyMark().

Here is the call graph for this function:

revealer()

void revealer ( )

inlineprivate

Test:

configure a handler for the (optional) "reveal yourself" functionality.

We install a lambda to supply the actual implementation action, which can then either be triggered by a signal/slot invocation, or by sending a "state mark".

Definition at line 478 of file abstract-tangible-test.cpp.

References EventMatch::afterCall(), EventMatch::arg(), EventMatch::beforeCall(), EventMatch::beforeEvent(), Tangible::installRevealer(), MARK_TEST_FUN, Tangible::slotExpand(), Tangible::slotReveal(), Nexus::testUI(), and MockElm::verifyMark().

Here is the call graph for this function:

notify()

void notify ( )

inlineprivate

Test:

receive various kinds of notifications.

Send message, error and flash messages via Bus to the element and verify the doMsg, doErr or doFlash handlers were invoked.

Definition at line 562 of file abstract-tangible-test.cpp.

References MARK_TEST_FUN, and Nexus::testUI().

Here is the call graph for this function:

mutate()

void mutate ( )

inlineprivate

Test:

mutate the mock element through diff messages This test performs the basic mechanism used to populate the UI or to change structure or settings within individual elements.

This is done by sending a MutationMessage via UI-Bus, which is handled and applied to the receiver by Lumiera's diff framework.

This test uses the MockElem to simulate real UI elements; to be able to verify the diff application, MockElm is already preconfigured with a diff binding, and it exposes a set of attributes and a collection of child mock elements. Basically, the diff mechanism allows to effect structural changes within an otherwise opaque implementation data structure. For this to work, the receiver needs to create a custom diff binding. Thus, each subclass of Tangible has to implement the virtual function Tangible::buildMutator() and hook up those internal structures, which are exposed to changes via diff message. This is what we then call a "diff binding" (and MockElement is already outfitted this way). Note especially how child UI elements can be added recursively, allowing gradually to populate the contents of the UI.

The diff itself is an iterable sequence of diff verbs. Typically, such a diff is generated as the result of some operation in the Session core, or it is created by comparing two versions of an abstracted object description (e.g. session snapshot).

Here in this test case, we use a hard wired diff sequence, so we can check the expected structural changes actually took place.

See also

MutationMessage_test

Definition at line 660 of file abstract-tangible-test.cpp.

References MARK_TEST_FUN.

Inheritance diagram for AbstractTangible_test:

Collaboration diagram for AbstractTangible_test:

---

The documentation for this class was generated from the following file:

• abstract-tangible-test.cpp