Ansible 2.4 - Testing Ansible

不可能なテスト

Introduction
テストの種類
GitHub＆Shippable内でのテスト
- Organization
- 失敗したCIジョブの再実行
PRをテストする方法
- セットアップ：プルリクエストのチェックアウト
- プルリクエストのテスト
テストの詳細を知りたいですか？

前書き

このドキュメントでは、

どのようにAnsibleがテストされたか
どのようにAniableをローカルでテストするか
テスト機能を拡張する方法

テストの種類

高レベルでは、次のようなテストの分類があります。

コンパイル：	テストのコンパイルさまざまなPythonバージョンに対するPythonコードをテストします。
正気：	サニティテストサニティテストは、静的コード解析を実行するために使用されるスクリプトとツールで構成されています。これらのテストの第一の目的は、コード化の基準と要件を強制することです。
統合：	統合テストモジュールの機能テストと不可欠なコア機能
単位：	単体テストコードベースの個々の部分に対して直接テストします。

あなたが開発者であれば、GitHubの問題リストを見てバグを修正するのが最も貴重なもののひとつです。ほとんどの場合、機能開発よりもバグ修正の優先順位付けが優先されるため、バグを修正する手助けをすることができます。

開発者でなくても、バグ修正や機能のプルリクエストをテストすることは、依然として非常に貴重です。

GitHub＆Shippable内でのテスト

組織

プルリクエスト（PR）が作成されると、Continuous Integration（CI）ツールであるShippableを使用してテストされます。結果はすべてのPRの最後に表示されます。

Shippableがエラーを検出し、それをPRで修正されたファイルにリンクすると、関連する行がGitHubコメントとして追加されます。例えば：

The test `ansible-test sanity --test pep8` failed with the following errors:

lib/ansible/modules/network/foo/bar.py:509:17: E265 block comment should start with '# '

The test `ansible-test sanity --test validate-modules` failed with the following errors:
lib/ansible/modules/network/foo/bar.py:0:0: E307 version_added should be 2.4. Currently 2.3
lib/ansible/modules/network/foo/bar.py:0:0: E316 ANSIBLE_METADATA.metadata_version: required key not provided @ data['metadata_version']. Got None

上の例から、 --test validate-modules --test pep8と--test validate-modulesが問題を識別していることが--test validate-modulesます。与えられたコマンドを使用すると、同じテストをローカルで実行できるようになり、GitHubに変更をプッシュしてShippableを待たずに問題を解決できるようになります。

Anabilitiesがまだ利用できない場合は、次のコマンドを実行してローカルチェックアウトを使用してください：

source hacking/env-setup

次に、GitHubのコメントに詳述されているテストを実行します。

ansible-test sanity --test pep8
ansible-test sanity --test validate-modules

何が失敗したのかを示すGitHubコメントがない場合は、PRの最後に「チェックが失敗しました」というメッセージの下にある「Details」ボタンをクリックして結果を調べることができます。

失敗したCIジョブの再実行

時には、PRがあなたの変更に無関係な理由で失敗することがあります。これには、以下のようないくつかの理由が考えられます。

yumやgit repoなどの外部リソースにアクセスする一時的な問題
テストを実行する仮想マシンを作成するタイムアウト

これらの問題のいずれかが発生した場合は、次の方法でShippableテストを再実行できます。

PRを閉じて再開する
PRにもう一度変更を加え、GitHubにプッシュする

問題が解決しない場合は、Freenode IRCの#ansible-develにご連絡ください。

PRをテストする方法

開発者でなくても、バグ修正や機能のプルリクエストをテストすることは、依然として非常に貴重です。

理想的には、コードはコードが動作することを証明するテストを追加する必要があります。これは必ずしも可能ではなく、テストは常に包括的ではありません。ユーザーが多種多様なプラットフォームにアクセスできない場合や、APIやWebサービスを使用している場合などです。このような場合、実際の機器に対するライブテストは、シミュレートされたインターフェースに対して実行される自動化よりも重要です。いずれにしても、初めて手動でも手動でテストする必要があります。

ありがたいことに、Anabilitiesをテストする手助けはかなり簡単です。あなたがAnabilitiesの仕組みに精通していることを前提としています。

セットアップ：プルリクエストのチェックアウト

あなたはこれを行うことができます：

Ansibleをチェックアウトする
メインブランチからテストブランチを作成する
GitHubの問題をマージする
テスト
GitHubのその特定の問題についてコメントしています

方法は次のとおりです。

警告

送信されたソースコードにシステムに悪影響を及ぼす可能性のある間違いや悪意のあるコードが含まれている可能性があるため、私たちに送信されたGitHubプルリクエストからのソースコードのテストにはいくつかの固有のリスクがあります。クラウドインスタンスでもローカルでも、すべてのテストを仮想マシンで実行することをお勧めします。このためにVagrantやDockerを好むユーザーもいますが、オプションです。いくつかの機能（例えば、aptとyum）は、OSのバージョンに固有のものなので、Linuxや他の味の異なる仮想マシンを持つことも便利です。

作業するための新しい領域を作成します。

git clone https://github.com/ansible/ansible.git ansible-pr-testing
cd ansible-pr-testing

次に、テストするプルリクエストを見つけて、ソースリポジトリと宛先リポジトリを説明する一番上の行を書き留めます。それは次のようになります：

Someuser wants to merge 1 commit into ansible:devel from someuser:feature_branch_name

注意

ansible:develテストのみansible:devel

他のブランチにプルリクエストを受け入れないので、PRリクエストの対象は可能であることが重要です。ドット・リリースは、Ansibleスタッフが手動でチェリーピッキングします。

最後のユーザ名とブランチは重要な部分です。次のようにgitコマンドに変わります：

git checkout -b testing_PRXXXX devel
git pull https://github.com/someuser/ansible.git feature_branch_name

最初のコマンドはtesting_PRXXXXという名前の新しいブランチを作成して切り替えます。ここで、XXXXはプル要求に関連付けられた実際の発行番号です（たとえば1234）。このブランチはdevelブランチに基づいています。 2番目のコマンドは、ユーザーの機能ブランチから新しく作成されたブランチに新しいコードをプルします。

注意

GitHubのユーザーインターフェイスにプルリクエストが完全にマージされないことが示されている場合は、マージの競合を解決する必要があるため、gitとコーディングになじみのない方はお勧めしません。これは元のプルリクエストコントリビュータの責任です。

注意

いくつかのユーザーはフィーチャーブランチを作成しません。フィーチャーブランチは、それらのバージョンのdevel複数の無関係なコミットがある場合に問題を引き起こします。ソースがsomeuser:develように見える場合は、プル要求にリストされているコミットが1つだけであることを確認してください。

Anipalソースには、Ansible上で開発者が頻繁に使用する完全インストールを必要とせずに、ソースから直接Anabilitiesを使用できるようにするスクリプトが含まれています。

単にソース（Linux / Unixの用語を使用する）を使用して、すぐにそれを使い始める：

source ./hacking/env-setup

このスクリプトはPYTHONPATH環境変数を変更します（他にもいくつかあります）。これはシェルセッションが開いている間は一時的に設定されます。

プルリクエストのテスト

この時点で、テストを開始する準備ができているはずです。

テストするもののいくつかのアイデアは次のとおりです。

サンプルが入ったテストプレイブックを作成し、それらが正しく機能するかどうかを確認します
Pythonのバックトレースが返されたかどうかを調べる（これはバグです）
異なるオペレーティングシステムまたは異なるライブラリのバージョンに対するテスト

潜在的な問題は、プルリクエストのコメントとして追加する必要があります（また、その機能がうまくいくかどうかをコメントすることもできます）。可能性のあるansible --versionの出力を含めることを忘れないでansible --version

例：

Works for me! Tested on `Ansible 2.3.0`.  I verified this on CentOS 6.5 and also Ubuntu 14.04.

PRが問題を解決しない場合、またはユニット/統合テストの失敗が見られる場合は、代わりにその出力を含めてください：

テストの詳細を知りたいですか？

テストの改善計画の詳細について知りたい場合は、テストワーキンググループに参加することをおすすめします。