Lumiera  0.pre.03
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Modules Pages
AbstractTangible_test Class Reference


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

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

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

Private Member Functions

void invokeCommand ()
void markState ()
void mutate ()
void notify ()
virtual void run (Arg)
void verify_mockManipulation ()

Static Private Member Functions

static string memLocation (Tangible &uiElm)

Member Function Documentation

virtual void run ( Arg  )

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

References AbstractTangible_test::invokeCommand(), AbstractTangible_test::markState(), AbstractTangible_test::mutate(), AbstractTangible_test::notify(), and AbstractTangible_test::verify_mockManipulation().

+ Here is the call graph for this function:

void verify_mockManipulation ( )
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.


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 gui::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 210 of file abstract-tangible-test.cpp.

References EventMatch::arg(), EventMatch::before(), MockElm::ensureNot(), Nexus::getLog(), util::join(), MockElm::joinLog(), MARK_TEST_FUN, MockElm::verify(), and EventLog::verify().

Referenced by AbstractTangible_test::run().

+ Here is the call graph for this function:

+ Here is the caller graph for this function:

void invokeCommand ( )

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

References proc::control::test::command1::capture(), Command::get(), Tangible::invoke(), util::join(), MARK_TEST_FUN, proc::control::test::command1::operate(), CommandDef::operation(), Nexus::setCommandHandler(), Nexus::startNewLog(), util::toString(), Command::undo(), and proc::control::test::command1::undoIt().

Referenced by AbstractTangible_test::run().

+ Here is the call graph for this function:

+ Here is the caller graph for this function:

void markState ( )
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.

maybe we'll even provide a default implementation for expand/collapse which then means that, by replaying the mentioned state marks, the doExpand() or doCollapse() should be re-invoked, of course without issuing a further notification
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 374 of file abstract-tangible-test.cpp.

References EventMatch::afterEvent(), EventMatch::arg(), EventMatch::beforeCall(), EventMatch::beforeEvent(), MockElm::ensureNot(), MockElm::getID(), MockElm::getLog(), MockElm::isExpanded(), MockElm::isTouched(), util::join(), MARK_TEST_FUN, Tangible::slotCollapse(), Tangible::slotExpand(), Nexus::startNewLog(), Nexus::testUI(), MockElm::verifyCall(), MockElm::verifyEvent(), and MockElm::verifyMark().

Referenced by AbstractTangible_test::run().

+ Here is the call graph for this function:

+ Here is the caller graph for this function:

void notify ( )
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 481 of file abstract-tangible-test.cpp.

References EventMatch::before(), MockElm::ensureNot(), MockElm::getError(), MockElm::getID(), MockElm::getLog(), MockElm::getMessage(), MockElm::isError(), util::isnil(), util::join(), MARK_TEST_FUN, Time::NEVER, Tangible::reset(), Nexus::startNewLog(), Nexus::testUI(), MockElm::verify(), VERIFY_ERROR, and MockElm::verifyMark().

Referenced by AbstractTangible_test::run().

+ Here is the call graph for this function:

+ Here is the caller graph for this function:

void mutate ( )
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. Note especially how child UI elements are added this way, 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

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

References MockElm::attrib, Ref::ATTRIBS, EventMatch::beforeCall(), EventMatch::beforeEvent(), Record< VAL >::Mutator::genNode(), MockElm::getID(), MockElm::getLog(), util::isnil(), util::join(), MARK_TEST_FUN, AbstractTangible_test::memLocation(), EventMatch::on(), MockElm::scope, Nexus::startNewLog(), Nexus::testUI(), and MockElm::verifyEvent().

Referenced by AbstractTangible_test::run().

+ Here is the call graph for this function:

+ Here is the caller graph for this function:

static string memLocation ( Tangible uiElm)

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

References lib::idi::instanceTypeID().

Referenced by AbstractTangible_test::mutate().

+ Here is the call graph for this function:

+ Here is the caller graph for this function:

+ Inheritance diagram for AbstractTangible_test:
+ Collaboration diagram for AbstractTangible_test:

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