summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorChristophe Monniez <moc@odoo.com>2019-10-25 11:27:35 +0000
committerChristophe Monniez <moc@odoo.com>2019-10-30 12:35:23 +0000
commit8d5da6e4be05428f3243f92c0464d3c1f6a43873 (patch)
treea0fdc729641ef638d1edfb3646c463eba28f3697 /doc
parentb6ed34e134f868d7ccdfcb436592e0cc343fa3b5 (diff)
[IMP] tests: log a warning when HttpCase test in at_install
When loading a page on an existing starting database, registry is not fully loaded causing potential error when trying to access model existing in database (views, menitem, ...) since model added in last loaded module does not exist in registry. Thus, executing browser js test may lead to errors when executed during an update on a database with other modules installed. HTTPCase should be executed post_install to ensure that registry is fully loaded to avoid this problem. Since HTTPCase are slower than other test, it is also a good idea to execute them at the end, in order to prioritize fast fail. With this commit, a warning is isued if such a test class is tagged to run at install time. While at it, remove deprecated at_install and post_install helpers and remove the deprecated phantom_js alias. closes odoo/odoo#39462 Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Diffstat (limited to 'doc')
-rw-r--r--doc/reference/testing.rst6
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/reference/testing.rst b/doc/reference/testing.rst
index 54c46da3b96..def3e9f62ad 100644
--- a/doc/reference/testing.rst
+++ b/doc/reference/testing.rst
@@ -56,7 +56,7 @@ related to testing Odoo content (modules, mainly):
.. autoclass:: odoo.tests.common.SavepointCase
.. autoclass:: odoo.tests.common.HttpCase
- :members: browse_ref, ref, url_open, phantom_js
+ :members: browse_ref, ref, url_open, browser_js
.. autofunction:: odoo.tests.common.tagged
@@ -321,7 +321,7 @@ infrastructure:
- we want the runbot to also run these tests, so there is a test (in `test_js.py`_)
which simply spawns a browser and points it to the *web/tests* url. Note that
- the phantom_js method does not spawn phantom_js, but Chrome headless instead.
+ the browser_js method spawns a Chrome headless instance.
Modularity and testing
@@ -501,7 +501,7 @@ Testing Python code and JS code separately is very useful, but it does not prove
that the web client and the server work together. In order to do that, we can
write another kind of test: tours. A tour is a mini scenario of some interesting
business flow. It explains a sequence of steps that should be followed. The
-test runner will then create a phantom_js browser, point it to the proper url
+test runner will then create a Chrome headless browser, point it to the proper url
and simulate the click and inputs, according to the scenario.
Screenshots and screencasts during browser_js tests