| Age | Commit message (Collapse) | Author |
|---|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
|
|
|
Previously, the context for `options.{before,after}Each()` functions was
isolated from the context created by the odoo `test` function, making
it impossible to save attributes in the test during
`options.beforeEach()` that are accessible from the test itself, or to
clear resources created in the test in `options.afterEach()`
Moreover, the odoo test infrastructure was set up completely inside the
test wrapper, after `options.beforeContext()` had already run, making
it impossible for `options.beforeContext()` to use this infrastructure.
Here we use the QUnit context directly in the test, but move the
initialization previously done in the test wrapper to a `beforeEach`
wrapper (and, symetrically, on `afterEach`), making it possible to use
the odoo infrastructure in the javascript test setup, including
declared section dependencies.
|
|
each time a js test is run, it used to start the chat manager, which
does a rpc. This simply prevent the chat manager to start.
|
|
this js module centralizes all odoo initialization
|
|
Various tests (mostly tours) were broken with the large changes in the
way the js code works.
|
|
The test suite needs to be adapted to the modules. Also, the update
of qunit changes the API, so the tests needs to be changed as well.
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130725112416-j6wbm254yx05i890
|
|
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
|
|
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
|
|
also all existing tests shoud now be completely broken and need to be fixed
bzr revid: xmo@openerp.com-20121025154745-rw2gktfd6tp68k2m
|
|
bzr revid: chs@openerp.com-20120814152900-8r84kyz0qy1hwkvz
|
|
on ORM method name
bzr revid: xmo@openerp.com-20120704132822-3p4h1c6cyr0qvn2x
|
|
view tests to those
bzr revid: xmo@openerp.com-20120704112406-1lqwahtdo7fnla8o
|
