Lumiera  0.pre.03
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Modules Pages
Test List
Class AbstractTangible_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
Member AbstractTangible_test::markState ()
mark interface state.
Member AbstractTangible_test::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.
Member AbstractTangible_test::notify ()
receive various kinds of notifications.
Member AbstractTangible_test::verify_mockManipulation ()
verify the UI widget unit test support framework.
Class AccessCasted_test
verify a helper template for accessing values either through conversion or (dynamic) downcast. Typically, this helper is used in value holder containers or variant-like data structures, where the actual type is given at instantiation time of the template and possibly erased.
Class AddClip_test
adding an test clip to the Model/Session.
See also
Class AdviceBasics_test
proof-of-concept for the Advice collaboration. Advice allows data exchange without coupling the participants tightly. This test demonstrates the basic expected behaviour in a simple but typical situation: two unrelated entities exchange a piece of data just by referring to a symbolic topic ID.
Member AdviceBasics_test::createCollaboration ()
multiple ways how to initiate the advice collaboration
Member AdviceBasics_test::overwriting_and_retracting ()
changing the provided advice, finally retracting it, causing fallback on the default value. Any given advisor can connect to the advice system with multiple bindings consecutively. The connection has no identity beside this binding, so another server (advisor) can step into an existing connection and overwrite or retract the advice. Unless retracted, advice remains in the system, even after the advisor is gone.
Member AdviceBasics_test::simpleExchange ()
the very basic usage situation: the advisor sets an information value and the advised entity picks it up.
Class AdviceBindingPattern_test
the pattern matching machinery used to find an Advice solution. Each advice::Provision and advice::Request specifies a binding, used to discern various pieces of advice. Whenever patterns on the two sides match, an Advice channel is created, causing the advice provision to get visible to the advised entity.
Member AdviceBindingPattern_test::verifyDynamicMatch ()
match against patterns containing variables, verify the created solution arguments
Class AdviceConfiguration_test
this is a collection of tests to cover the configuration options available as policy arguments when establishing the collaboration.
  • default advice values, or blocking or throwing
  • using activation signals on both sides
  • dispatch without locking (TODO any chance we can cover this by test??)
  • more to come....
Member AdviceConfiguration_test::blockOnAdvice ()
instead of allowing default advice values, both sides may enter a blocking wait until an advice solution is available. This is implemented as special case of using signals
Member AdviceConfiguration_test::checkDefaultAdvice ()
typically, advice is a default constructible value, so there is a natural fallback in case no active advice provision exists. Alternatively we may specify to throw.
Member AdviceConfiguration_test::checkSignals ()
when opening the advice collaboration, both sides may independently install a signal (callback functor) to be invoked when the actual advice solution gets established.
Class AdviceIndex_test
the Advice system uses an index datastructure to support matching the bindings to get pairs of participants to connect by an individual advice channel.
Class AdviceMultiplicity_test
stress test for the Advice system: Concurrently add a multitude of advice provisions and check correct matching and dispatch of all advice.
Member AdviceMultiplicity_test::check_highLoadSimpleMatch ()
run simple pairs of collaborators in multiple threads. Intentionally, there should be just a single match per pair, but the timings of provision and pickup are chosen randomly
Member AdviceMultiplicity_test::check_multipleMatch ()
here, one advice might reach multiple advised entities and one entity may receive multiple pieces of advice, overwriting previous advice provisions. The receiving clients (advised entities) are polling irregularly, but finally should each pick up the correct value. To check this, advice values are generated with a specific pattern, which can be check summed
Member AdviceMultiplicity_test::check_unlockedDispatch ()
when dispatching Advice, some of the locking can be left out. Obviously this means we can't be sure anymore the client will see the newly dispatched piece of advice. But the main focus of this test is to ensure the advice system itself is working properly even without complete locking. To verify the results, each thread performs a kind of "flush" (actually creates a memory barrier) before picking up the final value
Class AdviceSituations_test
documentation of the fundamental usage scenarios envisioned in the Advice concept. This test will be augmented and completed as the Lumiera application matures.
Member AdviceSituations_test::check_DependencyInjection ()
usage scenario: dependency injection for tests
Member AdviceSituations_test::check_ProxyRenderingAdvice ()
usage scenario: switch a processing node into proxy mode.
Class AllocationCluster_test
verify the proper workings of our custom allocation scheme managing families of interconnected objects for the segments of the low-level model.
Member Appconfig_test::fetchSetupValue ()
accessing a value from setup.ini
Class ArgumentTupleAccept_test
Build a test object, which accepts a bind(...) call with specifically typed arguments.
Class AssetCategory_test
checking the properties of Asset Category structs. They are included in the Asset::Ident identification tuple of Assets and can be used to organize Assets into a tree like structure
Class BasicPipe_test
basic properties of Pipe (structural) Assets.
Class BufferMetadata_test
verify the properties of the BufferMetadata records used internally within BufferProvider to attach additional organisational data to the exposed buffers.
Member BufferMetadata_test::verifyStandardCase ()
simulate a standard buffer provider usage cycle
to get the big picture, please refer to BufferProviderProtocol_test::verifyStandardCase() This testcase here performs precisely the metadata related operations necessary to carry out the standard case outlined on a higher level in the mentioned test.
Class BufferMetadataKey_test
verify calculation and relations of Buffer metadata type keys. These are used internally within the standard implementation of BufferProvider to keep track of various kinds of buffers, to provide a service for attaching metadata, e.g. a state flag. These metadata key entries are based on chained hash values, thus forming sort-of a "type" hierarchy.
  • the actual BufferProvider instance-ID is the top level
  • second level is the size of the buffer required
  • optionally, custom ctor/dtor functions can be registered
  • also optionally, implementation might attach an private-ID
Class BufferProviderProtocol_test
verify and demonstrate the usage cycle of data buffers for the engine based on the BufferProvider interface. This is kind of a "dry run" for documentation purposes, because the BufferProvider implementation used here is just a diagnostics facility, allowing to investigate the state of individual buffers even after "releasing" them.
Class BuffTable_test
create a random pattern of recursive invocations, each allocating a chunk out of a global buffer table storage. After returning, each allocation should be cleanly deallocated and the internal level in the storage vector should have doped to zero again.
Class BuilderTool_test
the generic visitor pattern specialised for treating MObjects in the builder. Besides using existing MObject types (at the moment session::Clip), we create a yet-unknown new MObject subclass. When passing such to any BuilderTool subclass, the compiler enforces the definition of a catch-all function, which is called, when there is no other applicable treat(MO&) function. Note further, within the specific treat-functions we get direct references, without interfering with Placements and memory management. But from within the treat() function, we may access the wrapper object (i.e. shared_ptr, or lumiera::P or Placement) used when invoking the BuilderTool by using the protected interface on BuilderTool.
Class BuildSegment_test
the builder core functionality: create a render pipeline for a given segment of the Session/Timeline.
Class BusTerm_test
cover the standard node element (terminal element) within the UI-Bus, with the help of an attached mock UI element. Contrary to the related [ui-element test](AbstractTangible_test), here we focus on the bus side of the standard interactions.
Member BusTerm_test::attachNewBusTerm ()
build a new BusTerm and verify connectivity.
Member BusTerm_test::captureStateMark ()
collect state mark notifications from bus We use a test version of the PresentationStateManager, based on the same building blocks as the real thing
Member BusTerm_test::clearStates ()
broadcast various degrees of state reset
Member BusTerm_test::commandInvocation ()
perform the full command binding and invocation protocol
Member BusTerm_test::pushDiff ()
integration test of mutation by diff message Since this test focuses on the bus side of standard interactions, it seems indicated to emulate the complete invocation situation, which involves passing thread boundraries. The main thread running this test shall enact the role of the UI event thread (since the UI-Bus in the real application is confined to this UI thread). Thus we'll start another thread to enact the role of the Session, to produce diff messages and "cast" them towards the UI.
a defining property of this whole interaction is the fact that the diff is pulled asynchronously, which means the actual diff generation happens on callback from the UI. Access to any "session" data needs to be protected by lock in such a situation.
Member BusTerm_test::replayStateMark ()
replay previously captured state information" </dd> <dt>\anchor _test000214 Member \_internalref classgui_1_1model_1_1test_1_1BusTerm__test#a08cfefabd0d8b4a7802f4a3f53968dff "BusTerm_test::verifyNotifications" ()</dt><dd> send notifications to a distinct element, or as broadcast. </dd> <dt>\anchor _test000135 Class \_internalref classproc_1_1engine_1_1test_1_1CalcStream__test "CalcStream_test" detailed coverage of the various CalcStream flavours supported by the render engine interface.
Class CallQueue_test
verify a helper component for dispatching functors through a threadsafe queue.
  • simple usage
  • enqueue and dequeue several functors
  • multithreaded stress test
Member CallQueue_test::verify_Consistency ()
consistency of queue data handling
  • functors of various types can be mixed
  • entries are moved in and out of the queue
  • no copying whatsoever happens
  • each entry gets invoked
  • all entries are invoked in order
  • enqueuing and dequeuing can be interspersed
  • no memory leaks in bound argument data
Member CallQueue_test::verify_ThreadSafety ()
torture the CallQueue by massively multithreaded dispatch
  • start #NUM_OF_THREADS (e.g. 50) threads in parallel
  • each of those has a randomised execution pattern to add new functors and dispatch other thread's functors
Class CmdContext_test
verify the front-end for context bound commands, command argument binding and invocation state from within the UI structures.
Class CmdlineWrapper_test
for lib::Cmdline, wrapping various example cmdlines
Member CmdlineWrapper_test::testStandardCmdlineformat ()
wrapping a (albeit faked) standard commandline given as (argc, argv[])
Class CommandArgument_test
Check storage handling of the command parameters and state memento.
Member CommandArgument_test::checkArgumentComparison ()
verify the comparison operators
Member CommandArgument_test::createTuples (ArgTuples &tup)
create various argument tuples and re-access their contents
Member CommandArgument_test::serialiseArgTuples (ArgTuples &tup)
serialise and de-serialise each tuple and check validity
Member CommandArgument_test::simulateCmdLifecycle ()
simulate a complete command lifecycle with regards to the storage handling of the command parameters and state memento.
Class CommandBasic_test
basic usage of the Proc-Layer command dispatch system. Shows how to define a simple command inline and how to trigger execution and UNDO. Verifies the command action takes place and is reverted again by the UNDO function.
Class CommandBinding_test
coverage for some specific situations when binding command arguments.
Class CommandCloneBuilder_test
check creation of a command implementation clone from top level, without disclosing specific type information about the involved closure. This includes verifying sane allocation management.
this test covers a very specific low-level perspective, but on an integration level, involving TypedAllocationManager, CommandRegistry, CommandImpl, CmdClosure, StorageHolder, UndoMutation, MementoTie. Closes: Ticket #298
Member CommandCloneBuilder_test::verifySeparation (PCmdImpl orig, PCmdImpl copy)
verify the two command implementation frames are indeed separate objects without interconnection. Performing an simulated command execution-undo cycle on both instances and verify difference.
Class CommandEquality_test
cover command equality detection. Two commands are deemed equivalent, if they
  • build on the same Mutation functors
  • are either both incomplete or
  • are bound to equivalent arguments
  • hold equivalent undo state (memento) To conduct this test, we set up two sets of functions, and then build both complete command objects and command implementation facilities based on them.
Class CommandInstanceManager_test
CommandInstanceManager is responsible for providing individual clone copies from a basic command definition, to be bound with actual arguments and finally handed over to the ProcDispatcher for invocation.
Member CommandInstanceManager_test::verify_duplicates ()
there can be only one active "opened" instance The CommandInstanceManager opens (creates) a new instance by cloning from the prototype.
Member CommandInstanceManager_test::verify_extendedUsage ()
demonstrate the complete command instance usage pattern.
Member CommandInstanceManager_test::verify_fallback ()
the instance manager automatically falls back on globally registered commands, when the given ID is not and was not known locally
Member CommandInstanceManager_test::verify_instanceIdentity ()
relation of command, instanceID and concrete instance The CommandInstanceManager provides the notion of a current instance, which can then be used to bind arguments.
Member CommandInstanceManager_test::verify_lifecycle ()
verify sane command lifecycle is enforced
  • instance need to be opened (created) prior to access
  • can not dispatch an instance not yet created
  • can not create new instance before dispatching the existing one
  • can not dispatch an instance before binding its arguments
  • can not access an instance already dispatched
Member CommandInstanceManager_test::verify_simpleUsage ()
demonstrate the transparent instance generation (»fire and forget«)
  • when just specifying a global commandID and arguments, an anonymous instance will be created on-the-fly, bound and dispatched, without leaving any traces in the global or local registry
  • when dispatching a global commandID, where the corresponding prototype entry is already fully bound and ready for execution, likewise an anonymous clone copy is created and dispatched.
    these simplified use cases cover a large fraction of all usages, and most notably, the internal registry embedded within the CommandInstanceManager won't be used at all.
Class CommandMessageBinding_test
verify the simple standard usage pattern, where command arguments for binding are passed via UI-Bus message with GenNode elements. This is a simplified demonstration, but covers some tricky aspects.
  • commands may define arguments of arbitrary type, and at runtime these are initialised from the set of standard types allowed within GenNode elements. Here the Duration is initialised from a TimeSpan object
  • we support immutable argument types, which means the command binding machinery works without (re)assignment, only copy construction of argument holders into an inline buffer.
  • likewise we support to use an immutable type as captured state memento, which is demonstrated by capturing a Time value
Member CommandMutation_test::checkMutation ()
check the Mutation functor which is bound to our testFunc(int). Then create a argument closure and use this to invoke the Mutation and verify actually testFunc(param) is executed.
Member CommandMutation_test::checkStateCapturingMechanism ()
check the undo memento capturing mechanism in isolation
See also
memento-tie-test.cpp more in-depth coverage
Member CommandMutation_test::checkUndoMutation ()
check the special Mutation which is used to undo a command. This time, we use our testFunc(int) as implementation of the "undo" function; thus its parameter has now the meaning of an captured state value. Consequently this time the operation which is to be undone would have the signature void(void) . Obviously this is a rather silly "undo" function, but it is easy to check for unit testing. To carry out this test, we first have to trigger the state capturing mechanism; after that, invoking the UndoMutation will call the testFunc with the previously captured state.
Mutation and UndoMutation are value objects, but they refer to a common command state, which for this test is modelled by local variables and which for the real commands is contained in a Command-StorageHolder
Class CommandQueue_test
verify proper working of queue management used within ProcDispatcher.
  • can enqueue and dequeue command messages
  • handling of priority messages
Class CommandRegistry_test
verify sane behaviour of the relevant operations on the CommandRegistry interface. Add/remove a command instance to the index, allocate an CommandImpl frame and verify it is removed properly on ref count zero.
this test covers the internal bits of functionality, not the behaviour of the (integrated) command framework
Member CommandRegistry_test::checkAllocation (CommandRegistry &registry)
verify the allocation/de-allocation handling as embedded into the CommandRegistry operation. Simulates on low level what normally happens during command lifecycle.
Member CommandRegistry_test::checkRegistration (CommandRegistry &registry)
verify the index operation. Add, search, remove, store copy.
Class CommandSetup_test
cover the behaviour of the CommandSetup helper intended for inserting actual command definitions into the Session.
Member CommandSetup_test::verify_DefinitionRegistration ()
actually issue the definitions captured as side-effect of the preceding test.
Member CommandSetup_test::verify_DefinitionSetup ()
create some command definitions inline and verify their properties.
Member CommandSetup_test::verify_standardUsage ()
demonstrate the standard usage pattern of command definition setup
  • static CommandSetup instances are created "somewhere"
  • when the ON_GLOBAL_INIT lifecycle event is issued, all command definitions collected thus far are invoked and thus inserted into the proc::control::CommandRegistry
  • from this point on, we may access a control::Command handle corresponding to these definitions, and we may create derived instances to bind parameters and invoke the operation.
    this test assumes that the static initialisation of the test fixture indeed created CommandSetup instances, which – as a side-effect – also scheduled the corresponding functors for invocation. Moreover the test-suite main() in fact triggers the lifecycle event ON_GLOBAL_INIT, causing these test command definitions to be issued alongside with all the real session commands defined in the application.
Class CommandUse1_test
command usage aspects I: defining commands in various ways, then re-accessing those definitions, create instances, invoke them and undo the effect. Clean up finally.
Class CommandUse2_test
command usage aspects II: patterns of command invocation.
Member CommandUse2_test::check_DispatcherInvocation ()
simplified integration test of command dispatch
  • performs the minimal actions necessary to start the session loop thread
  • then issues a test command, which will be queued and dispatched by the ProcDispatcher. Like in the real application, the command executions happens in the dedicated session loop thread, and thus we have to wait a moment, after which execution can be verified.
  • finally the ProcDispatcher is signalled to shut down.
    See also
    SessionCommandFunction_test for much more in-depth coverage of this aspect
Class CommandUse3_test
command usage aspects III: elaborate handling patterns, like e.g. asynchronous or repeated invocation and command sequence bundles.
Member CompoundMedia_test::buildCompound ()
building a compound media asset by using a special factory, normally intended for loading existing sessions.
Member CompoundMedia_test::modifyCompound ()
adding and removing elementary media.
Member CompoundMedia_test::verifyClipStructure ()
create a (compound) clip from some compound media asset and verify the clip mirrors the media asset's structure
Class ConfigFlags_test
check the handling of types representing a specific configuration. Basically, this is a bitset like feature, but working on types instead of runtime values. The Goal is to detect automatically all possible defined specialisations of some template based on such configuration-tuples. This allows us to assemble the glue code for pulling data from processing nodes out of small building blocks in all possible configurations.
Member ConfigFlags_test::check_ConfigSelector ()
use the ConfigSelector template to build a set of factories, based on a set of configurations. Then invoke the appropriate factory by specifying the configuration bit code
Member ConfigFlags_test::check_filter ()
given a list of flag-tuples, we first create config-types out of them and then filter out those configs for which template Maybe is defined
Member ConfigFlags_test::check_FlagInfo ()
FlagInfo metafunction, which takes as argument a list-of-flags as well as a list-of-lists-of-flags and especially allows to apply a visitor object to the latter
Member ConfigFlags_test::check_flags ()
conversion between list-of-flags and a config-type in both directions
Member ConfigFlags_test::check_instantiation ()
creates a predicate template (metafunction) returning true iff the template Maybe is defined for the configuration in question
Class CreateAsset_test
creating new Assets and registering them with the AssetManager.
See also
Member CreateAsset_test::createMedia ()
Creating and automatically registering Asset instances. Re-Retrieving the newly created objects from AssetManager. Checking AssetManager access functions, esp. getting different kinds of Assets by ID, querying with the wrong Category and querying unknown IDs.
Member CreateAsset_test::factoryVariants ()
different variants of calling the MediaFactory, with focus on the behaviour of the basic Asset creation machinery. Covers filling out Asset's datafields, amending missing pieces of information.
Class CustomSharedPtr_test
assure correct behaviour of lumiera's custom shared-ptr, including ADL of operators, shared ownership, typing and ordering
See also
Member CustomSharedPtr_test::check_ordering ()
equality and ordering operators forwarded to pointee
Member CustomSharedPtr_test::check_refcounting ()
smart-ptr basic behaviour
Member CustomSharedPtr_test::check_shared_ownership ()
cooperation with other shared-ptr types
Member CustomSharedPtr_test::check_type_relations ()
building type relationships on smart-ptrs
Class DefsManager_test
basic behaviour of the defaults manager ("the big picture")
  • retrieving a "default" object repeatedly
  • retrieving a more constrained "default" object
  • failure registers a new "default"
  • instance management
Class DefsManagerImpl_test
verify some general assumptions regarding implementation details of the the defaults manager.
See also
DefsManager_test for the "big picture"
Class DefsRegistryImpl_test
build an registry table (just for this test) configured for some artificial test Types. Register some entries and verify the intended behaviour of the storage structure.
See also
DefsManagerImpl_test for checking the implementation details in the actual context used in Lumiera.
Class DeleteAsset_test
deleting an Asset includes removing all dependent Assets and all MObjects relying on these. Especially this means breaking all links between the involved Objects, so the shared-ptrs can do the actual cleanup.
See also
Class DeleteClip_test
removing a test clip from the Session/Model.
See also
Class DelStash_test
create a bunch of objects with varying type and size, memorising how to kill them properly. Verify everyone is dead after mass-kill. Use a checksum not only to verify the number of objects created and destroyed, but also the individual (random) contents of the data within the objects, to ensure that the correct destructor actually is invoked for each type.
Member DelStash_test::checkCustomKill ()
use a custom-provided deleter function
Class DependencyConfiguration_test
verify the various modes of creating dependencies.
  • standard case is singleton creation
  • configuration of a specific subclass for the singleton
  • expose a service with explicit lifecycle
  • use of a custom factory function
  • injection of a mock implementation for unit tests
Member DependencyConfiguration_test::verify_automaticReplacement ()
injecting test mocks temporarily
Member DependencyConfiguration_test::verify_customFactory ()
instance creation can be preconfigured with a closure Both Singleton and Test-Mock creation can optionally be performed through a user provided Lambda or Functor.
Member DependencyConfiguration_test::verify_expose_Service_with_Lifecycle ()
expose a dedicated service instance, which can be shut down
Member DependencyConfiguration_test::verify_Singleton ()
without special configuration, singletons are injected as dependency
Member DependencyConfiguration_test::verify_SubclassSingleton ()
preconfigure a specific subclass to be injected as singleton dependency
Class DependencyFactory_test
verify the various modes of creating dependencies.
  • standard case is singleton creation
  • configuration of a specific subclass for the singleton
  • use of a custom factory function
  • injection of a mock implementation for unit tests
Class DependentAssets_test
the handling of Assets dependent on other Assets and the enabling/disabling of Assets.
See also
Member DependentAssets_test::checkDependencyMechanics ()
check operation of basic asset dependency support
Member DependentAssets_test::checkEnablementPropagation ()
enabling and disabling an asset should propagate to dependant assets
Member DependentAssets_test::checkRealAssetDependencyRegistration ()
each real world asset subclass has to care for registering and deregistering any additional dependencies. Here we collect some more prominent examples (and hopefully don't fail to cover any important special cases...)
Member DependentAssets_test::checkUnlinking ()
unlink operation removing inter asset links
Class DiagnosticContext_test
verify a diagnostic facility to collect and access contextual information. DiagnosticContext frames are placed into automatic storage (as local variable within some function scope). Based on thread-local storage, the next reachable frame can be accessed from anywhere within the callstack. This feature is useful for collecting information regarding features cross-cutting the usual dependency hierarchy.
Member DiagnosticContext_test::verify_heavilyParallelUsage ()
verify the thread local property of ContextStack.
Member DiagnosticContext_test::verify_simpleAccess ()
create nested scopes and place a DiagnosticContext frame into each. Access the next reachable frame.
Class DiffComplexApplication_test
Demonstration: apply a structural change to unspecified private data structures, with the help of an dynamic adapter
  • we use private data classes, defined right here in the test fixture to represent "just some" pre-existing data structure.
  • we re-assign some attribute values
  • we add, re-order and delete child "elements", without knowing what these elements actually are and how they are to be handled.
  • we recurse into mutating such an _"unspecified"_ child element.
Class DiffIndexTable_test
Cover a simple lookup table helper, used to support diff generation. The IndexTable takes a snapshot of generic sequence data on construction. After that, it is immutable and supports lookup by element as key and membership check.
Class DiffListApplication_test
Demonstration/Concept: a description language for list differences. The representation is given as a linearised sequence of verb tokens. This test demonstrates the application of such a diff representation to a given source list, transforming this list to hold the intended target list contents.
Class DiffListGeneration_test
Demonstration/Concept: how to derive a list diff representation from the comparison of two sequences. The changes necessary to transform one sequence into the other one are given as a linear sequence of elementary mutation operations.
Class DiffTreeApplication_test
Demonstration/Concept: a description language for tree differences. The representation is given as a linearised sequence of verb tokens. In addition to the verbs used for list diffing, here we additionally have to deal with nested scopes, which can be entered thorough a bracketing construct mut(ID)...emu(ID). This test demonstrates the application of such diff sequences
  • in the first step, an empty root #Record<GenNode> is populated with a type-ID, three named attribute values, three child values and a nested child-Record.
  • the second step demonstrates various diff language constructs to alter, reshape and mutate this data structure After applying those two diff sequences, we verify the data is indeed in the expected shape.
    to follow this test, you should be familiar both with our generic data record, as well as with the variant data node. The key point to note is the usage of Record elements as payload within GenNode, which allows to represent tree shaped object like data structures.
    literally the same test case is repeated in MutationMessage_test, just there the diff is transported in a MutationMessage capsule, as is the case in the real application as well.
    See also
    DiffComplexApplication_test handling arbitrary data structures
Class Digxel_test
verify correct behaviour of an display "Digxel": A self-contained numeric element to support building displays.
  • build a Digxel
  • set a value
  • retrieve formatted display
  • verify comparisons and increments
  • performing side-effects from the setter-functor
  • formatted value caching
Member Digxel_test::checkDisplayOverrun ()
Digxel should be protected against display buffer overrun
Member Digxel_test::timingMeasurements ()
perform several timing measurements and especially verify the effect of caching formatted values.
Member Digxel_test::verifyAssignMutatingOperators ()
verify the self-assigning increment/decrement operators.
especially these need to invoke the mutator function, much like a direct assignment. We use a special mutator to protocol the previous / new value.
Class DigxelConfigurations_test
verify correctness of the predefined standard Digxels. Some widely used standard configurations, including
  • default Digxel for int and double values
  • sexagesimal Digxel
  • hex byte Digxel
  • ...more to come
Class DispatcherInterface_test
document and verify the engine::Dispatcher interface, used to translate a CalcStream into individual node jobs. This test covers the definition of the interface itself, together with the supporting types and the default implementation of the basic operations. It creates and uses a mock Dispatcher implementation.
Member DispatcherInterface_test::check_ContinuationBuilder ()
usually at the end of each standard invocation, after scheduling a chunk of new Jobs, an additional continuation job is created to re-invoke this scheduling step.
Member DispatcherInterface_test::verify_basicDispatch ()
perform the basic dispatch step and verify the generated frame coordinates
Member DispatcherInterface_test::verify_standardDispatcherUsage ()
the standard invocation sequence used within the engine for planning new jobs.
Class DispatcherLooper_test
verify encapsulated control logic of ProcDispatcher.
  • fusing of conditions for the pthread waiting condition
  • detection and handling of work states
  • management of builder run triggers
Member DispatcherLooper_test::verifyBuilderStart ()
logic to trigger the builder over a complete simulated lifecycle.
  • when Looper::requireAction is true, the thread does not go into wait state
  • in the loop body
    • either when runBuild() is true, the builder run is triggered
    • or when isWorking() is true, the next command is processed
  • after that, Looper::markStateProcessed proceeds the state machine
    this test actually has to sleep in order to verify triggering a timeout
Class DuckDetector_test
verify building predicates to detect properties of a type at compile time. Especially, this allows us to detect if a type in question
  • has a nested type with a specific name
  • has a member with a specific name
  • defines a function with a specific signature
Class DuckDetectorExtension_test
demonstrate some details regarding detection of functions within a type. The purpose of these metaprogramming techniques is to write generic containers, handlers, iterators etc, which automatically adapt themselves to the abilities of their payload type. To give an example, we may investigate the argument type of a functor or lambda, and then compose it with a suitable adapter or converter to work with the given data.
Member DuckDetectorExtension_test::detect_freeFunctionADL_ExtensionPoint ()
detect the presence of a free function extension point at compile time.
Member DuckDetectorExtension_test::detect_memberFunctionVariations ()
cover variations of member function detection
  • detect an explicitly given full signature
  • detect just the presence of a function name
  • distinguish this from detecting a member
  • detect especially a member function without arguments
    some corner cases are demonstrated here as well:
  • private functions can not be detected
  • detection fails on ambiguity due to overloads
Class DummyPlayConnection_test
verify the OutputSlot interface and base implementation by performing full data exchange cycle. This is a kind of "dry run" for documentation purposes, both the actual OutputSlot implementation as the client using this slot are Mocks.
Class DummySessionConnection_test
verify scaffolding used to develop the actual connection between the UI, the UI-Bus, the core services in the UI and the Session.
  • weakness of WIP-WIP-WIP
Member DummySessionConnection_test::demonstrate_weakness ()
demonstrate a serious weakness of When...
Class EngineInterface_test
cover the basic service exposed at the engine interface: create a calculation stream and verify the translation into individual jobs.
Class EntryID_test
proof-of-concept test for a combined symbolic and hash based ID.
  • create some symbolic IDs
  • check default assignment works properly
  • check comparisons
  • check hashing
  • use the embedded hash ID (LUID) as hashtable key
Member EntryID_test::buildHashtable ()
build a hashtable, using EntryID as key, thereby using the embedded hash-ID
there is a known weakness of the boost::hash when used on IDs with a running number suffix. /////TICKET #587 We use a trick to spread the numbers better.
See also
Member EntryID_test::checkErasure ()
handling of EntryIDs through their common base class, which means erasing the specific type information. While this type information can't be recovered after erasure, we can try to upcast back to a known type; this upcast is safe, because the embedded hash-ID is based on the type info.
Member ExceptionError_test::checkErrorFlagPropagation ()
verify throwing of Exceptions based on a non-cleared C error flag
Member ExceptionError_test::checkErrorIntegration ()
by constructing an lumiera::Error object, the corresponding lumiera_error state is set automatically
Member ExceptionError_test::checkRootCauseChaining ()
the chaining of lumiera::Exception objects and the retrieval of the original root cause.
Member ExceptionError_test::doubleNestedTh (string msg)
repeated repackaging and rethrowing
Member ExceptionError_test::nestedThrower (string msg)
catching, repackaging and rethrowing of errors. This feature is important for passing exceptions transparently over several layers. The nested operation will throw an error::External, which we are able to catch because it is derived from std::exception. We don't need to know the exact type, but we can classify the error situation as a "state error" and throw an error::State, passing on the root cause. Some levels up, this error get caught and the root cause can be extracted successfully.
Member ExceptionError_test::terminateUnknown () noexcept
terminate the Application by throwing an undeclared exception. this should result in the global unknown() handler to be called, so usually it will terminate the test run.
inside error.hpp, an initialisation hook has been installed into AppState, causing our own unknown() handler to be installed and invoked, which gives additional diagnostics.
Member ExceptionError_test::throwSpecial (string)
simply throw some exception and pass context info
Class FixtureChangeDetector_test
planned test for detecting changes in a given segmentation
Class FormatCOUT_test
How to build generic string conversion into ostream::operator<<. This task (#985) was actually a conglomerate of several chores:
  • sanitise and segregate the type-traits usage
  • disentangle the existing util::str() conversion helper
  • extract a basic form from this helper, which can be placed into a header with minimal dependencies. After some consideration, I decided to allow <typeinfo> in this category, which allows us at least to show a type name as fallback
  • distill an essential version of enable_if, which can be inlined. This allowed us to get rid of boost::enable_if finally.
  • build a sensible operator string() for our lib::P based on this
  • and finally, to come up with a templated version of the ostream inserter operator<<, which does not cause too much havoc when used by default. The greatest challenge here is to avoid ambiguous overloads, yet also to deal with references, void and arrays.
Class FormatHelper_test
verifies the proper working of some string-formatting helper functions.
  • util::toString() provides a failsafe to-String conversion, preferring an built-in conversion, falling back to just a type string.
  • util::join() combines elements from arbitrary containers or iterators into a string, relying on aforementioned generic string conversion
    See also
Member FormatHelper_test::check2String ()
verify a failsafe to-string conversion.
Member FormatHelper_test::checkPrefixSuffix ()
convenience helpers to deal with prefixes and suffixes
Member FormatHelper_test::checkStringify ()
inline to-string converter function
  • can be used as transforming iterator
  • alternatively accept arbitrary arguments
Member FormatHelper_test::checkStringJoin ()
verify delimiter separated joining of arbitrary collections.
  • the first test uses a STL container, which means we need to wrap into a lib::RangeIter. Moreover, lexical_cast is used to convert the double numbers into strings.
  • the second test uses an inline transforming iterator to build a series of AutoCounter objects, which provide a custom string conversion function. Moreover, since the transforming iterator conforms to the Lumiera Forward Iterator concept, we can just move the rvalue into the formatting function without much ado
Class FormatString_test
verifies our front-end for printf-style format string based formatting.
  • the implementation is based on boost::format
  • we create a wrapper-object on-the fly, which is able to hold the result of a partial invocation, until all parameters are given.
  • explicit specialisations feed all primitive types directly down into the implementation level. If possible, a custom operator string() will be used for formatting.
  • exceptions will be logged, but handled gracefully
Class FormatSupport_test
check how support for a specific timecode format can be enabled and detected. Actually this test verifies a simple metaprogramming facility, which allows to check type support at runtime.
Class FunctionClosure_test
building a function closure for a given function or functor, while arguments are passed in as tuple
  • accessing signatures as typelists
  • apply free function to tuple
  • apply functor to tuple
  • bind free function to tuple
  • bind functor to tuple
  • build a simple "tuple closure"
Class FunctionComposition_test
this test covers some extensions and variations on function closures:
  • partial application of a function, returning a partial closure
  • variation: binding an arbitrary term, might even be a nested binder
  • chaining of two functions with suitable arguments ("composition")
Class FunctionErasure_test
Create specifically typed functor objects and then wrap them into common holder objects, thereby discarding the specific signature type information. Later on, the concrete functor can be re-accessed, given the exact and specific type.
Class FunctionSignature_test
verify metaprogramming trait to pick up function signature types.
  • ability to handle function like entities uniformly
  • can handle function references, function pointers, member pointer to function, functor objects, std::function and lambdas
  • supports arbitrary number of arguments
    See also
Class FunctorUtil_test
verify some aspects of the functor-util's behaviour. At times, this is just a scrapbook for new ideas....
Member FunctorUtil_test::verifyBruteForceComparison ()
workaround for the missing functor comparison operator
Member FunctorUtil_test::verifyHashThroughBackdoor ()
workaround for missing standard hash calculation for functor objects. Workaround relying on boost implementation internals
Class GeneratorCombinations_test
check utilities for generating case combinations.
  • verify the Cartesian product is built properly
  • instantiate a two-parameter test template for all those cases, as given by the Cartesian product of two Type collections
Class GenericIdFunction_test
cover a standard scheme to generate type and instance identifiers.
Class GenericRecordRepresentation_test
Verify properties of a special collection type meant for external representation of object-like data, especially for symbolic representation in diff messages.
  • there is a type meta attribute
  • a Record can have attributes (by key) and contents (ordered list of values)
  • various kinds of iterators are provided
  • besides the regular constructor, which explicitly takes a type, a collection of attributes, and a collection of contents, there is a convenience constructor especially for literal notation and data definition. This one figures out the break between attributes and contents automatically; a type meta attribute is recognised and the first element without a given key or ID ends the attributes and starts the content scope
  • Record elements are conceived as values and equality is defined in terms of their contents, including the order (no normalisation, no sorting)
  • they are immutable after construction. But we provide a Mutator for remoulding a given element, enabling object builder notation.
  • a reference wrapper for handling of large structures is provided.
    this test uses the specialisation Record<string> solely, to cover the basic properties and behaviour, while leaving out the complexities of specific payload data types. For the actual use case, the symbolic description of data structure differences, we use a specific "value" within Record, the diff::GenNode, which is a limited typesafe Variant element, and in turn allows Record<GenNode> as embedded payload. Effectively this creates a "recursive data type", which is key to typesafe functional processing of unlimited data structures. The design of diff::Record only makes sense with this use case in mind; most notably, we have the keys (attribute names) embedded within the value payload, which turns attributes into just another content scope with special access operations. This also explains, why we do not normalise the content in any way; content is meant to reflect other data structures, which are normalised and maintained by their owner.
Class GenNodeBasic_test
Verify properties of a special collection type shaped for external representation of object-like data.
  • GenNode elements can be created "right away", picking up the given type, assumed that the payload is one of the supported basic types.
  • optionally, GenNode elements can be named
  • unnamed elements get a marker ID plus unique number extension
  • object-like elements can be represented by using a diff:Record<GenNode> as payload. Obviously, the resulting data structure type is recursive.
  • a shortcut is provided to simplify defining empty baseline objects
  • a special notation is provided to create "id references", which can be used to stand-in for an "object" (Record). This shortcut notation is relevant for the tree diff language – used within Lumiera as "External Tree Description" of object networks.
Class HandlingPatternBasics_test
operate and verify a simple dummy command handling pattern.
this test covers mainly the behaviour of a handling pattern as a concept, not so much the behaviour of the (standard) handling pattern implementations.
Member HandlingPatternBasics_test::checkExec (PCommandImpl com)
verify the Handling pattern API: execute a command
Member HandlingPatternBasics_test::checkUndo (PCommandImpl com)
verify the Handling pattern API: undo a command
Member HandlingPatternBasics_test::useCustomHandler (PCommandImpl com)
use custom implementation of the HandlingPattern interface, rigged to verify the functions are actually invoked.
Class HandlingPatternStandardImpl_test
verify correct behaviour of all the command handling patterns provided by the default configuration of a lumiera session.
  • executing quasi synchronous
  • the throw-on-error variant
  • background execution
  • ...?
Class HashGenerator_test
cover various detail aspects regarding hash value generation
  • weakness of boost::hash
Member HashGenerator_test::demonstrate_boost_hash_weakness ()
demonstrate a serious weakness of boost::hash for strings.
Member HashGenerator_test::verify_Knuth_workaround ()
verify a well-known pragmatic trick to help with unevenly spaced hash values.
Class HashIndexed_test
proof-of-concept test for a generic hash based and typed ID struct.
  • check the various ctors
  • check default assignment works properly
  • check assumptions about memory layout
  • check equality comparison
  • extract LUID and then cast LUID back into ID
  • use the embedded hash ID (LUID) as hashtable key
Class HashStandardToBoostBridge_test
document and verify an automatic bridge to integrate boost-style hash functions with the new std::hash template. Currently (as of 2014) this requires us to "hijack" the standard library definition to defeat a static assertion, which otherwise would defeat any attempts based on SFINAE
Class HelloBug_test
cover known regressions
Class HelloWorld_test
demo of using the test framework
Class HierarchyOrientationIndicator_test
describing and rebuilding a tree structure while visiting the tree in depth first order. To keep track of the level changes during that navigation, we use an indicator to represent the relative level difference compared to the previously visited node in the tree.
Member HierarchyOrientationIndicator_test::demonstrate_tree_rebuilding ()
demonstrate how a Node tree structure can be rebuilt just based on the visitation sequence of an original tree.
Class IdentityOfAssets_test
creating several Assets and checking object identity, detection of duplicates and version handling.
See also
Member IdentityOfAssets_test::createDuplicate ()
produce an ID clash. documents the current behaviour of the code as of 9/07
Class ItemWrapper_test
use the ItemWrapper to define inline-storage holding values, pointers and references. Verify correct behaviour in each case, including (self)assignment, empty check, invalid dereferentiation.
Member ItemWrapper_test::verifyFunctionRefResult ()
verify an extension built on top of the ItemWrapper: a function which remembers the last result. Here we use a test function, which picks a member of an vector and returns a reference to it. Thus the cached "result" can be used to access and change the values within the original vector. In a real world usage scenario, such a function could be an (expensive) data structure access.
Member ItemWrapper_test::verifyFunctionResult ()
verify an extension built on top of the ItemWrapper: a function which remembers the last result. As a simple test, we bind the rand() standard lib function and remember the last returned random value.
Member ItemWrapper_test::verifySaneInstanceHandling ()
verify that ctor and dtor calls are balanced, even when assigning and self-assigning.
Member ItemWrapper_test::verifySaneMoveHandling ()
proper handling of move and rvalue references
Member ItemWrapper_test::verifyWrappedRef ()
verify especially that we can wrap and handle a reference "value" in a pointer-like manner
Class IterableClassification_test
verify the (static) classification/detection of iterables. Currently (1/10) we're able to detect the following
  • a STL like container with begin() and end()
  • a Lumiera Forward Iterator This test just retrieves the results of a compile time execution of the type detection; thus we just define types and then access the generated meta function value.
Class IterAdapter_test
set up example implementations based on the iterator-adapter templates and verify the behaviour in accordance to the concept "lumiera forward iterator"
Member IterAdapter_test::enumerate ()
enumerate all number within a range
Member IterAdapter_test::exposeDataAddresses ()
build an iterator to expose the address of underlying data elements
Member IterAdapter_test::iterTypeVariations (TestContainer &elms)
verify the const and dereferencing variants, which can be created based on IterAdapter
Member IterAdapter_test::simpleUsage (CON &elms)
use the IterAdapter as if it was a STL iterator
Member IterAdapter_test::verifyComparisons (TestContainer &elms)
iterator comparison, predicates and operators
Member IterAdapter_test::wrapIterRange ()
usage scenario, where we allow the client to access a range of elements given by STL iterators, without any specific iteration behaviour.
Class IterAdapterSTL_test
verify some of the adapters to expose typical container usage patterns as Lumiera Forward Iterators.
  • distinct values from a sequence
  • keys and values of a map / multimap
  • distinct keys from a multimap
  • multimap values associated with a given key
  • snapshot of an iterator, to be retrieved as iterator
Class IterCursor_test
demonstrate and cover the properties of IterCursor. This wrapper allows to change between iterating forward and backwards.
Member IterCursor_test::iterTypeVariations ()
verify the const and dereferencing variants, based on the const-ness of the underlying STL iterator
Member IterCursor_test::simpleIteration ()
just iterate in various ways.
Member IterCursor_test::switchDirection ()
verify the ability of IterCursor to switch the direction of the iteration.
Member IterCursor_test::verifyComparisons (IT const &ii)
verify equality handling and NIL detection for the given iterator/wrapper handed in.
the argument is not altered; rather we create several copies, to iterate and compare those
Class IterExplorer_test
use a simple source iterator yielding numbers to build various functional evaluation structures, based on the IterExplorer template.
  • the verifyStateAdapter( "state adapter" ) iterator construction pattern
  • helper to verifyChainedIterators( "chain iterators" )
  • building verifyDepthFirstExploration( "tree exploring structures")
  • the verifyMonadOperator( "monadic nature") of IterExplorer
  • a verifyRecrusiveSelfIntegration( "recursively self-integrating") evaluation pattern
Member IterExplorer_test::verifyBreadthFirstExploration ()
a breadth-first visiting and exploration scheme of a tree like system, built on top of the IterExplorer monad.
Member IterExplorer_test::verifyChainedIterators ()
verify a helper to chain a series of iterators into a "flat" result sequence.
Member IterExplorer_test::verifyDepthFirstExploration ()
a depth-first visiting and exploration scheme of a tree like system, built on top of the IterExplorer monad.
Member IterExplorer_test::verifyMonadOperator ()
cover the basic monad bind operator, which is used to build all the specialised Iterator flavours.
Member IterExplorer_test::verifyRawChainedIterators ()
variation of the iterator chaining facility.
Member IterExplorer_test::verifyRecursiveSelfIntegration ()
verify a variation of recursive exploration, this time to rely directly on the result set iterator type to provide the re-integration of intermediary results.
Member IterExplorer_test::verifyStateAdapter ()
demonstrate the underlying solution approach of IterExplorer.
Class IterQueue_test
cover an easy to use queue, built as convenience wrapper on top of std::deque and allowing element retrieval by iteration.
  • iterable according to the Lumiera Forward Iterator concept
  • can enqueue and dequeue elements repeatedly
  • can be loaded through an generic builder API.
Class IterSource_test
create some (opaque) data sources, and then pull the data out by iteration.
Member IterSource_test::verify_singleValIter ()
an IterSouce which returns just a single value once
Member IterSource_test::verify_transformIter ()
verify transforming an embedded iterator This test not only wraps a source iterator and packages it behind the abstracting interface IterSource, but in addition also applies a function to each element yielded by the source iterator.
Class IterStack_test
cover behaviour of a convenience class built by using a std::deque as "state core" of an Lumiera IterStateWrapper.
  • iterable according to the Lumiera Forward Iterator concept
  • can push and pop values repeatedly
  • iterating and push / pop can be mixed
  • empty state detected consistently
Class IterTools_test
build combined and filtering iterators with the help of lib::IterTool.
Member IterTools_test::buildWrappedSingleElement ()
wrap an arbitrary single element as pseudo-iterator
Member IterTools_test::verify_filterExtension ()
verify the ability to extend a filter condition while in the middle of an ongoing iteration.
Member IterTools_test::verify_filterRepetitions ()
verify the helper to filter duplicate elements emitted by an source iterator. This test creates a sequence of numbers with random repetitions.
Member IterTools_test::verifyComparisons (IT const &ii)
verify equality handling and NIL detection for the given iterator/wrapper handed in
Class IterTreeExplorer_test
use a simple source iterator yielding numbers to build various functional evaluation structures, based on the IterExplorer template.
  • the verifyStateAdapter( "state adapter" ) iterator construction pattern
  • helper to verifyChainedIterators( "chain iterators" )
  • building verifyDepthFirstExploration( "tree exploring structures")
  • the verifyMonadOperator( "monadic nature") of IterExplorer
  • a verifyRecrusiveSelfIntegration( "recursively self-integrating") evaluation pattern
Member IterTreeExplorer_test::demonstrate_LayeredEvaluation ()
Demonstration how to build complex algorithms by layered tree expanding iteration
this is the actual use case which inspired the design of TreeExplorer: Search with backtracking over an opaque (abstracted), tree-shaped search space.
Member IterTreeExplorer_test::verify_asIterSource ()
package the resulting Iterator as automatically managed, polymorphic opaque entity implementing the IterSource interface.
Member IterTreeExplorer_test::verify_combinedExpandTransform ()
combine the recursion into children with a tail mapping operation.
Member IterTreeExplorer_test::verify_depthFirstExploration ()
use a preconfigured exploration scheme to expand depth-first until exhaustion.
Member IterTreeExplorer_test::verify_expandOperation ()
use a preconfigured "expand" functor to recurse into children.
Member IterTreeExplorer_test::verify_FilterIterator ()
add a filtering predicate into the pipeline.
Member IterTreeExplorer_test::verify_IterSource ()
ability to wrap and handle IterSource based iteration.
Member IterTreeExplorer_test::verify_scheduledExpansion ()
child expansion can be scheduled to happen on next iteration.
Member IterTreeExplorer_test::verify_transformOperation ()
pipe each result through a transformation function.
Member IterTreeExplorer_test::verify_wrappedIterator ()
TreeExplorer is able to wrap any Lumiera Forward Iterator
Member IterTreeExplorer_test::verify_wrappedState ()
without using any extra functionality, TreeExplorer just wraps an iterable state.
Class JobHash_test
verify the basic properties of the job and job descriptor struct; especially verify that job data is passed properly back to the closure and that a identity can be constructed based on a hash of the job's data.
Class LifeCycle_test
the global lifecycle hooks got registered, the ON_BASIC_INIT hook has been already called, while our custom callback can be triggered at our will
Class LinkedElements_test
cover our custom single linked list template, in combination with Lumiera Forward Iterators and the usage of a custom allocator.
Member LinkedElements_test::verify_nonOwnership ()
add some node elements to the LinkedElements list but without taking ownership or performing any memory management. This usage pattern is helpful when the node elements are already managed elsewhere.
we're still (intrusively) using the next pointer within the node elements. This means, that still a given node can't be member in multiple lists.
Member LinkedElements_test::verify_RAII_safety ()
to support using LinkedElements within RAII-style components, all the elements might be added in one sway, by pulling them from a Lumiera Forward Iterator. In case this is done in the ctor, any exception while doing so will trigger cleanup of all elements (and then failure of the ctor alltogether)
Class MakeClip_test
creating a Clip MObject and an associated Clip Asset from a given asset::Media.
See also
Class MaybeValue_test
Investigate various situations of using a Maybe value or option monad.
this is a testbed for experiments for the time being 11/2011
Class MediaAccessMock_test
inject a Mock object replacing the backend_interface::MediaAccessFacade. Verify if the Mock object behaves as expected when calling the Facade.
Class MementoTie_test
Verify the state capturing mechanism (memento), which is used to implement the Undo() functionality for Proc-Layer commands. Bind an undo function and a state capturing function and wire up both to store and retrieve a memento value. Verify that after closing the functions, actually state is captured by each invocation.
Class MetaUtils_test
verify basic type trait and metaprogramming helpers.
  • marker types to tell which overload the compiler picks
  • simple trait to detect the possibility of a string conversion
  • trait to detect a typelist type
Member MetaUtils_test::verify_basicTypeProbing ()
demonstrate the basic type trait detection technique:
  • we have two overloads with differing return type
  • we form a function call expression
  • by investigating the return type, we can figure out which overload the compiler picks.
Class MObjectInterface_test
cover the common behaviour of all MObjects.
the MObject interface is still very preliminary (as of 10/10). It is expected to support some kind of metadata and object serialisation
Class MObjectRef_test
properties and behaviour of the external reference-mechanism for MObjects placed into the session. We create a simple, simulated "session" (no real session datastructure) and a mock PlacementIndex. Then we add two Placements, which can be used then to build MObjectRef instances to validate their behaviour.
See also
Class ModelPortRegistry_test
create a standalone model port registry to verify the behaviour of model ports, accessed through reference handles. This test provides an example setup detached from the real usage situation within the builder. The ModelPortRegistry management interface is used to create and track a set of model ports, to be made visible by an atomic, transactional switch. The access for client code through the ModelPort frontend is then verified.
Class MultiFact_test
verify the basic usage patterns of the configurable factory template.
  • Depending on the concrete fabrication signature, the factory can produce "things" by invoking suitable fabrication functions. These functions are to be installed beforehand, and can be addressed through an ID.
  • these fabrication functions are installed per instance of the factory. Such a concrete factory configuration can be copied
  • optionally each created product can be passed through a wrapper function
  • there is a preconfigured wrapper for creating refcounting smart ptrs.
  • it is possible to define a custom wrapper function on factory setup.
    See also
Class MultiFactArgument_test
define a MultiFact (factory with dynamic registration), which accepts additional arguments and passes them through to the registered factory function(s).
we set up fabrication functions by binding the functions in such a way as to match the function signature declared in the factory; thereby one argument remains unclosed, which is the argument to be supplied on each factory invocation by the client code.
Class MultiFactSingleton_test
verify the use of the MultiFact template to access Singletons. While generally speaking the MultiFact allows us to address and invoke several "production lines" by ID, an obvious use case would be to access a "family" of singletons through this mechanism. And indeed, MultiFact::Singleton is a preconfigured shortcut for this use case. The actual singleton access factories are placed into a static context (here in the anonymous namespace above) and their access operation is wired as "factory function".
  • we use a hierarchy of test dummy objects
  • we set up a singleton factory for several subclasses
  • the registration happens automatically in the ctor
  • we verify that we indeed get the correct flavour.
Class MutationMessage_test
properties of a container to transport a diff from an abstracted source generator to an abstracted consumer.
  • this covers a standard usage scenario within Lumiera, where some producer in the Session core detects changes in session structure and sends a message to make the UI conform to the new structure
  • diff messages are hard to debug and test, since they are designed as opaque sequences to be consumed only once. Thus for we provide a snapshot decorator to offer diagnostic facilities
  • moreover we provide a simplified builder function to create hard wired diff messages in a concise way
  • and finally this test repeats the scenario of DiffTreeApplication_test, but this time the diff sequences are encapsulated as MutationMessage.
    like all the other diff related tests, this code might be hard to follow, unless you're familiar with the underlying concepts. Basically, a Diff is represented as a linearised sequence of verb tokens. Together these tokens form a diff language. The semantics of that language are oriented towards application of this diff onto a target structure. The goal is to represent structure changes without being bound to a specific data structure implementation. Yet there is one meta data representation used within the diff itself, as well as for various test and demonstration examples: the generic data record together with its variant node element. The key point to note is the (recursive) usage of Record elements as payload within GenNode, which allows to represent tree shaped object like data structures.
Member MutationMessage_test::demonstrate_standardUsage ()
demonstrate the intended usage pattern
  • a diff generation context is allocated
  • the MutationMessage takes ownership
  • and exposes the generated diff sequence
  • which is pulled during iteration
Member MutationMessage_test::demonstrate_treeApplication ()
use MutationMessage to transport and apply changes to target data
this almost literally repeats the DiffTreeApplication_test
Class NodeBasic_test
basic render node properties and behaviour.
Class NodeFabrication_test
creating and wiring various kinds of render nodes.
Class NodeOperation_test
check render node operation modes and collaboration.
Class NodeSource_test
the source reading render node.
Class NullValue_test
Access "NIL values" just by type, verify these are actually singletons and are indeed created on demand.
Class OpaqueHolder_test
use the OpaqueHolder inline buffer to handle objects of a family of types through a common interface, without being forced to use heap storage or a custom allocator.
Member OpaqueHolder_test::checkHandling (TestList &objs)
cover the basic situations of object handling, especially copy operations and re-assignments
Member OpaqueHolder_test::checkSpecialSubclass ()

OpaqueHolder with additional storage for subclass. When a subclass requires more storage than the base class or Interface, we need to create a custom OpaqueHolder, specifying the actually necessary storage. Such a custom OpaqueHolder behaves exactly like the standard variant, but there is protection against accidentally using a standard variant to hold an instance of the larger subclass.

Moreover, if the concrete class has a custom operator bool(), it will be invoked automatically from OpaqueHolder's operator bool()

Class OpaqueUncheckedBuffer_test
use an inline buffer to place objects of a subclass, without any checks. InPlaceBuffer only provides minimal service, to be covered here, including automatic dtor invocation and smart-ptr style access.
Class OptionalRef_test
verify a reference-like wrapper class, used to provide a switchable link to an already existing object.
  • bottom ref can be detected by bool check
  • access to bottom ref raises exception
  • refs can be compared
  • refs can be changed and copied
  • access to refs is secure even after destructor invocation
Class OrderingOfAssets_test
validate the equality and order relations of Asset::Ident and Asset objects.
a known problem is that only Asset smart ptrs are supported for comparison, not smartpointers of Asset subclasses. To solve this, we would either have to repeat the operator definitions, or resort to template metaprogramming tricks. Just providing templated comparison operators would generally override the behaviour of std::shared_ptr, which is not desirable.
See also
Class OutputMapping_test
create a synthetic / example mapping to verify generic mapping behaviour. We're creating a custom mapping type here, for this test only: The struct DummyDef provides a "definition context" for this custom mapping
  • there is a function to retrieve the actual target object for any target pipe stored in the mapping. In this case, we just extract the name-ID string from the pipe as result
  • as an additional sideeffect, this DummyDef::output functor also defines the Target type of this custom mapping to be std::string
  • DummyDef::buildQuery provides a template query, to be issued whenever a yet nonexistent mapping is requested. In this special case here we query for a pipe with the name "master_XXX", where XXX denotes the stream-type of the source pipe to be mapped.
Class OutputSlotProtocol_test
verify the OutputSlot interface and base implementation by performing full data exchange cycle. This is a kind of "dry run" for documentation purposes, both the actual OutputSlot implementation as the client using this slot are Mocks.
Class PathArray_test
verify abstraction wrapper to handle some char pointers in the way of a standard sequence container with iteration and range checks.
Member PathArray_test::verify_boundaries ()
cover some tricky corner cases of the bound checks and normalisation routine.
Member PathArray_test::verify_comparisons ()
verify equality comparison Equality of PathArray is based on overall size, position and normalised content.
Class PlacementBasic_test
basic behaviour of Placements and access to MObjects.
See also
Class PlacementHierarchy_test
creating placements specifically typed, forming an hierarchy of placement types which loosely mirrors the hierarchy of the pointee types. Assignments between placement of differing type, while still sharing ownership.
See also
Class PlacementIndex_test
basic behaviour of the index mechanism used to keep track of individual Placements as added to the current Session.
See also
Member PlacementIndex_test::checkContentsEnumeration (Idx index)
drill down into the tree-like structure and enumerate the contents of each element, if any
at this point, our test index holds 9 Placements, which actually refer to 3 distinct TestClip objects
  • two where installed into root scope in checkSimpleAccess()
  • one was installed below one of the above in checkTypedAccess()
  • checkScopeHandling() left back 6 instances, all pointing to the same TestClip. This can be verified in the test output (look at the use-cnt and the actual address of the pointee
Class PlacementIndexQuery_test
accessing the PlacementIndex through the generic query interface, for discovering scope contents and containing scope.
Class PlacementObjectIdentity_test
verify correct handling of object identity. Create test objects, add placements to a dummy index/session, then create PlacementRef and MObjectRef handles. Finally do cross comparisons.
Class PlacementRef_test
properties and behaviour of the reference-mechanism for Placements. We create an mock placement index and install it to be used by all PlacementRef instances while conducting this test. Then we add two dummy placements and create some references to conduct placement operations through these references.
See also
Class PlacementScope_test
basic behaviour of the nested placement search scopes. Using a pseudo-session (actually just a PlacementIndex), this test creates some nested scopes and then...
  • discovers the scope of a placement
  • finds the parent scope
  • enumerates a scope path up to root
Member PlacementScope_test::verifyEquality ()
equality of scopes is based on the ID of the scope top (Placement)
Member PlacementScope_test::verifyLookup (PPIdx sess)
for each Placement in our test "session", find the scope and verify it's in line with the index
Member PlacementScope_test::verifyNavigation (PPIdx sess)
for each element in our test session, establish the scope and retrieve the path to root, verifying the parent relationships as we go up.
this is the "raw" path, i.e as stored in the PlacementIndex, as opposed to the effective path, which might digress for meta-clips
Class PolymorphicValue_test
build a bunch of PolymorphicValue objects. Handle them like copyable value objects, without knowing the exact implementation type; moreover execute implementation internals only disclosed to the concrete subtype. Verify correctness through checksums.
Member PolymorphicValue_test::verifyCopySupportDetectionMetafunctions ()
internally, PolymorphicValue uses some metafunctions to pick a suitable code path, based on the presence of helper functions on the API of the embedded objects.
Class QuantiserBasics_test
cover the basic Quantiser API. This test uses a standalone quantiser implementation to demonstrate and verify the basic behaviour and the usage corner cases of a quantiser.
Class QueryFocus_test
handling of current query focus when navigating a system of nested scopes. Using a pseudo-session (actually just a PlacementIndex), this test accesses some nested scopes and then checks moving the "current scope". Moreover a (stack-like) sub-focus is created, temporarily moving aside the current focus and returning later on.
Member QueryFocus_test::checkNavigation (QueryFocus &focus)
move the current focus to different locations and discover contents there.
Member QueryFocus_test::manipulate_subFocus ()
side-effect free manipulation of a sub-focus, while the original focus is pushed aside (stack)
Class QueryFocusStack_test
behaviour of the stack of focus location paths. Basically this is just a stack, but has a somewhat unusual behaviour on pop(), as it considers the (intrusive) ref-count maintained within the stack frames (ScopePath instances) and cleans up unused frames. Similar to the ScopePath_test, we use a pseudo-session to create some path frames to play with.
this test executes a lot of functionality in a manual by-hand way, which in the actual application is accessed and utilised through QueryFocus objects as frontend.
Class QueryResolver_test
verify the mechanism for issuing typed queries through a generic interface, without disclosing the facility actually answering those queries. Results are to be retrieved through a Lumiera Forward Iterator.
Class QueryText_test
cover basic properties of the generic syntactical query representation.
  • build from query string
Class QueryUtils_test
check the various small helpers and utilities we utilise for dealing with ConfigQuery
Member QueryUtils_test::check_countPred ()
counting of predicates in a query (currently 4/08 regexp based...)
Member QueryUtils_test::check_extractID ()
the simple regexp extracting a parameter token
Member QueryUtils_test::check_normaliseID ()
sanitising and normalising various tokens
Member QueryUtils_test::check_removeTerm ()
the regexp based cutting of a term with given symbol
Class RebuildFixture_test
(re)building the ExplicitPlacement objects from the objects placed into the Session/Model.
See also
Class RefArray_test
build several wrappers, each based on a different storage, all providing RefArray access to a given vector. The rationale for RefArray is to expose just the interface: the data structure within the actual implementation holds subclass instances of the specified interface.
  • RefArrayVectorWrapper is a ref to an existing vector
  • RefArrayVector subclasses std::vector
  • RefArrayTable holds a fix sized table, i.e. embedded storage
Member RemoveFromSet_test::test_remove (string elems_to_remove)
populate a test set, remove the denoted elements and print the result...
Class RenderSegment_test
create a render process from a given segment of the Session. Basically this includes cooperation of all parts of the Lumiera Proc Layer. For a prepared test-Session we invoke the controller to create a render process. This includes building the render pipeline. Finally, we analyze all the created Structures.
this test doesn't cover the actual rendering.
See also
Class ReplaceableItem_test
scrutinise an adapter to snapshot non-assignable values.
  • create instantiations for various types
  • both assignable and non-assignable types
  • empty-construct and copy construct the adapter
  • perform assignments and even content swapping
  • use counting to verify proper instance management
  • compare by delegating to element comparison
Member ReplaceableItem_test::verifyNonComparableElements ()
verify we can handle elements without comparison operator
Member ReplaceableItem_test::verifyOnlyMoveConstructible ()
handle elements that allow nothing but move construction
Member ReplaceableItem_test::verifySaneInstanceHandling ()
verify that ctor and dtor calls are balanced, even when assigning and self-assigning.
Tracker uses the simple implementation for assignable values, while NonAssign uses the embedded-buffer implementation
Member ReplaceableItem_test::verifyWrappedPtr ()
verify especially that we can handle and re-"assign" an embedded pointer
Member SanitizedIdentifier_test::print_clean (const string org)
print the original and the sanitised string
Class SchedulerInterface_test
verify and demonstrate the organisation of the high-level interface for defining jobs to be invoked by the scheduler.
Member SchedulerInterface_test::demonstrate_nested_job_specification (SchedulerFrontend &scheduler)
demonstrate how a tree of dependent render jobs can be handed over to the scheduler within a single "transaction"
Class ScopedCollection_test
ScopedCollection manages a fixed set of objects, but these child objects are noncopyable, may be polymorphic, an can be created either all at once or chunk wise. The API is similar to a vector and allows for element access and iteration.
Member ScopedCollection_test::building_RAII_Style ()
using the ScopedCollection according to the RAII pattern.
Member ScopedCollection_test::building_StackStyle ()
using the ScopedCollection to hold a variable and possibly increasing number of elements, within the fixed limits of the maximum capacity defined by the ctor parameter.
Member ScopedCollection_test::verify_defaultPopulator ()
for using ScopedCollection in RAII style, several pre-defined "populators" are provided.
Member ScopedCollection_test::verify_embeddedCollection ()
simulate the typical situation of a manager owning some embedded components.
Class ScopedHolder_test
ScopedHolder and ScopedPtrHolder are initially empty and copyable. After taking ownership, they prohibit copy operations, manage the lifecycle of the contained object and provide smart-ptr like access. A series of identical tests is conducted both with the ScopedPtrHolder (the contained objects are heap allocated but managed by the holder) and with the ScopedHolder (objects placed inline)
Member ScopedHolder_test::checkSTLContainer ()
collection of noncopyable objects maintained within a STL map
Class ScopedHolderTransfer_test
growing a vector containing noncopyable objects wrapped into ScopedHolder instances. This requires the use of a custom allocator, invoking a transfer_control() function to be provided for the concrete noncopyable class type, being invoked when the vector needs to reallocate.
Class ScopedPtrVect_test
ScopedPtrVect manages the lifecycle of a number of objects. The API is similar to a vector and allows for element access and iteration. Individual elements can be detached and thus removed from the responsibility of the container.
Class ScopePath_test
properties and behaviour of the path of nested scopes. Using a pseudo-session (actually just a PlacementIndex), this test creates some nested scopes, builds scope paths and executes various comparisons navigation moves on them. Especially detection of invalid scopes and paths and the special handling of empty and root paths is covered.
See also
Member ScopePath_test::check_RefcountProtection (PMO &refPlacement)
the embedded refcount is handled sensibly when it comes to copying. (This refcount is used by QueryFocusStack)
Member ScopePath_test::navigate (const ScopePath refPath, PPIdx index)
modify a path by navigating it.
  • move one step above the current leaf
  • move up to the root element
  • move back to the parent and verify we're just above the leaf
  • attach a new sibling node and move the path down to there
  • extract the common prefix, which should again point to the parent
  • find a placement in a completely separate branch (only sharing the root node). Navigate to there and verify root is the common prefix.
Class ScopeQuery_test
how to discover contents or location of a container-like part of the high-level model. As this container-like object is just a concept and actually implemented by the PlacementIndex, this means querying the index for elements registered with a given scope or finding the enclosing scopes. The discovered elements will be filtered by a runtime type check.
Class SearchPathSplitter_test
verify splitting a search path specification and retrieving the components by iteration. Embedded $ORIGIN tokens get resolved to the absolute path of this executable.
Class SegmentationDatastructure_test
TODO blubb
Class SessionCommandFunction_test
verify integrated functionality of command dispatch through the SessionCommand facade.
  • operate lifecycle of the supporting components, similar to activating the »session subsystem«
  • generate command messages similar to what is received from the UI-Bus
  • us the handler mechanism from gui::ctrl::CoreService to talk to the facade
  • have a specially rigged command function to observe invocation
  • wait for the session loop thread to dispatch this command
  • verify that commands are really executed single-threaded
Member SessionCommandFunction_test::perform_massivelyParallel (Arg args_for_stresstest)
massively multithreaded torture test to verify that commands are properly enqueued and executed one by one
  • create several threads to send random command messages
  • verify that, after executing all commands, the internal state variable reflects the result of a proper sequential calculation and summation
Member SessionCommandFunction_test::perform_messageInvocation ()
invoke a command in the same way as CoreService does when handling command messages from the UI-Bus
  • build a command message, similar to what the generic UI element does
  • use the contents of this message at the SessionCommand facade, similar to what CoreService does
Member SessionCommandFunction_test::perform_simpleInvocation ()
demonstrate a simple direct invocation
Member SessionCommandFunction_test::startDispatcher ()
start the session loop thread, similar to what the »session subsystem« does
we are not actually starting the subsystem itself, but we indeed start the _»session loop thread«_
See also
Member SessionCommandFunction_test::stopDispatcher ()
verify the »session loop thread« has finished properly
Class SessionElementQuery_test
cover the part of the session API allowing to retrieve specific elements by query.
  • This test first picks an object from the test session, where the filter predicate utilises the specific MObject subclass (here DummyMO).
  • Then re-fetches the same object using a different filter (based on the specific random int-ID).
  • Next the element is removed from the test session to verify the "not found" result
  • finally we re-attach another placement of the same underlying MObject instance at a different location in the test session and verify we can again pick this element with the specific query.
Class SessionElementTracker_test
verify the tracking of special session/model elements, to be exposed through an self-contained interface module on the session API. The basic element-tracking mechanism uses a simple (vector based) registry, which stores a smart-ptr. Thus the elements need to be created by a factory. In case of Timeline / Sequence, the asset::StructFactory will take on this role. The integration test creates a Timeline (facade asset) and verifies proper registration and deregistration.
Member SessionElementTracker_test::verify_cleanup (PTimeline const &aTimeline_in_session)
ensure the asset cleanup doesn't interfere with session shutdown
Member SessionManager_test::clearSession ()
clear current session contents without resetting global session config.
Member SessionManager_test::getCurrentSession ()
accessing the current (global) session
Member SessionManager_test::loadMockSession ()
use a mock session serialiser to load a preconfigured test session. Verify objects are wired correctly.
Member SessionManager_test::loadSession (const string &src)
load serialised session using the real session serialiser implementation.
Member SessionManager_test::resetSession ()
reset global session config and start with a pristine default session.
Member SessionManager_test::saveSession (string &dest)
serialise (save) the current session
deststring receiving the generated serialised stream
Class SessionModifyParts_test
perform the most important structural modifications on a session and verify they're carried out properly.
  • attaching forks ("tracks")
  • adding clips
Member SessionServiceAccess_test::access_defaultSession ()
accessing an non-existing session causes creation of a new TSessionImpl instance. After that, the public API function gets invoked.
Member SessionServiceAccess_test::invoke_implServices ()
accessing implementation-level APIs
Member SessionServiceAccess_test::make_newSession ()
invoking the management API to close the session. The next public API invocation will create a new TSessionImpl instance.
Class SessionStructure_test
access the current session and verify the correct structure of the most important components: The session contains an Sequence, we can get at the Fixture, we have at least one Fork and the corresponding Fork-ID (asset) can be retrieved.
Class SessionStructureMapping_test
demonstrate the fundamental patterns to access the current session structure and contents from the GUI, and to receive a notification with the updated structure and contents.
  • since we focus on the mapping and enumeration mechanism, the explored content is faked diagnostic data
  • in reality, these operations are intended to be run from within the GUI event thread and immediately interwoven with GTK / Cairo display code
  • it is the responsibility of the "Gui Model" (#SessionFacade) to ensure a read barrier, so the retrieved data can not be corrupted by concurrent session mutation operations.
Member SessionStructureMapping_test::retrieveSessionStructure ()
how to retrieve and enumerate session contents as operation initiated from GUI display code
Class SimpleAllocator_test
cover the basic operations of a custom allocator, delegating to mpool. The SimpleAllocator doesn't provide any ref-counting or tracking facilities, nor does he support bulk de-allocation. The advantage over using std::allocator directly is the shortcut for (placement) construction, and – of course – the ability to exchange the memory model at one central location.
Class Singleton_test
implement a Singleton class using our Singleton Template. Expected results: single instance created in static memory, single instance properly destroyed, no memory leaks.
See also
Class SingletonSubclass_test
specific dependency-injection setup, to create a singleton subclass (implementation class) instance, without coupling the caller to the concrete type.
Expected results: an instance of the subclass is created.
See also
Class SingletonTestMock_test
inject a Mock object into the Singleton Factory, to be returned and used in place of the original object. This test covers the full usage cycle: first access the Client Object, then replace it by two different mocks, and finally restore the original Client Object.
See also
Class StateMapGroupingStorage_test
verify the storage structure for capturing UI state works as intended.
Class StreamTypeBasics_test
check the basic workings of the stream type handling. create some stream implementation data, build a StreamType::ImplFacade from this, and derive a prototype and a full StreamType based on this information.
Class StreamTypeLifecycle_test
check the stream type registration lifecycle. Any internal or external component (plugin) can extend the Proc Layer's registry of media stream types. There is a basic pristine set of type information, which is restored automatically everytime the STypeManager is reset, which in turn happenes before loading a (new) Session.
Member StreamTypeLifecycle_test::check_pristineState ()
this test defines a new (dummy) type info and schedules it for setop in the pristine state; check this info is actually present after resetting the stream type manager, while other additional info not scheduled in this manner is not present in this state
Member StreamTypeLifecycle_test::register_additional_TypeInfo ()
use the stream type manager to register additional type info and verify it is used in type resolution.
Class SubID_test
for now (9/09) this is a playground for shaping a vague design idea
  • base types and casts
  • exploring some extensions
  • use this ID as Hash-Map key
Class SubsystemRunner_test
managing start and stop of several dependent "subsystems" under various conditions. Using mock-subsystems, which actually spawn a thread and finish by themselves and generally behave sane. For each such MockSys, we can define a behaviour pattern, e.g. weather the start succeeds and if the run terminates with error.
Class Symbol_test
properties of Symbol data type. Currently this is just a thin wrapper for a const char *
Member Symbol_test::use_as_map_key ()
use Literal and Symbol as keys in a tree map.
neither Literal, nor Symbol defines an operator< so the map specialisation has to fall back on const char*, which are compared based on pointer identity. Contrast this with std::string, which does define its own ordering.
Class SymbolHashtable_test
build a hashtable using Symbol objects as Keys. Especially this verifies picking up a customised hash implementation via ADL
See also
Class SyncClasslock_test
check proper handling of class (not instance)-based Monitor locks. Because no instance is available in this case, a hidden storage for the Monitor object needs to be provided in a way safe for use even in the static startup/shutdown phase. This can not directly validate this allocation of a shared monitor object behind the scenes, but it can verify the monitor is indeed shared by all ClassLock instances templated to a specific type.
Class SyncLocking_test
create multiple threads, all concurrently trying to increment a number of counters with random steps and random pauses. Without locking, the likely result will be differing counters. But because the class Victim uses an object level monitor to guard the mutations, the state should remain consistent.
Class SyncTimedwait_test
timeout feature on condition wait as provided by pthread and accessible via the object monitor based locking/waiting mechanism. Without creating multiple threads, we engage into a blocking wait, which aborts due to setting a timeout. Our waiting facility is written such as to invoke the condition prior to entering wait state (and consecutively whenever awakened). This test switches into wait-with-timeout mode right from within this condition check and thus works even while there is no other thread and thus an unconditional wait would stall forever.
Class SyncWaiting_test
concurrent waiting and notification, implemented via object monitor. This test covers the second part of the monitor pattern, which builds upon the locking part, additionally using an embedded condition. We provide several pre-configured ways of specifying the condition to wait upon.
  • check a boolean flag
  • evaluate a member function as predicate
Class TestEventLog_test
verify a logging facility, which can be used to ensure some events happened while running test code.
  • various kinds of events or function calls are logged via the logging API.
  • within the test code, a match is performed against the contents of the log, using a DSL to represent matches relative to other matches
  • when a match fails, additional diagnostics are printed to STDERR
    See also
Member TestEventLog_test::verify_logJoining ()
combining several logs The EventLog objects are actually just lightweight front-end handles, while the actual log lives on the Heap.
Class TestFrame_test
verify test helper for engine tests: a dummy data frame. TestFrame instances can be created right away, without any external library dependencies. A test frame is automatically filled with random data; multiple frames are arranged in sequences and channels, causing the random data to be reproducible yet different in each frame.
Member TestFrame_test::useFrameTable ()
the table of test frames computed on demand
Member TestFrame_test::verifyFrameSeries ()
build sequences of test frames, organised into multiple families (channels). Verify that adjacent frames hold differing data
Class TestGui_test
demo of writing a unit-test to execute code implemented within the UI layer.
the point in question here is the build system and how library dependencies are handled. Typically such unit-tests will rather cover framework aspects of the UI, not perform a remote controlled execution of the UI. Thus we still create a commandline executable, but for this code to work, it needs to be linked against the GUI plugin (which is in fact a shared library)
Member TestHelper_test::checkThrowChecker ()
check the VERIFY_ERROR macro, which ensures a given error is raised.
Member TestHelper_test::checkTypeDisplay ()
prints "sizeof()" including some type name.
Class TestHelperVariadic_test
document usage of the diagnostics helper for variadic templates. Errors in variadic template instantiations are sometimes hard to spot, due to the intricacies of template argument matching and the reference collapsing rules. Our diagnostics facility is itself a variadic function template, which, when supplied with an argument pack, will build a diagnostic string describing the arguments.
care has to be taken to pass the template arguments properly, since template argument matching might mess up the reference kind (rvalue, lvalue) of the passed types. Thus, either use std::forward, or spell out the template argument(s) explicitly on invocation
Class TestOption_test
for test::TestOption, parsing of commandline options
See also
Member TestOption_test::doIt (const string cmdline)
performs the actual test for the option parser test::TestOption
Class ThreadLocal_test
use a wrapper to simplify handling of thread-local data. Create some threads, each referring to another piece of data through the "same" wrapper instance.
Class ThreadWrapper_test
use the Lumiera backend to create some new threads, utilising the lumiera::Thread wrapper for binding to an arbitrary operation and passing the appropriate context.
Class ThreadWrapperJoin_test
use the Lumiera backend to create some new threads, additionally synchronising with these child threads and waiting for termination.
Class ThreadWrapperSelfRecognitionTest_test
verify the ability of a thread to detect code executing within the thread itself.
Class TimeBasics_test
sanity check of basic Time handling.
Class TimeControl_test
use the time::Control to push a sequence of modifications to various time entities; in all cases, a suitable change should be imposed to the target and then a notification signal should be invoked.
Member TimeControl_test::verifyMatrix_of_MutationCases (TimeValue const &o, TimeValue const &c)
cover all possible combinations of input change values and target time value entities to be handled by time::Control. Each of these cases executes a standard test sequence, which is defined in TestCase::performTestSequence
Class TimeFormats_test
verify handling of grid aligned timecode values.
  • full cycle from parsing to formatting
  • mutating the components of timecode
  • some formatting corner cases
  • formatting in various formats
Member TimeFormats_test::checkSmpte ()
detailed coverage of SMPTE timecode representation. Using a scale grid with PAL framerate; this test doesn't cover the handling of drop-frame timecode.
  • creating a timecode representation causes frame quantisation
  • the components of SMPTE timecode can be accessed and manipulated
  • timecode can be incremented/decremented as a whole
  • we allow extension of the scale towards negative values
  • for these, the representation is flipped and the negative orientation only indicated through the sign field.
Member TimeFormats_test::checkTimecodeUsageCycle ()
demonstrate a full usage cycle of timecode and time values. Starting with a textual representation according to a specific timecode format, and based on the knowledge of the implicit underlying time grid (coordinate system, here with origin=0 and framerate=25fps), this timecode string may be parsed. This brings us (back) to the very origin, which is a raw TimeValue (internal time). Now, this time value might be manipulated, compared to other values etc. Anyway, at some point these time values need to be related to some time scale again, leading to quantised time values, which — finally — can be cast into a timecode format for external representation again, thus closing the circle.
Class TimeGridBasics_test
build some simple time grids and verify their behaviour for quantising (grid aligning) time values.
Class TimelineSequenceHandling_test
verify retrieval and instance management of the top level facade objects as integrated with the session and high-level model. Both sequences and timelines are at the same time structural assets and act as facades on the session API. Thus we can query specific instances from the struct factory or alternatively access them through the session. Moreover we can create new top level elements in the session just by querying the respective asset.
Class TimeMutation_test
cover all basic cases for mutating a time specification.
  • change to a given value
  • change by an offset
  • change using a grid value
  • apply an (grid) increment
Class TimeParsing_test
parse textual time specifications given in the supported timecode formats
Class TimeQuantisation_test
verify handling of quantised time values.
  • the simple usage, just referring to an predefined grid by name
  • explicitly defining an quantiser
  • converting these quantised values into various timecode formats
  • error detection
Class TimeValue_test
verify handling of time values, time intervals.
  • creating times and time intervals
  • comparisons
  • time arithmetics
Member TimeValue_test::checkBasicTimeValues (TimeValue org)
creating some time values and performing trivial comparisons.
you can't do much beyond that, because TimeValues as such are a "dead end": they are opaque and can't be altered.
Member TimeValue_test::checkMutableTime (TimeValue org)
time variables can be used for the typical calculations, like summing and subtracting values, as well as multiplication with a scale factor. Additionally, the raw time value is accessible by conversion.
Member TimeValue_test::checkTimeConvenience (TimeValue org)
additional convenience shortcuts supported especially by the canonical Time values.
Class TimingConstraints_test
document and verify the definition and combining of timing constraints for playback and rendering.
Class TrackingHeapBlockProvider_test
verify a test support facility, used to write mock components to test the lumiera engine. The TrackingHeapBlockProvider is a braindead implementation of the BufferProvider interface: it just claims new heap blocks and never de-allocates them, allowing other test and mock objects to verify allocated buffers after the fact.
Class TreeMutator_test
Demonstrate a customisable component for flexible bindings to enable generic tree changing and mutating operations to arbitrary hierarchical data structures.
  • we use lambdas to link into our private implementation
  • this test demonstrates the behaviour of an attribute setter
  • plus some of the primitive operations available on collections
Class TreeMutatorBinding_test
Building blocks to map generic changes to arbitrary private data structures.
  • use a dummy diagnostic implementation to verify the interface
  • verify an adapter to apply structure modification to a generic collection
  • use closures to translate mutation into manipulation of private attributes
  • integrate the standard case of tree diff application to Rec<GenNode>
Member TreeMutatorBinding_test::mutateAttribute ()
translate generic mutation into attribute manipulation
  • here we bind directly to data fields local to this scope
  • we execute the same diff primitives used in the preceding tests
  • yet binding to data fields has certain intrinsic limits; due to the fixed non-dynamic nature of data fields, it is impossible to define an "ordering" and consequently there is no sequence of diff application.
  • so the only form of actually applying a change is to invoke the given setter or use the given mechanism to construct a nested mutator.
Member TreeMutatorBinding_test::mutateCollection ()
map mutation primitives onto a STL collection managed locally.
  • we perform literally the same diff steps as in mutateDummy()
  • but now we have a completely opaque implementation data structure, where even the data type is unknown beyond this functions's scope.
  • thus we build a custom mutator, installing lambdas to tie into this local data structure, without disclosing any details. In fact we even install different lambdas on each usage cycle, according to the specific mutation operations to perform. Of course, it would be pointless to do so in real world usage, yet nicely demonstrates the point that the implementation really remains in control about anything regarding its private data structure.
  • and still, by exposing such a custom configured mutator, this private structure can be populated, reordered and even altered recursively, by generic instructions.
Member TreeMutatorBinding_test::mutateDummy ()
diagnostic binding: how to monitor and verify the mutations applied
Member TreeMutatorBinding_test::mutateGenNode ()
apply mutation primitives to a GenNode tree.
  • again we perform literally the same diff steps as before
  • but we use the pre-configured binding for Record<GenNode>
  • internally this is comprised of two collection binding layers
  • we start with an empty root node, to be populated and transformed
Class TupleHelper_test
Cover various aspects of the integration of our type sequences with the tuple type from the standard library
  • verify our generic tuple access decorator
  • verify generating tuple types from type list processing
  • TODO more helpers to come
Member TupleHelper_test::check_tuple_from_Typelist ()
verify the ability to generate tuple types from typelist metaprogramming
  • the resulting types are plain flat std::tuple instantiations
  • memory layout is identical to a POD, as expected
  • our generic string conversion is extended to work with tuples
Class TupleRecordInit_test
Metaprogramming: how to unload the contents of a runtime typed variant sequence into ctor arguments of a (compile time typed) tuple.
Class TypedAllocationManager_test
cover the basic implementation of a custom allocator, delegating to mpool. TypedAllocationManager is a base class, used e.g. to build the CommandRegistry.
Class TypedCounter_test
build multiple sets of type-based contexts and run a simple counting operation in each of them concurrently. Check the proper allocation of type-IDs in each context and verify correct counting operation by checksum.
Class TypeDemangling_test
verify the demangling of C++ names, as available through the GCC platform ABI. The Lumiera support library exposes this non-portable feature through a convenience helper to ease the writing of unit tests.
Class TypedFamilyMemberID_test
simplistic unit test to demonstrate generating _member IDs within a family of objects delineated by type.
this test does not cover the thread safety, because FamilyMember relies on lib::ClassLock, which is assumed to be covered separately
Class TypedID_test
outline of an instance registration and accounting service. The service is self-contained and supports automatic registration and deregistration. The instance access is configurable on a per-type base.
  • create instances of an auto-registered type
  • verify the registration entries
  • re-access the instances just by symbolic ID
  • verify the registration is cleaned up automatically.
Class TypeDisplay_test
verify post processing of demangled C++ type names. The purpose of those pretty printing functions is to support diagnostics and unit testing by making type names easier to digest. But of course we do not want to pick the wrong primary type for shortened display and we do not want mess up the semantic structure.
  • the first example should be passed through unaltered
  • the second example demonstrates various simplifications
    • strip some frequent namespace prefixes ** std:: ** lib::meta:: ** proc::mobject::
    • omit the standard allocator from STL containers
  • the third example demonstrates an embedded function signature
    • the primary type component is "`function`"
    • anything leading up to anonymous namespaces will be stripped
    • our special smart-ptr lib::P will be simplified
Class TypeList_test
try out Loki-style typelist metaprogramming. Assembles a Class definition from parts specified as collection of types. The elementary building block has an talking ctor, so by automatic ctor chaining we get a message of each part.
Class TypeListGenerator_test
check the helpers for dealing with lists-of-types. Build an interface and an implementation class by inheriting template instantiations for a collection of classes
Class TypeListManip_test
check utilities for manipulating lists-of-types.
  • build an list of constant-wrapper-types and print them for debugging purpose.
  • append lists, single elements and NullType in various combinations
  • manipulations like splice, get end, dissect
  • filtering out some types from a typelist by using a "predicate template" (metafunction)
  • building combinations and permutations
Class TypeListUtil_test
verify the simple helpers for working with lists-of-types. These are simple metafunctions to count the number of elements, calculate the maximum size or check for inclusion.
Class TypeSeqManipl_test
check the basic utilities for manipulating (fixed) type sequences.
  • re-build an sequence from a type list
  • prepend a type to a given type sequence
  • create shifted sequences
  • dissect a sequence to extract head, tail, prefix, last element
Class UICoord_test
verify the basic properties of topological UI coordinate specifications.
  • created as path-like sequence of Literal components
  • provides a builder API for definition and mutation
  • Normalisation and handling of missing parts
  • access to UI coordinate components
  • string representation
  • comparisons
  • predicates
Class UICoordResolver_test
verify query and mutation of UICoord in relation to actual UI topology. A UI-Coordinate resolver is a special builder, which is initialised by the given coordinate spec, and also attached to a "location query API", which allows to investigate the current actual UI structure. The builder then exposes query and mutation operations, to determine to what extent the coordinate spec is "covered" by the real UI, and to match and expand any wildcards in the coordinate spec (pattern).
Member UICoordResolver_test::verify_backingQuery ()
verify the command-and-query interface backing the resolver.
Member UICoordResolver_test::verify_mutateAnchor ()
mutate given UI coordinates by anchoring them.
Member UICoordResolver_test::verify_mutateCoverage ()
path matching algorithm to resolve UI coordinates with wildcards against the current UI structure tree.
Member UICoordResolver_test::verify_mutateCoverPartially ()
resolve by matching, but retain an extraneous, uncovered extension.
Member UICoordResolver_test::verify_mutateExtend ()
mutate given UI coordinates by uncovered extension.
Member UICoordResolver_test::verify_queryAnchor ()
query anchorage of given UI coordinates.
  • an anchored UI coordinate spec explicitly rooted within a top level window.
  • an explicit UI coordinate spec impossible to anchor within current UI tree
  • a UI coordinate spec with dynamic reference to first/current window
  • an incomplete spec, which needs to be solved (pattern matched) to determine anchor.
Member UICoordResolver_test::verify_simpleUsage ()
introduction to UI coordinate resolution
  • use a backing "real" (dummy) data structure to resolve against
  • establish a suitable implementation of the LocationQuery interface
  • attach a resolver
  • have fun
Class UILocationSolver_test
verify a mechanism to resolve the desired location of an UI-element. The UILocationSolver is operated by the ViewLocator service, which itself is part of the InteractionDirector. In typical usage, the location rules are drawn from the ViewSpec-DSL, evaluated with the help of a Coordinate Resolver, based on the real UI topology existing at that moment, accessible in abstracted form through the LocationQuery interface. This test setup here mimics that invocation scheme, but replaces the real UI by an abstract tree notation embedded directly into the individual test cases.
Member UILocationSolver_test::simple_usage_example ()
demonstrate the typical invocation and usage" </dd> <dt>\anchor _test000230 Member \_internalref classgui_1_1interact_1_1test_1_1UILocationSolver__test#a57851c8461ff2a608cd4fed6759bd20b "UILocationSolver_test::verify_cornerCases" ()</dt><dd> cover theoretical corner cases regarding the process of location solving.</dd> <dt>\anchor _test000231 Member \_internalref classgui_1_1interact_1_1test_1_1UILocationSolver__test#a8e636ce91e5cf4dcf66278a284d0ff17 "UILocationSolver_test::verify_standardSituations" ()</dt><dd> emulate the relevant standard situations of view location resolution.</dd> <dt>\anchor _test000447 Class \_internalref classlib_1_1test_1_1UniqueMallocOwner__test "UniqueMallocOwner_test" Verify automatic management of memory originally allocated by C malloc. This situation typically arises when some plain-C function returns results in a heap allocated buffer, requiring the client to care for proper clean-up. To avoid creating a liability, we wrap the buffer into a smart pointer, which acts as ownership token and abstracts the specifics of clean-up.
Class UtilCollection_test
verify some convenience shortcuts and helpers dealing with Collections and sequences (Iterators).
  • metafunctions to distinguish STL containers and Lumiera Iterators
  • get the first element
  • get the last element
Class UtilFloordiv_test
Evaluate a custom built integer floor function. Also known as Knuth's floor division. This function is crucial for Lumiera's rule of quantisation of time values into frame intervals. This rule requires time points to be rounded towards the next lower frame border always, irrespective of the relation to the actual time origin. Contrast this to the built-in integer division operator, which truncates towards zero.
Member UtilFloordiv_test::runPerformanceTest ()
timing measurements to compare implementation details.
Class UtilFloorwrap_test
Verify a custom built integer scale division and wrapping function. This function is relevant for decimating values into a given scale, like splitting time measurements in hours, minutes, seconds etc. Basically, in Lumiera the quantisation into a scale is always done with the same orientation, irrespective of the zero point on the given scale. Contrast this to the built-in integer division and modulo operators working symmetrical to zero.
See also
Class UtilForeach_test
Invoking an operation for each element of a collection. Covers the various flavours of these convenience helpers: They might operate either on a STL container (providing begin() and end() functions), or at a "Lumiera Forward Iterator", which is incremented and dereferenced for each value it yields, until exhaustion.
Member UtilForeach_test::check_existence_quant (CO coll)
verify the logic of universal and existential quantisation. Using lambda expressions as predicates
Member UtilForeach_test::check_foreach_bind (CO coll)
bind additional parameters on-the-fly, including the possibility to use a placeholder to denote the position of the variable parameter
Member UtilForeach_test::check_foreach_bind_const (CO const &coll)
the input sequence can be also taken from a const container (for iterators this obviously doesn't make sense
Member UtilForeach_test::check_foreach_lambda (CO coll)
use lambda-expressions, to be invoked for each element
Member UtilForeach_test::check_foreach_memFun (CO coll)
bind a member function to be invoked for each element
Member UtilForeach_test::check_foreach_plain (CO coll)
invoke a simple free function, given as reference, function pointer or functor. The invoked test function will print its argument
Member UtilForeach_test::check_invoke_on_each ()
the binding can also be used to dispatch an operation on each element within a object collection: here the parameter is used as this pointer to specify the object instance
Member UtilForeach_test::check_ref_argument_bind (CO coll)
under some circumstances, it is even possible to take a ref to the data in the input sequence, or to a summation variable. In the example performed here, the function to be applied takes the 3rd argument by reference and assigns the sum of first and second argument to this parameter. If we us a bind variable at that position, we end up assigning by reference to the values contained in the collection.
in case of invoking this test with a Lumiera Forward Iterator, the changes go through to the original container, in spite of passing the iterator by value. This behaviour is correct, as an iterator is an reference-like object
Member UtilForeach_test::check_wrapped_container_passing (VecI coll)
pass the collection to be iterated in various ways
  • anonymous temporary
  • smart pointer
  • pointer
  • const&
    We do modifications using a lambda expression with a side-effect. The container passed in is always modified, disregarding const! (In case of the anonymous temporary the modifications get discarded after reaching the end of the for_each expression
Class ValueTypeBinding_test
verify result type rebinding for containers, iterators values and references. When augmenting, combining or decorating generic entities, there is often the need to find out about the value_type, a reference or pointer to such a value. Many STL compliant containers and iterators provide suitably nested type definitions to indicate those types. The meta::TypeBinding helper allows to pick up such definitions, and additionally it levels and unifies access for various combinations of primitive types, references and pointers. The purpose of this test is to verify and document this behaviour.
Class VariadicArgumentPicker_test
check the basic utilities for manipulating variadic template arguments.
  • single out and pick an argument designated by index
  • pick an argument with fallback on default construction
  • demonstrate usage by reordering the position of arguments
Member VariadicArgumentPicker_test::check_reorderedArguments ()
demonstrate reordering of arguments
Class Variant_test
cover the essential properties of Lumiera's lightweight variant record.
  • this typesafe union can never be constructed empty
  • it defaults to the default constructed first type in list
  • it is copyable and assignable, but only with compatible type
  • value access requires knowledge of the contained type
  • generic visitor style access
Class VectorTransfer_test
growing (re-allocating) a vector with noncopyable objects, with the help of a special Allocator and a custom transfer_control operation provided by the contained objects. The idea is to allow some special copy-operations for the purpose of re-allocations within the vector, without requiring the object to be really copyable.
Class VerbFunctionDispatch_test
Demonstration/Concept: dispatch a specific function based on the given verbs of an embedded custom language. Actually what we want to achieve here is a specific form of double dispatch; thus the implementation relies on a variation of the visitor pattern.
Member VerbFunctionDispatch_test::render_verbose (VerbSeq tokens)
demonstrate the dispatching based on the concrete verb token. Here the implementation just prints the name of the invoked verb
Member VerbFunctionDispatch_test::verify_dispatch (VerbSeq tokens)
verify the correct individual dispatch through a computation specific for the given verb
Class ViewSpecDSL_test
verify the mechanics of a functor based internal DSL to configure access and allocation patters for component views.
Class VirtualCopySupport_test
verify a mechanism to allow for cloning and placement new of opaque, type-erased entities. Basically we allow only assignments and copy between objects of the same concrete type, but we want to initiate those operations from the base interface, without any further knowledge about the actual types involved.
Member VirtualCopySupport_test::verify_TestFixture ()
our test fixture is comprised of
  • a common interface (#Interface)
  • a implementation template #Sub to hold a buffer and manage a distinct random value at some position in that buffer, which depends on the concrete implementation type
  • layered on top are adapters to make this implementation class either fully copyable, non-assignable, only movable or noncopyable.
Class VisitingTool_concept
build and run some common cases for developing and verifying ichthyo's implementation concept for the Visitor Pattern. Defines a hierarchy of test classes to check the following cases
Class VisitingTool_test
our lib implementation of the visitor pattern. Defines a hierarchy of test classes to check the following cases
  • calling the correct visiting tool specialised function for given concrete hierarchy classes
  • visiting tool not declaring to visit some class is silently ignored by default
  • newly added classes will be handled by existing functions according to inheritance relations
Class VisitingToolExtended_test
more esoteric corner cases of our visitor lib implementation. Defines a hierarchy of test classes, which mix two different kinds of "visitable" by two disjoint tool base classes. One of these base classes uses an explicit error handling catch-all-function.