MPS 2019.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. Create a Test aspect in your language

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

T2

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

T1

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

2. Create a test model

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

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(Project Settings -> Path Variables)で定義されているパス変数への参照として、プロジェクトルートへのパスを指定する必要がある場所です。

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

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

T18

T19

ルールの識別子が追加されました。Control/Cmd + B (またはクリック)でルールの定義に移動できます。

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

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

移行テスト

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

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スクリプトを作成する必要があります。

最終更新日: 2019年7月5日