デブサミ出張 Shibuya イベントの補足

デブサミ発表資料中に、テストプラグインがどういうコードなのかを書いていたのですが、時間がなくてまったく説明できなかったので、ここで補足しておきます。

テストプラグインのコードはこの様になっています。

package Assurer::Plugin::Test::SMTP;

use strict;
use warnings;
use base qw( Assurer::Plugin::Test ); #(A)
use Assurer::Test; #(B)
use Net::SMTP;

sub register {
    my $self = shift;
    $self->register_tests( qw/ connect / );          #(C)
}

sub connect {
    my ( $self, $context, $args ) = @_;

    my $conf = $self->conf;

    my $host     = $conf->{host}     || $context->conf->{host};
    my $timeout  = $conf->{timeout}  || 10;

    my $smtp = Net::SMTP->new(Host => $host, Timeout => $timeout);
    ok($smtp, "smtp ok $host"); #(D)
}

1;

青字の部分が、プラグインを書く際のお約束というかポイントとなる部分なので、順に説明していきます。

(A) では Assurer::Plugin::Test を継承しているわけですが、テストプラグイン共通の処理はすべて Assurer::Plugin::Test に記述することにより、各プラグインでのコード量を減らそうという目論見になってます。

(B) で Assurer::Test を use することより、ok(), is(), like() といったテスト用メソッドをインポートしています。

$self->register_tests( qw/ test1 test2 test3 / );

といった記述をします。この場合、test1(), test2(), test3() の順で実行されます。

(D) が実際にテストを行っているところで、Test::More の ok() と同じ動作をします。この ok() は上で書いたように、Assurer::Test からインポートしたメソッドです。このような組み込みのテストメソッドを使うことで、if 文で結果を判断して適切なステータスを返す、といった処理を書く必要がなくなります。

kazeburo さんの発表にある、Nagios プラグインと対比してみると、Nagios は exit 時のステータスコードだけ気にすればいい、というのに対して、Assurer では、上のコード (A), (B), (C) の様に、Assurer 特有のお約束を守る必要があるものの、exit コードは気にしなくていい、といった特徴があります。また、お約束を守ることによってコード量も減らせます。（特に結果判定で if を書かなくていい。）

Nagios の場合、ステータスコードだけ気にすればいい、とは言っても、ステータスが OK, Warning, Crtitical, Unknown とあるわけで、OK はまだしも、どういった場合が Warning でどういった場合が Critical なのか、ということを気にするのは、ちょっと面倒な気もします。

また、結果を受け取る側も、Warning とか Unknown とか受け取ると、それって問題あるの？ないの？って迷ったりしないのかな、とか、Warning と Critical の解釈って、人によって違うんじゃないかな、って思ったりします。（Nagios使ったことないんで、変なこと言ってるかもしれませんが。）

そういった曖昧さをなくしたくて、Assurer では OK か NOT OK かの2種類の結果しか返さない、というポリシーにしました。

とは言っても、Nagios の様にステータスが何種類かある方が便利だという場面はあるんでしょうね。その辺りは Assurer では、エラーメッセージでフィルタリングできるようにして、「こういったエラーメッセージの場合は、問題ないから OK にする」といった設定ができるような形にして、結果の解釈を利用者に委ねられるようにしようと考えています。

↑ newer post older post ↓