[FIX] rdtraining: fix writing errors
closes odoo/documentation#3276 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit is contained in:
parent
a63621dc7a
commit
14be609d38
@ -12,9 +12,9 @@ Advanced E: Python Unit Tests
|
|||||||
|
|
||||||
**Reference**:
|
**Reference**:
|
||||||
`Odoo's Test Framework: Learn Best Practices <https://www.youtube.com/watch?v=JEIscps0OOQ>`__
|
`Odoo's Test Framework: Learn Best Practices <https://www.youtube.com/watch?v=JEIscps0OOQ>`__
|
||||||
(Odoo Experience 2020) on Youtube.
|
(Odoo Experience 2020) on YouTube.
|
||||||
|
|
||||||
Writing tests is a necessity for multiple reasons. Here is a non exhaustive list:
|
Writing tests is a necessity for multiple reasons. Here is a non-exhaustive list:
|
||||||
|
|
||||||
* Ensure code will not be broken in the future
|
* Ensure code will not be broken in the future
|
||||||
* Define the scope of your code
|
* Define the scope of your code
|
||||||
@ -168,7 +168,7 @@ Modules
|
|||||||
=======
|
=======
|
||||||
|
|
||||||
Because Odoo is modular, the tests need to be also modular. This means tests are defined in
|
Because Odoo is modular, the tests need to be also modular. This means tests are defined in
|
||||||
the module that adds the functionality you are adding in and tests cannot depend on functionality
|
the module that adds the functionality you are adding in, and tests cannot depend on functionality
|
||||||
coming from modules your module doesn't depend on.
|
coming from modules your module doesn't depend on.
|
||||||
|
|
||||||
**Reference**: the documentation related to this topic can be found in
|
**Reference**: the documentation related to this topic can be found in
|
||||||
@ -193,21 +193,21 @@ coming from modules your module doesn't depend on.
|
|||||||
|
|
||||||
|
|
||||||
If the behavior you want to test can be changed by the installation of another module, you need to
|
If the behavior you want to test can be changed by the installation of another module, you need to
|
||||||
ensure that the tag `at_install` is set; otherwise you can use the tag `post_install` to speed up
|
ensure that the tag `at_install` is set; otherwise, you can use the tag `post_install` to speed up
|
||||||
the CI and ensure it is not changed if it shouldn't.
|
the CI and ensure it is not changed if it shouldn't.
|
||||||
|
|
||||||
Writing a test
|
Writing a test
|
||||||
==============
|
==============
|
||||||
|
|
||||||
**Reference**: the documentation related to this topic can be found in
|
**Reference**: the documentation related to this topic can be found in
|
||||||
`Python unittest <https://docs.python.org/3/library/unittest.html>`__.
|
`Python unittest <https://docs.python.org/3/library/unittest.html>`__
|
||||||
and :ref:`Testing Odoo<reference/testing>`.
|
and :ref:`Testing Odoo<reference/testing>`.
|
||||||
|
|
||||||
Here are a few things to take into consideration before writing a test
|
Here are a few things to take into consideration before writing a test
|
||||||
|
|
||||||
* The tests should be independent from the data currently in the database (including demo data)
|
* The tests should be independent of the data currently in the database (including demo data)
|
||||||
* Tests should not impact the database by leaving/changing residual data. This is usually done by
|
* Tests should not impact the database by leaving/changing residual data. This is usually done by
|
||||||
the test framework by doing a rollback. This is why you must never call ``cr.commit`` in a test
|
the test framework by doing a rollback. Therefore, you must never call ``cr.commit`` in a test
|
||||||
(nor anywhere else in the business code).
|
(nor anywhere else in the business code).
|
||||||
* For a bug fix, the test should fail before applying the fix and pass after.
|
* For a bug fix, the test should fail before applying the fix and pass after.
|
||||||
* Don't test something that is already tested elsewhere; you can trust the ORM. Most of the tests
|
* Don't test something that is already tested elsewhere; you can trust the ORM. Most of the tests
|
||||||
@ -218,7 +218,7 @@ Here are a few things to take into consideration before writing a test
|
|||||||
in python. This also applies in the tests. If you want to emulate a Form view, you can use
|
in python. This also applies in the tests. If you want to emulate a Form view, you can use
|
||||||
``odoo.tests.common.Form``.
|
``odoo.tests.common.Form``.
|
||||||
|
|
||||||
The tests should be located in a ``tests`` folder in the root of your module. Each test file name
|
The tests should be in a ``tests`` folder at the root of your module. Each test file name
|
||||||
should start with `test_` and be imported in the ``__init__.py`` of the test folder. You shouldn't
|
should start with `test_` and be imported in the ``__init__.py`` of the test folder. You shouldn't
|
||||||
import the test folder/module in the ``__init__.py`` of the module.
|
import the test folder/module in the ``__init__.py`` of the module.
|
||||||
|
|
||||||
@ -283,7 +283,7 @@ These test classes are built on top of the ``unittest`` python module.
|
|||||||
|
|
||||||
.. note:: For better readability, split your tests into multiple files depending on the scope of the
|
.. note:: For better readability, split your tests into multiple files depending on the scope of the
|
||||||
tests. You can also have a Common class that most of the tests should inherit from; this common
|
tests. You can also have a Common class that most of the tests should inherit from; this common
|
||||||
class can define the whole set up for the module. For instance in
|
class can define the whole setup for the module. For instance, in
|
||||||
`account <{GITHUB_PATH}/addons/account/tests/common.py>`__.
|
`account <{GITHUB_PATH}/addons/account/tests/common.py>`__.
|
||||||
|
|
||||||
.. exercise:: Update the code so no one can:
|
.. exercise:: Update the code so no one can:
|
||||||
|
@ -23,7 +23,7 @@ information in an organized template to support the business in different ways.
|
|||||||
can additionally add our company's header and footer to our reports with minimal extra effort.
|
can additionally add our company's header and footer to our reports with minimal extra effort.
|
||||||
|
|
||||||
The documentation related to this topic can be found in :ref:`reference/qweb`,
|
The documentation related to this topic can be found in :ref:`reference/qweb`,
|
||||||
:ref:`reference/reports/report` and the :ref:`reference/actions/report`
|
:ref:`reference/reports/report`, and the :ref:`reference/actions/report`
|
||||||
section of the Actions reference.
|
section of the Actions reference.
|
||||||
|
|
||||||
File Structure
|
File Structure
|
||||||
@ -32,13 +32,13 @@ File Structure
|
|||||||
The bulk of a PDF report is its QWeb template. It also typically needs a corresponding
|
The bulk of a PDF report is its QWeb template. It also typically needs a corresponding
|
||||||
``ir.actions.report`` to include the report within a module's business logic.
|
``ir.actions.report`` to include the report within a module's business logic.
|
||||||
There is no strict rule for the file names or where they are located, but these two parts are
|
There is no strict rule for the file names or where they are located, but these two parts are
|
||||||
typically stored in 2 separate files within a ``report`` folder in the top level of your module's
|
typically stored in 2 separate files within a ``report`` folder at the top level of your module's
|
||||||
directory. If a module has many or multiple long report templates, then they are often organized in
|
directory. If a module has many or multiple long report templates, then they are often organized
|
||||||
a logical manner across different files named after the report(s) they contain. All actions
|
logically across different files named after the report(s) they contain. All actions
|
||||||
for the reports are usually stored in the same file ending with ``_reports.xml`` regardless of the
|
for the reports are usually stored in the same file ending with ``_reports.xml``, regardless of the
|
||||||
number of reports it contains.
|
number of reports it contains.
|
||||||
|
|
||||||
Therefore it is expected that your work tree will look something like:
|
Therefore, it is expected that your work tree will look something like this:
|
||||||
|
|
||||||
.. code-block:: bash
|
.. code-block:: bash
|
||||||
|
|
||||||
@ -61,8 +61,8 @@ the report folder. These are unrelated to the reports covered in this tutorial a
|
|||||||
:ref:`another advanced topic <howto/rdtraining/K_dashboard>`. For now you can think of them as customized views
|
:ref:`another advanced topic <howto/rdtraining/K_dashboard>`. For now you can think of them as customized views
|
||||||
that use direct SQL queries (sometimes referred to as SQL Views).
|
that use direct SQL queries (sometimes referred to as SQL Views).
|
||||||
|
|
||||||
Don't forget to add whatever files your template and action view will be located in to your ``__manifest__.py``.
|
Don't forget to add whatever files your template and action view will be into to your ``__manifest__.py``.
|
||||||
In this case you will want to add the files to the ``data`` list and remember that the files listed in a manifest
|
In this case, you will want to add the files to the ``data`` list and remember that the files listed in a manifest
|
||||||
are loaded sequentially!
|
are loaded sequentially!
|
||||||
|
|
||||||
Basic Report
|
Basic Report
|
||||||
@ -155,10 +155,10 @@ our minimal property offers template file:
|
|||||||
Most of the Odoo specific (i.e. non-HTML) items in our file are explained in the minimal viable template section.
|
Most of the Odoo specific (i.e. non-HTML) items in our file are explained in the minimal viable template section.
|
||||||
Some additional features in our template are:
|
Some additional features in our template are:
|
||||||
|
|
||||||
* The use of the ``class="table"`` attribute so our table has some nice formatting. Twitter Bootstrap
|
* The use of the ``class="table"`` attribute, so our table has some nice formatting. Twitter Bootstrap
|
||||||
(we're using its table class in this case) and FontAwesome (useful for adding icons) classes can
|
(we're using its table class in this case), and Font Awesome (useful for adding icons) classes can
|
||||||
be used in your report template.
|
be used in your report template.
|
||||||
* The use of ``t-set``, ``t-value``, ``t-foreach`` and ``t-as`` so that we can loop over all of the ``offer_ids``.
|
* The use of ``t-set``, ``t-value``, ``t-foreach``, and ``t-as`` so that we can loop over all the ``offer_ids``.
|
||||||
|
|
||||||
If you are already familiar with website templating engines, then the QWeb directives (i.e. the `t-` commands)
|
If you are already familiar with website templating engines, then the QWeb directives (i.e. the `t-` commands)
|
||||||
probably don't need much explanation and you can just look at its :ref:`documentation <reference/qweb>` and
|
probably don't need much explanation and you can just look at its :ref:`documentation <reference/qweb>` and
|
||||||
@ -172,7 +172,7 @@ such as setting and accessing temporary variables. For example, in the above exa
|
|||||||
|
|
||||||
* ``t-set`` creates a temporary variable called "offers" that has its value set by ``t-value`` to the current
|
* ``t-set`` creates a temporary variable called "offers" that has its value set by ``t-value`` to the current
|
||||||
``estate.property`` recordset's ``offer_ids``.
|
``estate.property`` recordset's ``offer_ids``.
|
||||||
* the ``t-foreach`` and ``t-as`` usage is the equivalent to the Python:
|
* The ``t-foreach`` and ``t-as`` usage is the equivalent to the Python:
|
||||||
|
|
||||||
.. code-block:: Python
|
.. code-block:: Python
|
||||||
|
|
||||||
@ -189,9 +189,9 @@ corresponding to
|
|||||||
Its contents are all explained in :ref:`the documentation <reference/actions/report>`.
|
Its contents are all explained in :ref:`the documentation <reference/actions/report>`.
|
||||||
|
|
||||||
An ``ir.actions.report`` is primarily used via the Print menu of a model's view. In the practical
|
An ``ir.actions.report`` is primarily used via the Print menu of a model's view. In the practical
|
||||||
example, the ``binding_model_id`` specifies which model's views the report should show in and Odoo
|
example, the ``binding_model_id`` specifies which model's views the report should show, and Odoo
|
||||||
will auto-magically add it for you. Another common use case of the report action is to link it to
|
will auto-magically add it for you. Another common use case of the report action is to link it to
|
||||||
a button like we learned in :ref:`howto/rdtraining/10_actions`. This is handy for reports that
|
a button as we learned in :ref:`howto/rdtraining/10_actions`. This is handy for reports that
|
||||||
only make sense under specific conditions. For example, if we wanted to make a "Final Sale" report,
|
only make sense under specific conditions. For example, if we wanted to make a "Final Sale" report,
|
||||||
then we can link it to a "Print Sale Info" button that appears in the form view only when the
|
then we can link it to a "Print Sale Info" button that appears in the form view only when the
|
||||||
property is "Sold".
|
property is "Sold".
|
||||||
@ -201,7 +201,7 @@ property is "Sold".
|
|||||||
:alt: Print Menu Button
|
:alt: Print Menu Button
|
||||||
|
|
||||||
You may have noticed or are wondered why our report template loops through a recordset. When our
|
You may have noticed or are wondered why our report template loops through a recordset. When our
|
||||||
template is passed more than one record, it can produce one PDF report for all of the records.
|
template is passed more than one record, it can produce one PDF report for all the records.
|
||||||
Using the Print menu in the list view with multiple records selected will demonstrate this.
|
Using the Print menu in the list view with multiple records selected will demonstrate this.
|
||||||
|
|
||||||
Make a Report
|
Make a Report
|
||||||
@ -235,7 +235,7 @@ Sub-templates
|
|||||||
:alt: Report using a subtemplate
|
:alt: Report using a subtemplate
|
||||||
|
|
||||||
There are two main reasons for using sub-templates. One is to make the code easier to read when working with
|
There are two main reasons for using sub-templates. One is to make the code easier to read when working with
|
||||||
extra long or complicated templates. The other is to reuse code where possible. Our simple property offers
|
extra-long or complicated templates. The other is to reuse code where possible. Our simple property offers
|
||||||
report is useful, but listing property offers information can be useful for more than just one report template.
|
report is useful, but listing property offers information can be useful for more than just one report template.
|
||||||
One example is a report that lists all of a salesman's properties' offers.
|
One example is a report that lists all of a salesman's properties' offers.
|
||||||
|
|
||||||
@ -288,7 +288,7 @@ created for them, so we can add this information to our report.
|
|||||||
Additional Features
|
Additional Features
|
||||||
===================
|
===================
|
||||||
|
|
||||||
All of the following extra features are described further in the :ref:`reference/reports/report`
|
All the following extra features are described further in the :ref:`reference/reports/report`
|
||||||
documentation, including how to implement each of them.
|
documentation, including how to implement each of them.
|
||||||
|
|
||||||
Translations
|
Translations
|
||||||
@ -296,13 +296,13 @@ Translations
|
|||||||
|
|
||||||
We all know Odoo is used in multiple languages thanks to automated and manual translating. QWeb reports are no
|
We all know Odoo is used in multiple languages thanks to automated and manual translating. QWeb reports are no
|
||||||
exception! Note that sometimes the translations do not work properly if there are unnecessary spaces in your
|
exception! Note that sometimes the translations do not work properly if there are unnecessary spaces in your
|
||||||
template's text content so try to avoid them when possible (especially leading spaces).
|
template's text content, so try to avoid them when possible (especially leading spaces).
|
||||||
|
|
||||||
Reports are web pages
|
Reports are web pages
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
You probably are tired of hearing that QWeb creates HTML, but we're saying it again! One of the
|
You probably are tired of hearing that QWeb creates HTML, but we're saying it again! One of the
|
||||||
neat features about reports being written in QWeb is they can be viewed within the web browser.
|
neat features of reports being written in QWeb is they can be viewed within the web browser.
|
||||||
This can be useful if you want to embed a hyperlink that leads to a specific report. Note that
|
This can be useful if you want to embed a hyperlink that leads to a specific report. Note that
|
||||||
the usual security checks will still apply to prevent unauthorized users from accessing the reports.
|
the usual security checks will still apply to prevent unauthorized users from accessing the reports.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user