MPS 2020.1 ヘルプ

テスト言語

テスト言語

導入

テストは、言語デザイナーの作業に欠かせない部分です。MPS は BaseLanguage コードと言語の両方のためのテスト機能を提供しなければなりません。jetbrains.mps.baselanguage.unitTest 言語は JUnit -like 単体テストで BaseLanguage コードをテストできるようにしますが、言語テスト言語 jetbrains.mps.lang.test は言語テストを作成するための便利なインターフェースを提供します。

クイックナビゲーションテーブル

言語定義のさまざまな側面がさまざまな方法でテストされています。

言語定義の側面

テストする方法

インテンション
行動
サイド変換
エディターアクションマップ
キーマップ

EditorTestCases を作成するには、jetbrains.mps.lang.test 言語を使用してください。最初のコードを提供してステージを設定し、最初のコードに対して実行する一連の編集アクションを定義して、別のコードとして期待される結果を提供します。テストの予想出力と実際の出力の間に違いがあると、エラーとして報告されます。
詳細はエディターテストセクションを参照してください。

制約
スコープ
型システム
データフロー

NodeTestCases を作成するには、jetbrains.mps.lang.test 言語を使用してください。これらのテストケースでは、「正しい」コードの断片を書き、それらにエラーや警告が報告されていないことを確認してください。同様に、「無効な」コードを書いて、正しいノードでエラーまたは警告が報告されていることを表明します。
詳細はノードテストセクションを参照してください。

ジェネレータ
TextGen

ジェネレータテストを作成するには、 言語を使用してください。これらにより、テストモデルを変換し、生成されたコードが予想される結果と一致するかどうかを確認できます。
詳細はジェネレーターテストセクションを参照してください。

現時点でこれらの側面のための組み込みテスト機能はありません。時間の経過とともに私たちのために働いてきたいくつかの習慣があります:

  • おそらく、生成プロセスをチェックするための最も合理的な方法は、正しい生成結果がわかっているモデルを生成し、生成された出力を予想されたものと比較することです。例:生成コードが VCS に格納されている場合は、テストを実行するたびに違いを確認できます。

  • また、ジェネレータの重要なケースを表すコードスニペットを用意し、ジェネレータがそれらから出力を正常に生成するかどうか、または失敗するかどうかを確認することもできます。

  • 生成されたコードをコンパイルして実行すると、ジェネレータの正しさについての信頼性が高まる可能性があります。

マイグレーション

MigrationTestCases を作成するには、jetbrains.mps.lang.test 言語を使用してください。これらのテストケースでは、移行を実行するためのコードを書いてください。
詳細は移行テストセクションを参照してください。

作成をテストする

プロジェクトにテストモデルを追加する方法は 2 つあります。

1. 言語でテストアスペクトを作成する

これはセットアップがより簡単ですが、新しく開始された MPS インスタンスで実行する必要がないテストだけを含むことができます。そのため、通常は単純な基本言語の単体テストを保持できます。テストアスペクトを作成するには、言語ノードを右クリックして New->Test Aspect を選択します。

T2

これで、テストアスペクトで単体テストの作成を始めることができます。

T1

テストアスペクトを右クリックすると、すべてのテストを実行するためのオプションが表示されます。テストレポートは、画面下部の実行パネルに表示されます。

2. テストモデルを作成する

このオプションはあなたにさらに柔軟性を与えます。新しいまたは既存のソリューションでテストモデルを作成します。モデルのステレオタイプがテストに設定されていることを確認してください。

T3

モデルのプロパティを開き、単体テストを作成できるように jetbrains.mps.baselanguage.unitTest 言語を追加します。言語(ノード)テストを作成するために jetbrains.mps.lang.test 言語を追加して下さい。

T4

さらに、テストモデルを含むソリューションに種類セットがあることを確認する必要があります。他の 2 つのオプション(コアプラグインまたはエディタープラグイン)のどちらも必要ない場合は、通常その他を選択します。

T8

モデルを右クリックすると、新しい単体テストまたは言語テストを作成できます。利用可能なすべての根本的概念を参照してください。

T5

T6

BTestCase による単体テスト

BaseLanguage テストケースに関しては、baseLanguage で書かれた単体テストを表します。JUnit に慣れている人はすぐに家にいるでしょう。

T7

BTestCase には 4 つのセクションがあります。1 つはテストメソッドで再利用されるテストメンバー(フィールド)を指定するセクション、1 つは初期化コードを指定するセクション、1 つはクリーンアップコード用、最後に実際のテストメソッド用のセクションです。この言語には、コード補完が明らかにしている便利なアサーションステートメントもいくつか用意されています。

TestInfo

ノードテストを実行できるようにするには、テストモデルのルートにある TestInfo ノードを通してより多くの情報を提供する必要があります。

testInfox1

特にプロジェクトパス属性は注目に値します。絶対パスまたは相対パスとして、あるいは MPS(プロジェクト設定 -> パス変数)で定義されているパス変数への参照として、プロジェクトルートへのパスを指定する必要がある場所です。

pathVariables1

パス変数を Ant スクリプトで使用できるようにするには、mps.macro. 接頭辞を付けてビルドファイルで定義します(以下の例を参照)。

言語定義のテスト面

ノードテスト

NodeTestCase には 3 つのセクションがあります。

T10

最初のものは検証されるべきコードを含みます。テストメソッドのセクションには、最初のセクションで指定されたノードをさらに詳しく調べる baseLanguage コードを含めることができます。ユーティリティメソッドセクションは、通常はテストメソッドから呼び出される再利用可能な baseLanguage コードを保持できます。

正確さをチェックする

型システムが型を正しく計算し、適切なエラーや警告が報告されていることをテストするには、まず希望の言語でコードを書きます。それから正しいかどうかテストしたいノードを選択し、ノード操作テスト注釈の追加インテンションを選択してください。

T11
T12
T13

これは check 属性でコードに注釈を付け、チェックのタイプを設定することによってより具体的にされることができます:

T14

T15

オプションの多くは廃止予定であり、もう使用しないでください。

for error messages オプションは、チェックされたノード内の潜在的なエラーメッセージがテスト失敗として報告されることを保証します。与えられた例では、スクリプト全体にエラーがないことを確認しています。

型システムとデータフローのエラーと警告をチェックする

一方、特定のノードが MPS によってエラーまたは警告があると正しく報告されていることをテストしたい場合は、has error / has warning オプションを使用してください。

T16

T17

これは、警告とエラーの両方で機能します。単一の注釈で複数の警告とエラーを宣言できます。

T26 1

エラー / 警告を報告する予定のルールにチェックを関連付けることもできます。ノード上にカーソルを置いたときに Alt+Enter を押し、ルール参照を指定するオプションを選択します。

T18

T19

ルールの識別子が追加されました。 Ctrl+Space でルールの定義に移動できます。

T29

実行すると、テストは指定されたルールが実際にエラーを報告したものであることを確認します。

型システム固有のオプション

check コマンドには、計算されたノードの種類をテストするためのいくつかのオプションがあります。

T100

T101

複数の期待を簡単に組み合わせることができます。

T37

テストスコープ

スコープテスト注釈では、有効範囲の規則によって正しい項目が適切な範囲に含まれることをテストで検証できます。

T102

インスペクタパネルは、補完メニューに表示する必要があり、注釈付きセルの有効なターゲットとなる予定の項目のリストを保持しています。

T103

T104

テスト方法と実用方法

テストメソッドはラベルを通してあなたのテストのノードを参照するかもしれません。インテンションを使用してラベルをノードに割り当てます。

T32

その後、ラベルはテストメソッドで利用可能になります。

T33

エディターテスト

エディターテストでは、エディターのダイナミズム(アクション、インテンション、置換)をテストできます。

T20

空のエディターテストケースには、名前、オプションの説明、エディターの変換のコード、変換のコード(結果)、最後にコードセクションのコードを変換する実際のトリガーが必要です。

T21

例: if キーワードの前に入力して Robot_Kaja 言語の IfStatementWhileStatement に変換できることをテストすると、次のようになります。

T22

コードセクションでは、jetbrains.mps.lang.test 言語はユーザーが開始したアクションを呼び出すためのいくつかのオプションを提供します - タイプを使う、キーを押すアクション呼び出す、またはインテンションを呼び出す。明白な baseLanguage コードのための特別なテストコマンドを組み合わせることができます。

コード内でキャレットの位置をマークするには、目的の位置にカーソルを置いて適切なインテンションを使用します。

T23

カーソル位置は、のコードとのコードの両方で指定できます。

T25

セルエディターの注釈には、注釈付きのエディターセル内のキャレットの位置を微調整するための追加のプロパティがあります。これらはインスペクターパネルで設定できます。

エディターの状態を調べる

一部のエディターテストでは、エディターの状態をより徹底的に調べることを望んでいるかもしれません。エディターコンポーネント式を使用すると、カーソル下のエディターコンポーネントにアクセスできます。次のサンプルのように、状態を調べたり変更したりできます。

ec1

ec2

ec3

ec4

インテンションに適用可能な、特定のインテンションが特定のエディターコンテキストで起動できるかどうかをテストしてみましょう。

iiap

モデル式プロジェクト式をそれぞれ使用して、モデルプロジェクトを把握することもできます。

2 段階削除のテスト

ノードの 2 フェーズ削除は、次のようにエディターコンポーネント式を使用してテストできます。

EditorTestUtil.runWithTwoStepDeletion({ => invoke action -> Delete assert true DeletionApproverUtil.isApprovedForDeletion(editor component.getEditorContext(), editor component.getSelectedNode()); assert true editor component.getDeletionApprover().isApprovedForDeletion(editor component.findNodeCell(editor component.getSelectedNode())); invoke action -> Delete }, true);

  • EditorTestUtils.runWithTwoStepDeletion は、2 段階削除を有効にしてローカルコンテキストを作成します。ユーザーは 2 段階の削除を自由にオンおよびオフにできるため、テストの一貫した環境が確保されることに注意してください。メソッドの 2 番目のブールパラメーターは、2 段階削除をオンにするかオフにするかを示します。

  • DeletionApproverUtil.isApprovedForDeletion- 現在のノードに対応するセルを取得し、テストは「approvedForDeletion」フラグです。

  • または、component.getDeletionApprover() を使用して、ユーティリティクラスの助けを借りずにフラグをテストします。「削除の承認」フラグがテストされているエディターセルを見つけて提供する必要があります。

移行テスト

移行テストを使用して、指定された入力を使用して移行スクリプトが期待どおりの結果を生成することを確認できます。

new migration test

移行テストケースを作成するには、その名前とテストする移行スクリプトを指定する必要があります。多くの場合、個々の移行スクリプトを別々にテストするだけで十分ですが、移行が互いにどのように相互作用するかをテストする必要がある場合は、単一のテストケースで複数の移行スクリプトを安全に指定できます。

empty migration test

さらに、移行テストケースには、移行プロセスに渡されるノードと、移行の成果として出てくることが予想されるノードも含まれます。

input output

実行すると、移行テストは次のように動作します。

  1. 入力ノードは、単一モデルの空のモジュールにルートとしてコピーされます。

  2. 移行スクリプトはそのモジュール上で実行されます。

  3. 移行後にそのモジュールに含まれているルートは、予想される出力と比較されます。

  4. 問題のマイグレーションの check() メソッドが、問題の空のリストを確実に返すようにするために呼び出されます。

移行テストを作成するプロセスを簡素化するために、現在デプロイされている移行スクリプトを使用して、期待される出力を入力ノードから自動的に生成できます。これを行うには、' 入力から出力を生成 ' というインテンションを使用します。

generate output

ジェネレーターテスト

ジェネレーターはジェネレーターテストでテストすることができます。彼らのゴールは、ジェネレータまたはジェネレータのセットが、期待通りに変換を実行することを保証することです。IDE では、MPS、Ant ビルドスクリプトからの実行と同様に、インプロセス実行モードとアウトプロセス実行モードの両方がサポートされています。MPS のすべてのテストと同様に、ユーザーは以下を指定します。

  1. 入力モデルの形での前提条件

  2. 出力モデルの形でのジェネレータの期待される出力

  3. 明示的なジェネレータプランの形式で入力モデルに適用するジェネレータのセット。省略した場合は、暗黙的なジェネレータプランが使用されます。

jetbrains.mps.lang.test.generatorジェネレータテストを作成することを可能にします。jetbrains.mps.lang.modelapi 言語を使用すると、モデル / モデル / 構文を使用して便利なモデル参照を作成できます。

GT1

ジェネレータテストの構造には、すべてのモデル(入力、予測出力、およびオプションで生成計画を保持するモデル)を指定する必要がある引数というセクションと、目的の変換とマッチングを行うアサーションというセクションがあります。指定されています。

ジェネレータの出力と予想される出力との一致に失敗すると、テストレポートでユーザに表示されます。

GT2

テストを実行する

内側 MPS

モデルでテストを実行するには、プロジェクトビューパネルでモデルを右クリックしてテストの実行を選択します。

T39

モデルに jetbrains.mps.lang.test テストのいずれかが含まれている場合は、MPS の新しいインスタンスがバックグラウンドで暗黙のうちに開始され(通常の baseLanguage 単体テストと比較して実行にかなり時間がかかります)、テストはその新しい MPS インスタンスで実行されます。新しい実行構成が作成され、それを再利用またはカスタマイズできます。

testrunconfig

実行構成ダイアログには、テストのパフォーマンスを調整するためのオプションがあります。

  • デフォルト設定の場所を上書きする - キャッシュを保存するディレクトリを指定します。デフォルトでは、MPS は一時ディレクトリを選択します。ディレクトリは実行ごとにクリアされます。

  • 同じプロセスで実行する - テストをスピードアップするために、テストはいわゆるインプロセスモードで実行できます。これはテスト用に特別に設計されたもため、MPS インスタンスを実行する必要があります。(例:言語型システムテストでは、MPS は安全にその場でノードの型をチェックできるはずです。)
    元の方法は、新しい MPS インスタンスをバックグラウンドで起動し、このインスタンスでテストを実行することでした。このオプションではなく、すべてのテストを同じ元の MPS プロセスで実行できるため、新しいインスタンスを作成する必要はありません。オプション同じプロセスで実行するが設定されている場合(デフォルト設定)、テストは現在の MPS 環境で実行されます。独自の方法で(別のプロセスで)テストを実行するには、このオプションのチェックを外します。このテストの実行方法は MPS のすべてのテストに適用できます。そのため、エディターのテストでも機能します。

    テストレポートは画面下部の実行パネルに表示されます。

  • JUnit 実行構成はテストを実行する前にデプロイするプラグインを受け入れます。ユーザーはテスト実行中にデプロイされるアイデアプラグインのリストを提供できます。前のタスク 'Assemble プラグイン ' は JUnit の実行構成でも利用できます。与えられたプラグインを自動的に構築し、アーティファクトを設定ディレクトリにコピーします。

T41

ビルドスクリプトから

生成したビルドスクリプトに Ant を使用したテストの実行に使用できるテストターゲットを提供するには、jetbrains.mps.build.mpsjetbrains.mps.build.mps.tests の言語をビルドスクリプトにインポートし、module-tests プラグインを使用して宣言し、テストモジュール構成を指定する必要があります

testScript1

Ant が JUnit に渡すマクロを定義するには(たとえば、テストの TestInfo ルートで使用するために)、mps.macro. を頭に付けます。

image2016 10 13 17 29 27

IDEA プラグインでエディターテストを実行する

新しい JUnit テストスイート(jetbrains.mps.idea.core.tests.PluginsTestSuite)では、MPS プラグインを使用している場合、IntelliJ IDEA であなたの言語用のエディターテストを実行することが可能です。この機能を利用するには、必要なすべてのプラグインを IntelliJ プラットフォームにインストールし、テストモジュール名を指定してテストを実行する単純な ANT スクリプトを作成する必要があります。

最終更新日 : 2020 年 6 月 18 日