Turns out select has its own select.error which does *not* subclass
EnvironmentError (or OSError or IOError) and does *not* have a .errno
attribute. So use the correct exception, might just work better than using
a completely different one with no relation.
bzr revid: xmo@openerp.com-20140219155303-sgz7m3gnzr2bmani
altered reporting to handle and deserialize JSON if JSON-deserializable. Can't
just send multiple lines as driver currently does not handle multiple lines of
message... Yeah turns out having a JSON-based protocol between phantomjs and
the python runner allowed multiple lines in messages, who'd have thought eh?
bzr revid: xmo@openerp.com-20140219123850-0h0upb3x33j7leqk
* use Skip exception to skip tests in case phantomjs binary not found
* remove spurious logging, move some to debug when debatable
* use testing assertions for correct reporting
* allow failure message
* use mutable buffer to accumulate stdout data
bzr revid: xmo@openerp.com-20140218133445-e5l155j10i934o88
self.phantom_js(<page_to_load>, <code_to_run>, <global_object_to_wait>, **options)
example:
self.phantom_js("/", "openerp.module.mytest()", "openerp.module.mytest");
console.log('ok') or console.log('error') should be used to signal success or
failure. Other console.log's will be passed to the test logger.
bzr revid: al@openerp.com-20140210004517-jc2cobc31qshxchm
remove deprecated zipfile support
add preload_registry option when server is running
allow registries to be used in contruction in test mode
add a rollback test case for http tests
add a phantomjs helper
bzr revid: al@openerp.com-20140209004005-p5pwym4sqc23vw5b
encapsulatse the whole content inside a div. This means that html fields are
not editor-clean after being sanitized, because a div has been inserted as root
element. Removing this element allows to have snippets that can be dragged,
dropped, or to insert new snippets inside edited html content in html fields.
[IMP] tools: tests: mail: updated a test accordingly
bzr revid: tde@openerp.com-20140115142709-e4951b4nc06sfxf0
locales are a pain in the ass, there doesn't seem to be any locale
which all machines are guaranteed to have (except maybe C), and some
systems reject encoding-less locales while babel rejects encodings.
bzr revid: xmo@openerp.com-20140109081731-uryy2aa2odc7ud2g
In order to ensure that the conversion is at least sensible, we test
the output of strftime and babel on the same pattern (after conversion
from POSIX to LDML for Babel). This requires that both use the same
locale.
Previously, the default locale was being used(-ish), but it turns out
when the locale is unset (getdefaultlocale() returns (None, None)
``strftime`` still manages to use some sort of default locale (C?),
whereas Babel will yield the locale None. It turns out the runbot
executes the server with no locale-related envvar set, and thus hits
this very issue.
Assume there are no concurrent tests being run and use setlocale to
try and ensure strftime and babel see the same locale.
Also, remove tests on %x and %X, turns out libc and babel generally
have very different ideas about what constitutes a "national
representation" of a date or time, so the patterns don't match in the
first place. And I found no way to expand %x/%X into its sub-patterns.
bzr revid: xmo@openerp.com-20140108162817-n5gd2oryaszf099k
Antony Lesuisse
Xavier Morel
Christophe Matthieu
Fabien Pinckaers
Olivier Dony
Christophe Simonis
jke-openerp
Gery Debongnie
Thibault Delavallée
Denis Ledoux
Stephane Wirtel