Use dj tool to generate fixtures for tests

[simahawk]

It would be super useful if we could reuse dj tool to generate fixtures data for tests. Many times you need to prepare a whole scenario to test macro functionalities and some times we don't write tests at all because it would be too complex to generate demo data for them.

Generated files should stay inside the test folder and test setup should be able to run songs on demand.

Running anthem inside tests should work. Maybe we want to prefix xmlids w/ __test__ or something like that to avoid confusion (?).

@guewen any thoughts?

[simahawk]

for anthem we need this https://github.com/camptocamp/anthem/pull/23

[guewen]

Maybe we want to prefix xmlids w/ test or something like that to avoid confusion (?).

I'd say yes, or no module at all? Anyway they should be rollbacked at the end of the test.

We can't execute anthem as a subprocess, because it would commit the changes. We'll have to adapt anthem's lib (started in https://github.com/camptocamp/anthem/pull/23/). I'd say the Context should be really different to handle that mode. It must share the same public interface (log_line and log). With those differences:

• it doesn't need any odoo_args as we won't start a new odoo instance, we're already in one
• although it would need an existing odoo environment
• it would not commit nor rollback the Cursor, the environment passed to it will be handled at an upward level
• _build_odoo_env (https://github.com/camptocamp/anthem/blob/master/anthem/cli.py#L112-L133) is useless, as we don't have to start a new odoo service

Beside that, the code inside the run function in the context should be turned as a method of Context https://github.com/camptocamp/anthem/blob/a3773a76a3d33bbf28a95978b6cf0cfdcbda82a6/anthem/cli.py#L85-L94

class Context(object):

   # ...

   def run(self, target):
        mod_name, func_name = target.split('::')
        module = importlib.import_module(mod_name)
        func = getattr(module, func_name)
        func(self)
        if options.interactive:
            console = code.InteractiveConsole(locals={'ctx': self})
            import rlcompleter  # noqa
            import readline
            readline.parse_and_bind("tab: complete")
            console.interact(banner=banner())

From the test perspective, the usage of the API could look like:

from anthem import TestContext, Options

def test_a(self):
    with TestContext(Options(quiet=True)) as ctx:
        ctx.run('odoo.addons.mymodule.tests.fixtures.partner::main')

Or (no interactive support in this case)

from anthem import TestContext, Options
from .fixtures.partner import main

def test_a(self):
    with TestContext(Options(quiet=True)) as ctx:
        main(ctx)

That being said, what would easier between that, which brings anthem as dependency, or add a specific export in odoo-prototype that outputs xml / yaml and allow to generate the few lines to add in the tests to import them the odoo way? Main concern being that for an OCA module, if we can avoid a dependency on anthem that'd be better. If the goal is mainly to import data, I'd go the odoo way, if we want more configuration (accounting, stock), then indeed anthem is required.