Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
Accounting tests are executed post install to be sure a chart
of account is install. However, for some case, we might want
to run test at module installation, involving accounting, without
being sure a chart of account is installed.
This commit provides a base common test class with a minimal chart
of account (some journals and accounts) allowing to start tests at
installation. this class should be extended in sale or expense for
this modules to be tests at installation. We will required this for
reinvoice test in sale later (test consumable product when sale_stock
is not installed, but maybe without a chart of account). The idea is
each test suite can call method to setup their own data.
This commit also use this common test class in sale_expense.
Accounting tests are done 'post install' because
their generally requried a chart of account to be
installed before test execution.
If a test is launched before l10n install, the test
will be skipped but nobody will know it, unless you
read all the logs of your server.
When skipping a test, a warning should be displayed.
Before this commit, when a localization defined default payable or receivable
accounts on partners (like l10n_do does)
The reconciliation tests that involve an invoice on the one hand and a payment on the other hand
broke just because the accounts of the payment and the one of the invoice did not match
After this commit, we force the receivable or payable account to be the partner's (if available)
and the tests do not break
- Create a tax:
Fixed amount: 10
Price included
- Add it by default to a product costing 100
- In a SO/PO/Invoice, add 2 units of the product
The total price is 210 instead of 200.
opw-779696
- Create a tax included of 21 %
- Create a product sold 7.00, set the 21 % tax
- Add the product in a SO
Amount w/o tax: 5.79
Amount tax: 1.22
Total: 7.01
We defer the base rounding to the end of the method so that the rounding
doesn't impact the tax computation of included taxes.
Complement of 6e46ba7b46
opw-777221
In some countries, we need to be able to make appear on an invoice a rounding line, appearing there only because the smallest
coinage has been removed from the circulation.
For example, in Switerzland invoices have to be rounded to 0.05 CHF because coins of 0.01 CHF and 0.02 CHF aren't used anymore.
Was PR #15231
Was task 30904
This is usually made through the action of the setup bar but in the test we create manually the wizard, so we have to force the opening entry creation first
Add a setup bar on account's dashboard, so that the user can more easily enter the initial data of his Odoo installation, following the steps that are proposed to him.
Was PR #16864
Was task 32119
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
Christophe Monniez