benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

WIP: test-driven brainstorming -- a framework for event log verification

Browse source 
this is a recipe for writing UI related tests
This commit is contained in:
Fischlurch 2015-11-27 02:38:23 +01:00
parent 42c2569bb8
commit 25805635ff
2 changed files with 77 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

74
tests/gui/abstract-tangible-test.cpp
View file

@ -46,6 +46,7 @@
#include "lib/test/run.hpp"
#include "lib/test/test-helper.hpp"
//#include "gui/model/session-facade.hpp"
//#include "gui/model/diagnostics.hpp"
//#include "lib/util.hpp"
@ -62,6 +63,8 @@
//using std::cout;
//using std::endl;
using lib::error::LUMIERA_ERROR_ASSERTION;
namespace gui {
namespace model{
@ -110,9 +113,76 @@ namespace test {
void
verify_mockManipulation ()
{
UNIMPLEMENTED ("setup and usage of an UI-Element mock");
MockElm mock("dummy");
mock.verify("ctor");
mock.verifyEvent("ctor");
mock.verify("ctor").arg("dummy");
CHECK ("dummy" == mock.getID().getSym());
CHECK ("ID<gui::model::test::MockElm>-dummy" = string(mock.getID()));
VERIFY_ERROR (ASSERTION, mock.verifyCall("reset"));
mock.reset();
mock.verify("reset");
mock.verifyCall("reset");
mock.verifyEvent("reset");
mock.verify("reset").after("ctor");
mock.verify("ctor").before("reset");
VERIFY_ERROR (ASSERTION, mock.verify("reset").before("ctor"));
VERIFY_ERROR (ASSERTION, mock.verify("ctor").after("reset"));
mock.verify("reset").before("reset");
mock.verify("reset").beforeEvent("reset");
mock.verifyCall("reset").before("reset");
mock.verifyCall("reset").beforeEvent("reset");
VERIFY_ERROR (ASSERTION, mock.verifyCall("reset").afterCall("reset"));
VERIFY_ERROR (ASSERTION, mock.verifyCall("reset").afterEvent("reset"));
VERIFY_ERROR (ASSERTION, mock.verifyEvent("reset").afterEvent("reset"));
CHECK (!mock.isTouched());
CHECK (!mock.isExpanded());
mock.noteMsg("dolorem ipsum quia dolor sit amet consectetur adipisci velit.");
mock.verifyNote("Msg");
mock.verifyCall("noteMsg");
mock.verifyCall("noteMsg").arg("lorem ipsum");
mock.verifyCall("noteMsg").argMatch("dolor.+dolor\\s+");
mock.verifyMatch("Rec\\(note.+kind = Msg.+msg = dolorem ipsum");
EventLog log = mock.getLog();
log.verify("ctor")
.before("reset")
.before("lorem ipsum");
MockElm foo("foo"), bar;
foo.verify("ctor").arg("foo");
bar.verify("ctor").arg();
bar.ensureNot("foo");
log.ensureNot("foo");
mock.ensureNot("foo");
VERIFY_ERROR (ASSERTION, foo.ensureNot("foo"));
log.join(bar).join(foo);
log.verifyEvent("logJoin").arg(bar.getID())
.beforeEvent("logJoin").arg("foo");
mock.verifyEvent("logJoin").arg(bar.getID())
.beforeEvent("logJoin").arg("foo");
mock.verify("ctor").arg("foo");
log.verify("ctor").arg("foo");
log.verify("ctor").arg("dummy")
.before("ctor").arg(bar.getID())
.before("ctor").arg("foo");
mock.kill();
foo.noteMsg("dummy killed");
log.verifyEvent("dtor").on("dummy")
.beforeCall("noteMsg").on("foo");
}
void
invokeCommand ()
{
@ -124,6 +194,8 @@ namespace test {
markState ()
{
UNIMPLEMENTED ("mark interface state");
TODO ("be sure also to cover signal diagnostics here");
}

8
wiki/renderengine.html
View file

@ -8314,7 +8314,7 @@ The UI-Bus is a ''Mediator'' -- impersonating the role of the //Model// and the
The ~MVC-Pattern as such is fine, and probably the best we know for construction of user interfaces. But it doesn't scale well towards the integration into a larger and more structured system. There is a tension between the Controller in the UI and other parts of an application, which as well need to be //in control.// And, even more important, there is a tension between the demands of UI elements for support by a model, and the demands to be placed on a core domain model of a large scale application. This tension is resolved by enacting these roles while transforming the requests and demands into //Messages.//</pre>
</div>
<div title="UI-Element" creator="Ichthyostega" modifier="Ichthyostega" created="201511210307" modified="201511261841" tags="GuiPattern design draft decision" changecount="12">
<div title="UI-Element" creator="Ichthyostega" modifier="Ichthyostega" created="201511210307" modified="201511270107" tags="GuiPattern design draft decision" changecount="15">
<pre>While our UI widgets are implemented the standard way as proposed by GTKmm, some key elements -- which are especially relevant for the anatomy and mechanics of the interface -- are made to conform to a common interface and behaviour protocol. {{red{WIP 11/15 work out what this protocol is all about}}}. #975
As a starting point, we know
* there is a backbone structure known as the UI-Bus
@ -8352,9 +8352,9 @@ And finally, there are the //essential updates// -- any changes in the model //f
:receive a GenNode representing the //feedback// or replayed //state mark//
;signals
:the individual element exposes some generic signal slots
:* sigMut prompts the element to draw a diff to alter its configuration
:* sigExpand promts the element to transition into expanded / unfolded state. If this state is sticky, the element should answer with a ''mark''
:* sigShow prompts the element to bring the indicated child into sight
:* slotExpand prompts the element to transition into expanded / unfolded state. If this state is sticky, the element should answer with a ''mark''
:* slotReveal prompts the element to bring the indicated child into sight
:these slots are defined to be {{{sigc::trackable}}} for automated disconnection (&amp;rarr; see [[#940|http://issues.lumiera.org/ticket/940#comment:3]] for an explanation)
;diff
:ask to retrieve a diff, which
:* either is an incremental status update