openerp-expert-framework team mailing list archive

[Georges Racinet <gracinet@xxxxxxxxx>]

Hi Leonardo,

On 04/30/2014 12:14 PM, Leonardo Pistone wrote:
> Hi Georges.
> 
> Not an answer to your questions, but on the subject on how to run tests:
> when writing OpenERP tests, and especially when trying to do some TDD, I
> did feel the need for somewhat better output. In particular, having test
> failures mixed into the logging messages is a bit inconvenient,
> assertRaises shows an ERROR message even if the test passes, and there
> is no exit value in case of failure, so some kind of grepping is needed
> for CI or for running "git bisect".
> 
> Your mention to nose grabbed my attention: even if as you say it is a
> bit crude, could you please elaborate on your setup with nose?

This is for users of the buildout recipe only, but you happen to be one…

It's explained there, as a use-case example (well you'll need to add at
least 'nose' to the eggs):
http://pythonhosted.org/anybox.recipe.openerp/scripts.html#command-line-options

A few precisions on top of that:

- you'll probably need to restrict the scope of search for tests to your
addon, and even (maybe not always) to the precise directory holding the
tests. Something like

  bin/nosetests -d mydb -- my_addons/the_addon/tests

- nose does not care about fast_suite. Conversely, it's easy to forget
to register the tests in fast_suite if you develop with nose, meaning
that the builtin OpenERP runner will ignore them
- for the current trunk, you'll need the fix for this
https://bugs.launchpad.net/anybox.recipe.openerp/+bug/1314566 (later today)

That's it ! Enjoy the options I can't imagine to live without: --pdb,
--pdb-failures, --with-id, --failed etc.

This is also how the integrations tests of the recipe work:
http://docs.anybox.fr/anybox.recipe.openerp/trunk/contributing.html#integration-tests
(in this case, the tests are not even in a proper addon)

Actually, if you launch nosetests with the python interpreter built by
the recipe, it'll work, but you'll get strange effects if nose happens
to import your modules before the registry (through the base test class)
does.

That's why I introduced this "command-line-options=-d" modifier in the
recipe : to load the database before exec'ing nose (previous versions
required protection of the addon against double import).

Alas, the side effect is that coverage doesn't witness the loading,
leading to a mostly unsuable report (that's the crude part)
It's been a while since I've focused on that, but I think to correct the
problem would require writing a dedicated nose plugin.

Cheers,
-- 
Georges Racinet
Anybox SAS, http://anybox.fr
Bureau: 09 72 39 50 97 / 09 72 39 13 06
Portable: 06 51 32 07 27
GPG: 0x33AB0A35, sur serveurs publics

Attachment: signature.asc
Description: OpenPGP digital signature