テストOdoo¶

アプリケーションをテストする方法はたくさんあります。Odooでは3種類のテストがあります。

Python の単体テスト (`Testing Python code`_を参照): ビジネスロジックのテストに役立ちます
JS の単体テスト (`JS codeのテストを参照してください: JavaScriptコードを単独でテストするのに役立ちます
ツアー (`Integration Testing`_を参照) : ツアーは現実の状況をシミュレートします。Python と javascript の部分が互いに適切に動作するようにします。

Python コードのテスト¶

Odoo は Pythonのunittest library を使用してモジュールをテストするためのサポートを提供しています。

テストを記述するには、モジュールに tests サブパッケージを定義するだけで、テストモジュールが自動的に検査されます。テストモジュールは test_ で始まる名前で、tests/__init__.py などからインポートする必要があります。

your_module
├── ...
├── tests
|   ├── __init__.py
|   ├── test_bar.py
|   └── test_foo.py

および `__init__.py`には以下が含まれています：

from . import test_foo, test_bar

警告

tests/__init__.py からインポートされていないテストモジュールは実行されません

テストランナーは公式の unittest documentation に記述されているように、任意のテストケースを実行します。しかし、Odoo は Odoo コンテンツのテストに関連する多くのユーティリティやヘルパーを提供しています(主にモジュール)。

デフォルトでは、対応するモジュールがインストールされた直後にテストは一度実行されます。テストケースは、すべてのモジュールがインストールされた後に実行されるように設定することもでき、モジュールのインストール直後に実行されることはありません:

# coding: utf-8
from odoo.tests import HttpCase, tagged

# This test should only be executed after all modules have been installed.
@tagged('-at_install', 'post_install')
class WebsiteVisitorTests(HttpCase):
  def test_create_visitor_on_tracked_page(self):
      Page = self.env['website.page']

最も一般的な状況は、 TransactionCase を使用し、各メソッドでモデルのプロパティをテストすることです:

class TestModelA(TransactionCase):
    def test_some_action(self):
        record = self.env['model.a'].create({'field': 'value'})
        record.some_action()
        self.assertEqual(
            record.field,
            expected_field_value)

    # other tests...

注釈

テストメソッドは test_ で開始する必要があります

実行中のテスト¶

Odoo サーバーの起動時に --test-enable が有効になっている場合、モジュールのインストールまたは更新時にテストが自動的に実行されます。

テストの選択¶

Odooでは、テストの実行時にPythonテストをタグ付けすることで、テストの選択を容易にすることができます。

odoo.tests.BaseCase`のサブクラス（通常は :class:`~odoo.tests.TransactionCase`または :class:`~odoo.tests.HttpCase）は、デフォルトで自動的に``standard`` と at_install でタグ付けされます。

呼び出し中¶

--test-tags can be used to select/filter tests to run on the command-line. It implies --test-enable, so it's not necessary to specify --test-enable when using --test-tags.

このオプションのデフォルトは +standard です。つまり、standard (明示的または暗黙的に) タグ付けされたテストは :option:`--test-enable <odoo-bin --test-enable> ` でOdoo を起動するときにデフォルトで実行されます。

テストを書くときは、**テストクラス**でタグを追加または削除するために :func:`~odoo.tests.tagged`デコレータを使用できます。

デコレータの引数はタグ名を文字列として表します。

危険

tagged() はクラスデコレータで、関数やメソッドには影響を与えません

タグにはマイナス記号(-)で接頭辞をつけて、追加する代わりに*削除*するか、eを選択します。をクリックします。デフォルトでテストを実行したくない場合は、standard タグを削除できます。

from odoo.tests import TransactionCase, tagged

@tagged('-standard', 'nice')
class NiceTest(TransactionCase):
    ...

このテストはデフォルトでは選択されません。関連するタグを明示的に選択する必要があります。

$ odoo-bin --test-tags nice

nice とタグ付けされたテストのみが実行されることに注意してください。両方 nice と standard テストを実行するには、コマンドライン上の --test-tags: に複数の値を提供します。値は additive です (あなたは指定したタグの any のすべてのテストを選択しています)

$ odoo-bin --test-tags nice,standard

設定切り替えパラメータは + と - プレフィックスも受け付けます。+ プレフィックスは暗示されているため、完全に任意です。 - (minus) プレフィックスは、プレフィックスタグでタグ付けされたテストの選択を解除します。をクリックします。 slow としてタグ付けされた standard テストがある場合、全ての標準テストを*例外*実行できます。

$ odoo-bin --test-tags 'standard,-slow'

TestCase` を実行しない場合に一般的な問題です。

import unittest
from odoo.tests import tagged

@tagged('standard', 'at_install')
class SmallTest(unittest.TestCase):
    ...

タグに加えて、特定のモジュール、クラス、またはテストする関数を指定することもできます。 --test-tags で受け付けるフォーマットの完全な構文は次のとおりです。

[-][tag][/module][:class][.method]

ですから、 stock_account モジュールをテストしたい場合は、

$ odoo-bin --test-tags /stock_account

特定の関数を一意の名前でテストしたい場合は、直接指定することができます。

$ odoo-bin --test-tags .test_supplier_invoice_forwarded_by_internal_user_without_supplier

これは以下と等価です

$ odoo-bin --test-tags /account:TestAccountIncomingSupplierInvoice.test_supplier_invoice_forwarded_by_internal_user_without_supplier

テストの名前が曖昧でなければならないのです通常のタグのように、複数のモジュール、クラス、関数を一度に`,`で区切って指定できます。

特殊タグ¶

standard: BaseCase から継承されるすべての Odoo テストは暗黙的にタグ付けされています。 --test-tags もデフォルトで standard です。

つまり、テストが有効になっている場合、タグ付けされていないテストはデフォルトで実行されます。
at_install: モジュールのインストール直後や他のモジュールがインストールされる直前にテストが実行されることを意味します。これはデフォルトの暗黙のタグです。
post_install: 全てのモジュールがインストールされた後にテストが実行されることを意味します。ほとんどの場合、HttpCaseテストに必要なものがこれです。

これは at_install の*排他的ではない*ことに注意してください。ただし、一般的には両方の post_install はテストクラスにタグを付ける際に -at_install とペアリングされる必要はありません。

例¶

重要

Tests will be executed only in installed modules. If you're starting from a clean database, you'll need to install the modules with the -i switch at least once. After that it's no longer needed, unless you need to upgrade the module, in which case -u can be used. For simplicity, those switches are not specified in the examples below.

販売モジュールからのテストのみを実行します。

$ odoo-bin --test-tags /sale

販売モジュールからテストを実行しますが、遅くタグ付けされたものは実行しません。

$ odoo-bin --test-tags '/sale,-slow'

標準からテストのみを実行するか、遅くタグ付けされています:

$ odoo-bin --test-tags '-standard, slow, /stock'

注釈

-standard は暗黙的です (必須ではありません)。明確さを表すために存在します

JavaScriptコードのテスト¶

複雑なシステムのテストは、リグレッションを防ぎ、いくつかの基本的な機能がまだ動作することを保証するための重要な保護です。 OdooはJavaScriptで簡単ではないコードベースを持っているので、テストする必要があります。このセクションでは、JS コードを単独でテストする方法について説明します。これらのテストはブラウザに残ります。サーバーには届かないはずです

Qunit テストスイート¶

Odooフレームワークは、QUnit_ライブラリテストフレームワークをテストランナーとして使用します。 QUnit は tests と modules (関連するテストのセット) の概念を定義し、テストを実行するための Web ベースのインターフェイスを提供します。

例えば、pyUtils のテストは以下のようになります。

QUnit.module('py_utils');

QUnit.test('simple arithmetic', function (assert) {
    assert.expect(2);

    var result = pyUtils.py_eval("1 + 2");
    assert.strictEqual(result, 3, "should properly evaluate sum");
    result = pyUtils.py_eval("42 % 5");
    assert.strictEqual(result, 2, "should properly evaluate modulo operator");
});

テストスイートを実行する主な方法は、実行中の Odoo サーバーを持ってから、 /web/tests への Web ブラウザをナビゲートすることです。テストスイートは、WebブラウザのJavascriptエンジンによって実行されます。

Web UIには多くの便利な機能があります。いくつかのサブモジュールのみを実行したり、文字列に一致するテストをフィルタリングしたりできます。それは、すべてのアサーション、失敗または合格、特定のテストを再実行することができます。

警告

テストスイートが稼働している間は、以下を確認してください:

ブラウザウィンドウにフォーカスがあります
ズームイン/ズームアウトされていません。ズームレベルが100%である必要があります。

これが事実でない場合、適切な説明なしでテストに失敗することがあります。

インフラストラクチャのテスト¶

テストインフラストラクチャの最も重要な部分の概要は次のとおりです。

web.qunit_suite という名前のアセットバンドルがあります。このバンドルには、メインコード(共通資産+アセットバックエンド)、一部のライブラリ、QUnitテストランナー、および以下にリストされたテストバンドルが含まれています。
`web.tests_assets`_という名前のバンドルには、テストスイートで必要とされるほとんどのアセットとユーティリティが含まれています。カスタムQUnitアサート、テストヘルパー、遅延ロードされたアセットなどです。
別のアセットバンドル web.qunit_suite_tests にはすべてのテストスクリプトが含まれています。これは通常、テストファイルがスイートに追加される場所です。
ルート*/web/tests*にマップされた`controller`_があります。このコントローラは単に*web.qunit_suite*テンプレートをレンダリングします。
テストを実行するには、ブラウザをルート*/web/tests*に向けるだけです。その場合、ブラウザはすべての資産をダウンロードし、QUnitが引き継ぎます。
qunit_config.js には、テストが合格または失敗したときにコンソールに情報を記録するコードがあります。
ランボットにもこれらのテストを実行させたいので、テストがあります(`test_js。単純にブラウザを生成し、それを web/tests url に指定します。browser_js メソッドは Chrome のヘッドレスインスタンスを生成することに注意してください。

モジュール性とテスト¶

Odooの設計方法により、どのアドオンでもシステムの他の部分の動作を変更できます。例えば、voip アドオンは FieldPhone ウィジェットを変更して、追加機能を使用することができます。これはテストシステムの観点からはあまり良くありませんこれは、VoIPアドオンがインストールされるたびにアドオンWeb内のテストが失敗することを意味します (ランボットはすべてのアドオンをインストールしてテストを実行することに注意してください)。

同時に、私たちのテストシステムは優れています。なぜなら、別のモジュールがコア機能を壊すたびに検出できるからです。この問題に対する完全な解決策はありません。現時点では、ケースバイケースで解決します。

通常、他の動作を変更することは良い考えではありません。 voipの例では、新しい*FieldVOIPPhone*ウィジェットを追加し、必要ないくつかのビューを変更することは確かにクリーンです。これにより、FieldPhone ウィジェットは影響を受けず、両方ともテストできます。

新しいテストケースを追加する¶

アドオン my_addon を維持していると仮定しましょう。そして、いくつかのJavaScriptコードのテストを追加したいと考えています (例えば、いくつかのユーティリティ関数 myFunctionは、my_addonにあります)。 tils). 新しいテストケースを追加するプロセスは次のとおりです:

新しいファイル my_addon/static/tests/utils_tests.js を作成します。このファイルには、QUnit モジュール my_addon > utils を追加するための基本コードが含まれています。

odoo.define('my_addon.utils_tests', function (require) {
"use strict";

var utils = require('my_addon.utils');

QUnit.module('my_addon', {}, function () {

    QUnit.module('utils');

});
});

my_addon/assets.xml で、ファイルをメインのテストアセットに追加します。

<?xml version="1.0" encoding="utf-8"?>
<odoo>
    <template id="qunit_suite_tests" name="my addon tests" inherit_id="web.qunit_suite_tests">
        <xpath expr="//script[last()]" position="after">
            <script type="text/javascript" src="/my_addon/static/tests/utils_tests.js"/>
        </xpath>
    </template>
</odoo>

サーバーを再起動して*my_addon*を更新するか、インターフェースから実行してください（新しいテストファイルがロードされていることを確認してください）

utils サブテストスイートの定義の後にテストケースを追加します。

QUnit.test("some test case that we want to test", function (assert) {
    assert.expect(1);

    var result = utils.myFunction(someArgument);
    assert.strictEqual(result, expectedResult);
});

テストが実行されていることを確認するには、/web/tests/ を参照してください

ヘルパー機能と特殊なアサーション¶

助けがなければ、Odooの一部をテストするのはかなり難しいです。特に、サーバと通信し、モックする必要がある多くの rpc を実行するため、ビューはトリッキーです。これが、test_utils.js にある特殊なヘルパー関数を開発した理由です。

モックテスト機能:これらの関数はテスト環境の設定に役立ちます。最も重要なユースケースは、Odooサーバーから与えられた回答をモックすることです。これらの関数は mock server を使用します。これは最も一般的なモデルメソッドであるread_read, nameget, ...
DOM ヘルパー: 特定のターゲットでイベント/アクションをシミュレートするのに便利です。例えば、testUtils.dom.click はターゲットをクリックします。ターゲットが存在し見えることを確認するため、手動で行うよりも安全であることに注意してください。
create helpers: これらは test_utils.js でエクスポートされた最も重要な関数です。これらのヘルパーは、モック環境でウィジェットを作成するのに便利です。可能な限り実際の条件をシミュレートするための細部がたくさんあります最も重要なのは createView です。
qunit assertions: QUnit は特殊なアサーションで拡張できます。 Odoo では、DOM プロパティを頻繁にテストします。そのため、いくつかのアサーションを作成しました。例えば、containsOnce アサーションは、widget/jQuery/HtmlElement とセレクターを取得し、ターゲットに CSS セレクターに対して1つの一致が含まれているかどうかを確認します。

たとえば、これらのヘルパーを使用すると、以下のような簡単なフォームテストができます。

QUnit.test('simple group rendering', function (assert) {
    assert.expect(1);

    var form = testUtils.createView({
        View: FormView,
        model: 'partner',
        data: this.data,
        arch: '<form string="Partners">' +
                '<group>' +
                    '<field name="foo"/>' +
                '</group>' +
            '</form>',
        res_id: 1,
    });

    assert.containsOnce(form, 'table.o_inner_group');

    form.destroy();
});

testUtils.createViewヘルパーとcontainsOnce assertionの使用に注意してください。また、フォームコントローラはテストの最後に適切に破棄されました。

ベストプラクティス¶

特定の順序ではありません:

すべてのテストファイルは some_addon/static/tests/ に追加する必要があります
バグ修正の場合は、バグ修正なしでテストが失敗することを確認し、それに合格します。これにより実際に動作します。
テストに必要な最小限のコードを持ってみてください
通常、2つの小さなテストは1つの大きなテストよりも優れています。より小さいテストは理解しやすく、修正することができます。
テストの後は常にクリーンアップします。たとえば、テストがウィジェットをインスタンス化した場合は、最後にそれを破壊する必要があります。
コードを完全にカバーする必要はありませんしかし、いくつかのテストを追加すると、コードが完全に壊れていないことを確認できます。バグが修正されると既存のテストスイートにテストを追加する方がずっと簡単です
否定的なアサーションをチェックしたい場合(例えば、HtmlElement が特定の CSS クラスを持たないなど) 次に、同じテストに正のアサーションを追加しようとします(たとえば、状態を変更するアクションを実行するなど)。これは、テストが将来的に死んでしまうのを避けるのに役立ちます (例えば、css クラスが変更された場合)。

ヒント¶

唯一のテストを実行する: あなたは (一時的に!) QUnit.test(...) 定義を QUnit に変更できます。 nly(...) これは、QUnit がこの特定のテストのみを実行することを確認するのに役立ちます。
デバッグフラグ: ほとんどの生成ユーティリティ関数はデバッグモードを持ちます(debug: true パラメータによって有効化されます)。その場合、隠された qunit 固有のフィクスチャの代わりに DOM にターゲットウィジェットが置かれます。さらに多くの情報が記録されますたとえば、すべてのモックされたネットワーク通信はコンソールで利用できます。
テストに失敗する場合はデバッグフラグを追加するのが一般的です次に、テストの終了(特に破棄呼び出し)をコメントします。これにより、直接ウィジェットの状態を見ることができ、さらに良いことに、クリック/操作によってウィジェットを操作することができます。

統合テスト¶

Python コードと JS コードを別々にテストすることは非常に便利ですが、Web クライアントとサーバーが一緒に動作することを証明するものではありません。これを行うために、私たちは別の種類のテストを書くことができます: ツアー。ツアーはいくつかの興味深いビジネスフローのミニシナリオです。これは、従うべき一連のステップを説明します。テストランナーはPhantomJsブラウザを作成しますシナリオに従って適切なURLを指してクリックと入力をシミュレートします。

テストツアーを書く¶

給与体系¶

`your_module`のテストツアーを書くには、まず必要なファイルを作成します。

your_module
├── ...
├── static
|   └── tests
|       └── tours
|           └── your_tour.js
├── tests
|   ├── __init__.py
|   └── test_calling_the_tour.py
└── __manifest__.py

次に、次のことができます:

update __manifest__.py でアセットに your_tour.js を追加します。

'assets': {
    'web.assets_tests': [
        'your_module/static/tests/tours/your_tour.js',
    ],
},

update __init__.py フォルダ内の tests で test_calling_the_tour をインポートします。

Javascript¶

ツアーを登録してセットアップします。

import tour from 'web_tour.tour';
tour.register('rental_product_configurator_tour', {
    url: '/web',  // Here, you can specify any other starting url
}, [
    // Your sequence of steps
]);

任意のステップを追加します。

すべてのステップには少なくともトリガーが含まれています。あらかじめ定義されたステップを使用するか、自分用にカスタマイズされたステップを書くことができます。

次の手順の例を示します:

Example

// First step
tour.stepUtils.showAppsMenuItem(),
// Second step
{
   trigger: '.o_app[data-menu-xmlid="your_module.maybe_your_module_menu_root"]',
   isActive: ['community'],  // Optional
   run: "click",
}, {
    // Third step
},

Example

{
    trigger: '.js_product:has(strong:contains(Chair floor protection)) .js_add',
    run: "click",
},

Example

{
    isActive: ["mobile", "enterprise"],
    content: "Click on Add a product link",
    trigger: 'a:contains("Add a product")',
    tooltipPosition: "bottom",
    async run(helpers) { //Exactly the same as run: "click"
      helpers.click();
    }
},

あなたのパーソナライズされたステップのいくつかの可能な引数を以下に示します:

trigger: アクションオンの run に必要なセレクター/要素を指定します。ツアーは要素が存在するまで待機し、*上で*実行される*アクションの``run``の前に表示されます。
run: 任意, trigger 要素を実行するアクション. run がない場合, アクションはありません.

アクションは次のようになります:
- 関数は非同期で、トリガーの Tip をコンテキスト (this) として実行し、アクションヘルパーをパラメータとして実行します。
- トリガー要素上で実行されるアクションヘルパーの名前:
  
  check
  trigger 要素がチェックされていることを保証します。このヘルパーは`<input[type=checkbox]>`要素のみを対象としています。
  
  clear
  **trigger**要素の値をクリアします。このヘルパーは`<input>`または`<textarea>`要素のみを対象としています。
  
  click
  関連するすべての中間イベントを実行する trigger 要素をクリックします。
  
  dblclick
  2 つの繰り返しで click と同じです。
  
  drag_and_drop target
  target への**trigger**要素のドラッグをシミュレートします。
  
  編集 content
  clear 要素と fill は content です。
  
  editor content
  trigger 要素 (wysiwyg) と content を press にフォーカスします。
  
  :samp:` {content}`
  trigger 要素にフォーカスし、その後 press content`` を press にフォーカスします。このヘルパーは、<input> または <textarea> 要素のみを対象としています。
  
  hover
  trigger 要素のホバーシーケンスを実行します。
  
  :samp:` {content} を押す`
  キーボードイベントシーケンスを実行します。
  
  range content
  **trigger**要素にフォーカスし、content を値として設定します。このヘルパーは、`<input[type=range]>`要素のみを対象としています。
  
  select value
  trigger 要素の選択イベントシーケンスを実行します。value でオプションを選択します。このヘルパーは、`<select>`要素のみを対象としています。
  
  selectByIndex index
  select と同じですが、index でオプションを選択します。最初のオプションはインデックス0であることに注意してください。
  
  selectByLabel label
  select と同じですが、label でオプションを選択します。
  
  uncheck
  **trigger**要素がチェックされていないことを保証します。このヘルパーは`<input[type=checkbox]>`要素のみを対象としています。
isActive: 任意, isActive 配列のすべての条件が満たされている場合にのみ、ステップを有効にします。 - ブラウザは、デスクトップ**または**モバイル**モードのいずれかです。 - ツアーは**コミュニティ か エンタープライズ のいずれかに関係します。- ツアーは**自動** (ランボット) または マニュアル (オンボーディング) モードのいずれかで実行されます。
tooltipPosition: 省略可能, "top", "right", "bottom", "left". インタラクティブなツアーを実行する際に**ターゲット**に対して相対的なツールチップを配置する場所。
content: オプションですが、インタラクティブツアーのツールチップの内容をお勧めします。自動ツアーの追跡とデバッグにも非常に役立つコンソールにもログを記録しました
timeout: ステップが``run``になるまでの時間、ミリ秒単位で10000（10秒）まで待つ時間。

重要

ツアーの最後のステップは、常にクライアントを「安定」状態に戻す必要があります (例: 継続的なエディションはありません)およびすべての副作用(ネットワーク要求)が、分解中に競合状態やエラーを避けるために実行を終えていることを確認します。

Python¶

Python テストからツアーを開始するには、クラスに HTTPS PCase を継承して、`start_tour`を呼び出します。

def test_your_test(self):
    # Optional Setup
    self.start_tour("/web", "your_tour_name", login="admin")
    # Optional verifications

オンボーディングツアーを書く¶

給与体系¶

`your_module`のオンボーディングツアーを書くには、まず必要なファイルを作成します。

your_module
├── ...
├── data
|   └── your_tour.xml
├── static/src/js/tours/your_tour.js
└── __manifest__.py

その後、 :file:`__manifest__.py`を更新して、アセットに :file:`your_tour.js`を、データに :file:`your_tour.xml`を追加できます。

'data': [
   'data/your_tour.xml',
],
'assets': {
    'web.assets_backend': [
        'your_module/static/src/js/tours/your_tour.js',
    ],
},

Javascript¶

javascript の部分は :ref: `the test tour <testing/javascript/test> ` と同じです。

XML形式¶

javascriptレジストリにツアーがある場合は、xmlに`web_tour.tour`レコードを作成できます。

<?xml version="1.0" encoding="utf-8"?>
<odoo>
    <record id="your_tour" model="web_tour.tour">
        <field name="name">your_tour</field>
        <field name="sequence">10</field>
        <field name="rainbow_man_message">Congrats, that was a great tour</field>
    </record>
</odoo>

name: javascriptレジストリの名前と同じ名前でなければなりません。
sequence: オプション; オンボーディングツアーを実行する順序を決定します。デフォルトは 1000 です。
url: オプション; ツアーを開始するURL。url が False の場合、レジストリからURLを取得します。デフォルトは "/odoo" です。
rainbow_man_message: 省略可能。虹の男効果のメッセージがツアーの完了時に表示されます。 rainbow_man_message が False の場合、虹の効果はありません。デフォルトは <b>よくできました！</b> このツアーのすべてのステップを実行しました。

オンボーディングツアー¶

They can all be started in their sequence order by toggling the Onboarding option in the user menu. You can run specific onboarding tours by going to the Settings ‣ Technical ‣ User Interface ‣ Tours and clicking on Onboarding or Testing.

オンボーディング: インタラクティブモードでツアーを実行します。つまり、ツアーは何をすべきかを示し、ユーザーからのやり取りを待ちます。
テスト：ツアーは自動的に実行されます。つまり、ツアーはユーザーの前ですべてのステップを実行します。

ツアー録画¶

ツアーレコーダーで簡単にツアーを作成することもできます。そのためには、オンボーディングツアービューで Record をクリックしてください。開始すると、このツールは Odoo でのすべての操作を記録します。

作成されたツアーは、オンボーディングツアーの表示で**カスタム**としてフラグが付けられます。これらのツアーは、javascriptファイルにエクスポートしてモジュールに入れることもできます。

デバッグのヒント¶

ブラウザでのテストツアーの監視¶

異なるトレードオフを持つ3つの方法があります。

`watch=True`¶

テストスイートを介してローカルでツアーを実行する場合、browser_js または start_tour 呼び出しに``watch=True`` パラメータを追加することができます:

self.start_tour("/web", "your_tour_name", watch=True)

これにより自動的にChromeウィンドウが開き、ツアーがその中で実行されます。

利点

ツアーにPythonの設定/周囲のコードがある場合、または複数のステップがある場合は常に動作します
(ツアーを起動するテストを選択するだけで) 完全に自動的に実行されます
トランザクション (should は常に複数回実行可能)

欠点

ローカルでのみ動作します
テスト/ツアーがローカルで正しく実行できる場合にのみ動作します

`debug=True`¶

テストスイートを介してローカルでツアーを実行する場合、debug=True パラメータを browser_js または start_tour 呼び出しに追加することができます:

self.start_tour("/web", "your_tour_name", debug=True)

これにより、自動的に全画面Chromeウィンドウが開かれ、ツアー開始時に設定されたデバッガブレークポイントが表示されます。ツアーはdebug=assetsクエリパラメータで実行されます。エラーがスローされると、デバッガーは例外で停止します。

利点

`watch=True`モードと同じ利点
デバッグが簡単になります

欠点

ローカルでのみ動作します
テスト/ツアーがローカルで正しく実行できる場合にのみ動作します

ブラウザー経由で実行¶

テストツアーは、呼び出しによって、ブラウザのUIを介して起動することもできます

odoo.startTour("tour_name");

javascript コンソールで、または URL に ?debug=tests を設定して、 :ref:`tests mode <frontend/framework/tests_debug_mode>を有効にしてください。

利点

より簡単に走れます
ローカルインスタンスだけでなく本番サイトやテストサイトでも利用できます
オンボーディングモード（手動ステップ）で実行できます

欠点

Pythonのセットアップに関わるテストツアーでは使いにくいです
ツアーの副作用によっては複数回動作しない場合があります

ちなみに

このメソッドを使用して、Python の設定が必要なツアーを観察したり、対話したりすることができます。

関連ツアーが開始される前に python ブレークポイントを追加します (start_tour または browser_js コール)
ブレークポイントが当たったら、ブラウザでインスタンスを開きます。
ツアーを実行してください

この時点で、Pythonの設定はブラウザに表示され、ツアーは実行できるようになります。

ツアーの副作用に応じて、テストをその後も続けたい場合は、start_tour または browser_js の呼び出しにコメントしてください。

browser_jsテスト中のスクリーンショットとスクリーンキャスト¶

コマンドラインから HttpCase.browser_js を使用するテストを実行する場合、Chromeブラウザがヘッドレスモードで使用されます。デフォルトでは、テストに失敗した場合、PNGスクリーンショットは失敗時に撮影され、以下に書き込まれます

'/tmp/odoo_tests/{db_name}/screenshots/'

この動作を制御するために、Odoo 13.0から2つの新しいコマンドライン引数が追加されました。 --screenshots と --screencasts

Introspecting / debugging step¶

ツアーを修正/デバッグしようとすると、スクリーンショット(失敗時)が必ずしも十分ではありません。その場合、いくつかのステップまたは各ステップで何が起こっているかを確認するのに役立ちます。

これは、「オンボーディング」で(ほとんどがユーザーによって明示的に駆動されているように)「テスト」ツアーを実行すると、より複雑になります。テストスイートを見学する時にもですその場合、主に2つのトリックがあります:

デバッグモードの break: true, ステッププロパティ (debug=True) です。

これにより、ステップの最初にデバッガブレークポイントが追加されます。必要な場所に独自のブレークポイントを追加できます。
利点
- とてもシンプルで
- あなたが実行を再開するとすぐにツアーは続ける
欠点
- すべての javascript がブロックされているため、ページのやり取りは制限されます
デバッグモードの pause: true, ステッププロパティ (debug=True) です。

ツアーはステップの最後に停止します。これにより、ブラウザーコンソールに play(); と入力することで、開発者が再開する準備ができるまでページを検査し、対話することができます。
利点
- ページとやり取りすることができます
- 役に立たない（この状況のため）デバッガーのUI
run() { debugger; } アクションのステップ。

これは既存のステップに追加することも、新しい専用ステップにすることもできます。ステップの trigger が一致すると、実行は javascript のすべての実行を停止します。
利点
- 簡単な
- あなたが実行を再開するとすぐにツアーは続ける
欠点
- すべての javascript がブロックされているため、ページのやり取りは制限されます
- デバッガは、ステップで定義されたターゲット要素を見つけようとした後にトリガされます。

パフォーマンステスト¶

クエリ数¶

パフォーマンスをテストする方法の1つは、データベースクエリを測定することです。手動で、これは --log-sql CLI パラメータでテストできます。操作に対するクエリの最大数を設定したい場合は、 :meth:`~odooを使用できます。 ests.BaseCase.assertQueryCount`メソッドは、Odooテストクラスに統合されています。

with self.assertQueryCount(11):
    do_something()

テストOdoo¶

Python コードのテスト¶

実行中のテスト¶

テストの選択¶

呼び出し中¶

特殊タグ¶

例¶

JavaScriptコードのテスト¶

Qunit テストスイート¶

インフラストラクチャのテスト¶

モジュール性とテスト¶

新しいテストケースを追加する¶

ヘルパー機能と特殊なアサーション¶

ベストプラクティス¶

ヒント¶

統合テスト¶

テストツアーを書く¶

給与体系¶

Javascript¶

Python¶

オンボーディングツアーを書く¶

給与体系¶

Javascript¶

XML形式¶

オンボーディングツアー¶

ツアー録画¶

デバッグのヒント¶

ブラウザでのテストツアーの監視¶

watch=True¶

debug=True¶

ブラウザー経由で実行¶

browser_jsテスト中のスクリーンショットとスクリーンキャスト¶

Introspecting / debugging step¶

パフォーマンステスト¶

クエリ数¶

`watch=True`¶

`debug=True`¶