Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: Tests failure when invoicing is involved after a change in Odoo upstream

Archives

Contributors

Re: Tests failure when invoicing is involved after a change in Odoo upstream

Re: Tests failure when invoicing is involved after a change in Odoo upstream

Re: Tests failure when invoicing is involved after a change in Odoo upstream

Stefan and Denis, the reason for the Odoo patch may be legit, and it is. The problem is that it comes too late for the lifecycle of this version IMO, and more having in version 17 integrated the generic CoA into account for better practices. Anyway, this is just undisclosing a problem that has been hidden in the design of our OCA tests, them not being deterministic and really unit tests, as they are relying on previous state of data for being successful:

- The company used is the one populated by default instead of using a full set of data including the company. This may be reasonable for execution times, and that's why the decision to just fix this condition installing an existing CoA instead of populating on each test a new company.
- There's no guarantee a CoA is loaded at the time of performing the tests, but creating an invoice requires it. That's why the post-install thing (and it's also a requirement if inheriting AccountTestInvoicingCommon).


Inheriting from AccountTestInvoicingCommon, as explained in the commit message I linked in my first message, it's not improving the thing (at least in 16, in 17 it's more ironized), because it still requires `l10n_generic_coa` installed (and installed before the execution of this test), and its setup is very heavy, creating 2 companies (even if you only require one), so this would increase the test execution times a lot in the best case, or skipped without you really noticing in the worst (when generic CoA is not available).

The added code is NOT boilerplate. It's legit code for making deterministic tests, the same as you may remove currency rates for having a deterministic environment. And it's totally harmless if you don't need it, because starting with, it's in test code, not in business code, and if you keep the previous status quo, the if it's not executed, so it doesn't affect any previous condition. This can only uncover other hidden defects on the modules being executed in post-install, and this is being patched at the same time.

Replying to other threads answers, I don't think this will reverted, as AFAIK Odoo.sh is auto-installing the modules that hides the problem, and not installing any localization module, but I'm not expert of that platform, so I may be wrong.

Regards.
by Pedro M. Baeza - 04:52 - 26 Feb 2025

Reference

  • Tests failure when invoicing is involved after a change in Odoo upstream
    I write to inform you that Odoo has performed a change in "stable" 16.0 in this commit:


    that is affecting CIs, specially on those integration ones that OCA implementers perform combining all the modules of a specific instance.

    This change avoids the auto-install of one CoA on the existing demo main company, as it doesn't comply with a country CoA unless you have l10n_us installed. Some tests inheriting from  AccountTestInvoicingCommon won't fail if l10n_generic_coa is installed, but it's also a requirement that can't always be fulfilled.

    The impact of this is huge across OCA, as basically every test creating an invoice is affected. OCA CI may not be red, but use it in other place and you may be doomed.


    Thus, from Tecnativa, we have started a massive pull request campaign fixing most of the common modules with this problem.

    The strategy has been to force a load of the generic CoA or the first existing one into the main company if starting the test, it doesn't have any. Check the minimum example at:


    If you are inheriting from AccountTestInvoicingCommon, the strategy should be different. By default, you won't have a red CI, but the tests are skipped, which is also undesirable. Thus, you have to do the work before calling super. Check an example here:


    v17 is not affected for now. Let's hope it continues this way...

    Regards.
    by Pedro M. Baeza - 03:41 - 25 Feb 2025