テストデータの形式¶
この節では、 Robot Framework のテストデータの形式を大まかに解説します。 実際のテストケースやテストスイートなどの作成方法は、後の節で述べます。
ファイルとディレクトリ¶
テストケースを階層的にアレンジする方法は、以下の通りです:
- テストケースは テストケースファイル の中に書きます。
- テストケースファイル一つが、自動的にファイル中の全てのテストケースからなる テストスイート になります。
- テストケースファイルの入ったディレクトリは、より高水準のテストスイートとなります。 この テストスイートディレクトリ の中には、ディレクトリ内のテストファイルによるテストスイートが、サブテストスイートとして入っています
- テストスイートディレクトリの中に、別のテストスイートディレクトリを配置できます。 その場合、階層構造は必要に応じて深くなっていきます。
- テストスイートディレクトリに、特殊な 初期化ファイル を置くことがあります。
上のルールの他に、テストに関係する以下のファイルがあります:
サポートするファイル形式¶
Robot Framework のテストデータは、 HTML, タブ区切りの値(TSV)、プレーンテキスト、 reStruncturedText (reST) フォーマットのいずれかを使ったテーブル形式です。 それぞれのフォーマットの詳細と長所や短所については、以降の節で個々に説明していきます。 どのフォーマットを使うべきかは状況次第ですが、特に事情がないのなら、プレーンテキストを推奨します。
Robot Framework は、ファイルの拡張子に基づいて、テストデータのパーザを切り替えます。拡張子の大小文字は区別しません。 認識する拡張子は、 .html, .htm, .xhtml が HTML, .tsv が TSV, .txt と .robot がプレーンテキスト、 .rst と .rest が reStructuredText です。
テストの書き方を学びやすくするため、 HTML と TSV 形式には特別なテストデータ形式があります。
注釈
拡張子 .robot のプレーンテキストファイルへの対応は Robot Framework 2.7.6 以降でサポートしています。
HTML 形式¶
HTML ファイルを使うと、テーブルのフォーマットができ、その前後に自由にテキストを書けます。 テストケースファイルに追加の情報を記載できるので、様式に沿ったテスト仕様書にできます。 HTML フォーマットの大きな問題は、普通のテキストエディタで編集するのが楽ではないことです。 もう一つの問題は、 HTML にすると、差分の中にテストデータに加えて HTML の構文が交じるので、バージョン管理システムでの管理がしづらいことです。
HTML ファイルでは、テストデータは個別のテーブルで定義します (下の例を参照)。 Robot Framework は テストデータテーブル を、テーブルの最初のセルのテキストで判別します。 テーブルの外にある情報は、全て無視されます。
Setting | Value | Value | Value |
---|---|---|---|
Library | OperatingSystem | ||
Variable | Value | Value | Value |
---|---|---|---|
${MESSAGE} | Hello, world! | ||
Test Case | Action | Argument | Argument |
---|---|---|---|
My Test | [Documentation] | Example test | |
Log | ${MESSAGE} | ||
My Keyword | /tmp | ||
Another Test | Should Be Equal | ${MESSAGE} | Hello, world! |
Keyword | Action | Argument | Argument |
---|---|---|---|
My Keyword | [Arguments] | ${path} | |
Directory Should Exist | ${path} |
テストデータの編集¶
HTML ファイルのテストデータはどんなエディタでも編集できますが、テーブルを表の形で見られるグラフィカルなエディタがお勧めです。 RIDE_ は HTML を読み書きできますが、残念ながら、 HTML によるフォーマットが失われ、テストケーステーブルの外にある情報が欠落することがあります。
エンコーディングとエンティティ参照¶
Robot Framework は HTML エンティティ参照 (ä など) をサポートしています。 さらに、どんなエンコーディングも、データファイル中で指定している限り使えます。 通常の HTML ファイルには、以下のような META エレメントが必要です:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
XHTML ファイルの場合は、以下のように XML のプリアンブルが必要です:
<?xml version="1.0" encoding="Big5"?>
エンコーディングを指定しない場合、 Robot Framework はデフォルト値として ISO-8859-1 (latin-1) を使います。
TSV 形式¶
TSV ファイルは表計算プログラムで編集でき、構文が簡単なためプログラムで簡単に生成できます。 普通のテキストエディタでも編集しやすく、バージョン管理システムでの管理も楽です。 とはいえ、同じ理由で選ぶのであれば、 プレーンテキスト形式 の方がもっと向いています。
TSV 形式は、ほぼ HTML と同じ用途のテストデータに使えます。 TSV ファイルの中では、全テストデータが一つの大きなテーブルの中に入っています。 各々の テストデータテーブル は、「一つ以上のアスタリスク (*)、テーブル名、アスタリスク」が書かれている場所から始まります。ただし、テーブル名の後のアスタリスクは省略できます。 最初に認識されたテーブルよりも前にかかれている内容は、 HTML データのテーブルの外のデータと同様、無視されます。
*Setting* | *Value* | *Value* | *Value* |
Library | OperatingSystem | ||
*Variable* | *Value* | *Value* | *Value* |
${MESSAGE} | Hello, world! | ||
*Test Case* | *Action* | *Argument* | *Argument* |
My Test | [Documentation] | Example test | |
Log | ${MESSAGE} | ||
My Keyword | /tmp | ||
Another Test | Should Be Equal | ${MESSAGE} | Hello, world! |
*Keyword* | *Action* | *Argument* | *Argument* |
My Keyword | [Arguments] | ${path} | |
Directory Should Exist | ${path} |
テストデータの編集¶
TSV ファイルの作成や編集は、Microsoft Excel をはじめほとんどの表計算ソフトでできます。 ファイルを保存するときに、タブ区切り形式のフォーマットにして、ファイルの拡張子を .tsv にセットしてください。 編集するときは、オートコレクトをオフにして、ファイル中の全ての値をプレーンテキストで保存する設定にしてください。
TSV ファイルは、テキストエディタでも比較的容易に編集できます。 特に、エディタがタブとスペースを視覚的に区別できると便利です。 RIDE_ は TSV 形式をサポートしています。
Robot Framework は、 TSV データを解析するときに、全ファイルコンテンツを行に分割して、さらに各行をタブ文字で分割します。 表計算ソフトによっては、("my value" のように) セルの値をクオートで囲うことがあり、 Robot Framework はクオートを除去します。 データ中のクオートが2重でエスケープされている場合 (例: "my ""quoted"" value") もありますが、これも正しく扱います。 表計算ソフトで TSV データを作成する場合はこうした挙動を気にする必要はありませんが、プログラムでデータを生成するときには、表計算と同じクオートの取扱いが必要なので注意してください。
エンコーディング¶
TSV ファイルは、常に UTF-8 エンコーディングとみなします。 ASCII は UTF-8 のサブセットなので、 ASCII エンコーディングもサポートしています。
プレーンテキスト形式¶
プレーンテキスト形式は、編集がとても簡単で、どんなテキストエディタでも編集でき、バージョン管理システムでも容易に扱えます。 こうした諸々の長所から、 Robot Framework で最もよく使われているデータ形式です。
プレーンテキスト形式は、技術的にはどちらかといえば TSV形式 に近いですが、セルの区切り方が違います。 TSV 形式がタブを使うのに対して、プレーンテキスト形式は 2 個以上のスペースか、パイプ文字の両側にスペースを入れたもの ( | ) で区切ります。
テストデータテーブル は、TSVと同様、「一つ以上のアスタリスク (*)、テーブル名、アスタリスク」が書かれている場所から始まります。余分なアスタリスクとスペースがヘッダにあっても無視されるので、 *** Settings *** と *Settings は同じです。 また、 TSV と同様、最初に認識したテーブルよりも前の内容は無視されます。
プレーンテキスト形式では、タブは自動的に 2 スペースに変換されます。そのため、 TSV と同様、タブを区切り文字として使えます。 ただし、TSV 形式ではタブは常に区切り文字ですが、プレーンテキスト形式では、複数のタブ文字が連続すると合わせて一つの区切りとみなします。
スペース区切り方式¶
スペース区切り方式では、区切りに使うスペースの数は 2文字以上なら何個つづけてもかまいません。 そのため、データを見栄え良く並べられます。 これはテキストエディタで TSV 形式を編集するより好都合です。 というのも、TSV は列の並びを完全にはコントロールできないからです。
*** Settings ***
Library OperatingSystem
*** Variables ***
${MESSAGE} Hello, world!
*** Test Cases ***
My Test
[Documentation] Example test
Log ${MESSAGE}
My Keyword /tmp
Another Test
Should Be Equal ${MESSAGE} Hello, world!
*** Keywords ***
My Keyword
[Arguments] ${path}
Directory Should Exist ${path}
スペースを区切り文字として使っているので、空のセルは ${EMPTY} という特殊な変数か、バックスラッシュ一文字で エスケープ せねばなりません。 また、 空白文字の扱い が他のテストデータと違っていて、テストデータの前後にスペースがある場合や、データの中に2つ以上続くスペースがある場合は常にエスケープせねばなりません。
ちなみに
キーワードと引数の間は、4文字以上スペースを入れるよう勧めます。
スペース・パイプ区切り方式¶
スペース区切り方式の最大の問題は、キーワードと引数の区切りが見づらいことです。 特に、引数がたくさんあるキーワードや、引数にスペースが入る場合には厄介です。 そんな時は、パイプとスペースを使った区切りの方が、セルの境界がはっきり判ります。
| *Setting* | *Value* |
| Library | OperatingSystem |
| *Variable* | *Value* |
| ${MESSAGE} | Hello, world! |
| *Test Case* | *Action* | *Argument* |
| My Test | [Documentation] | Example test |
| | Log | ${MESSAGE} |
| | My Keyword | /tmp |
| Another Test | Should Be Equal | ${MESSAGE} | Hello, world!
| *Keyword* |
| My Keyword | [Arguments] | ${path}
| | Directory Should Exist | ${path}
プレーンテキスト形式のテストデータには、スペース区切り方式とスペース・パイプ区切り方式を混在させられます。 ただし、一つの行の中ではどちらかに揃えねばなりません。 パイプ・スペース方式の行はパイプで開始せねばなりませんが、行末のパイプは省略可能です。 行の先頭を除き、パイプ文字の両側には必ず一つ以上スペースがなければなりません。 ただし、データの並びをはっきりさせるために、パイプの位置を他の行と揃える必要はありません。
パイプ・スペース方式では、(末尾の空白セル を除き、) 空のセルをエスケープする必要はありません。 唯一、エスケープを考慮しなければならないのは、パイプの両側にスペースがあるような文字列を書きたい時で、その場合はバックスラッシュでエスケープしてください:
| *** Test Cases *** | | | |
| Escaping Pipe | ${file count} = | Execute Command | ls -1 *.txt \| wc -l |
| | Should Be Equal | ${file count} | 42 |
編集とエンコーディング¶
プレーンテキスト形式が HTML や TSV に対して最も優れているのは、普通のテキストエディタでの編集がとても簡単なことです。 ほとんどのエディタや IDE (Eclipse, Emacs, Vim, TextMate など) には、 Robot Framework のテストデータを編集するための構文ハイライト用プラグインがあり、キーワード保管などの機能も備えています。 RIDE_ もプレーンテキスト形式をサポートしています。
TSV 形式のテストデータと同様、プレーンテキスト形式のファイルも UTF-8 エンコーディング想定です。 従って、 ASCII エンコーディングのファイルもサポートしています。
Robot Framework の認識する拡張子¶
Robot Framework 2.7.6 から、プレーンテキスト形式のテストデータファイルの拡張子として、従来の .txt に加えて .robot のサポートを追加しました。 新しい拡張子を使えば、他のプレーンテキストファイルとテストデータを区別しやすくなります。
reStructuredText 形式¶
reStructuredText_ (reST) は、読みやすさを重視したプレーンテキストのマークアップ方式で、 Python プロジェクトのドキュメンテーションによく使われています (Python のソースコード自体にも、ユーザガイドにも)。 reST ドキュメントは HTML にコンパイルされることが多いですが、他の出力フォーマットもサポートしています。
reST を Robot Framework に使うと、簡単なテキストフォーマットのファイル中に、巧みにフォーマットしたドキュメントとテストデータを混在させられます。 ファイルは単純なテキストエディタでも簡単に編集でき、差分ツールやソースコード管理システムで扱えます。 プレーンテキストと HTML フォーマットの長所をうまく合わせたフォーマットといえるでしょう。
reST ファイルを使う場合、テストデータの定義方法は2つあります。 コードブロック を使って、 プレーンテキスト形式 でテストケースを書く方法と、 HTML 形式 と同じように、 テーブル で書く方法です。
注釈
reST ファイルのテストデータを Robot Framework で扱うには、 Python の docutils_ モジュールが必要です。
コードブロック方式¶
reStructuredText のドキュメントには、コードブロックと呼ばれるマークアップにコードサンプルを入れられます。 ドキュメントを HTML などのフォーマットに変換すると、コードブロックの内容は Pygments_ などでハイライト表示されます。 標準の reST の書き方では、コードブロックは code ディレクティブで開始します。 Sphinx_ を使っている場合は、 code-block か sourcecode ディレクティブを使います。 ディレクティブの最初の引数には、コードブロック内のコードのプログラミング言語名を指定できます。 例えば、以下のコードブロックには、それぞれ Python と Robot Framework のコードサンプルが入っています:
.. code:: python
def example_keyword():
print 'Hello, world!'
.. code:: robotframework
*** Test Cases ***
Example Test
Example Keyword
Robot Framework に reStructuredText ファイルを処理させると、まず code, code-block, sourcecode ブロックのうち、 Robot Framework のテストデータが入ったものを探します。 コードブロックが見つかったら、テストデータをメモリ上のファイルに書き出して実行します。コードブロック外の情報は全て無視します。
コードブロック内のテストデータは、 プレーンテキスト形式 で書かねばなりません。 以下の例のように、スペース区切り方式、スペース・パイプ区切り方式の両方をサポートしています。
サンプル
----------
このテキストは、コードブロックの外にあるので無視されます。
.. code:: robotframework
*** Settings ***
Library OperatingSystem
*** Variables ***
${MESSAGE} Hello, world!
*** Test Cases ***
My Test
[Documentation] Example test
Log ${MESSAGE}
My Keyword /tmp
Another Test
Should Be Equal ${MESSAGE} Hello, world!
このテキストも、コードブロックの外にあるので無視されます。
上のブロックはスペース区切り方式のプレーンテキストで、下のブロックは
パイプ・スペース区切り方式です。
.. code:: robotframework
| *** Keyword *** | | |
| My Keyword | [Arguments] | ${path} |
| | Directory Should Exist | ${path} |
注釈
このフォーマット内では、バックスラッシュを使った エスケープ を使えます。 reST のテーブルを使う時のように、2重のエスケープは要りません。
注釈
コードブロックでテストデータを書けるようになったのは、 Robot Framework 2.8.2 からです。
テーブル方式¶
reStructuredText ドキュメント中に、 Robot Framework のデータの入ったコードブロックがなければ、Robot Framework は、 HTML 形式 と同様、テーブルにテストデータが入っているものとみなし、ドキュメントをメモリ上で HTML にコンパイルしてから、通常の HTML ファイルのテストデータと同じように解析します。
Robot Framework は、テーブルの最初のセルで テストデータテーブル を認識し、テーブルの外にある情報を無視します。 以下に、 4 つのテストデータを、シンプルなテーブル形式と、グリッド形式で示します:
Example
-------
このテキストは、コードブロックの外にあるので無視されます。
============ ================ ======= =======
Setting Value Value Value
============ ================ ======= =======
Library OperatingSystem
============ ================ ======= =======
============ ================ ======= =======
Variable Value Value Value
============ ================ ======= =======
${MESSAGE} Hello, world!
============ ================ ======= =======
============= ================== ============ =============
Test Case Action Argument Argument
============= ================== ============ =============
My Test [Documentation] Example test
\ Log ${MESSAGE}
\ My Keyword /tmp
\
Another Test Should Be Equal ${MESSAGE} Hello, world!
============= ================== ============ =============
このテキストも、コードブロックの外にあるので無視されます。
上はシンプルなテーブル定義の書き方で、下はグリッドを使った書き方です。
+-------------+------------------------+------------+------------+
| Keyword | Action | Argument | Argument |
+-------------+------------------------+------------+------------+
| My Keyword | [Arguments] | ${path} | |
+-------------+------------------------+------------+------------+
| | Directory Should Exist | ${path} | |
+-------------+------------------------+------------+------------+
注釈
シンプルなテーブル定義の場合、各行の最初のカラムが空のときはエスケープが必要です。 上の例では \ を使っていますが .. も使えます。
注釈
reST ではバックスラッシュ文字をエスケープ文字として使っています。 そのため、バックスラッシュを Robot Framework に認識させたい場合には、 \ のように、もう一つバックスラッシュが必要です。 例えば、改行文字を表現するときは、 \n です。 Robot Framework のデータは、バックスラッシュを エスケープ に使うので、 reST のテーブルの中で、リテラルとしてバックスラッシュを使いたい場合には、さらにエスケープして c:\\temp のように書かねばなりません。
テストをランする度に毎回 reST で HTML ファイルを生成していると、明らかにオーバヘッドを生じます。 問題になるようなら、外部ツールを使って reST ファイルを予め HTML に変換しておき、生成したファイルを Robot Framework に読ませるとよいでしょう。
編集とエンコーディング¶
reStructuredText 形式のテストデータはどんなテキストエディタでも編集でき、多くのテキストエディタが reST の構文ハイライトをサポートしています。 残念ながら、 RIDE_ は reST をサポートしていません。
reST ファイルでは、非 ASCII 文字を UTF-8 エンコーディングで保存せねばなりません。
reST ソースファイルの構文エラー¶
reStructuredText ドキュメントが構文的に正しくない場合 (テーブルの書式がおかしい場合など) は、 reST ファイルの解析に失敗するため、テストケースを抽出できないことがあります。単一の reST ファイルを実行しているときには、 Robot Framework はコンソールにエラーを出力しますが、ディレクトリ単位で実行しているときには、解析エラーは無視されてしまいます。
Robot Framework 2.9.2 からは、 SEVERE レベルに達しないエラーを無視することで、 reST 文書中に標準でサポートしないディレクティブやマークアップがあっても、ノイズの影響を受けないようにしました。 この仕様のため、 reST マークアップのエラーはテストランナには隠蔽されますが、 docutils でファイルを普通にコンパイルするとエラーが表示されるので注意してください。
テストデータテーブル¶
テストデータは、以下の 4 つのタイプのテーブルで構成されています。 各々のテストデータテーブルは、テーブルの最初のセルの値で区別します。 Robot Framework が認識するテーブル名は、 Settings (設定)、 Variables (変数), Test Cases (テストケース), Keywords (キーワード) です。 テーブル名は大小文字の区別をせず、 Setting や Test Case のように単数形でもかまいません。
テーブル | 用途 |
---|---|
Settings | |
Variables | テストデータ中で使う 変数 の定義 |
Test Cases | 定義済みのキーワードを使った テストケース定義 |
Keywords | 既存の低水準キーワードを使った キーワード定義 |
テストデータ解析のルール¶
コメント、無視される情報¶
Robot Framework がテストデータを解析する際、以下の内容は無視されます:
- 最初のセルに テストデータテーブル の名前が入っていないテーブル。
- テストデータのテーブルで、最初の行の最初のセル以外の内容。
- 最初に見つかったテストデータテーブルより前に書かれている情報全て。 テーブルの間に何か記述できるデータフォーマットの場合は、その内容も無視されます。
- テーブルの見栄えをよくするなどの目的で挿入されている空の行。
- 行末側の空のセルで、 エスケープ していないもの全て。
- エスケープ に使っていないバックスラッシュ (\) 全て。
- セル中の値がハッシュ文字 (#) で始まる場合、ハッシュ文字より後ろの内容。 この機能を使って、テストデータのコメントを書けます。
- HTML/reST 中の全マークアップ。
Robot Framework がテストデータ中の情報を無視した場合、その情報は結果レポートから一切アクセスできません。 また、 Robot Framework と組み合わせて使うツールのほとんどが、同じようにデータを無視します。 Robot Framework の出力に何らかの情報を表示したいなら、テストケースやテストスイートにドキュメントやメタデータを付与するか、 組み込み キーワードの Log や Comment を使ってログに出力してください。
空白文字の扱い¶
Robot Framework は、空白文字を HTML のソースコード中の空白文字と同じように扱います。すなわち:
- 改行、復帰、タブはスペースに変換される。
- セルの先頭や末尾に入っている空白文字は全て無視する。
- スペースが複数個並んでいる時は、ひとつのスペースに置き換える。
加えて、非改行スペースは普通のスペースに置き換わります。 これは、普通のスペースの代わりに誤って非改行スペースを使ってしまった場合に、検出が難しいエラーとなるのを防ぐためです。
セルの先頭や末尾のスペース、複数個並んだスペースが必要な場合は、 エスケープ が必要です。 改行、復帰、タブ、非改行スペースは、それぞれ n, r, t, xA0 といった エスケープシーケンス で入力できます。
エスケープ¶
Robot Framework のテストデータでエスケープに使う文字は、バックスラッシュ (\) です。 組み込み変数 の ${EMPTY} および ${SPACE} もよく使われます。 この節では、それぞれのエスケープメカニズムについて解説します。
特殊文字のエスケープ¶
バックスラッシュを使って特殊文字をエスケープすることで、リテラルとしてその文字を表現できます。
文字 | 意味 | 例 |
---|---|---|
$ | スカラー変数 の開始記号でない | ${notvar} |
@ | リスト変数 の開始記号でない | @{notvar} |
% | 環境変数 の開始記号でない | %{notvar} |
# | コメント の開始記号でない | # not comment |
= | 名前付き引数 の記法でない | not=named |
| | パイプ区切り でない | | Run | ps | grep xxx | |
\ | バックスラッシュそのもので、何もエスケープしない | c:\temp, \${var} |
エスケープシーケンスの記法¶
バックスラッシュは、テストデータ中で入力するのが難しい文字を扱うときに、文字を表現する特殊なエスケープシーケンスにも使われます。
シーケンス | 意味 | 例 |
---|---|---|
n | 改行文字 | first linen2nd line |
r | 復帰文字 | textrmore text |
t | タブ | texttmore text |
xhh | 16 進 hh で表される文字 | null byte: x00, ä: xE4 |
uhhhh | 16 進 hhhh で表される文字 | snowman: u2603 |
Uhhhhhhhh | 16 進 hhhhhhhh で表される文字 | love hotel: U0001f3e9 |
注釈
テストデータ中でエスケープシーケンスで表した文字は、 x02 のようなものも含め、全て Unicode での表現なので、必要に応じて明示的な変換が必要です。 変換は、例えば、 BuiltIn や String ライブラリの Convert To Bytes や Encode String To Bytes といったキーワードでできます。
あるいは、Python コードで str(value) や value.encode('UTF-8') のようにして変換できます。
注釈
x, u, U に無効な16進の値を指定した場合は、バックスラッシュ抜きの16進値に変換されます。 たとえば、 xAX (16進でない) や U00110000 (値が大きすぎる) は、それぞれ xAX や U00110000 になります。 ただし、この挙動は将来変更される可能性があります。
注釈
OS による改行文字の違い (Windows は rn , それ以外は n elsewhere) を吸収したい場合は、 組み込み変数 の ${n} を使えます。
注釈
n の後にエスケープなしの空白文字を続けた場合は無視されます。 つまり、 two linesnhere と two linesn here は同じになります。 これはもともと、 HTML 形式で改行を含む長い行を折り返せるようにするための措置ですが、他のフォーマットにも適用されています。 唯一の例外は、 拡張変数記法 中の空白文字は無視されないというルールです。
注釈
x, u, U のエスケープシーケンスは Robot Framework 2.8.2 で導入されました。
空セルを無視させない方法¶
セルの前後にあるスペースや、セル内の複数連続するスペースは 無視される ので、キーワードの引数などでスペースを無視させたくないときには、スペースをエスケープする必要があります。 空のセルを無視させたくないときと同じように、 組み込み変数 の ${SPACE} でも表現できます。
キーワードの引数に空の値を指定したい場合など、データを 無視 させたくないときには、空セルのエスケープが必要です。 行の末尾側にある空のセルは、テストデータをどのフォーマットで書いていてもエスケープが必要です。 スペース区切り方式 のフォーマットの場合は、空の値はどこにあっても常にエスケープせねばなりません。
空のセルは、バックラッシュでエスケープするか、 組み込み変数 の ${EMPTY} で表現します。 見やすさの観点から、基本的に後者を勧めます。 例外は、 スペース区切り方式 のフォーマットで for ループ を書いていて、セルのインデントにバックスラッシュを使うときです。 こうしたケースについて、以下に例を挙げます。最初の例は HTML のテーブル、次の例はスペース区切り方式のテキストフォーマットです:
Test Case | Action | Argument | Argument | Argument |
---|---|---|---|---|
Using backslash | Do Something | first arg | \ | |
Using ${EMPTY} | Do Something | first arg | ${EMPTY} | |
Non-trailing empty | Do Something | second arg | # HTML 形式は行末のエスケープ不要 | |
For loop | :FOR | ${var} | IN | @{VALUES} |
Log | ${var} | # エスケープは不要 |
*** Test Cases ***
Using backslash
Do Something first arg \
Using ${EMPTY}
Do Something first arg ${EMPTY}
Non-trailing empty
Do Something ${EMPTY} second arg # スペース区切り方式ではエスケープが必要
For loop
:FOR ${var} IN @{VALUES}
\ Log ${var} # エスケープが必要。バックスラッシュが見やすい
スペースを無視させない方法¶
セルの前後にあるスペースや、セル内の複数連続するスペースは 無視される ので、キーワードの引数などでスペースを無視させたくないときには、スペースをエスケープする必要があります。 空のセルを無視させたくないときと同じように、 組み込み変数 の ${SPACE} でも表現できます。
バックスラッシュを使う方法 | ${SPACE} を使う方法 | 備考 |
---|---|---|
\ 前のスペース` | ${SPACE}前のスペース | |
後ろのスペース \ | 後ろのスペース${SPACE} | バックスラッシュはスペースの後ろ |
\ \ | ${SPACE} | 爆スラッシュはスペースの前後 |
セル中の \ \ スペース | セル中の${SPACE * 3}スペース | `拡張変数記法<extended variable syntax>`_ |
上の例のように、 ${SPACE} を使ったほうが、テストデータはわかりやすく書けます。 特に、 拡張変数記法 と組み合わせることで、スペースが複数個のときに便利です。
テストデータを複数行に分ける¶
一行におさまらないデータがあるばあい、省略符号 (...) を使って、前行からの続きを書けます。 キーワードテーブルの場合、省略符号の前には、必ず一つ以上空のセルが必要です。 設定テーブルと変数テーブルについては行頭に省略符号を書けます。 どのテーブルも、省略符号よりも前の空のセルは無視されます。
さらに、設定テーブルの項目のうち、値がひとつしかないもの (主にドキュメント) は、データを複数のカラムに分けて記述できます。 その場合、各セルの値は、テストデータを解析するときにスペースで結合されます。 Robot Framework 2.7 からは、ドキュメントとテストスイートのメタデータを複数行に分けて書くと、 改行で結合されます 。
以下のサンプルは、上記の規則を実演したものです。 最初の3つのテーブルはでは、テストデータは分割されていません。 その次の3つのテーブルを見れば、複数行に分けることで少ないカラム数でテストデータを表現できることがわかります。
Setting | Value | Value | Value | Value | Value | Value |
---|---|---|---|---|---|---|
Default Tags | tag-1 | tag-2 | tag-3 | tag-4 | tag-5 | tag-6 |
Variable | Value | Value | Value | Value | Value | Value |
---|---|---|---|---|---|---|
@{LIST} | this | list | has | quite | many | items |
Test Case | Action | Argument | Arg | Arg | Arg | Arg | Arg | Arg |
---|---|---|---|---|---|---|---|---|
Example | [Documentation] | Documentation for this test case.\n This can get quite long... | ||||||
[Tags] | t-1 | t-2 | t-3 | t-4 | t-5 | |||
Do X | one | two | three | four | five | six | ||
${var} = | Get X | 1 | 2 | 3 | 4 | 5 | 6 |
Setting | Value | Value | Value |
---|---|---|---|
Default Tags | tag-1 | tag-2 | tag-3 |
... | tag-4 | tag-5 | tag-6 |
Variable | Value | Value | Value |
---|---|---|---|
@{LIST} | this | list | has |
... | quite | many | items |
Test Case | Action | Argument | Argument | Argument |
---|---|---|---|---|
Example | [Documentation] | Documentation | for this | test case. |
... | This can get | quite | long... | |
[Tags] | t-1 | t-2 | t-3 | |
... | t-4 | t-5 | ||
Do X | one | two | three | |
... | four | five | six | |
${var} = | Get X | 1 | 2 | |
... | 3 | 4 | ||
... | 5 | 6 |