| Age | Commit message (Collapse) | Author |
|
bzr revid: fme@openerp.com-20121205160656-0mg1hnv35vk27adh
|
|
bzr revid: odo@openerp.com-20121130175249-yrbcdsn2z1io79dz
|
|
when creating the instance, set instance.session.uid to 42 so the evaluator has something to chew on when it tries to create the evaluation context
bzr revid: xmo@openerp.com-20121120101733-b0ire11bbuywfi8u
|
|
avoid catching exception in executed callback, it just hinders debugging by generated completely bonkers traces
bzr revid: xmo@openerp.com-20121116105554-hu45anetrj1a8tl6
|
|
bzr revid: xmo@openerp.com-20121116101417-mkcjrdtocl6w7408
|
|
committed by mistake
bzr revid: xmo@openerp.com-20121116073738-9f43bm0q6eojns3v
|
|
duplication
bzr revid: xmo@openerp.com-20121116072906-0di2j83p602a2l9i
|
|
simplify code and make setup & teardown processes more reliable
add testing.Stack tools which stacks promise-returning functions
around the actual promise-returning function to execute (the test case
itself).
testing.Stack returns an object with 3 methods, ``push([setup][,
teardown])``, ``unshift([setup][, teardown])`` and ``execute(fn,
*args)``. ``push`` and ``unshift`` create a new stack with the
provided setup and teardown added respectively at the top and bottom
of the stack.
``execute`` will walk the stack from bottom to top executing ``setup``
handlers (and waiting on their result), if all setup handlers execute
without failure the ``fn`` callback gets executed (and waited on) then
*all* ``teardown`` handlers are executed from top to bottom:
| setup
| setup
| setup
| setup
| fn
| teardown
| teardown
| teardown
V teardown
If a ``setup`` handler fails (the promise is rejected), teardowns will
start executing *from the previous level* (so the ``teardown``
matching the failed ``setup`` will *not* be run), but all
``teardowns`` below that will be run regardless, even if one fails the
next one will still be executed.
The stack will either ultimately return a promise rejection using the
*first* rejection it got (a rejection may be cascading, so the
rejection of a setup may also lead to or be linked to a teardown being
rejected later), or will return the resolution from ``fn``.
If ``execute`` is passed further arguments, those arguments will in
turn be forwarded to ``fn`` as well as all ``setup`` and ``teardown``
handlers.
bzr revid: xmo@openerp.com-20121116071712-zuld957icellezum
|
|
* Global timeout significantly increased to correctly handle e.g. db creation and teardown
* Per-test timeout brought back down to 2s
bzr revid: xmo@openerp.com-20121115091501-ys8opo0ccr3dq29h
|
|
bzr revid: xmo@openerp.com-20121030082217-yjbh7j4apszsyg8l
|
|
bzr revid: xmo@openerp.com-20121030081525-i611as22kjlhcex5
|
|
bzr revid: xmo@openerp.com-20121030074615-lt517w5t9fd9ppvh
|
|
xmo@openerp.com-20121029110154-5927gaix8k0ijl0c introduced a
regression which wasn't caught by deferred piping (?) and caused
databases to not be dropped after rpc tests
bzr revid: xmo@openerp.com-20121030074325-wh39s75vj2zob9e0
|
|
bzr revid: xmo@openerp.com-20121029110154-5927gaix8k0ijl0c
|
|
bzr revid: xmo@openerp.com-20121026092144-0arxx2v9oi28e3d6
|
|
dependencies
bzr revid: xmo@openerp.com-20121026084543-fobkc3ta5q2jc3q6
|
|
also all existing tests shoud now be completely broken and need to be fixed
bzr revid: xmo@openerp.com-20121025154745-rw2gktfd6tp68k2m
|