SWAT-自動Webアプリケーションテストの迅速な開発のためのDSL

エントリー

テストの自動化のタスクは新しいものではありませんが、それでもWebアプリケーションのテストの分野で利用可能なツールには限界があります。



短時間で更新する必要がある100種類のWebアプリケーションがあり、それらの機能を検証するテストがない場合はどうなりますか？ UIテストの開発には時間がかかりますが、 curlリクエストを作成し、200 OKが戻ったことを確認するだけでは十分ではありません。



合理的な妥協が必要です。シンプルであると同時に、自動テストの開発に十分な汎用ツールです。 それでSWATが生まれました。

根拠のアイデア

したがって、エンドユーザーの観点から見たSWATは、テストスクリプトを実行するためのコンソールクライアントと、それらを記述するための言語（ DSL ）です。



ユーザーはテストスクリプトを特定の形式で作成し、別のディレクトリに配置して起動します。 一般的に、すべて次のようになります。

$ swat /path/to/your/project/ $base_url
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、SWATプロジェクトは、Webアプリケーションをテストするときにすべてのhttp要求が送信されるベースURLと同様に、テストスクリプトを含むフォルダーです。 さて、これまでのところ新しいものは何もありません。多くのレイアウトは同様のレイアウトを使用しています... SWATシステムの本質は何ですか？



少しの間、SWATについて話していることを忘れて、curlユーティリティを使用して通常のhttp要求を作成し、 grepユーティリティを使用して応答を分析することしかできないと想像してください。

 $ curl $base_url | grep foo-bar-baz
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、これはSWATフレームワークの真髄です。



全体のポイントは、テストされたサーバーからの応答が、さまざまな検索を実行できるテキストとして単に認識され 、成功したhttpステータスの検証が追加されることです。 私の実践が示しているように、これら2つのメソッド（大まかに言うと、200 OKが戻ったことを確認し、 何が返されたかを確認する）は、表面スモークテストから本格的な機能的なテストまで、さまざまな複雑さのテストスクリプトを記述するのに十分です。



アプリケーションでの私の実務経験が示しているように、SWATには多くの能力があります。

DSLの説明とデータ構造

SWATは、ファイルとディレクトリの命名に関する一連の規則に基づいています。 また、任意のテキスト（この場合はサーバーからの応答）を検証するためのルールを記述するための特別な構文も提供します。



まず、典型的なSWATプロジェクトのファイル構造の説明から始めましょう。



したがって、前述のように、SWATプロジェクトは、テストロジックを記述するファイルとサブディレクトリのあるディレクトリにすぎません。



まあ、最初に行う必要があるのは、プロジェクトを作成するだけです：

  $ mkdir swat-project
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

資料の理解を簡単にするために、いくつかの用語を紹介します。



Webアプリケーションのテストを処理する場合、使用可能なリソースについて話し合うか、さまざまなhttp メソッドを使用してリクエストを送信できるルートについて簡単に説明します。



そのため、テストしているアプリケーションには、それらにアクセスするための次のリソースとメソッドのセットがあるとします。

 GET / #   GET foo/bar # GET    foo/bar POST bar/baz # POST    bar/baz
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SWATを使用してこの構成を記述するために必要なものはほとんどありません。SWATプロジェクトで採用されている契約を使用してください。つまり、リソースは単なるディレクトリであり、メソッドはファイルです。 実際には次のようになります。

 $ cd swat-project $ mkdir -p foo/bar $ mkdir -p bar/baz $ touch get.txt $ touch foo/bar/get.txt $ touch bar/baz/post.txt #    ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則が明確であることを願っています。 ディレクトリ名はhttpリソース名に対応し、ファイル名はhttpメソッド名に対応します。 メソッドファイル名に* .txt拡張子が含まれる理由は、後ほど明らかになりますが、今はこれに注意を払っていません。



おめでとうございます！ 実行可能な最小限のテストセットを作成しました（もちろん、要求を受け入れるWebサービスがあると仮定します）。

 $ cd swa-project $ swat ./ 127.0.0.1:3000 /home/vagrant/.swat/.cache/31999/prove/00.GET.t ........... ok 1 - GET 127.0.0.1:3000/ succeeded # response saved to /home/vagrant/.swat/.cache/31999/prove/KBoHRGrYRm 1..1 ok /home/vagrant/.swat/.cache/31999/prove/bar/baz/00.POST.t .. ok 1 - POST 127.0.0.1:3000/bar/baz succeeded # response saved to /home/vagrant/.swat/.cache/31999/prove/z5lXw_dCLa 1..1 ok /home/vagrant/.swat/.cache/31999/prove/foo/bar/00.GET.t ... ok 1 - GET 127.0.0.1:3000/foo/bar succeeded # response saved to /home/vagrant/.swat/.cache/31999/prove/_DnvkvcUBw 1..1 ok All tests successful. Files=3, Tests=3, 0 wallclock secs ( 0.04 usr 0.02 sys + 0.25 cusr 0.03 csys = 0.34 CPU) Result: PASS
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、SWATはファイル構造を正常に解析し、一連のhttp要求に変換して実行します。 この場合、デフォルトでは、サーバーからの応答は成功したhttpステータスの存在について検証され、サーバーからのエラーの場合、そのようなテストはパスしません。

 $ cd swat-project #   : $ mkdir unknown $ touch unknown/get.txt #   SWAT : $ swat ./ 127.0.0.1:3000 /home/vagrant/.swat/.cache/32379/prove/bar/baz/00.POST.t .. ok 1 - POST 127.0.0.1:3000/bar/baz succeeded # response saved to /home/vagrant/.swat/.cache/32379/prove/Um9VB1zVyS 1..1 ok /home/vagrant/.swat/.cache/32379/prove/unknown/00.GET.t ... not ok 1 - GET 127.0.0.1:3000/unknown succeeded # Failed test 'GET 127.0.0.1:3000/unknown succeeded' # at /usr/local/share/perl/5.20.2/swat.pm line 81. # curl -X GET -k --connect-timeout 20 -m 20 -L -f -i -o /home/vagrant/.swat/.cache/32379/prove/TJO6JpsClL --stderr /home/vagrant/.swat/.cache/32379/prove/TJO6JpsClL.stderr '127.0.0.1:3000/unknown' # % Total % Received % Xferd Average Speed Time Time Time Current # Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 404 Not Found # can't continue here due to unsuccessfull http status code 1..1 # Looks like you failed 1 test of 1. # Looks like your test exited with 1 just after 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests /home/vagrant/.swat/.cache/32379/prove/foo/bar/00.GET.t ... ok 1 - GET 127.0.0.1:3000/foo/bar succeeded # response saved to /home/vagrant/.swat/.cache/32379/prove/N0i8or4eCR 1..1 ok /home/vagrant/.swat/.cache/32379/prove/00.GET.t ........... ok 1 - GET 127.0.0.1:3000/ succeeded # response saved to /home/vagrant/.swat/.cache/32379/prove/eQpLp7zbAw 1..1 ok Test Summary Report ------------------- /home/vagrant/.swat/.cache/32379/prove/unknown/00.GET.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=4, Tests=4, 1 wallclock secs ( 0.03 usr 0.02 sys + 0.28 cusr 0.02 csys = 0.35 CPU) Result: FAIL
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、優れた点として、SWATは未知のリソースを正常に検証することにより、または単にサーバーから受信した応答のhttpステータスを分析することにより機能することがわかります。



SWATがどのようにリクエストを行うかについて、いくつかの言葉を言いたいです。 curlユーティリティーは、http要求を生成するために使用されます。 たとえば、Perlのライブラリなど、curlが選択されて使用されなかったのはなぜですか？ （例： LWP ）。 私見、カールの場合の重要な利点の1つは、使いやすさ、優れたドキュメント、サポートです（最近、重要ではないチケットを始めましたが、数分で答えられました）。 このユーティリティを使用している間、curl web socketsができない限り、curlコマンドラインインターフェースを介して実装できないタイプのhttp要求に出くわすことはほとんどありませんでした...



そのため、SWATはcurlを使用してhttp要求を作成します。 これは、このユーティリティに関して、リクエストに必要なすべてのパラメーターを記述することを意味します。 このために、いわゆるクエリ設定が使用されます-swat.iniファイル。リソースディレクトリ内でユーザーが作成し、curlを呼び出すためのパラメーターを含む、その動作を決定する各テストスクリプトの追加パラメーターを設定できます。 例を挙げます。

 $ cat bar/baz/swat.ini #     POST/GET  curl_params="-d name=Alexey -d age=39" $ cat foo/bar/swat.ini #  http  curl_params="-H 'Content-Type: application/json'" $ cat login/swat.ini #  http basic  curl_params="-ufoo-user:foo-password'" $ cat slow-route/swat.ini #  -         try_num=3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

swat.iniファイルで設定できるパラメーターのリストの詳細については、 ドキュメントを参照してください。



swat.iniファイルは通常のbashスクリプトであることに注意することが重要です。特に、標準のbashコンストラクトを使用できます。創造性の余地が多く、例をよく理解するために、SWATドキュメントのページに興味のある読者を送ります。



さて、すべては問題ありませんが、ご覧のとおり、サーバーからの応答を確認する前に一度も言ったことはありません。真実を除き、httpステータスのみです。 上記の一連のテストを実行することで理解できたこと、アプリケーションリソースの特定のセットが利用可能であり、これらのリソースを要求するときにサーバーが成功（200 OK）応答を返したことをすべて理解しました。



SWAT DSLについて話をする時が来ました。

SWAT DSL

SWAT DSLは、フレームワークの2番目の（リソースとクエリ設定を説明した後の）メインコンポーネントです。 DSLを使用すると、サーバーから受信した応答をチェックして、単一行ステートメントとして説明されているいくつかのルールに準拠しているかどうかを確認できます。

 RULE1 RULE2 #    ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステートメントに準拠していない場合、テストエラーが生成されます。 ステートメントごとに、答えが再度チェックされます。 これは、検証プロセスの正式な説明です。 実際、すべてがより単純であり、ステートメントは、サーバーの応答で表示したいテキストまたは正規表現の単なる普通の行です。



例を挙げます。

 #     #  ,   SWAT   , #        200 OK #      regexp: (red|green|blue) #      #   ,    ,     #    -    HELLO WORLD #   regexp: ^HELLO WORLD$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の例の後、次を追加します。

• SWATはDSLを直接提供しませんが、テキストデータの検証に既製のモジュールOutthentic-DSLを使用します。 SWAT DSLの機能をより深く理解するには、このモジュールのドキュメントを使用してください
• ルールまたは（この用語の同義語）検証ステートメントを記述するとき、コメントを使用できます
• DSLスクリプトを解析するとき、空白または空白行のみを含む行は無視されます
• SWATは行単位の検証モードを使用します。つまり、サーバーからの応答が行に分割され、各行が次のルールと比較されます。 少なくとも1行がルールに一致する場合、SWATはコンソールクライアントからの出力でレポートするため、このルールのテストは合格と見なされ、そうでない場合は合格とみなされません
• 複数行のチェックが必要な場合-SWATブロックを使用できます
• 正規表現の構文は、Perlの正規表現と一致する必要があります。 Perlで書かれたSWAT DSL
• 検証ルールは静的、つまり ここでの例のように事前に説明しますが、SWATは、 ジェネレータ APIを介してソフトウェアAPIを介して、このようなルールを動的に設定する機能を提供します
• この記事では、DSLのすべての機能とテストステートメントを記述するためのルールについて言及することはできません。これらは非常に多様で多数あるため、興味のある読者にはドキュメントページを参照してください。

検証ルールを作成するためのDSLがありますが、疑問は残ります。これらのルールをどこで作成するのでしょうか 答えはそれ自体を示唆しています-もちろん、httpメソッドファイルで！ （メソッドファイル名の* .txt拡張子に関するコメントを思い出してください）。



さまざまなリソースを要求するときのサーバーからの応答にいくつかのチェックを追加して、以前の例を書き換えるか、むしろ更新します。

 $ cat get.txt HELLO USER! THIS IS INDEX PAGE $ cat foo/bar/get.txt I AM FOO-BAR $ cat bar/baz/post.txt POST TO BAR-BAZ OK
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、テストを再度実行します。

 $ cd swat-project $ swat ./ 127.0.0.1:3000 /home/vagrant/.swat/.cache/1422/prove/foo/bar/00.GET.t ... ok 1 - GET 127.0.0.1:3000/foo/bar succeeded # response saved to /home/vagrant/.swat/.cache/1422/prove/CmDiEY28iD ok 2 - output match 'I AM FOO-BAR' 1..2 ok /home/vagrant/.swat/.cache/1422/prove/bar/baz/00.POST.t .. ok 1 - POST 127.0.0.1:3000/bar/baz succeeded # response saved to /home/vagrant/.swat/.cache/1422/prove/rX8oenyA0j ok 2 - output match 'POST TO BAR-BAZ OK' 1..2 ok /home/vagrant/.swat/.cache/1422/prove/00.GET.t ........... ok 1 - GET 127.0.0.1:3000/ succeeded # response saved to /home/vagrant/.swat/.cache/1422/prove/PxDCnlbOA5 ok 2 - output match 'HELLO USER! THIS IS INDEX PAGE' 1..2 ok All tests successful. Files=3, Tests=6, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.24 cusr 0.00 csys = 0.27 CPU) Result: PASS
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、SWATはその仕事を行い、サーバーからの応答を検証しました。 これは、完了できるSWAT DSLの最初の知人です。



この記事の終わりに、SWATのもう1つの興味深い機能を紹介したいと思います。これにより、最も単純なチェックだけでなく、本格的な機能テストも作成できます（最初にSWATには多くの機能があると言っていたことを思い出してください...）。 それでは、再利用可能なhttpリクエストについて話しましょう。

再利用可能なhttpリクエスト

多かれ少なかれ複雑なWebアプリケーションまたはサービスは、多くの個別のリソースまたはルートに分解されており、実際、これらのリソースに関して強く「接続」されています。 それは私が言いたいことです-あるリソースへのリクエストは、多くの場合、別のリソースへの予備的なリクエストを意味します。 つまり 個々のリソースに対する単一の独立したリクエストについてではなく、そのようなリクエストのチェーンについて話しています。 例は明らかです：

• 認証/承認を必要とするリソースへのアクセス
• データベース内のレコードの作成、古いレコードの事前削除が必要
• 条件付きクエリ-データベースからレコードを削除します（ある場合）

など...



明らかに、「1つのテスト-1つのリソース-1つの要求」というアプローチでは、このようなテストシナリオは実行不可能です。 1つのリソースにリクエストを行う前に、何らかの方法で、1つまたは場合によっては複数の他のリソースにリクエストを行う必要があります。 どうする？ そしてここで、SWAT モジュールが私たちの助けになります-再利用可能なhttpリクエスト。



一般的に、SWATモジュールは関数に非常に似ており、一度定義すると、必要に応じて何度でも呼び出すことができます。必要に応じて、モジュール入力に初期パラメーターを渡し、結果を処理します。SWATでは、 アップストリーム/ダウンストリーム履歴メカニズムを通じて実装されます。



したがって、SWATモジュールについて理解する必要があるもの：

• これらは、SWATプロジェクトで作成された他のすべてと同じhttpリソースです。唯一の違いは、SWATがモジュールを直接呼び出さない（httpリソースに関連する要求を実装する）ことです。
• 別のリソースは、SWAT HOOKs APIを介してSWATモジュールを呼び出すことができます
• 別のリソースでSWATモジュールを呼び出すことは、最初にSWATがモジュールリソースに対してhttp要求を作成し、応答を検証することを意味します（つまり、httpステータスのチェックからリソースに定義されたルールによる検証まで、このリソースに関連付けられたチェックチェーン全体を実行します）、そして、SWATモジュールが呼び出されたメインリソースに対してリクエストを行います。
• SWATのドキュメントページでは、ある種のSWATモジュールを呼び出すリソースはアップストリームストーリー（メインストーリー）と呼ばれ、呼び出されたSWATモジュール（ダウンストリームストーリー）はセカンダリストーリーです。 用語はjenkins-ci.orgから取られていますが、SWATではこのモデルは逆になっています。 Jenkinsでは、メインタスクの後にダウンストリームジョブが呼び出されます
• SWAT HOOKs API-Perlコード（このコンテキストではHOOKS API）を記述することでSWATテストスクリプトを拡張する機能により、SWATモジュールをプログラムで呼び出すことができます。

上記のすべてを簡単な例で説明しましょう。 2つのリソースへのアクセスを提供するWebサービスを用意しましょう。



POSTログイン/-ユーザー認証用のリソース。 有効なログインとパスワードがサーバーに送信されると、アプリケーションはCookieセッションを返します。 簡単にするために、サーバーはPOST要求の名前付きフィールド（ユーザーとパスワード）を介してユーザー名とパスワードを受け入れると想定しています。



GET制限付き/-認証されたユーザーのみが保護されたリソースにアクセスできます。



このようなアプリケーションのSWATテストを作成します。 ここでの明らかなテストストーリーは、安全なGET制限リソースを認証してアクセスすることです。



リソースとメソッドを記述したプロジェクトスケルトンを作成しましょう。

 $ mkdir swat-project $ cd swat-project $ mkdir login $ mkdir restricted $ touch login/post.txt $ touch restricted/get.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、ログイン/リソースがSWATモジュールであることを宣言する必要があります。 GET制限付き/リソースを呼び出す前に呼び出す必要があります。

このためにリソース設定ファイルを使用します-swat.iniファイル：

 $ cat login/swat.ini swat_module=1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

swat_module変数を1に設定すると、リソースがSWATモジュールとして宣言されます。



認証に必要なパラメーターを追加します。 この場合、例を簡単にするために、ログインとパスワードは明示的に設定されますが、SWATでは、この種のパラメーターをプロジェクトから削除し、セキュリティ上の理由から別の場所に設定することもできます。

 $ cat login/swat.ini swat_module=1 url_params="-d user=my-login -d password=my-password"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして最後に、最後の仕上げ-認証が成功した場合にサーバーがCookieを返します。どこかに保存する必要があります。同じcurlユーティリティーのcookie-jarメカニズムを使用します。リソースに対する要求の最終バージョンは次のようになります。

 $ cat login/swat.ini swat_module=1 # $test_root_dir -  ,    #      #        url_params="-d user=my-login -d password=my-password --cookie-jar $test_root_dir/cookie.txt"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OK、POSTログイン/準備完了リソース。 成功ステータス（200 OK）に加えて、サーバーが戻る必要があることがわかっている場合（そして;-)）、メソッドファイルに追加のチェックを追加できます。

 $ cat login/post.txt hello user!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GET制限付き/を呼び出す前にPOSTログイン/を呼び出します。これは次のように行われます。

 $ cat restricted/hook.pm run_swat_module( POST => '/login' );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちは何をしましたか？ GET制限/リソース用のフックファイルを作成し、 最初に POSTログイン/リクエストを行うことを要求しました



私たちは何を残しましたか？ GET制限付き呼び出し/を設定して、POSTログイン/経由の認証が成功した後に作成されるCookieを使用するようにします。

 $ cat restricted/swat.ini url_params="--cookie $test_root_dir/cookie.txt"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、POSTログイン/リソースと同様に、GET制限/リクエストの場合、サーバーからの応答に追加のチェックを設定できます。

 $ cat login/get.txt restricted content
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

再利用可能なSWATリクエストに関して他に簡単に言及したいことはありますか（残念ながら、この記事の形式ではすべての資料を完全に開示することはできません）。 私は論文をリストします：

• SWATモジュールのカスケード呼び出し-通常の機能と同様に、1つのモジュールが別のモジュールを呼び出すことができます。
• メインリソースとその中で呼び出されるSWATモジュール間のデータ（状態）の転送。 はい、可能です。 純粋に技術的には、モジュールとそれを呼び出したコードは1つのプロセスで実行されます。 ドキュメントを参照してください
• SWATモジュールの入力にパラメーターを渡し、モジュールを実装するコード内でそれらにアクセスします-これはモジュール変数と呼ばれます。ドキュメントを参照してください

おわりに

記事の最後に「 プロジェクトページに移動し、ユーティリティのインストール方法と使用方法を学びましょう...」という言い回しで終わらせたくはありませんが、悪くはありませんが:-)



しかし、ここであなたが仕事でSWATを使い始めることができる理由があります（私見）：

• Larry Woll -SWATを自由に言い換えさせてください。SWATを使用すると、シンプルなものをシンプルで複雑なものにすることができます。 サンプルで記述しなければならないコードが非常に少ないことに注目してください。同時に、SWATはPerlに拡張できる強力なツールです。 基本的なプログラミングスキルを備えたシステム管理者であれ、経験豊富な開発者であれ、SWATは同様に便利で理解しやすいものです。
• SWATは最大限に実用的です。 特定の問題、つまり頻繁に更新される多数のアプリケーションの自動テストの迅速な開発を解決するために、生活の現実に基づいて発明されました。 SWATから不要な機能をすべて削除しました。問題を解決するために最大限に強化されており、「負荷」に対しては何も提供しません。
• SWATは、広く使用され実績のあるソリューションに基づいて構築されており、システム管理者と開発者の両方に知られています。つまり、curlとbashです。 curlを知っているなら、すでにSWAT構文に慣れているので、swatはswat.iniファイルの設定を直接curlに変換します（まあ、またはほぼそのようです;-)）。bashの基本を知っていれば、SWAT設定を簡単に説明できます。資源の
• SWATは衛星プロジェクトSparrowによってサポートされています。つまり、SWATプロジェクトを管理および開発するための便利なインフラストラクチャと、SWATによって作成されたテストを再利用し、中央のSparrowHubリポジトリからダウンロードして、同じリポジトリにアップロードすることができます。詳細については、こちらとこちらをご覧ください。

コメントや質問を待っています。



ありがとう



PSこの記事で言及したWebアプリケーションおよびSWATテストのソースは、ここからダウンロードできます。



今後のPPSすべて！